From dude
Interactive specification review session. Pulls all specs and architecture decisions for the current project and walks through them with the user to verify accuracy, update, or archive. Use when reviewing technical documentation, validating architecture decisions, or cleaning up outdated specs.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dude:review-specThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Walk through all specifications and architecture decisions for the current project with the user.
Walk through all specifications and architecture decisions for the current project with the user.
When this skill is invoked, follow these steps in order:
Call these in parallel:
dude:list_records { "kind": "spec", "status": "open" }
dude:list_records { "kind": "arch", "status": "open" }
dude:list_records { "kind": "spec", "status": "archived" }
Show the user a summary of what exists:
For each active spec, present it (including body if present) and ask the user:
Apply changes immediately using:
dude:upsert_record { "id": <record_id>, "kind": "spec", "title": "<updated_title>", "body": "<updated_body>", "status": "<new_status>" }
Repeat the same review for arch records. Architecture decisions tend to be longer-lived, so focus on:
Ask the user if there are any new specifications or architecture decisions to capture based on the current state of the project. If yes, create them:
dude:upsert_record { "kind": "spec", "title": "API: <description>", "body": "<details>" }
dude:upsert_record { "kind": "arch", "title": "ARCH: <description>", "body": "<details>" }
Present a final summary of all changes made during the session:
| Tool | Purpose |
|---|---|
dude:list_records | Fetch specs/arch records by kind and status |
dude:upsert_record | Update or create records |
dude:search | Find related specs if needed |
npx claudepluginhub fingerskier/claude-plugins --plugin dudeTransforms ideas into structured specifications (requirements, design, tasks) before implementation. Use when building features, fixing bugs, refactoring, or designing systems.
Write and manage spec files with search, conflict detection, and reporting. Use when user asks to create a spec, update a spec, write a spec, or mentions 스펙 생성, 스펙 업데이트, 스펙 작성, 스펙 만들어줘. Proactively trigger whenever the user's request involves specification documents, even if they don't explicitly say "spec".
Reviews spec.md files for completeness, clarity, implementability, testability, and structure. Identifies ambiguities, gaps, and missing sections before implementation.