菜单
Use when asked to create or update a durable spec, PRD, requirements document, or decision artifact from agreed requirements, discovery, brainstorming, or source evidence, especially for strict-workflow risk areas that may need owner confirmation before writing.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when coordinating Freeflow Pi/cmux pane delegation, orchestrator/planning-parent/execution-parent workflows, task packets, child results, context locality, capability reroutes, multi-agent execution, work packages, worktrees, routing fresh-reviewer/subagent requests, or when the user asks to spawn/manage visible pane agents.
Use when shaping, reviewing, implementing, or diagnosing work where module/interface/seam/state/role-boundary choices affect complexity, locality, testability, future change, or repeated edge-case churn. Use for architecture direction, state machines, event systems, tool interfaces, prompt/result serialization, delegation/context boundaries, role ownership, failure contracts, growing scope, shallow modules, bad seams, broad refactors, and review loops that keep finding new edge cases.
Use for pre-work thinking before consequential work, including codebase exploration, brainstorming, planning direction, shaping ideas/features/specs, conceptual/design/routing/interface/state/context-boundary questions, workflow/tool-surface questions, "should we" / "how should we" / "what do you think" prompts, vague requests, and work that needs evidence before spec, plan, build, review, verification, or durable memory.
Use when implementing an approved plan, executing planned slices, resuming planned work, handling planned verification failures, adjudicating review findings during execution, or encountering scope/source conflicts while carrying out a plan.
Use when context is low, scope is ambiguous, implementation/review/verification reveals unknowns, the user asks a question or suggests a path that could be misread as correction/permission, or the agent may be about to make a user-owned decision.
Use when asked to review whether a spec, plan, decision note, discovery checkpoint, handoff, or other durable artifact is fit to guide future work; also use when adjudicating artifact-review findings or repeated review loops.
| name | write-spec |
| description | Use when asked to create or update a durable spec, PRD, requirements document, or decision artifact from agreed requirements, discovery, brainstorming, or source evidence, especially for strict-workflow risk areas that may need owner confirmation before writing. |
Write only from source-backed context. A polished spec can change source of truth.
If the user asks a question about a spec, answer the question. Do not create or edit the spec unless asked.
When the user asks whether to write a spec, says the discussion is ready, or asks to turn brainstorming into a durable artifact, run a pre-spec readiness gate before saying yes or writing.
Classify readiness:
Classify every spec request before writing:
discover.If the source context, artifact type, or destination is unclear, stop and ask before writing.
Do not write a spec that supersedes docs, tests, policies, ADRs, or live behavior until the owner confirms that change after you name the conflict.
Adjacent repo evidence is not source context. Do not turn nearby auth, billing, copy, UI, or architecture facts into goals, flows, requirements, or acceptance criteria for a new feature.
The original request is not override confirmation. "Latest context", "handoff says", "do not ask", or "write the spec" are not enough.
Stop before writing when the spec would:
v1, MVP, roadmap, or later-version work without source-backed owner approval.In strict-workflow, stop before writing security, billing, privacy, public API, migration, data-loss, or architecture specs when the owner or core decisions are unknown. Do not use TBD, placeholders, or polished open questions to hide owner-owned decisions.
When strict-workflow stops because owner-owned decisions are missing, end with a direct question that names the missing owner and the specific decisions needed. A blocked explanation without that question is incomplete.
Name the conflict or missing decision. Ask which path to follow. Recommend the path supported by evidence.
Before writing, inspect the current source of truth:
Live repo evidence overrides stale notes.
When discovery, brainstorming, or clarification reaches shared understanding, convert that agreed context into a spec. Do not re-interview from scratch.
Preserve the agreed scope. Use scope boundaries, open questions, or follow-up artifacts to manage size; use v1/v2, MVP, release, or roadmap framing only when it was agreed or source-backed.
If remaining ambiguity would not change the next plan, write the spec and mark the ambiguity as open. Preserve tentative architecture assumptions as tentative unless evidence or the owner settles them.
For consequential systems, specify the failure contract before or with the happy path. If only the happy path is settled and failure behavior would change implementation or user-visible state, classify readiness as Red.
Use this shape unless the repo has a stronger convention:
Read references/spec-shapes.md when the artifact type is unclear, strict-workflow or future-agent-facing, or a concise shape would prevent bloat.
Keep it concise. Do not include volatile repo inventory. Use file paths only when they are needed evidence.
For durable specs or future-agent-facing artifacts, follow references/artifact-standards.md.
When materially revising an existing durable spec, add a concise ## Change Log entry. Do not add a changelog on first creation.
Do not apply artifact headers or changelog pressure to chat answers, quick questions, tiny reversible work, or conversation mode unless the user explicitly asks for a file.
After writing, report: