design-review

Name: design-review
Author: xwtro0tk1t-cloud

320stars42forks

How to install design-review?

xwtro0tk1t-cloud/harness/design-review

$npx -y skills add xwtro0tk1t-cloud/harness --skill design-review

Installs into the current project.

Summary

Dispatch an independent challenger agent to adversarially review a spec or implementation plan against the actual codebase. Catches hallucinated APIs, wrong field names, nonexistent files, and incorrect assumptions. Two modes: (1) spec review — verifies DB model fields, API paths

Files · 1

View on GitHub

SKILL.md

1	# Design Review (Challenger Agent)
2
3	## Overview
4
5	Specs and plans written by AI often contain hallucinations: references to APIs that don't exist, wrong column names, incorrect file paths, assumed config attributes that were never defined. These errors waste hours during implementation.
6
7	This skill dispatches an independent challenger agent that reads the spec or plan, identifies every concrete claim, and verifies each one against the actual codebase. The challenger has zero context from the authoring session — it trusts only `grep`, `read`, and the code.
8
9	Announce at start: "I'm using the design-review skill to dispatch a challenger agent for adversarial review."
10
11	## When to Use
12
13	- After `superpowers:brainstorming` produces a spec → `design-review spec <path>`
14	- After `superpowers:writing-plans` produces a plan → `design-review plan <path>`
15	- When a spec/plan references models, APIs, or config from an unfamiliar codebase
16	- When the document was written in a session that hit context limits (higher hallucination risk)
17	- User says "review the spec", "review the plan", "challenge this", "check for hallucinations"
18
19	## Modes
20
21	### Mode 1: Spec Review — `design-review spec <path>`
22
23	Triggered after a spec is written. Verifies:
24
25	\| Claim Type \| Verification Method \|
26	\|-----------\|-------------------\|
27	\| DB model fields mentioned in spec \| `grep "column_name" models.py` or `backend/db/models.py` \|
28	\| API endpoints mentioned in spec \| `grep "router.*path" backend/api/` \|
29	\| Config attributes mentioned in spec \| `grep "get_setting.*key" backend/` \|
30	\| File paths mentioned in spec \| `ls` / `test -f` to verify existence \|
31	\| Function names mentioned in spec \| `grep "def func_name" backend/` \|
32
33	### Mode 2: Plan Review — `design-review plan <path> [--spec <spec_path>]`
34
35	Triggered after a plan is written. Two verification dimensions:
36
37	Dimension 1: Technical Reference Verification (same as original plan-review)
38
39	\| Claim Type \| Verification Method \|
40	\|-----------\|-------------------\|
41	\| Import statements \| Does the module/function exist? `grep "def Y\\|class Y" X.py` \|
42	\| Model field access \| Does the column exist? Read model file \|
43	\| Function calls \| Does the function exist with that signature? \|
44	\| File paths \| Does the file exist? Is the name correct? \|
45	\| Config attributes \| Does config have this attribute? \|
46	\| Constructor arguments \| Does the model/class accept these kwargs? \|
47
48	Dimension 2: Spec Coverage Verification (requires `--spec` parameter)
49
50	When a spec path is provided, the challenger also verifies plan ↔ spec alignment:
51
52	\| Check \| Method \|
53	\|-------\|--------\|
54	\| Spec requirement → Plan task mapping \| Every spec requirement (F1, F2, ...) must have at least one plan task covering it \|
55	\| Missing requirements \| List any spec sections with NO corresponding plan task → BLOCKER \|
56	\| Partial coverage \| Spec requirement mentioned in plan but implementation steps incomplete → WARNING \|
57	\| Extra scope \| Plan tasks that don't trace to any spec requirement → WARNING (scope creep) \|
58
59	Usage: `design-review plan <plan_path> --spec <spec_path>` or `design-review plan <plan_path>` (spec-only review if spec auto-detected from same date prefix)
60
61	### Graph Enhancement (optional, if graph available)
62
63	If `.code-review-graph/graph.db` exists:
64	- Plan files → `/explore impact` to check for missed affected modules
65	- Spec functions → query graph nodes to verify existence
66
67	## Process
68
69	```
70	1. Identify the document path and type (spec or plan)
71	2. If plan review → auto-detect related spec (same date prefix in docs/superpowers/specs/) or use --spec
72	3. Dispatch challenger agent (general-purpose, in foreground)
73	4. Receive findings: BLOCKERs + WARNINGs + Coverage matrix (if spec provided)
74	5. If BLOCKERs exist → fix inline, re-verify
75	6. If only WARNINGs → present to user, fix if agreed
76	7. Report final status
77	```
78
79	## Step 1: Identify Inputs
80
81	Determine the document type and path:
82
83	Spec locations:
84	- `docs/superpowers/specs/*.md`
85	- User-specified path
86
87	Plan locations:
88	- `docs/superpowers/plans/*.md`
89	- `.harness/plans/*.md`
90	- User-specified path
91
92	## Step 2: Dispatch Challenger Agent
93
94	Use the Agent tool:
95
96	```
97	Agent:
98	description: "Adversarial design review"
99	subagent_type: general-purpose

People who liked this also viewed

6 picks

Type

design-review

320stars42forks

View on GitHub

How to install design-review?

xwtro0tk1t-cloud/harness/design-review

$npx -y skills add xwtro0tk1t-cloud/harness --skill design-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Design Review (Challenger Agent)
2
3	## Overview
4
5	Specs and plans written by AI often contain hallucinations: references to APIs that don't exist, wrong column names, incorrect file paths, assumed config attributes that were never defined. These errors waste hours during implementation.
6
7	This skill dispatches an independent challenger agent that reads the spec or plan, identifies every concrete claim, and verifies each one against the actual codebase. The challenger has zero context from the authoring session — it trusts only `grep`, `read`, and the code.
8
9	Announce at start: "I'm using the design-review skill to dispatch a challenger agent for adversarial review."
10
11	## When to Use
12
13	- After `superpowers:brainstorming` produces a spec → `design-review spec <path>`
14	- After `superpowers:writing-plans` produces a plan → `design-review plan <path>`
15	- When a spec/plan references models, APIs, or config from an unfamiliar codebase
16	- When the document was written in a session that hit context limits (higher hallucination risk)
17	- User says "review the spec", "review the plan", "challenge this", "check for hallucinations"
18
19	## Modes
20
21	### Mode 1: Spec Review — `design-review spec <path>`
22
23	Triggered after a spec is written. Verifies:
24
25	\| Claim Type \| Verification Method \|
26	\|-----------\|-------------------\|
27	\| DB model fields mentioned in spec \| `grep "column_name" models.py` or `backend/db/models.py` \|
28	\| API endpoints mentioned in spec \| `grep "router.*path" backend/api/` \|
29	\| Config attributes mentioned in spec \| `grep "get_setting.*key" backend/` \|
30	\| File paths mentioned in spec \| `ls` / `test -f` to verify existence \|
31	\| Function names mentioned in spec \| `grep "def func_name" backend/` \|
32
33	### Mode 2: Plan Review — `design-review plan <path> [--spec <spec_path>]`
34
35	Triggered after a plan is written. Two verification dimensions:
36
37	Dimension 1: Technical Reference Verification (same as original plan-review)
38
39	\| Claim Type \| Verification Method \|
40	\|-----------\|-------------------\|
41	\| Import statements \| Does the module/function exist? `grep "def Y\\|class Y" X.py` \|
42	\| Model field access \| Does the column exist? Read model file \|
43	\| Function calls \| Does the function exist with that signature? \|
44	\| File paths \| Does the file exist? Is the name correct? \|
45	\| Config attributes \| Does config have this attribute? \|
46	\| Constructor arguments \| Does the model/class accept these kwargs? \|
47
48	Dimension 2: Spec Coverage Verification (requires `--spec` parameter)
49
50	When a spec path is provided, the challenger also verifies plan ↔ spec alignment:
51
52	\| Check \| Method \|
53	\|-------\|--------\|
54	\| Spec requirement → Plan task mapping \| Every spec requirement (F1, F2, ...) must have at least one plan task covering it \|
55	\| Missing requirements \| List any spec sections with NO corresponding plan task → BLOCKER \|
56	\| Partial coverage \| Spec requirement mentioned in plan but implementation steps incomplete → WARNING \|
57	\| Extra scope \| Plan tasks that don't trace to any spec requirement → WARNING (scope creep) \|
58
59	Usage: `design-review plan <plan_path> --spec <spec_path>` or `design-review plan <plan_path>` (spec-only review if spec auto-detected from same date prefix)
60
61	### Graph Enhancement (optional, if graph available)
62
63	If `.code-review-graph/graph.db` exists:
64	- Plan files → `/explore impact` to check for missed affected modules
65	- Spec functions → query graph nodes to verify existence
66
67	## Process
68
69	```
70	1. Identify the document path and type (spec or plan)
71	2. If plan review → auto-detect related spec (same date prefix in docs/superpowers/specs/) or use --spec
72	3. Dispatch challenger agent (general-purpose, in foreground)
73	4. Receive findings: BLOCKERs + WARNINGs + Coverage matrix (if spec provided)
74	5. If BLOCKERs exist → fix inline, re-verify
75	6. If only WARNINGs → present to user, fix if agreed
76	7. Report final status
77	```
78
79	## Step 1: Identify Inputs
80
81	Determine the document type and path:
82
83	Spec locations:
84	- `docs/superpowers/specs/*.md`
85	- User-specified path
86
87	Plan locations:
88	- `docs/superpowers/plans/*.md`
89	- `.harness/plans/*.md`
90	- User-specified path
91
92	## Step 2: Dispatch Challenger Agent
93
94	Use the Agent tool:
95
96	```
97	Agent:
98	description: "Adversarial design review"
99	subagent_type: general-purpose

People who liked this also viewed

6 picks

Type