메뉴
Audit an existing team under `teams/<slug>/` for correctness, install-safety, frontmatter validity, name collisions, hook hygiene, and quality. Delegates to the `team-reviewer` subagent and returns a punch list with a verdict. Use before publishing or after substantial edits.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Architect produces a full web-app system design from the approved product vision and prototype (the **Design** phase of the spec-driven loop) — extracted architecture drivers, deep exploration of each load-bearing (one-way-door) decision weighed against those drivers, ADRs (architecture style, framework, DB, auth, rendering strategy, multi-tenancy), C4 context/container diagrams, data model, API contracts, component breakdown, observability + security plan, technical verification criteria that bind back to the vision's product criteria, and a phased implementation plan. Use after product vision and prototype are approved.
Architect decomposes the approved web-app system design into milestones and INVEST-sized tasks, splitting each feature slice into a backend task (API + business logic + data, test-driven) and a dependent frontend task (the UI that consumes it), with acceptance criteria, dependencies, and a parallelization plan (the **Tasks** phase of the spec-driven loop). Each task declares its discipline and which system-design verification criteria it advances, so the spec→implementation lineage is explicit. Starts with a walking skeleton (real, deployable, end-to-end). Use after system design is approved.
CEO revisits the product vision and knowledge base — re-reads everything, checks what's changed, talks to the client, and updates the strategic documents. Use when priorities shift, scope changes, or the CEO needs a full refresh.
DBA designs the database schema for a web application from the system design — tables, indexes, constraints, RLS, zero-downtime migration plan. Defaults to Postgres + Redis. Produces .claude/database-schema.md. Use after system design is approved.
Designer extracts a web design specification from the approved HTML prototype — design tokens (CSS custom properties for color/type/spacing/radius/shadow), component inventory, screen map with visual acceptance criteria per screen, responsive behavior, and interaction states. This becomes the single source of truth for UI implementation. Use after the prototype is approved.
Project kickoff — CEO has a natural conversation with the client, plays devil's advocate, crystallizes the product vision (the **Specify** phase of the spec-driven loop) with explicit verification criteria, then iterates with the designer on visuals until approved. No implementation details — pure product thinking. Use at the very start of a new project.
| name | team-review |
| description | Audit an existing team under `teams/<slug>/` for correctness, install-safety, frontmatter validity, name collisions, hook hygiene, and quality. Delegates to the `team-reviewer` subagent and returns a punch list with a verdict. Use before publishing or after substantial edits. |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Bash, Agent |
| argument-hint | <slug> |
Audit a team in teams/<slug>/ and produce a punch list.
Parse $ARGUMENTS for the slug. If missing, list existing teams (ls teams/) and ask which one to review.
If teams/<slug>/ doesn't exist, stop and tell the user.
team-reviewerSend the team-reviewer subagent with:
CLAUDE.md for the install model,The subagent reads everything under teams/<slug>/, checks frontmatter, name collisions against teams/common-web-app, hook hygiene, script executable bits, and .mcp.json collisions, then installs and removes the team in a sandbox.
Pass through the subagent's output verbatim — it's already structured as Blockers / Risks / Nits / Round-trip install / Verdict. Don't summarize it away; the user needs the file:line specifics to act.
If the verdict is REQUEST CHANGES, offer to delegate to /team-edit for any specific fix.