메뉴
Use when scanning a codebase for shallow modules, unclear interfaces, weak seams, poor adapters, poor locality, low leverage, or weak test surfaces
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when starting a new project from scratch or establishing project operating contracts, root CONTEXT.md, stack decisions, architecture summary, domain language, and a high-level roadmap before feature brainstorming
Use when executing implementation plans with mostly independent tasks in a fresh or same session after written plan approval
Use when an approved local design spec exists and an exact implementation plan is needed before code changes
Use when starting a conversation to route new-project setup requests to project-setup and make/build/create/implement app, site, tool, component, UI, API, workflow, or behavior requests to brainstorming before frontend, design, framework, or implementation skills
Use before make/build/create/implement requests for apps, sites, tools, components, UI, APIs, workflows, feature work, architecture changes, behavior changes, or unclear requirements; writes a local design spec before planning or coding
Use when executing written implementation plans linearly after written plan approval
| name | improve-codebase-architecture |
| description | Use when scanning a codebase for shallow modules, unclear interfaces, weak seams, poor adapters, poor locality, low leverage, or weak test surfaces |
Use Matt Pocock's codebase-design vocabulary to find architecture deepening opportunities. Produce markdown-only local architecture reviews.
Start from the user's selected repo area or the current repo. Inspect the codebase directly. Do not require browser output, Tailwind, Mermaid, temporary HTML files, context.md, or ADRs.
Look for:
Write a markdown review to:
docs/superpowers/architecture-reviews/YYYY-MM-DD-<topic>.md
The review is local developer working state. Do not commit it unless explicitly requested.
Each candidate must include:
End with a top recommendation.
After writing the review, ask which candidate the user wants to pursue. If they choose one, use brainstorming for a feature-level design spec before planning or implementation.
Do not create context.md. Do not create ADRs.
