Skip to content

Commit a172e4c

Browse files
localdenlocalden
committed
Update commands.
1 parent 265534c commit a172e4c

9 files changed

Lines changed: 218 additions & 21 deletions

File tree

‎templates/checklist-template.md‎

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
# [CHECKLIST TYPE] Checklist: [FEATURE NAME]
2+
3+
**Purpose**: [Brief description of what this checklist covers]
4+
**Created**: [DATE]
5+
**Feature**: [Link to spec.md or relevant documentation]
6+
7+
**Note**: This checklist is generated by the `/checklist` command based on feature context and requirements.
8+
9+
<!--
10+
============================================================================
11+
IMPORTANT: The checklist items below are SAMPLE ITEMS for illustration only.
12+
13+
The /checklist command MUST replace these with actual items based on:
14+
- User's specific checklist request
15+
- Feature requirements from spec.md
16+
- Technical context from plan.md
17+
- Implementation details from tasks.md
18+
19+
DO NOT keep these sample items in the generated checklist file.
20+
============================================================================
21+
-->
22+
23+
## [Category 1]
24+
25+
- [ ] CHK001 First checklist item with clear action
26+
- [ ] CHK002 Second checklist item
27+
- [ ] CHK003 Third checklist item
28+
29+
## [Category 2]
30+
31+
- [ ] CHK004 Another category item
32+
- [ ] CHK005 Item with specific criteria
33+
- [ ] CHK006 Final item in this category
34+
35+
## Notes
36+
37+
- Check items off as completed: `[x]`
38+
- Add comments or findings inline
39+
- Link to relevant resources or documentation
40+
- Items are numbered sequentially for easy reference

‎templates/commands/analyze.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -9,8 +9,8 @@ The user input to you can be provided directly by the agent or as a command argu
99

1010
User input:
1111

12-
$ARGUMENTS
13-
12+
`$ARGUMENTS
13+
`
1414
Goal: Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/tasks` has successfully produced a complete `tasks.md`.
1515

1616
STRICTLY READ-ONLY: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).

‎templates/commands/checklist.md‎

Lines changed: 130 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
1+
---
2+
description: Generate a custom checklist for the current feature based on user requirements.
3+
scripts:
4+
sh: scripts/bash/check-prerequisites.sh --json
5+
ps: scripts/powershell/check-prerequisites.ps1 -Json
6+
---
7+
8+
The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
9+
10+
User input:
11+
12+
`$ARGUMENTS
13+
`
14+
## Execution Steps
15+
16+
1. **Setup**: Run `{SCRIPT}` from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
17+
- All file paths must be absolute.
18+
19+
2. **Clarify intent (dynamic)**: Derive THREE contextual clarifying questions (no pre-baked catalog). They MUST:
20+
- Be generated from the user's phrasing + extracted signals from spec/plan/tasks
21+
- Only ask about information that materially changes checklist content
22+
- Be skipped individually if already unambiguous in `$ARGUMENTS`
23+
- Prefer precision over breadth
24+
25+
Generation algorithm:
26+
1. Extract signals: feature domain keywords (e.g., auth, latency, UX, API), risk indicators ("critical", "must", "compliance"), stakeholder hints ("QA", "review", "security team"), and explicit deliverables ("a11y", "rollback", "contracts").
27+
2. Cluster signals into candidate focus areas (max 4) ranked by relevance.
28+
3. Identify probable audience & timing (author, reviewer, QA, release) if not explicit.
29+
4. Detect missing dimensions: scope breadth, depth/rigor, risk emphasis, exclusion boundaries, measurable acceptance criteria.
30+
5. Formulate up to three questions chosen from these archetypes:
31+
- Scope refinement (e.g., "Should this include integration touchpoints with X and Y or stay limited to local module correctness?")
32+
- Risk prioritization (e.g., "Which of these potential risk areas should receive mandatory gating checks?")
33+
- Depth calibration (e.g., "Is this a lightweight pre-commit sanity list or a formal release gate?")
34+
- Audience framing (e.g., "Will this be used by the author only or peers during PR review?")
35+
- Boundary exclusion (e.g., "Should we explicitly exclude performance tuning items this round?")
36+
37+
Question formatting rules:
38+
- If presenting options, generate a compact table with columns: Option | Candidate | Why It Matters
39+
- Limit to A–E options maximum; omit table if a free-form answer is clearer
40+
- Never ask the user to restate what they already said
41+
- Avoid speculative categories (no hallucination). If uncertain, ask explicitly: "Confirm whether X belongs in scope."
42+
43+
Defaults when interaction impossible:
44+
- Depth: Standard
45+
- Audience: Reviewer (PR) if code-related; Author otherwise
46+
- Focus: Top 2 relevance clusters
47+
48+
Output the three questions (or fewer if not needed) and wait for answers before continuing. Clearly label each as Q1/Q2/Q3.
49+
50+
3. **Understand user request**: Combine `$ARGUMENTS` + clarifying answers:
51+
- Derive checklist theme (e.g., security, review, deploy, ux)
52+
- Consolidate explicit must-have items mentioned by user
53+
- Map focus selections to category scaffolding
54+
- Infer any missing context from spec/plan/tasks (do NOT hallucinate)
55+
56+
4. **Load feature context**: Read from FEATURE_DIR:
57+
- spec.md: Feature requirements and scope
58+
- plan.md (if exists): Technical details, dependencies
59+
- tasks.md (if exists): Implementation tasks
60+
- Use context to enrich or validate checklist items (omit irrelevant categories)
61+
62+
5. **Generate checklist**:
63+
- Create `FEATURE_DIR/checklists/` directory if it doesn't exist
64+
- Generate unique checklist filename:
65+
* Use short, descriptive name based on checklist type
66+
* Format: `[type].md` (e.g., `ux.md`, `test.md`, `security.md`, `deploy.md`)
67+
* If file exists, append counter: `[type]-2.md`, `[type]-3.md`, etc.
68+
* Examples: `ux.md`, `test.md`, `security.md`, `deploy.md`, `review-2.md`
69+
- Use format: `[ ] CHK001 Item description here`
70+
- Number items sequentially starting from CHK001
71+
- Group items by category/section if applicable
72+
- Include brief explanations or links where helpful
73+
- Each `/checklist` run creates a NEW file (never overwrites existing checklists)
74+
75+
6. **Checklist structure**:
76+
```markdown
77+
# [Checklist Type] Checklist: [Feature Name]
78+
79+
**Purpose**: [Brief description of what this checklist covers]
80+
**Created**: [Date]
81+
82+
## [Category 1]
83+
- [ ] CHK001 First item
84+
- [ ] CHK002 Second item
85+
86+
## [Category 2]
87+
- [ ] CHK003 Third item
88+
```
89+
90+
7. **Report**: Output full path to created checklist, item count, and remind user that each run creates a new file. Summarize:
91+
- Focus areas selected
92+
- Depth level
93+
- Actor/timing
94+
- Any explicit user-specified must-have items incorporated
95+
96+
**Important**: Each `/checklist` command invocation creates a NEW checklist file using short, descriptive names. This allows:
97+
- Multiple checklists of different types (e.g., `ux.md`, `test.md`, `security.md`)
98+
- Simple, memorable filenames that indicate checklist purpose
99+
- Counter-based uniqueness for duplicate types (e.g., `review-2.md`)
100+
- Easy identification and navigation in the checklists/ folder
101+
102+
To avoid clutter, use descriptive types and clean up obsolete checklists when done.
103+
104+
## Example Checklist Types
105+
106+
**Code Review:** `review.md`
107+
- Code quality checks
108+
- Documentation requirements
109+
- Test coverage verification
110+
- Security considerations
111+
112+
**Pre-Deployment:** `deploy.md`
113+
- Build verification
114+
- Test execution
115+
- Configuration validation
116+
- Rollback plan
117+
118+
**Accessibility:** `ux.md` or `a11y.md`
119+
- WCAG compliance
120+
- Keyboard navigation
121+
- Screen reader compatibility
122+
- Color contrast
123+
124+
**Security:** `security.md`
125+
- Input validation
126+
- Authentication/authorization
127+
- Data encryption
128+
- Dependency vulnerabilities
129+
130+
Generate checklist items that are specific, actionable, and relevant to the feature context.

‎templates/commands/clarify.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ The user input to you can be provided directly by the agent or as a command argu
99

1010
User input:
1111

12-
$ARGUMENTS
12+
`$ARGUMENTS`
1313

1414
Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.
1515

‎templates/commands/constitution.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ The user input to you can be provided directly by the agent or as a command argu
66

77
User input:
88

9-
$ARGUMENTS
9+
`$ARGUMENTS`
1010

1111
You are updating the project constitution at `/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
1212

‎templates/commands/implement.md‎

Lines changed: 36 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -9,47 +9,76 @@ The user input can be provided directly by the agent or as a command argument -
99

1010
User input:
1111

12-
$ARGUMENTS
12+
`$ARGUMENTS`
1313

1414
1. Run `{SCRIPT}` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
1515

16-
2. Load and analyze the implementation context:
16+
2. **Check checklists status** (if FEATURE_DIR/checklists/ exists):
17+
- Scan all checklist files in the checklists/ directory
18+
- For each checklist, count:
19+
* Total items: All lines matching `- [ ]` or `- [X]` or `- [x]`
20+
* Completed items: Lines matching `- [X]` or `- [x]`
21+
* Incomplete items: Lines matching `- [ ]`
22+
- Create a status table:
23+
```
24+
| Checklist | Total | Completed | Incomplete | Status |
25+
|-----------|-------|-----------|------------|--------|
26+
| ux.md | 12 | 12 | 0 | ✓ PASS |
27+
| test.md | 8 | 5 | 3 | ✗ FAIL |
28+
| security.md | 6 | 6 | 0 | ✓ PASS |
29+
```
30+
- Calculate overall status:
31+
* **PASS**: All checklists have 0 incomplete items
32+
* **FAIL**: One or more checklists have incomplete items
33+
34+
- **If any checklist is incomplete**:
35+
* Display the table with incomplete item counts
36+
* **STOP** and ask: "Some checklists are incomplete. Do you want to proceed with implementation anyway? (yes/no)"
37+
* Wait for user response before continuing
38+
* If user says "no" or "wait" or "stop", halt execution
39+
* If user says "yes" or "proceed" or "continue", proceed to step 3
40+
41+
- **If all checklists are complete**:
42+
* Display the table showing all checklists passed
43+
* Automatically proceed to step 3
44+
45+
3. Load and analyze the implementation context:
1746
- **REQUIRED**: Read tasks.md for the complete task list and execution plan
1847
- **REQUIRED**: Read plan.md for tech stack, architecture, and file structure
1948
- **IF EXISTS**: Read data-model.md for entities and relationships
2049
- **IF EXISTS**: Read contracts/ for API specifications and test requirements
2150
- **IF EXISTS**: Read research.md for technical decisions and constraints
2251
- **IF EXISTS**: Read quickstart.md for integration scenarios
2352
24-
3. Parse tasks.md structure and extract:
53+
4. Parse tasks.md structure and extract:
2554
- **Task phases**: Setup, Tests, Core, Integration, Polish
2655
- **Task dependencies**: Sequential vs parallel execution rules
2756
- **Task details**: ID, description, file paths, parallel markers [P]
2857
- **Execution flow**: Order and dependency requirements
2958
30-
4. Execute implementation following the task plan:
59+
5. Execute implementation following the task plan:
3160
- **Phase-by-phase execution**: Complete each phase before moving to the next
3261
- **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together
3362
- **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
3463
- **File-based coordination**: Tasks affecting the same files must run sequentially
3564
- **Validation checkpoints**: Verify each phase completion before proceeding
3665
37-
5. Implementation execution rules:
66+
6. Implementation execution rules:
3867
- **Setup first**: Initialize project structure, dependencies, configuration
3968
- **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
4069
- **Core development**: Implement models, services, CLI commands, endpoints
4170
- **Integration work**: Database connections, middleware, logging, external services
4271
- **Polish and validation**: Unit tests, performance optimization, documentation
4372
44-
6. Progress tracking and error handling:
73+
7. Progress tracking and error handling:
4574
- Report progress after each completed task
4675
- Halt execution if any non-parallel task fails
4776
- For parallel tasks [P], continue with successful tasks, report failed ones
4877
- Provide clear error messages with context for debugging
4978
- Suggest next steps if implementation cannot proceed
5079
- **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file.
5180
52-
7. Completion validation:
81+
8. Completion validation:
5382
- Verify all required tasks are completed
5483
- Check that implemented features match the original specification
5584
- Validate that tests pass and coverage meets requirements

‎templates/commands/plan.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ The user input to you can be provided directly by the agent or as a command argu
1212

1313
User input:
1414

15-
$ARGUMENTS
15+
`$ARGUMENTS`
1616

1717
## Execution Steps
1818

‎templates/commands/specify.md‎

Lines changed: 6 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ The user input to you can be provided directly by the agent or as a command argu
99

1010
User input:
1111

12-
$ARGUMENTS
12+
`$ARGUMENTS`
1313

1414
The text the user typed after `/specify` in the triggering message **is** the feature description. Assume you always have it available in this conversation even if `{ARGS}` appears literally below. Do not ask the user to repeat it unless they provided an empty command.
1515

@@ -33,10 +33,7 @@ Given that feature description, do this:
3333
Each requirement must be testable
3434
Mark ambiguous requirements
3535
6. Identify Key Entities (if data involved)
36-
7. Run Review Checklist
37-
If any [NEEDS CLARIFICATION]: WARN "Spec has uncertainties"
38-
If implementation details found: ERROR "Remove tech details"
39-
8. Return: SUCCESS (spec ready for planning)
36+
7. Return: SUCCESS (spec ready for planning)
4037

4138
4. Write the specification to SPEC_FILE using the template structure, replacing placeholders with concrete details derived from the feature description (arguments) while preserving section order and headings.
4239
5. Report completion with branch name, spec file path, and readiness for the next phase.
@@ -47,9 +44,10 @@ Given that feature description, do this:
4744

4845
## Quick Guidelines
4946

50-
- Focus on WHAT users need and WHY
51-
- Avoid HOW to implement (no tech stack, APIs, code structure)
52-
- Written for business stakeholders, not developers
47+
- Focus on **WHAT** users need and **WHY**.
48+
- Avoid HOW to implement (no tech stack, APIs, code structure).
49+
- Written for business stakeholders, not developers.
50+
- DO NOT create any checklists that are embedded in the spec. That will be a separate command.
5351

5452
### Section Requirements
5553

‎templates/commands/tasks.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ The user input to you can be provided directly by the agent or as a command argu
99

1010
User input:
1111

12-
$ARGUMENTS
12+
`$ARGUMENTS`
1313

1414
## Execution Steps
1515

0 commit comments

Comments
 (0)