菜单
Use when building a self-contained shippable artifact from scratch or a major rev — an MCP server, a CLI, a library/SDK, a skills pack, a plugin — anything that gets packaged and released rather than merged into an existing app.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when orchestrating multi-agent or long-running work — spawning sub-agents, fanning out parallel tasks, delegating subtasks, running build-then-review loops, or deciding which model tier should do a piece of work.
Use when maintaining project state across sessions — writing or reading a STATE.md / MEMORY.md, recording what was learned, resuming interrupted work, or deciding what to persist for future sessions.
Use when building or redesigning a product UI/visual system — creating a design system, writing or following a DESIGN.md contract, generating screens in a design tool (Stitch/Figma) then porting to code, or doing a branded visual redesign.
Use during hands-on execution of any coding or agent task — especially when following multi-item instructions, deciding how much to deliberate, about to claim something is done, or producing output at risk of reading as generic AI slop.
Use when building or running an automated measurement/audit/reporting pipeline that scores many subjects on a recurring basis and reports to stakeholders — a compliance monitor, a benchmark matrix, a metrics dashboard, a scheduled scan-and-report.
Use when planning, building, or reviewing a software milestone/release/version — any task framed as "ship vX", "build the next milestone", "plan and execute a feature set", "do a research + build pass", or "review what we shipped".
| name | artifact-build |
| description | Use when building a self-contained shippable artifact from scratch or a major rev — an MCP server, a CLI, a library/SDK, a skills pack, a plugin — anything that gets packaged and released rather than merged into an existing app. |
For shipping a thing — a server, CLI, library, plugin, or skills pack — as
opposed to a feature inside an existing app (that's milestone-workflow). The
spine is the same one that produced clean, releasable artifacts: spec → plan →
modular TDD build → review → live validation → package.
Read the repo's CLAUDE.md first for the verify commands, package manager, and
conventions. Use those.
node --check / tsc / whatever the repo uses).A standalone review commit that does nothing but fix review findings — guarded
error paths (don't throw opaque ENOENT on a missing input — name the bad path),
dead-code removal, and honest summaries (report succeeded/total, never claim
all N succeeded when some failed). Reviewer should be a fresh perspective, not the
author's own pass.
Run the artifact against the real thing — the live API, the real client, the actual eval set — not just unit mocks. Expect the spec's assumptions to be wrong and fix what reality exposes (e.g. "the API only accepts jpeg mime", "the eval baseline is too easy"). This phase routinely overturns Phase-A assumptions; that's the point. For a skills/eval artifact, this is the eval-as-failing-test gate: RED (no skill → record what it gets wrong) → GREEN (skill makes evals pass); a too-easy baseline means the eval is too weak.
README (real quick-start + config table + the full surface), LICENSE,
.env.example, package metadata (files, keywords, repo/homepage/bugs,
engines), a capability matrix where there are tiers/variants, forward-compat
env-overrides for anything a vendor rotates, CI matrix, issue/contributor
templates, and any showcase assets (mark one-off generators "not part of the
published package"). Scrub competitor attribution from internal design docs
before going public.
Atomic commits; verify after each step; never push after a failed run until a clean rerun; keep generated artifacts (indexes, manifests) regenerated, not hand-edited; honesty in every summary and capability claim.
See PROVENANCE.md for sources.