메뉴
Use when creating or revising a decision-ready specification from a request. Covers requirements discovery, settlement, acceptance criteria, and readiness; do not use for implementation planning, source changes, or reports.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | specification-authoring |
| description | Use when creating or revising a decision-ready specification from a request. Covers requirements discovery, settlement, acceptance criteria, and readiness; do not use for implementation planning, source changes, or reports. |
Create or revise one decision-ready specification. This Skill owns the correctness of what is to be built: alignment with the user's goal, coherent scope and constraints, verifiable acceptance criteria, and resolution of material open decisions. It does not own implementation approaches, task breakdowns, implementation, delegation, reports, or physical storage behavior.
Start from the user's request and any governing artifacts they identify. Treat the user's goal as fixed input. At the start of discovery, treat user-provided solutions, requirements, and constraints as drafts that may be challenged until the user confirms them.
Use available repository and external evidence to resolve discoverable facts.
Delegate question-cost decisions, bounded choices, provisional judgments, and
question-count control to liminal-lens; do not reproduce those mechanics here.
After a challenge, treat points the user confirms as settled. Treat every point in an approved specification as settled. Do not reopen settled points later in the same workflow.
liminal-lens for any material decision that remains after
investigation. Stop asking questions once further answers cannot change
scope, acceptance criteria, or implementation approach.Assign stable sequential IDs such as AC1 and AC2 to acceptance criteria.
Treat IDs as append-only across revisions: never renumber an existing ID and
never reuse a gap. Keep a withdrawn criterion in place and mark it withdrawn
instead of deleting it.
AC IDs are logical references between specification, plan, task completion criteria, and reports. Keep them in the artifact layer; do not embed them in code, comments, or test names. Record test-to-AC mappings in a plan or report.
The specification must include:
Status: decision-ready or Status: not decision-ready;Use Status: decision-ready only when planning can proceed without inventing
scope, interfaces, constraints, or acceptance criteria. Otherwise use
Status: not decision-ready and identify the blocking questions.
The runtime artifact-writer contract alone owns candidate approval and persistence. Follow that contract for those operations without reproducing its storage or approval procedure in this Skill.
Return:
Spec file: <artifact path | none>Status: <decision-ready | not decision-ready>Summary: <concise summary>Blocking questions: <none | concise list>Non-blocking questions/defaults/deferrals: <none | concise list>Report an artifact path only when approval and persistence completed; otherwise
use Spec file: none. Never fabricate a path or repeat the full artifact body
in this completion output.
Use when creating or revising an implementation-ready plan from a governing specification, artifact, or approved request. Covers approach selection, coverage, verification, and conditional task breakdown; do not use for specification authoring, source changes, or reports.
Use when a task has underspecified requirements, unresolved design directions, durable concept naming, vague option comparisons, workflow/prompt/skill design, or dissatisfaction without a settled desired change. Investigate the task normally, preserve settled decisions, state reversible assumptions visibly, and surface costly open decisions as bounded choices. Do not use for simple factual questions, fixed-format assignments, debugging with an obvious next step, or direct execution/final-artifact requests whose relevant decisions are already settled.
Use when creating durable agent artifacts: specifications, implementation plans, research notes, implementation reports, review reports, bug reports, or failure reports. Trigger when an agentic workflow needs a persisted contract, reusable evidence, or handoff record. Do not use for inline review comments, commit messages, transient scratch notes, or ordinary status updates that do not need a durable Markdown artifact.
Use when a primary agent must coordinate an approval-gated specification, planning, or implementation workflow through delegated capabilities. Trigger for staged workflows that select spec-only, plan-only, spec-then-plan, plan-then-implement, or implement profiles. Do not use for direct specialist work that has no staged user dialogue or approval boundary.
Use when planning or implementing a large request with multiple responsibilities, building an entire software or configuration system from scratch, or rebuilding one step by step. Trigger when the user asks for a complete feature set or environment whose parts must be introduced and verified incrementally without losing the final scope. Do not use for a small local change that clearly follows existing structure, or by itself for ordinary architecture, refactoring, testing, prompt-design, or approval-workflow tasks.
Use when UI accessibility or usability must shape specification planning, implementation planning, implementation, code/design review, or behavior-preserving refactoring. Trigger on work involving WCAG, semantic HTML, ARIA, keyboard operation, focus management, screen-reader support, forms, errors, contrast, reflow, status messages, or UX heuristics. Do not use for purely visual taste changes, legal compliance advice, framework-specific accessibility manuals, generic skill-authoring, or non-UI work unless accessibility/UX behavior is part of the task contract.