메뉴
Use when setting up a project's structure, or when the agent needs the stack, folder layout, data flow, schemas, and the hard boundary rules it must never cross. Use when code keeps crossing layers (UI logic in API routes, DB calls in components).
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when planning what to build and in what order — splitting a project into sequenced, scoped feature phases so the agent never has to decide "what's next" on its own. Use when work feels like random feature-hopping.
Use when establishing or enforcing how code is written in a project — naming, conventions, file structure, error handling — so the agent stays consistent across sessions instead of drifting into its own style by week two.
Use when a project depends on third-party libraries and the agent needs project-specific usage rules — and must check for an MCP server or current docs — before coding against a library it only half-remembers.
Use when tracking build progress across sessions — a living checklist updated as features complete, so a new session knows exactly where work left off without re-explaining.
Use when starting a new project, or when the agent lacks a clear picture of what's being built, who it's for, and what is explicitly out of scope. Use when a build keeps producing things nobody asked for.
Use when tracking which UI components exist and their exact classes, so the agent reuses components instead of rebuilding divergent ones. The living index maintained alongside the imprint skill.
| name | architecture |
| description | Use when setting up a project's structure, or when the agent needs the stack, folder layout, data flow, schemas, and the hard boundary rules it must never cross. Use when code keeps crossing layers (UI logic in API routes, DB calls in components). |
Once the agent knows WHAT to build (project-overview), it needs to know HOW it's built. This file is the system's shape plus the boundary rules the agent may never violate — the contract review checks against.
Lives at context/architecture.md.
Add a rule the moment you catch a boundary violation you don't want repeated. The rules are the highest-value part — they're what keeps a codebase coherent at scale.
review can verify it.