Agent Skills

---

name: competitor-intelligence

description: Watch named companies for material news; cited digests.

---

name: design-review

description: Five-dimension design audit (frontend UI/UX · server data-model & flow · endpoint spec · daemon-runtime/SDK & local-cache-first · built-in skill/agent-role), executed by a NON-implementing agent. Every dimension gets a verdict; N/A only with a stated reason. A dimension the design silently skipped must be surfaced as a gap; covered dimensions must not be over-reported.

---

name: doc-sync

description: Before merge, mechanize Documentation-First — derive the code delta from git diff, then verify required docs are in sync (CHANGELOG, docs/api, CLAUDE.md/ROADMAP). Any SDK-package change must carry a matching CHANGELOG entry + aligned version files. A change that skipped a required doc is flagged as a gap; a fully-synced change passes.

---

name: env-doctor

description: Diagnose the local dev machine before any APC loop step — run apc env doctor, classify each failure into a fault domain, apc env up to auto-fix what is safe, then fingerprint. Keeps env faults out of SUT verdicts.

---

name: git-ops

description: Close out a local coding task on the bound daemon — stage, commit, branch, merge, push via cloud git — and when a merge conflicts, STOP and escalate with the file list instead of auto-resolving. Push reaches only the bare replica; prod-triggering tags are refused.

---

name: impact-trace

description: For a change point (function / type / endpoint / SQL column), enumerate its real blast radius across six dimensions with a grep citation per row, then derive the regression test scope. Every impact-table row must trace to a real search hit — never a self-asserted claim.

---

name: observability

description: Periodic health sweep of the running system via the debug pipeline (cloud logs / k8s / daemon / DB slices). On a real anomaly, open a bug task (--kind work_item) carrying the evidence refs so it re-enters the bugfix loop. A healthy sweep opens NO task — never fabricate a bug.

---

name: release-db-config-sync

description: Compute the remote DB migration + Nacos config diff before a test release — apc release db-config-sync really spawns sync-test-migrations.ts --dry-run (never a stub) and diffs Nacos key dumps, stopping at the write boundary. green(0) no diff · staged(3) pending migrations/missing keys await approval · blocked(1) real script failed. Diff only, never writes the remote.

---

name: release-ota-promote

description: Publish signed Electron UI/daemon bundles to a local OTA feed with atomic manifest switch and digest readback, while dry-running the K8s drain_respawn rollout. Prod is refused before writes; feed publication is not client apply.

---

name: release-preflight

description: Run the release hard-precondition gate before any tag/OTA — apc release preflight runs the real tier gate (run.ts), version alignment, and prisma regen check, all read-only. green(0) releasable · staged(3) fixable preconditions · blocked(1) tier red/env_blocked. No push, no write.

---

name: release-rollback

description: Roll a release back for real when post-deploy regression goes red — apc release rollback flips the current version to pulled and the last good version back to current in the release ledger, and (with --mirror) repoints the bare mirror ref. Behind an approval gate; with no previous good version it BLOCKS instead of spinning green. green(0) applied · staged(3) plan awaiting approval · blocked(1) nothing to roll back to.

---

name: release-tag

description: Cut a release tag behind a real tier gate and cloud approval readback. The approval, task, approved commit, and resulting tag are bound; self-approval and HEAD drift fail closed. Prod prefixes remain refused.

---

name: releasing-prod

description: Use when 把已验证内容发到 Prismer 生产（prod.docbrew.cn / prismer.cloud / APP_ENV=prod），或听到「发生产 / 上 prod / 发版上线 / 打 ali-k8s-prod tag」。涉及 main 部署、prod 迁移、manual deploy 审批点时必读。

---

name: releasing-test

description: Use when 把任何批次的改动发到 Prismer 测试环境（test.docbrew.cn / APP_ENV=test），或听到「发测试 / 发 test / 上测试环境 / deploy test / 打 ali-k8s-test tag」。涉及 develop 部署、test 迁移通道、runner 节流时必读。

---

name: sdk-release

description: SDK build, test, version bump, and release to open source repo + registries. Covers the full pipeline from development in prismer-cloud-next to publishing on npm/PyPI/crates.io/Go.

---

name: spec-intake

description: Turn one atomic feature/gap request into a dispatchable task in a single pass — create the task, write SPEC.md (auto-folded into linkedAssetIds server-side), add acceptance criteria, record provenance. Two-part epics are refused, not silently split.

---

name: test-result-feedback

description: Close the acceptance loop for a tested change — consume the apc test TierResult, map EACH acceptance criterion to a pass/fail outcome from structured fields (never chat text), attach an evidence ref, and write it back to the task. A SUT red is a finding, never softened to green.

---

name: test-runner

description: For a code change, pick the right test tier by change surface, run apc test with baseline diff, and report only NEW reds vs baseline back to the task's acceptance criterion. Separates env_blocked from SUT red so a broken machine never fails the code.

---

name: ui-align

description: Visual-alignment workflow for a new UI need or a UI改进. Index-first (consult the ui-kit registry to avoid re-building an existing primitive), then implement, then run the screenshot harness to capture the component in light/dark against the live /ui-kit, then produce a ReportCard (screenshot assets side by side + a written conclusion) the requester reviews VISUALLY without reading code. The harness computes NO image diff — it verifies side effects (screenshots really have pixels, assets uploaded, ReportCard persisted); both "the visual looks good" and any deviation number are human judgments the machine never produces.

---

name: ui-canvas

description: Use when a product journey, production component path, UI/UX operation sequence, visual regression, or alignment review must be represented or audited in /ui-canvas with implementation-spec references, immutable versions, task-bound screenshots, and a persisted ReportCard.

---

name: design-first

description: Guides the creation of technical design documents before writing code, producing architecture diagrams, data models, API interface definitions, implementation plans, and multi-option trade-off analyses. Use when the user asks to plan a feature, architect a system, design an API, explore implementation approaches, or requests a technical design or spec before coding — especially for complex features involving multiple components, ambiguous requirements, or significant architectural changes.

---

name: find-skills

description: Discovers, searches, and installs skills from multiple AI agent skill marketplaces (400K+ skills) using the SkillKit CLI. Supports browsing official partner collections (Anthropic, Vercel, Supabase, Stripe, and more) and community repositories, searching by domain or technology, and installing specific skills from GitHub. Use when the user wants to find, browse, or install new agent skills, plugins, extensions, or add-ons; asks 'is there a skill for X' or 'find a skill for X'; wants to explore a skill store or marketplace; needs to extend agent capabilities in areas like React, testing, DevOps, security, or APIs; or says 'browse skills', 'search skill marketplace', 'install a skill', or 'what skills are available'.

---

name: handoff-protocols

description: Manages work transitions between team members or agents by creating structured handoff documents, summarizing project status, documenting key decisions, blockers, and open questions, and generating onboarding briefs. Use when someone needs to hand off, hand over, or transition a project; pass work to another person or agent; brief a colleague taking over; prepare a shift change summary; or onboard someone mid-task. Produces ready-to-use handoff documents covering current status, next steps, known issues, technical context, and communication templates for both planned and unplanned transfers.

---

name: hypothesis-testing

description: Applies the scientific method to debugging by helping users form specific, testable hypotheses, design targeted experiments, and systematically confirm or reject theories to find root causes. Use when a user says their code isn't working, they're getting an error, something broke, they want to troubleshoot a bug, or they're trying to figure out what's causing an issue. Concrete actions include isolating failing components, forming and testing hypotheses, analyzing error messages, tracing execution paths, and interpreting test results to narrow down root causes.