메뉴
Design phase for {PROJECT} — data model, module boundaries, API contract, access control, and any multi-tenancy/security design, before code is written. Called by project-orchestrator before implementation; also used directly when the user says "design {PROJECT}'s X module."
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Log a vault change (note created/edited/deleted) to a running daily changelog note. After any write to the vault, ask the user "should this be logged?" and run this skill on confirmation. Also runs directly when the user says /changelog.
Update a project's README and the relevant vault notes (overview / module map) after a meaningful code change — new feature, new file, new module, or an architectural decision. Should trigger on its own once a coding task is finished, without the user having to ask — skip it for trivial (typo/formatting) changes. Also runs manually when the user says "update the docs" or "document this."
Update "where we left off" tracking for {PROJECT} when a milestone or unit of work closes. Updates Status.md (active milestone + next concrete action) and Milestone_Log.md (chronological record); touches Goal.md/Decisions.md if needed. Called by project-orchestrator at the end of every milestone; also used directly when the user says "log this milestone" or "update status."
Implementation phase for {PROJECT} — builds the actual code for a module or vertical slice against an existing design. Called by project-orchestrator once a design exists; also used directly when the user says "implement {PROJECT}'s X module."
Main orchestrator for building {PROJECT}. Tracks cross-session continuity, reads "where we left off," routes to the correct phase sub-skill, and runs autonomously. Use when the user says "continue {PROJECT}," "work on {PROJECT}," "{PROJECT} where did we leave off," or /project-orchestrator. This is for the BUILD side of {PROJECT} — not for unrelated day-to-day tasks about it.
Research and data-gathering phase for {PROJECT} — domain knowledge, reference data models, external API details, and a gap analysis against what already exists. Called by project-orchestrator when a module/topic's knowledge is missing; also used directly when the user says "research {PROJECT}'s X module."
| name | project-design |
| description | Design phase for {PROJECT} — data model, module boundaries, API contract, access control, and any multi-tenancy/security design, before code is written. Called by project-orchestrator before implementation; also used directly when the user says "design {PROJECT}'s X module." |
Produces the design artifacts that project-implement will build against, and records any durable architectural decision.
Any decision that would be expensive to silently reverse later (a schema choice, a boundary, a naming convention applied project-wide) goes into Decisions.md (see project-orchestrator) as a short ADR: context, decision, why, alternatives considered. Anything already locked there is a constraint on this design, not a fresh choice — flag it as the "genuinely critical decision" stop condition in the orchestrator if a real conflict comes up.
A design note under the module's vault folder, structured so project-implement can build directly from it without re-deriving decisions that were already made here.
