원클릭으로
archive
Use at ship time to merge the spec into the living documentation, delete the staging spec and plan, and ask how to finish.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use at ship time to merge the spec into the living documentation, delete the staging spec and plan, and ask how to finish.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when taking over an existing codebase that has no living document. Produces a factual record of what already exists.
Use when all plan tasks are done and green to review, archive planning artifacts, and ask how to finish.
Use for standard or complex new work before coding or planning. Also handles vague goals — clarifies before designing.
Use at session start to learn how Praxis skills are invoked and why triage runs before every task.
Use when the goal is vague or vision-level and can't be defined well enough for design questions.
Use after design approval for milestone plans with executable acceptance.
| name | archive |
| description | Use at ship time to merge the spec into the living documentation, delete the staging spec and plan, and ask how to finish. |
Always in sync with code. Facts only — no plans, no interpretation.
README.md — users: what it is, who for, how to use; links to tech-specdocs/tech-spec.md — developers/agents: current system state (see format below)docs/specs/*.md — split-out details when tech-spec grows too large; referenced by pathdocs/ROADMAP.md — direction (exists when ≥3 milestones or long-term)Project artifacts — not merged into living docs:
CHANGELOG.md — version history (ship maintains)docs/decisions/ — architectural decisions, append-onlyDeclarations only.
purpose: <what problem this solves — one sentence>
user: <who uses this>
use-case: <key scenarios, one line each>
architecture: <structural shape — one line, or see docs/architecture.md>
stack: <language, runtime, frameworks, key deps>
entry: <where execution starts>
contract: <public APIs / interfaces that must not break>
flow: <name>: <trigger> → <steps> → <output>
(complex — branching/async/multi-actor: one-line summary here, diagram in docs/specs/<flow>.md)
invariant: <what must always hold>
constraint: <limits, warnings from code>
convention: <naming, file structure, test patterns>
milestone: <current milestone> (see docs/ROADMAP.md)
<gate>Before proceeding: (1) verify tdd/subagents have completed all tasks listed in the plan; (2) confirm the user has provided explicit written approval.</gate>
Merge staging spec (minus roadmap) into living doc. Not copy-paste — integrate, preserve existing structure.
Roadmap (if spec contains ## Roadmap): do not re-copy — roadmap updates independently.
Decisions (if spec or working notes contain a knowledge artifact — protocol spec, RE findings, architectural rationale): save to docs/decisions/YYYY-MM-DD-<topic>.md as context / choice / ruled-out.
<gate> confirm the merged content with the user before deleting staging spec and plan. </gate>
docs/staging/specs/YYYY-MM-DD-<topic>.md — content absorbed; Git has the history.docs/staging/plans/YYYY-MM-DD-<topic>.md — plans don't belong on main.