菜单
Translate the PRD into a spec slice for this repo. Reads the PRD from the meta PRD PR branch or merged develop, extracts capabilities relevant to this repo, and drafts docs/specification/product/INIT-*.md. Use after engineering opens the spec PR and before /initiative-feasibility.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | spec-draft |
| description | Translate the PRD into a spec slice for this repo. Reads the PRD from the meta PRD PR branch or merged develop, extracts capabilities relevant to this repo, and drafts docs/specification/product/INIT-*.md. Use after engineering opens the spec PR and before /initiative-feasibility. |
| disable-model-invocation | true |
| paths | AGENTS.md, docs/specification/**, .cursor/rules/** |
| background_eligible | true |
| background_trigger | spec PR opened in this repo (chore/INIT-*-spec-*) |
Translate the PRD into a spec slice for this repo. The spec slice is the engineering team's interpretation of what the PRD means for their codebase.
Do not implement. Produce docs/specification/product/INIT-{id}.md only.
PM writes PRD in feature language. Engineers own the spec.
This skill bridges the gap — it reads the PRD and drafts structured spec FRs
that the dev team can review, edit, and then run /initiative-feasibility on.
chore/INIT-{COMPONENT}-{NUMBER}-spec-{repo}Resolve paths from .harness/profile.yaml or references/layout-defaults.md.
<client>-meta/prd/INIT-*.md. Read from the meta
PRD PR branch or merged develop. Do not assume PRD is on develop if PR is
still open — use PR branch when iterating in parallel./prd-impact-map confirming
this repo's scope.implementation-status.md (REQUIRED) — understand what
already exists before writing FRs.source_roots from profile — understand current module structure.docs/specification/product/00-service-profile.md if
it exists — understand the repo's existing domain.adr_dir — existing ADRs constrain what this spec can propose..harness/profile.yaml or references/layout-defaults.mdDraft saved to {product_spec_dir}/INIT-{id}.md (from profile).
Use references/output-template.md.
After dev reviews and edits the spec draft:
git add docs/specification/product/INIT-{id}.md
git commit -m "feat: spec slice for INIT-{id}"
/initiative-feasibility ← run this on the committed spec
After the dev team has written their spec slice from the PRD, review it against the current codebase — baseline, gaps, impact, test harness, architecture governance (ADR + MDC), risks, and 4-lane triage. Use when the dev has drafted the spec and wants to check buildability before technical review and planning. Runs while the spec PR is open.
Before implementing one wave slice, produce a pre-flight checklist: verify the prior wave's human gate is satisfied, confirm contracts consumed from prior Ground Reports match what was actually built, then read specs/ADRs/rules. Use when starting implementation, opening a branch, or asked what to read before coding.
After feasibility (and technical review when applicable), produce a wave-level implementation plan with REQ/TASK/FILE/TEST tables and a WorkManifest YAML seed section (§9). Runs while the spec PR is open, before spec merge. Board seeding (gh issue create) happens after spec PR merge — not before.
After feasibility, produce a principal-engineer design document: resolve all engineering decisions (ADRs, interface contracts, test policy, module boundaries), draft any required ADRs, and route only true product questions back to PM on the meta PRD PR. Use before /spec-implementation-plan when the feasibility report contains NEW-ADR findings, Critical/Should-fix engineering items, or unclear module boundaries. TDD commits on the spec PR branch; PE gives GitHub Approve on the same spec PR.
Map a PRD to affected repos using the service catalog. Reads the PRD and config/service-catalog.yaml from <client>-meta, matches PRD capabilities to service descriptions, and posts an impact map as a PR comment on the meta PRD PR for tech lead confirmation. Run in <client>-meta Cursor session after PRD is validated and before engineering opens spec PRs in app repos.
Propagates corrections, new information, terminology changes, and scope changes across multiple related documents. Structures changes, verifies with user, performs impact analysis, presents a change manifest for approval, applies edits preserving each document's format and tone, and runs document-audit as a final consistency check. Use when a fact, assumption, or decision changes and multiple documents need updating, or when new information (e.g., from a design review, stakeholder feedback, or discovery session) must be reflected across a document set.