create-bashi-starter 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bin/create-bashi-starter.js +198 -0
- package/package.json +26 -0
- package/template/.claude/CLAUDE.md +70 -0
- package/template/.claude/REFERENCE.md +68 -0
- package/template/.claude/agents/builder.md +48 -0
- package/template/.claude/agents/orchestrator.md +220 -0
- package/template/.claude/agents/reviewer.md +58 -0
- package/template/.claude/commands/capture-idea.md +73 -0
- package/template/.claude/commands/run-project.md +109 -0
- package/template/.claude/commands/save.md +78 -0
- package/template/.claude/commands/setup.md +73 -0
- package/template/.claude/commands/start.md +55 -0
- package/template/.claude/commands/status.md +40 -0
- package/template/.claude/hooks/lib/detect-python.sh +12 -0
- package/template/.claude/hooks/pre-bash-firewall.sh +48 -0
- package/template/.claude/hooks/pre-write-secrets-scan.sh +56 -0
- package/template/.claude/hooks/session-start.sh +54 -0
- package/template/.claude/project/EVENTS.md +29 -0
- package/template/.claude/project/IDENTITY.md +12 -0
- package/template/.claude/project/RUN_POLICY.md +59 -0
- package/template/.claude/project/STATE.md +57 -0
- package/template/.claude/project/knowledge/DECISIONS.md +21 -0
- package/template/.claude/project/knowledge/GLOSSARY.md +21 -0
- package/template/.claude/project/knowledge/OPEN_QUESTIONS.md +21 -0
- package/template/.claude/rules/context-policy.md +47 -0
- package/template/.claude/rules/orchestration-routing.md +39 -0
- package/template/.claude/rules/user-consent.md +12 -0
- package/template/.claude/settings.json +51 -0
- package/template/.claude/skills/REGISTRY.md +23 -0
- package/template/.claude/skills/code-review/SKILL.md +251 -0
- package/template/.claude/skills/deployment/SKILL.md +301 -0
- package/template/.claude/skills/frontend-dev/SKILL.md +192 -0
- package/template/.claude/skills/plan-from-idea/SKILL.md +85 -0
- package/template/.claude/skills/prd-to-tasks/SKILL.md +207 -0
- package/template/.claude/skills/prd-writing/SKILL.md +226 -0
- package/template/.claudeignore +14 -0
- package/template/FRAMEWORK_VERSION +1 -0
- package/template/README.md +95 -0
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# Run Policy
|
|
2
|
+
|
|
3
|
+
> Defines execution boundaries for the orchestrator.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Default Mode
|
|
8
|
+
|
|
9
|
+
Semi-Autonomous
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Cycle Limits
|
|
14
|
+
|
|
15
|
+
| Mode | Cycles per /run-project |
|
|
16
|
+
|------|------------------------|
|
|
17
|
+
| Safe | 0 (proposal only) |
|
|
18
|
+
| Semi-Autonomous | 1 |
|
|
19
|
+
| Autonomous | 5 |
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## Stop Conditions
|
|
24
|
+
|
|
25
|
+
The orchestrator must stop immediately if any of the following occur:
|
|
26
|
+
|
|
27
|
+
1. The user says stop.
|
|
28
|
+
2. The current task becomes Blocked.
|
|
29
|
+
3. A single file modification exceeds 500 lines.
|
|
30
|
+
4. The Next Task Queue becomes empty.
|
|
31
|
+
5. A required artifact is missing and cannot be created safely.
|
|
32
|
+
6. Consecutive failure limit reached (default 3).
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## Circuit Breakers
|
|
37
|
+
|
|
38
|
+
| Breaker | Default | Description |
|
|
39
|
+
|---------|---------|-------------|
|
|
40
|
+
| Consecutive Failure Limit | 3 | Stop if 3 tasks in a row are Blocked or rolled back. |
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## Review Gates
|
|
45
|
+
|
|
46
|
+
| Task Type | Review |
|
|
47
|
+
|-----------|--------|
|
|
48
|
+
| Frontend code | Orchestrator suggests code review after build tasks |
|
|
49
|
+
| Planning | Orchestrator self-reviews task titles for clarity |
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## Execution Rule
|
|
54
|
+
|
|
55
|
+
After every cycle the orchestrator must:
|
|
56
|
+
|
|
57
|
+
1. Update `.claude/project/STATE.md`
|
|
58
|
+
2. Print an Execution Summary
|
|
59
|
+
3. Evaluate stop conditions before starting the next cycle
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# Project State
|
|
2
|
+
|
|
3
|
+
## Current Mode
|
|
4
|
+
Semi-Autonomous
|
|
5
|
+
|
|
6
|
+
### Mode Reference
|
|
7
|
+
| Mode | Behavior |
|
|
8
|
+
|------|----------|
|
|
9
|
+
| **Safe** | No file modifications. Only propose actions and print what would happen. |
|
|
10
|
+
| **Semi-Autonomous** | Execute one task, then pause for human review. (Default) |
|
|
11
|
+
| **Autonomous** | Execute tasks continuously. Enforce verification gates. Stop after 5 tasks per run cycle. |
|
|
12
|
+
|
|
13
|
+
## Current Phase
|
|
14
|
+
Not Started
|
|
15
|
+
|
|
16
|
+
## Active Task
|
|
17
|
+
- ID: —
|
|
18
|
+
- Description: —
|
|
19
|
+
- Owner Agent: —
|
|
20
|
+
- Started: —
|
|
21
|
+
- Status: —
|
|
22
|
+
|
|
23
|
+
## Definition of Done
|
|
24
|
+
- [ ] (populated per task)
|
|
25
|
+
|
|
26
|
+
## Inputs / Context Used
|
|
27
|
+
- (none yet)
|
|
28
|
+
|
|
29
|
+
## Outputs Produced
|
|
30
|
+
- (none yet)
|
|
31
|
+
|
|
32
|
+
## Files Modified (Last Task)
|
|
33
|
+
- (none yet)
|
|
34
|
+
|
|
35
|
+
## Blockers / Risks
|
|
36
|
+
- (none)
|
|
37
|
+
|
|
38
|
+
## Next Task Queue
|
|
39
|
+
|
|
40
|
+
| # | Task | Priority | Skill |
|
|
41
|
+
|---|------|----------|-------|
|
|
42
|
+
| — | — | — | — |
|
|
43
|
+
|
|
44
|
+
## Run Cycle
|
|
45
|
+
- Current Cycle: 0
|
|
46
|
+
- Max Cycles This Run: 1
|
|
47
|
+
- Last Run Status: Idle
|
|
48
|
+
- Consecutive Failures: 0
|
|
49
|
+
- Run Type: Standard
|
|
50
|
+
|
|
51
|
+
## Session Lock
|
|
52
|
+
- Session Started: —
|
|
53
|
+
- Last Activity: —
|
|
54
|
+
- Checkpointed: No
|
|
55
|
+
|
|
56
|
+
## Completed Tasks Log
|
|
57
|
+
- (none yet)
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# Decisions Log
|
|
2
|
+
|
|
3
|
+
> Architectural and design decisions for the project. Append-only. Never delete -- mark as Superseded.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Entry Template
|
|
8
|
+
|
|
9
|
+
```
|
|
10
|
+
### DEC-XXXX: [Decision Title]
|
|
11
|
+
|
|
12
|
+
- **Status:** Active | Superseded by DEC-XXXX
|
|
13
|
+
- **Date:** YYYY-MM-DD
|
|
14
|
+
- **Context:** [Why this decision was needed]
|
|
15
|
+
- **Decision:** [What was decided]
|
|
16
|
+
- **Consequences:** [What this means for the project]
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
*(No decisions logged yet.)*
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# Glossary
|
|
2
|
+
|
|
3
|
+
> One definition per term, written for beginners. Used by all agents to keep language consistent.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
- **Syntax Wall** -- The invisible barrier that has historically prevented people without programming skills from turning their ideas into software. AI lowers this wall but does not remove it entirely.
|
|
8
|
+
|
|
9
|
+
- **Orchestrator** -- The person who coordinates the work. You direct AI agents through a structured workflow to build software.
|
|
10
|
+
|
|
11
|
+
- **Agent** -- A specialized AI role designed to handle one type of task well. Examples: a builder agent that writes code, a reviewer agent that checks quality.
|
|
12
|
+
|
|
13
|
+
- **Skill** -- A packaged workflow that bundles steps, review gates, and a definition of done into a single reusable operation.
|
|
14
|
+
|
|
15
|
+
- **Event** -- A signal that something happened in the project. Events trigger follow-up actions automatically.
|
|
16
|
+
|
|
17
|
+
- **State** -- The current snapshot of the project: what's done, what's in progress, what's next. Keeping state in a file prevents the system from losing track between sessions.
|
|
18
|
+
|
|
19
|
+
- **SDLC** -- Software Development Life Cycle. The structured process for building software: plan, design, build, test, deploy, maintain.
|
|
20
|
+
|
|
21
|
+
- **PRD** -- Product Requirements Document. A written description of what you want to build, who it's for, and what it should do.
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# Open Questions
|
|
2
|
+
|
|
3
|
+
> Unresolved questions that affect future work. Update status when resolved.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Entry Template
|
|
8
|
+
|
|
9
|
+
```
|
|
10
|
+
### OQ-XXXX: [Question]
|
|
11
|
+
|
|
12
|
+
- **Date:** YYYY-MM-DD
|
|
13
|
+
- **Source:** [Where this question came from]
|
|
14
|
+
- **Context:** [Why it matters]
|
|
15
|
+
- **Status:** Open | Resolved
|
|
16
|
+
- **Resolution:** [Answer, if resolved]
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
*(No open questions yet.)*
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
# Context Conservation Policy
|
|
2
|
+
|
|
3
|
+
> Prevent context window waste by keeping large artifacts in files, not chat.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Rules
|
|
8
|
+
|
|
9
|
+
### 1. Summarize, Don't Reproduce
|
|
10
|
+
|
|
11
|
+
Reference file paths instead of echoing content.
|
|
12
|
+
|
|
13
|
+
**Do:** "PRD written to `docs/PRD.md` with 5 user stories."
|
|
14
|
+
**Don't:** Print the entire PRD in chat.
|
|
15
|
+
|
|
16
|
+
### 2. Write Artifacts to Files
|
|
17
|
+
|
|
18
|
+
| Artifact Type | Location |
|
|
19
|
+
|---------------|----------|
|
|
20
|
+
| Documentation | `docs/` |
|
|
21
|
+
| Decisions | `.claude/project/knowledge/DECISIONS.md` |
|
|
22
|
+
| Glossary terms | `.claude/project/knowledge/GLOSSARY.md` |
|
|
23
|
+
| Open questions | `.claude/project/knowledge/OPEN_QUESTIONS.md` |
|
|
24
|
+
| Task status | `.claude/project/STATE.md` |
|
|
25
|
+
| Event records | `.claude/project/EVENTS.md` |
|
|
26
|
+
|
|
27
|
+
### 3. Persist Decisions
|
|
28
|
+
|
|
29
|
+
Every architectural or design decision must be written to DECISIONS.md. Decisions stated only in chat are at risk of loss.
|
|
30
|
+
|
|
31
|
+
### 4. Update System State
|
|
32
|
+
|
|
33
|
+
After every unit of work:
|
|
34
|
+
- STATE.md -- update active task status, outputs, files modified
|
|
35
|
+
- EVENTS.md -- update event processing status
|
|
36
|
+
|
|
37
|
+
### 5. Chat Budget
|
|
38
|
+
|
|
39
|
+
Chat output per task cycle should stay under 200 words. Include only:
|
|
40
|
+
- Task completed (ID + one-line description)
|
|
41
|
+
- Files changed (list of paths)
|
|
42
|
+
- Decisions made (one-line each)
|
|
43
|
+
- Next task (ID + one-line description)
|
|
44
|
+
|
|
45
|
+
### 6. Lazy Context Loading
|
|
46
|
+
|
|
47
|
+
Do not preemptively read all files. Load only what the current task requires.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Orchestration Routing Rules
|
|
2
|
+
|
|
3
|
+
> Maps task types to primary and review agents. Used when no skill trigger matches in REGISTRY.md.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Task Routing Table
|
|
8
|
+
|
|
9
|
+
| Task Type | Primary Agent | Review Agent | Notes |
|
|
10
|
+
|-----------|--------------|--------------|-------|
|
|
11
|
+
| Product Vision / Scope | orchestrator | -- | PRD creation (SKL-0004) |
|
|
12
|
+
| Planning / Task Breakdown | orchestrator | -- | PRD to tasks (SKL-0003) |
|
|
13
|
+
| UI / Frontend | builder | reviewer | Web UI components, pages, styling (SKL-0005) |
|
|
14
|
+
| Deployment / Ship | builder | -- | Ship workflow (SKL-0021) |
|
|
15
|
+
| Review / Quality | reviewer | -- | Code review (SKL-0016) |
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## Recommended Workflow
|
|
20
|
+
|
|
21
|
+
```
|
|
22
|
+
/capture-idea --> /run-project (planning) --> /run-project (execution) --> /save
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
| Phase | Command | Purpose |
|
|
26
|
+
|-------|---------|---------|
|
|
27
|
+
| Idea capture | `/capture-idea` | Record the idea and emit IDEA_CAPTURED event |
|
|
28
|
+
| Planning | `/run-project` | Process event, generate PRD, create task queue |
|
|
29
|
+
| Execution | `/run-project` | Execute tasks from the queue (repeat as needed) |
|
|
30
|
+
| Save | `/save` | Persist all progress for session continuity |
|
|
31
|
+
|
|
32
|
+
---
|
|
33
|
+
|
|
34
|
+
## Fallback Rule
|
|
35
|
+
|
|
36
|
+
If a task type is not listed above:
|
|
37
|
+
1. Assign to Orchestrator as primary.
|
|
38
|
+
2. Log a warning: "No routing rule for task type."
|
|
39
|
+
3. Proceed with best-effort execution.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# User Consent for Choices
|
|
2
|
+
|
|
3
|
+
> Never auto-select a value when the procedure says to ask the user.
|
|
4
|
+
|
|
5
|
+
When a command procedure includes a choice:
|
|
6
|
+
|
|
7
|
+
1. Present the options exactly as listed.
|
|
8
|
+
2. **STOP and wait for the user's answer.** Do not continue. Do not write files. Do not say "For now I'll proceed with..."
|
|
9
|
+
3. Never infer, assume, or pre-fill a selection.
|
|
10
|
+
4. **Recommending is fine. Proceeding is not.** You may say "I'd recommend X because..." but you must end with the question and wait.
|
|
11
|
+
|
|
12
|
+
**Exception:** If the procedure explicitly allows inference, inference is permitted. This rule only applies when the procedure says to ask.
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
{
|
|
2
|
+
"permissions": {
|
|
3
|
+
"allow": [
|
|
4
|
+
"Read",
|
|
5
|
+
"Edit",
|
|
6
|
+
"Write",
|
|
7
|
+
"Bash",
|
|
8
|
+
"Glob",
|
|
9
|
+
"Grep"
|
|
10
|
+
],
|
|
11
|
+
"deny": [
|
|
12
|
+
"Bash(git push --force*)",
|
|
13
|
+
"Bash(git reset --hard*)",
|
|
14
|
+
"Bash(rm -rf*)",
|
|
15
|
+
"Bash(DROP TABLE*)"
|
|
16
|
+
]
|
|
17
|
+
},
|
|
18
|
+
"hooks": {
|
|
19
|
+
"SessionStart": [
|
|
20
|
+
{
|
|
21
|
+
"matcher": "",
|
|
22
|
+
"hooks": [
|
|
23
|
+
{
|
|
24
|
+
"type": "command",
|
|
25
|
+
"command": "bash .claude/hooks/session-start.sh"
|
|
26
|
+
}
|
|
27
|
+
]
|
|
28
|
+
}
|
|
29
|
+
],
|
|
30
|
+
"PreToolUse": [
|
|
31
|
+
{
|
|
32
|
+
"matcher": "Bash",
|
|
33
|
+
"hooks": [
|
|
34
|
+
{
|
|
35
|
+
"type": "command",
|
|
36
|
+
"command": "bash .claude/hooks/pre-bash-firewall.sh \"$TOOL_INPUT\""
|
|
37
|
+
}
|
|
38
|
+
]
|
|
39
|
+
},
|
|
40
|
+
{
|
|
41
|
+
"matcher": "Write|Edit|MultiEdit",
|
|
42
|
+
"hooks": [
|
|
43
|
+
{
|
|
44
|
+
"type": "command",
|
|
45
|
+
"command": "bash .claude/hooks/pre-write-secrets-scan.sh \"$TOOL_INPUT\""
|
|
46
|
+
}
|
|
47
|
+
]
|
|
48
|
+
}
|
|
49
|
+
]
|
|
50
|
+
}
|
|
51
|
+
}
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Skills Registry
|
|
2
|
+
|
|
3
|
+
> Skills are discovered automatically from SKILL.md files in subfolders.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Skills Index
|
|
8
|
+
|
|
9
|
+
| Skill ID | Name | Version | Owner | Folder | Triggers |
|
|
10
|
+
|----------|------|---------|-------|--------|----------|
|
|
11
|
+
| SKL-0001 | Plan From Idea | 1.0 | orchestrator | `.claude/skills/plan-from-idea/` | IDEA_CAPTURED |
|
|
12
|
+
| SKL-0003 | PRD to Tasks | 1.0 | orchestrator | `.claude/skills/prd-to-tasks/` | PRD_UPDATED |
|
|
13
|
+
| SKL-0004 | PRD Writing | 2.0 | orchestrator | `.claude/skills/prd-writing/` | PRD_CREATION_REQUESTED |
|
|
14
|
+
| SKL-0005 | Frontend Development | 2.0 | builder | `.claude/skills/frontend-dev/` | FRONTEND_TASK_READY |
|
|
15
|
+
| SKL-0016 | Code Review | 2.0 | reviewer | `.claude/skills/code-review/` | CODE_REVIEW_REQUESTED |
|
|
16
|
+
| SKL-0021 | Deployment & Ship | 3.0 | builder | `.claude/skills/deployment/` | DEPLOYMENT_REQUESTED, SHIP_REQUESTED |
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## Stats
|
|
21
|
+
|
|
22
|
+
- **Skills:** 6
|
|
23
|
+
- **Last Refreshed:** 2026-04-04
|
|
@@ -0,0 +1,251 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: SKL-0016
|
|
3
|
+
name: Code Review
|
|
4
|
+
description: |
|
|
5
|
+
Review code for correctness, maintainability, and best practices. Uses a
|
|
6
|
+
structured two-pass review (CRITICAL then INFORMATIONAL) with interactive
|
|
7
|
+
issue resolution. Includes scope challenge, failure mode analysis, and
|
|
8
|
+
TODOS.md cross-reference. Use this skill when a code review is requested
|
|
9
|
+
on new or modified code.
|
|
10
|
+
version: 2.0
|
|
11
|
+
owner: reviewer
|
|
12
|
+
triggers:
|
|
13
|
+
- CODE_REVIEW_REQUESTED
|
|
14
|
+
inputs:
|
|
15
|
+
- Target files (from active task or event)
|
|
16
|
+
- .claude/project/STATE.md
|
|
17
|
+
- .claude/project/knowledge/DECISIONS.md
|
|
18
|
+
- TODOS.md (if exists)
|
|
19
|
+
- Existing project source files
|
|
20
|
+
outputs:
|
|
21
|
+
- Review summary (CRITICAL / INFORMATIONAL findings)
|
|
22
|
+
- Verdict (APPROVED / NEEDS WORK)
|
|
23
|
+
- .claude/project/STATE.md (updated)
|
|
24
|
+
tags:
|
|
25
|
+
- review
|
|
26
|
+
- quality
|
|
27
|
+
- code
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
# Skill: Code Review
|
|
31
|
+
|
|
32
|
+
## Metadata
|
|
33
|
+
|
|
34
|
+
| Field | Value |
|
|
35
|
+
|-------|-------|
|
|
36
|
+
| **Skill ID** | SKL-0016 |
|
|
37
|
+
| **Version** | 2.0 |
|
|
38
|
+
| **Owner** | reviewer |
|
|
39
|
+
| **Inputs** | Target files, STATE.md, DECISIONS.md, TODOS.md |
|
|
40
|
+
| **Outputs** | Review summary, verdict, STATE.md updated |
|
|
41
|
+
| **Triggers** | `CODE_REVIEW_REQUESTED` |
|
|
42
|
+
|
|
43
|
+
---
|
|
44
|
+
|
|
45
|
+
## Purpose
|
|
46
|
+
|
|
47
|
+
Review code for quality, security, and correctness using a structured two-pass approach. Read-only analysis by default --- only modifies files if the user explicitly chooses to fix an issue. Produces actionable findings categorized by severity.
|
|
48
|
+
|
|
49
|
+
---
|
|
50
|
+
|
|
51
|
+
## Cognitive Mode
|
|
52
|
+
|
|
53
|
+
**Paranoid Staff Engineer.** You are looking for the bugs that pass CI, the security holes that look like features, the edge cases that only surface in production at 2am. Be thorough. Be skeptical. Be kind in delivery.
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## Procedure
|
|
58
|
+
|
|
59
|
+
### Step 0 --- Scope Challenge
|
|
60
|
+
|
|
61
|
+
Before reviewing any code, answer these questions:
|
|
62
|
+
|
|
63
|
+
1. **What changed?** Get the diff: `git diff origin/main --stat` and `git diff origin/main` for the full diff. If reviewing specific files rather than a branch diff, read those files.
|
|
64
|
+
2. **What existing code already handles this concern?** Check if the new code duplicates existing patterns. Flag any unnecessary rebuilding.
|
|
65
|
+
3. **Read DECISIONS.md** --- understand naming patterns, architecture choices, and conventions the code should follow.
|
|
66
|
+
4. **Read TODOS.md** (if exists) --- does this change address any open TODOs? Does it create work that should become a TODO?
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
### Step 1 --- Review Checklist
|
|
71
|
+
|
|
72
|
+
Apply the following checklist categories during the review. Items listed under "DO NOT Flag" in DECISIONS.md (if any) should be skipped.
|
|
73
|
+
|
|
74
|
+
**Security:**
|
|
75
|
+
- No hardcoded secrets, API keys, or credentials
|
|
76
|
+
- No SQL injection, XSS, or command injection vectors
|
|
77
|
+
- Input validation on all user-provided data
|
|
78
|
+
- Authentication and authorization checks in place
|
|
79
|
+
- Sensitive data not logged or exposed in error messages
|
|
80
|
+
|
|
81
|
+
**Data Safety:**
|
|
82
|
+
- Database operations use transactions where needed
|
|
83
|
+
- No silent data loss (deletes, overwrites without confirmation)
|
|
84
|
+
- Migrations are reversible
|
|
85
|
+
- Backup/rollback path exists for destructive operations
|
|
86
|
+
|
|
87
|
+
**Code Quality:**
|
|
88
|
+
- Functions do one thing and are named clearly
|
|
89
|
+
- No dead code or commented-out blocks
|
|
90
|
+
- Error handling is explicit (no swallowed exceptions)
|
|
91
|
+
- Dependencies are necessary and up to date
|
|
92
|
+
- No duplicated logic that should be extracted
|
|
93
|
+
|
|
94
|
+
**Testing:**
|
|
95
|
+
- New code paths have corresponding tests
|
|
96
|
+
- Edge cases are covered (null, empty, boundary values)
|
|
97
|
+
- Tests are deterministic (no flaky reliance on timing or external state)
|
|
98
|
+
|
|
99
|
+
**Performance:**
|
|
100
|
+
- No N+1 queries or unbounded loops
|
|
101
|
+
- Large data sets are paginated
|
|
102
|
+
- Expensive operations are cached or debounced where appropriate
|
|
103
|
+
|
|
104
|
+
---
|
|
105
|
+
|
|
106
|
+
### Step 2 --- Read the Full Diff
|
|
107
|
+
|
|
108
|
+
Read the complete diff before making any comments. This prevents flagging issues that are already addressed elsewhere in the same change.
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
### Step 3 --- Two-Pass Review
|
|
113
|
+
|
|
114
|
+
Apply the checklist against the diff in two passes:
|
|
115
|
+
|
|
116
|
+
#### Pass 1 --- CRITICAL (Must Fix)
|
|
117
|
+
- Security vulnerabilities
|
|
118
|
+
- Data safety issues
|
|
119
|
+
- Trust boundary violations
|
|
120
|
+
|
|
121
|
+
For each CRITICAL finding:
|
|
122
|
+
- State the problem: `file:line` + one-line description
|
|
123
|
+
- Explain the risk: what could go wrong in production
|
|
124
|
+
- Recommend a fix: specific, actionable
|
|
125
|
+
|
|
126
|
+
#### Pass 2 --- INFORMATIONAL (Should Fix / Consider)
|
|
127
|
+
- Logic & edge cases
|
|
128
|
+
- Code quality
|
|
129
|
+
- Consistency
|
|
130
|
+
- Test gaps
|
|
131
|
+
- Performance
|
|
132
|
+
|
|
133
|
+
For each INFORMATIONAL finding:
|
|
134
|
+
- State the problem: `file:line` + one-line description
|
|
135
|
+
- Suggest improvement: one-line recommendation
|
|
136
|
+
|
|
137
|
+
**Be terse.** One line problem, one line fix. No preamble.
|
|
138
|
+
|
|
139
|
+
---
|
|
140
|
+
|
|
141
|
+
### Step 4 --- Failure Mode Analysis
|
|
142
|
+
|
|
143
|
+
For each new codepath introduced in the diff:
|
|
144
|
+
|
|
145
|
+
1. Describe one realistic way it could fail in production (timeout, null reference, race condition, stale data, etc.)
|
|
146
|
+
2. Check whether:
|
|
147
|
+
- A test covers that failure
|
|
148
|
+
- Error handling exists for it
|
|
149
|
+
- The user would see a clear error or a silent failure
|
|
150
|
+
|
|
151
|
+
If any failure mode has **no test AND no error handling AND would be silent**, flag it as a **CRITICAL GAP**.
|
|
152
|
+
|
|
153
|
+
---
|
|
154
|
+
|
|
155
|
+
### Step 5 --- Output Findings
|
|
156
|
+
|
|
157
|
+
**Always output ALL findings** --- both critical and informational.
|
|
158
|
+
|
|
159
|
+
Format the output as:
|
|
160
|
+
|
|
161
|
+
```
|
|
162
|
+
## Code Review: [N] issues ([X] critical, [Y] informational)
|
|
163
|
+
|
|
164
|
+
### CRITICAL
|
|
165
|
+
1. [file:line] --- [problem] -> [fix]
|
|
166
|
+
2. ...
|
|
167
|
+
|
|
168
|
+
### INFORMATIONAL
|
|
169
|
+
1. [file:line] --- [problem] -> [suggestion]
|
|
170
|
+
2. ...
|
|
171
|
+
|
|
172
|
+
### Failure Modes
|
|
173
|
+
[codepath] --- [failure scenario] --- [covered? / gap?]
|
|
174
|
+
|
|
175
|
+
### TODOS Cross-Reference
|
|
176
|
+
- Addresses: [TODO items this change completes]
|
|
177
|
+
- Creates: [new work that should become a TODO]
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
**If CRITICAL issues found:** For EACH critical issue, present it individually with:
|
|
181
|
+
- The problem and recommended fix
|
|
182
|
+
- Options: A) Fix it now, B) Acknowledge and proceed, C) False positive --- skip
|
|
183
|
+
- If the user chooses A (fix), apply the fix. This is the ONLY case where this skill modifies files.
|
|
184
|
+
|
|
185
|
+
**If only informational issues found:** Output findings. No further action needed.
|
|
186
|
+
|
|
187
|
+
**If no issues found:** Output `Code Review: No issues found.`
|
|
188
|
+
|
|
189
|
+
---
|
|
190
|
+
|
|
191
|
+
### Step 6 --- Unresolved Decisions
|
|
192
|
+
|
|
193
|
+
If any critical issue was presented but the user did not respond or interrupted, list it under "Unresolved decisions that may surface later." Never silently default.
|
|
194
|
+
|
|
195
|
+
---
|
|
196
|
+
|
|
197
|
+
### Step 7 --- Issue Verdict
|
|
198
|
+
|
|
199
|
+
- Default verdict is **NEEDS WORK**. The code must earn approval.
|
|
200
|
+
- To issue **APPROVED**, cite evidence for each:
|
|
201
|
+
- Zero CRITICAL issues (or all fixed/acknowledged)
|
|
202
|
+
- Code works per requirements
|
|
203
|
+
- Edge cases handled
|
|
204
|
+
- All Definition of Done items satisfied
|
|
205
|
+
- If any item lacks evidence, verdict remains **NEEDS WORK** with specific, actionable feedback.
|
|
206
|
+
|
|
207
|
+
---
|
|
208
|
+
|
|
209
|
+
### Step 8 --- Update STATE.md
|
|
210
|
+
|
|
211
|
+
Write review summary and verdict to STATE.md.
|
|
212
|
+
|
|
213
|
+
---
|
|
214
|
+
|
|
215
|
+
## Constraints
|
|
216
|
+
|
|
217
|
+
- Read-only by default --- only modifies files if user explicitly chooses "Fix it now"
|
|
218
|
+
- Never approves code without actually reading it
|
|
219
|
+
- Always reads the full diff before commenting --- do not flag issues already addressed in the diff
|
|
220
|
+
- Never commits, pushes, or creates PRs --- review only
|
|
221
|
+
- Respect suppressions --- do not flag items listed in the suppressions section of DECISIONS.md
|
|
222
|
+
|
|
223
|
+
---
|
|
224
|
+
|
|
225
|
+
## Primary Agent
|
|
226
|
+
|
|
227
|
+
reviewer
|
|
228
|
+
|
|
229
|
+
---
|
|
230
|
+
|
|
231
|
+
## Definition of Done
|
|
232
|
+
|
|
233
|
+
- [ ] Scope challenge completed (Step 0)
|
|
234
|
+
- [ ] Checklist applied
|
|
235
|
+
- [ ] Full diff read before any comments
|
|
236
|
+
- [ ] Pass 1 (CRITICAL) completed
|
|
237
|
+
- [ ] Pass 2 (INFORMATIONAL) completed
|
|
238
|
+
- [ ] Failure mode analysis completed
|
|
239
|
+
- [ ] TODOS.md cross-referenced (if exists)
|
|
240
|
+
- [ ] All findings categorized and output
|
|
241
|
+
- [ ] Critical issues presented individually for user decision
|
|
242
|
+
- [ ] Verdict issued with evidence
|
|
243
|
+
- [ ] STATE.md updated with review summary
|
|
244
|
+
|
|
245
|
+
## Output Contract
|
|
246
|
+
|
|
247
|
+
| Field | Value |
|
|
248
|
+
|-------|-------|
|
|
249
|
+
| **Artifacts** | Review summary with verdict (`APPROVED` or `NEEDS WORK`), categorized findings (CRITICAL / INFORMATIONAL) |
|
|
250
|
+
| **State Update** | `.claude/project/STATE.md` --- mark task complete, log files modified |
|
|
251
|
+
| **Handoff Event** | `TASK_COMPLETED` or `REWORK_REQUESTED` (depends on verdict) |
|