@aslomon/effectum 0.1.2 → 0.1.3
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/package.json +1 -1
- package/system/commands/prd/decompose.md +88 -0
- package/system/commands/prd/discuss.md +65 -0
- package/system/commands/prd/express.md +81 -0
- package/system/commands/prd/handoff.md +82 -0
- package/system/commands/prd/network-map.md +70 -0
- package/system/commands/prd/new.md +71 -0
- package/system/commands/prd/prompt.md +62 -0
- package/system/commands/prd/resume.md +62 -0
- package/system/commands/prd/review.md +59 -0
- package/system/commands/prd/status.md +63 -0
- package/system/commands/setup.md +158 -0
- package/system/commands/workshop/archive.md +58 -0
- package/system/commands/workshop/init.md +78 -0
package/package.json
CHANGED
|
@@ -0,0 +1,88 @@
|
|
|
1
|
+
# /prd:decompose — Split Large Scope into Multiple PRDs (Phase 3)
|
|
2
|
+
|
|
3
|
+
You break down a large project scope into manageable, individually implementable PRDs.
|
|
4
|
+
|
|
5
|
+
## Step 1: Load Project
|
|
6
|
+
|
|
7
|
+
Interpret `$ARGUMENTS` as project-slug.
|
|
8
|
+
|
|
9
|
+
- If empty: List available projects, ask the user.
|
|
10
|
+
- Validate that `workshop/projects/{slug}/` exists.
|
|
11
|
+
|
|
12
|
+
Read the current project state:
|
|
13
|
+
|
|
14
|
+
- `workshop/projects/{slug}/PROJECT.md`
|
|
15
|
+
- `workshop/projects/{slug}/vision.md` (if present)
|
|
16
|
+
- `workshop/projects/{slug}/requirements-map.md` (if present)
|
|
17
|
+
- Existing PRDs under `workshop/projects/{slug}/prds/`
|
|
18
|
+
|
|
19
|
+
## Step 2: Load Decomposition Guide
|
|
20
|
+
|
|
21
|
+
Read `workshop/knowledge/03-decomposition-guide.md` for strategies and signals.
|
|
22
|
+
|
|
23
|
+
## Step 3: Check Decomposition Signals
|
|
24
|
+
|
|
25
|
+
Analyze the scope for decomposition signals:
|
|
26
|
+
|
|
27
|
+
- More than 8 acceptance criteria total
|
|
28
|
+
- Independent user journeys identifiable
|
|
29
|
+
- Different bounded contexts / domains
|
|
30
|
+
- Different technical layers (frontend, backend, data)
|
|
31
|
+
- Features with different priorities / timelines
|
|
32
|
+
- Different risk levels
|
|
33
|
+
|
|
34
|
+
If no clear signals: Inform the user that a single PRD might suffice. Ask whether to decompose anyway.
|
|
35
|
+
|
|
36
|
+
## Step 4: Propose Decomposition Strategy
|
|
37
|
+
|
|
38
|
+
Propose one or more strategies:
|
|
39
|
+
|
|
40
|
+
| Strategy | When | Example |
|
|
41
|
+
| ---------------------- | -------------------------- | ------------------------------------------------ |
|
|
42
|
+
| **Domain-based** | Different bounded contexts | Auth PRD, Billing PRD, Dashboard PRD |
|
|
43
|
+
| **User-Journey-based** | Independent user flows | Onboarding PRD, Core Workflow PRD, Reporting PRD |
|
|
44
|
+
| **Phase-based** | Natural sequence | MVP PRD, Enhancement PRD, Scale PRD |
|
|
45
|
+
| **Layer-based** | Clear tech separation | Data Model PRD, API PRD, Frontend PRD |
|
|
46
|
+
|
|
47
|
+
Explain to the user why you recommend this strategy.
|
|
48
|
+
|
|
49
|
+
## Step 5: Discussion and Adjustment
|
|
50
|
+
|
|
51
|
+
Discuss the proposed decomposition with the user:
|
|
52
|
+
|
|
53
|
+
- Show the proposed PRDs with title and brief description.
|
|
54
|
+
- Show which requirements / features belong to which PRD.
|
|
55
|
+
- Show dependencies between the PRDs.
|
|
56
|
+
- Let the user adjust the split (merge, split further, regroup).
|
|
57
|
+
|
|
58
|
+
## Step 6: Create/Update Files
|
|
59
|
+
|
|
60
|
+
After agreement:
|
|
61
|
+
|
|
62
|
+
1. **Vision Document** (`vision.md`): Update or create the project vision document with the overall picture.
|
|
63
|
+
|
|
64
|
+
2. **Requirements Map** (`requirements-map.md`): Create the assignment table — which requirements/features belong to which PRD.
|
|
65
|
+
|
|
66
|
+
3. **Network Map** (`network-map.mmd`): Create an initial Network Map (Stage 2) with PRD boundaries, per `workshop/knowledge/06-network-map-guide.md`.
|
|
67
|
+
|
|
68
|
+
4. **PRD Stubs** (`prds/{number}-{name}.md`): Create a stub file for each identified PRD with:
|
|
69
|
+
- Title and brief description
|
|
70
|
+
- Assigned requirements from the Requirements Map
|
|
71
|
+
- Known dependencies on other PRDs
|
|
72
|
+
- Status: `stub`
|
|
73
|
+
|
|
74
|
+
5. **PROJECT.md**: Update with the complete PRD list and status `decomposing` → `drafting`.
|
|
75
|
+
|
|
76
|
+
## Step 7: Next Steps
|
|
77
|
+
|
|
78
|
+
Show the user:
|
|
79
|
+
|
|
80
|
+
1. The final decomposition as an overview.
|
|
81
|
+
2. A recommended processing order (dependency-based).
|
|
82
|
+
3. Suggest starting with `/prd:discuss {slug}/001` for the first PRD.
|
|
83
|
+
|
|
84
|
+
## Communication
|
|
85
|
+
|
|
86
|
+
Follow the language settings defined in CLAUDE.md.
|
|
87
|
+
All file content must be written in English.
|
|
88
|
+
User-facing communication uses the language configured in CLAUDE.md.
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
# /prd:discuss — Deep-Dive Discussion for a Specific PRD (Phase 4)
|
|
2
|
+
|
|
3
|
+
You conduct an in-depth discussion about a specific PRD. Goal: maximum understanding, clarify all details.
|
|
4
|
+
|
|
5
|
+
## Step 1: Load PRD
|
|
6
|
+
|
|
7
|
+
Interpret `$ARGUMENTS`:
|
|
8
|
+
|
|
9
|
+
- Format `project-slug/001` → Read `workshop/projects/{project-slug}/prds/001-*.md`
|
|
10
|
+
- Format as file path → Read the file directly
|
|
11
|
+
- If empty or unclear: List available projects and PRDs, ask the user.
|
|
12
|
+
|
|
13
|
+
Read the PRD completely.
|
|
14
|
+
|
|
15
|
+
## Step 2: Load Questioning Framework
|
|
16
|
+
|
|
17
|
+
Read `workshop/knowledge/02-questioning-framework.md`, specifically the Phase 4 section (Feature Deep-Dive).
|
|
18
|
+
|
|
19
|
+
## Step 3: Identify Feature Type
|
|
20
|
+
|
|
21
|
+
Determine the primary feature type of the PRD:
|
|
22
|
+
|
|
23
|
+
- **UI/Frontend**: Screens, components, interactions, responsive behavior
|
|
24
|
+
- **API/Backend**: Endpoints, business logic, data processing
|
|
25
|
+
- **Data/Storage**: Data models, migrations, queries, caching
|
|
26
|
+
- **Integration**: Third-party services, webhooks, OAuth, external APIs
|
|
27
|
+
- **AI/ML**: Prompts, models, pipelines, feedback loops
|
|
28
|
+
|
|
29
|
+
## Step 4: Ask Type-Specific Questions
|
|
30
|
+
|
|
31
|
+
Ask questions appropriate to the feature type. There is no fixed limit — ask as many questions as needed until the feature is fully understood.
|
|
32
|
+
|
|
33
|
+
Rules for the discussion:
|
|
34
|
+
|
|
35
|
+
- Ask 2-3 questions per round, no more.
|
|
36
|
+
- Accept all response formats:
|
|
37
|
+
- Detailed answers → process fully.
|
|
38
|
+
- Short answers ("yes", "standard", "as usual") → derive sensible defaults.
|
|
39
|
+
- "Skip that" → mark as `[NEEDS CLARIFICATION]` in the PRD and move on.
|
|
40
|
+
- Summarize your current understanding after each round.
|
|
41
|
+
- Let the user correct before proceeding.
|
|
42
|
+
- Go deep where needed — superficiality is worse than too many questions.
|
|
43
|
+
|
|
44
|
+
## Step 5: Update PRD
|
|
45
|
+
|
|
46
|
+
After the discussion (or after significant insights in between):
|
|
47
|
+
|
|
48
|
+
1. Update the PRD with the new details.
|
|
49
|
+
2. Replace existing `[ASSUMPTION]` markers with clarified information.
|
|
50
|
+
3. Add new `[ASSUMPTION]` or `[NEEDS CLARIFICATION]` markers where needed.
|
|
51
|
+
4. Update Acceptance Criteria, Scope, Data Model, etc.
|
|
52
|
+
|
|
53
|
+
## Step 6: Check Network Map
|
|
54
|
+
|
|
55
|
+
Read `workshop/projects/{slug}/network-map.mmd` if it exists.
|
|
56
|
+
If the discussion uncovered new connections, dependencies, or components:
|
|
57
|
+
|
|
58
|
+
- Update `network-map.mmd` accordingly.
|
|
59
|
+
- Inform the user about the changes.
|
|
60
|
+
|
|
61
|
+
## Communication
|
|
62
|
+
|
|
63
|
+
Follow the language settings defined in CLAUDE.md.
|
|
64
|
+
All file content must be written in English.
|
|
65
|
+
User-facing communication uses the language configured in CLAUDE.md.
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
# /prd:express — Quick PRD from Structured/Semi-Structured Input
|
|
2
|
+
|
|
3
|
+
You create a complete PRD from an already relatively clear feature input. Minimal follow-up questions, maximum inference.
|
|
4
|
+
|
|
5
|
+
## Step 1: Analyze Input
|
|
6
|
+
|
|
7
|
+
Read `$ARGUMENTS` as a feature description.
|
|
8
|
+
|
|
9
|
+
If empty: Ask the user for a feature description. Briefly explain that Express is intended for features that are already relatively clear.
|
|
10
|
+
|
|
11
|
+
Parse the input for existing structure:
|
|
12
|
+
|
|
13
|
+
- User Stories / Job Stories
|
|
14
|
+
- Acceptance Criteria
|
|
15
|
+
- Scope / Boundaries
|
|
16
|
+
- Technical details
|
|
17
|
+
- Data model hints
|
|
18
|
+
- Integrations
|
|
19
|
+
|
|
20
|
+
## Step 2: Determine Project
|
|
21
|
+
|
|
22
|
+
Check if a matching project exists under `workshop/projects/`:
|
|
23
|
+
|
|
24
|
+
- If yes: Assign the PRD there.
|
|
25
|
+
- If no: Create a new project (like `/workshop:init`). Derive the slug from the feature description.
|
|
26
|
+
|
|
27
|
+
## Step 3: Generate PRD
|
|
28
|
+
|
|
29
|
+
Read `workshop/knowledge/01-prd-template.md` for the template.
|
|
30
|
+
|
|
31
|
+
Fill out the template intelligently:
|
|
32
|
+
|
|
33
|
+
1. **Title and Problem Statement**: Derive from the description.
|
|
34
|
+
2. **User Stories**: Adopt existing ones or generate from the description.
|
|
35
|
+
3. **Acceptance Criteria**: Adopt existing ones or derive from described behavior.
|
|
36
|
+
4. **Scope**: Clearly define what is in-scope.
|
|
37
|
+
5. **Non-Goals**: Proactively suggest — what is explicitly NOT part of this feature?
|
|
38
|
+
6. **Data Model**: If data persistence is involved, suggest tables/fields.
|
|
39
|
+
7. **API Contracts**: If API endpoints are needed, suggest them.
|
|
40
|
+
8. **Quality Gates**: Set sensible defaults (tests, performance, accessibility).
|
|
41
|
+
9. **Autonomy Rules**: Define what the implementing agent may decide on its own.
|
|
42
|
+
10. **Completion Promise**: Clear definition of "done".
|
|
43
|
+
|
|
44
|
+
## Step 4: Mark Assumptions
|
|
45
|
+
|
|
46
|
+
Mark ALL assumptions with `[ASSUMPTION]` at the end of the PRD in a dedicated section.
|
|
47
|
+
Group them by category:
|
|
48
|
+
|
|
49
|
+
- Business/Product Assumptions
|
|
50
|
+
- Technical Assumptions
|
|
51
|
+
- Scope Assumptions
|
|
52
|
+
|
|
53
|
+
## Step 5: Determine Workflow Mode
|
|
54
|
+
|
|
55
|
+
Read `workshop/knowledge/08-workflow-modes.md`.
|
|
56
|
+
Determine the appropriate workflow mode for the implementation.
|
|
57
|
+
|
|
58
|
+
## Step 6: Save Files
|
|
59
|
+
|
|
60
|
+
1. Save the PRD under `workshop/projects/{slug}/prds/{number}-{name}.md`.
|
|
61
|
+
2. Update `PROJECT.md` with the new PRD.
|
|
62
|
+
|
|
63
|
+
## Step 7: Generate Handoff Prompt
|
|
64
|
+
|
|
65
|
+
Read `workshop/knowledge/07-prompt-templates.md`.
|
|
66
|
+
Immediately generate a handoff prompt and save it under `workshop/projects/{slug}/prompts/{number}-{name}-handoff.md`.
|
|
67
|
+
|
|
68
|
+
## Step 8: Present Result
|
|
69
|
+
|
|
70
|
+
Show the user:
|
|
71
|
+
|
|
72
|
+
1. The generated PRD (complete or summary).
|
|
73
|
+
2. List of all assumptions — the user should confirm or correct these.
|
|
74
|
+
3. The chosen workflow mode with justification.
|
|
75
|
+
4. Next steps: recommend review (`/prd:review`) or direct handoff.
|
|
76
|
+
|
|
77
|
+
## Communication
|
|
78
|
+
|
|
79
|
+
Follow the language settings defined in CLAUDE.md.
|
|
80
|
+
All file content must be written in English.
|
|
81
|
+
User-facing communication uses the language configured in CLAUDE.md.
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
# /prd:handoff — Hand Off PRD to the Target Project
|
|
2
|
+
|
|
3
|
+
You export a completed PRD as a handoff package for implementation in the target project.
|
|
4
|
+
|
|
5
|
+
## Step 1: Load PRD and Check Readiness
|
|
6
|
+
|
|
7
|
+
Interpret `$ARGUMENTS` as `project-slug/001`.
|
|
8
|
+
|
|
9
|
+
- If empty or unclear: List available projects and PRDs, ask the user.
|
|
10
|
+
|
|
11
|
+
Read the PRD: `workshop/projects/{project-slug}/prds/001-*.md`
|
|
12
|
+
|
|
13
|
+
Check the readiness score:
|
|
14
|
+
|
|
15
|
+
- If no review has been performed yet: Automatically perform a review (like `/prd:review`). Read `workshop/knowledge/05-quality-checklist.md` for this.
|
|
16
|
+
- If score < 2.0: Warn the user and ask whether to proceed anyway. List the weaknesses.
|
|
17
|
+
- If score >= 2.0: Proceed.
|
|
18
|
+
|
|
19
|
+
## Step 2: Load Project Information
|
|
20
|
+
|
|
21
|
+
Read `workshop/projects/{slug}/PROJECT.md` for:
|
|
22
|
+
|
|
23
|
+
- `target_repo`: Path to the target repository
|
|
24
|
+
- Project context and tech stack information
|
|
25
|
+
|
|
26
|
+
## Step 3: Determine Workflow Mode
|
|
27
|
+
|
|
28
|
+
Read `workshop/knowledge/08-workflow-modes.md` for the decision matrix.
|
|
29
|
+
|
|
30
|
+
Determine the appropriate mode based on:
|
|
31
|
+
|
|
32
|
+
- PRD complexity
|
|
33
|
+
- Number of affected files
|
|
34
|
+
- Risk level
|
|
35
|
+
- User preference (if known)
|
|
36
|
+
|
|
37
|
+
Possible modes:
|
|
38
|
+
|
|
39
|
+
- **Standard Session**: Normal Claude Code session with the PRD as context
|
|
40
|
+
- **Full-Auto**: Autonomous implementation with defined checkpoints
|
|
41
|
+
- **Ralph Loop**: Iterative Review-Adjust-Learn-Polish-Harden cycle
|
|
42
|
+
|
|
43
|
+
## Step 4: Generate Handoff Prompt
|
|
44
|
+
|
|
45
|
+
Read `workshop/knowledge/07-prompt-templates.md` for the appropriate template.
|
|
46
|
+
|
|
47
|
+
Generate the complete handoff prompt:
|
|
48
|
+
|
|
49
|
+
1. Embed or reference the PRD content.
|
|
50
|
+
2. Workflow instructions according to the chosen mode.
|
|
51
|
+
3. Adopt Quality Gates and Completion Criteria from the PRD.
|
|
52
|
+
4. Include tech stack context from PROJECT.md.
|
|
53
|
+
|
|
54
|
+
## Step 5: Save Files
|
|
55
|
+
|
|
56
|
+
Save the prompt under: `workshop/projects/{slug}/prompts/{number}-{name}-handoff.md`
|
|
57
|
+
|
|
58
|
+
## Step 6: Serve Target Repository (optional)
|
|
59
|
+
|
|
60
|
+
If `target_repo` is defined in PROJECT.md and the path exists:
|
|
61
|
+
|
|
62
|
+
- Ask the user whether PRD and prompt should be copied there.
|
|
63
|
+
- If yes: Copy both files to the target repository (e.g., under `docs/prds/`).
|
|
64
|
+
|
|
65
|
+
## Step 7: Update Status
|
|
66
|
+
|
|
67
|
+
Update the PRD status in `PROJECT.md` to `handed-off`.
|
|
68
|
+
|
|
69
|
+
## Step 8: Show Next Steps
|
|
70
|
+
|
|
71
|
+
Show the user:
|
|
72
|
+
|
|
73
|
+
1. Where the handoff prompt was saved.
|
|
74
|
+
2. How the prompt is used in the target project (brief instructions).
|
|
75
|
+
3. The chosen workflow mode and why.
|
|
76
|
+
4. If additional PRDs are open in the project: what comes next.
|
|
77
|
+
|
|
78
|
+
## Communication
|
|
79
|
+
|
|
80
|
+
Follow the language settings defined in CLAUDE.md.
|
|
81
|
+
All file content must be written in English.
|
|
82
|
+
User-facing communication uses the language configured in CLAUDE.md.
|
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
# /prd:network-map — Create or Update the Project Network Map
|
|
2
|
+
|
|
3
|
+
You create or update the visual network map of a project as a Mermaid diagram.
|
|
4
|
+
|
|
5
|
+
## Step 1: Identify Project
|
|
6
|
+
|
|
7
|
+
Interpret `$ARGUMENTS` as project-slug.
|
|
8
|
+
|
|
9
|
+
- If empty: List available projects, ask the user.
|
|
10
|
+
- Validate that `workshop/projects/{slug}/` exists.
|
|
11
|
+
|
|
12
|
+
## Step 2: Load Project Data
|
|
13
|
+
|
|
14
|
+
Read all relevant files:
|
|
15
|
+
|
|
16
|
+
- All PRDs under `workshop/projects/{slug}/prds/*.md`
|
|
17
|
+
- `workshop/projects/{slug}/vision.md` if present
|
|
18
|
+
- `workshop/projects/{slug}/requirements-map.md` if present
|
|
19
|
+
- `workshop/projects/{slug}/network-map.mmd` if present (existing map)
|
|
20
|
+
|
|
21
|
+
## Step 3: Load Conventions
|
|
22
|
+
|
|
23
|
+
Read `workshop/knowledge/06-network-map-guide.md` for the Mermaid conventions and styling rules.
|
|
24
|
+
|
|
25
|
+
## Step 4: Determine Stage
|
|
26
|
+
|
|
27
|
+
Determine the appropriate level of detail based on the project status:
|
|
28
|
+
|
|
29
|
+
| Stage | When | Content |
|
|
30
|
+
| ------------------ | ------------------- | ------------------------------------------------ |
|
|
31
|
+
| 1 — Feature Map | Early discovery | Only features and their relationships |
|
|
32
|
+
| 2 — PRD Boundaries | After decomposition | Features grouped into PRD boundaries |
|
|
33
|
+
| 3 — Full Technical | PRDs in detail | Data models, APIs, external services, tech stack |
|
|
34
|
+
|
|
35
|
+
## Step 5: Analyze Network
|
|
36
|
+
|
|
37
|
+
Identify and catalog:
|
|
38
|
+
|
|
39
|
+
- **Features/Modules**: All described functionalities
|
|
40
|
+
- **Data Entities**: Tables, models, schemas
|
|
41
|
+
- **External Services**: Third-party APIs, auth providers, payment, etc.
|
|
42
|
+
- **Connections**: Dependencies, data flows, event chains
|
|
43
|
+
- **PRD Assignment**: Which feature belongs to which PRD
|
|
44
|
+
|
|
45
|
+
## Step 6: Generate Mermaid Diagram
|
|
46
|
+
|
|
47
|
+
Create the diagram according to the conventions from the guide:
|
|
48
|
+
|
|
49
|
+
- Use status colors: `planned` (gray), `inProgress` (blue), `done` (green)
|
|
50
|
+
- Group with `subgraph` for PRD boundaries
|
|
51
|
+
- Label edges with relationship types
|
|
52
|
+
- Keep the diagram readable — split or simplify if >20 nodes
|
|
53
|
+
|
|
54
|
+
## Step 7: Write File
|
|
55
|
+
|
|
56
|
+
Write the updated Network Map to `workshop/projects/{slug}/network-map.mmd`.
|
|
57
|
+
|
|
58
|
+
## Step 8: Display Result
|
|
59
|
+
|
|
60
|
+
Show the user:
|
|
61
|
+
|
|
62
|
+
1. The complete Mermaid source in a code block.
|
|
63
|
+
2. A brief summary: number of features, PRDs, connections, identified dependencies.
|
|
64
|
+
3. Notes on potential issues (circular dependencies, isolated nodes, too many connections).
|
|
65
|
+
|
|
66
|
+
## Communication
|
|
67
|
+
|
|
68
|
+
Follow the language settings defined in CLAUDE.md.
|
|
69
|
+
All file content must be written in English.
|
|
70
|
+
User-facing communication uses the language configured in CLAUDE.md.
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
# /prd:new — Start a New Project or PRD
|
|
2
|
+
|
|
3
|
+
You start a new PRD workshop session. Work interactively and adaptively with the user.
|
|
4
|
+
|
|
5
|
+
## Step 1: Check Input
|
|
6
|
+
|
|
7
|
+
If `$ARGUMENTS` is empty, ask: **[in configured language] "What do you want to build?"** — wait for a response before proceeding.
|
|
8
|
+
|
|
9
|
+
If `$ARGUMENTS` is provided, analyze the input:
|
|
10
|
+
|
|
11
|
+
- **Workshop Mode** (vague description, idea, problem): Start the full workshop process with Phase 1.
|
|
12
|
+
- **Express Mode** (specific feature with clear scope): Redirect to `/prd:express`.
|
|
13
|
+
|
|
14
|
+
## Step 2: Create New Project or Use Existing One
|
|
15
|
+
|
|
16
|
+
Check if a matching project already exists under `workshop/projects/`.
|
|
17
|
+
|
|
18
|
+
- **New project**: Create the project structure following the `/workshop:init` pattern:
|
|
19
|
+
1. Derive a slug from the project name (lowercase, hyphens, no spaces).
|
|
20
|
+
2. Create `workshop/projects/{slug}/` with subdirectories `prds/`, `prompts/`, `notes/`.
|
|
21
|
+
3. Create `PROJECT.md` from `workshop/templates/PROJECT.md` with slug and today's date.
|
|
22
|
+
4. Create `notes/discovery-log.md` and `notes/decisions.md` as empty files.
|
|
23
|
+
5. Set status to `discovery`.
|
|
24
|
+
|
|
25
|
+
- **Existing project**: Read `PROJECT.md` and determine the current state.
|
|
26
|
+
|
|
27
|
+
## Step 3: Start Discovery Phase (Phase 1 — Vision & Problem Discovery)
|
|
28
|
+
|
|
29
|
+
Read `workshop/knowledge/02-questioning-framework.md` for the question progression.
|
|
30
|
+
|
|
31
|
+
Begin Phase 1 with adaptive questions:
|
|
32
|
+
|
|
33
|
+
- Ask 2-3 questions at a time, no more.
|
|
34
|
+
- Adapt follow-up questions to the responses.
|
|
35
|
+
- Accept short answers ("yes", "standard", "skip that").
|
|
36
|
+
- Summarize your understanding after each round and let the user correct.
|
|
37
|
+
- Record key insights in `notes/discovery-log.md`.
|
|
38
|
+
|
|
39
|
+
## Step 4: Progress Through Phases
|
|
40
|
+
|
|
41
|
+
Work through the phases:
|
|
42
|
+
|
|
43
|
+
1. **Vision & Problem Discovery** → Save result in `vision.md`
|
|
44
|
+
2. **Scope & Requirements** → Save in `requirements-map.md`
|
|
45
|
+
3. **Decomposition Check**: If the scope is large (>8 ACs, multiple independent journeys, different bounded contexts), suggest decomposition and reference `workshop/knowledge/03-decomposition-guide.md`.
|
|
46
|
+
4. **Create Network Map** → `network-map.mmd` per `workshop/knowledge/06-network-map-guide.md`
|
|
47
|
+
|
|
48
|
+
After each phase:
|
|
49
|
+
|
|
50
|
+
- Save results to the corresponding files.
|
|
51
|
+
- Update `PROJECT.md` with the new status.
|
|
52
|
+
|
|
53
|
+
## Step 5: Write PRD
|
|
54
|
+
|
|
55
|
+
When the scope is clear:
|
|
56
|
+
|
|
57
|
+
1. Read `workshop/knowledge/01-prd-template.md` for the template.
|
|
58
|
+
2. Guide the user through PRD creation:
|
|
59
|
+
- Title, Problem Statement, User Stories
|
|
60
|
+
- Acceptance Criteria, Scope/Non-Goals
|
|
61
|
+
- Data Model (if data persistence is involved), API Contracts
|
|
62
|
+
- Quality Gates, Autonomy Rules, Completion Promise
|
|
63
|
+
3. Mark open items with `[ASSUMPTION]` or `[NEEDS CLARIFICATION]`.
|
|
64
|
+
4. Save PRD under `workshop/projects/{slug}/prds/{number}-{name}.md`.
|
|
65
|
+
5. Update `PROJECT.md`.
|
|
66
|
+
|
|
67
|
+
## Communication
|
|
68
|
+
|
|
69
|
+
Follow the language settings defined in CLAUDE.md.
|
|
70
|
+
All file content must be written in English.
|
|
71
|
+
User-facing communication uses the language configured in CLAUDE.md.
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# /prd:prompt — Generate Handoff Prompt for a PRD
|
|
2
|
+
|
|
3
|
+
You generate a handoff prompt for a PRD without performing the full export process.
|
|
4
|
+
|
|
5
|
+
## Step 1: Load PRD
|
|
6
|
+
|
|
7
|
+
Interpret `$ARGUMENTS` as `project-slug/001`.
|
|
8
|
+
|
|
9
|
+
- If empty or unclear: List available projects and PRDs, ask the user.
|
|
10
|
+
|
|
11
|
+
Read the PRD: `workshop/projects/{project-slug}/prds/001-*.md`
|
|
12
|
+
|
|
13
|
+
## Step 2: Determine Workflow Mode
|
|
14
|
+
|
|
15
|
+
Read `workshop/knowledge/08-workflow-modes.md` for the decision matrix.
|
|
16
|
+
|
|
17
|
+
Evaluate the PRD against the matrix criteria:
|
|
18
|
+
|
|
19
|
+
- **Complexity**: Number of ACs, data model scope, integrations
|
|
20
|
+
- **Risk**: New technologies, security-relevant, critical path
|
|
21
|
+
- **File Impact**: How many files are expected to be affected
|
|
22
|
+
- **Autonomy Level**: How much can be implemented without follow-up questions
|
|
23
|
+
|
|
24
|
+
Determine the mode:
|
|
25
|
+
|
|
26
|
+
- **Standard Session**: Moderate complexity, user wants to collaborate
|
|
27
|
+
- **Full-Auto**: Clearly defined, low risk, high autonomy
|
|
28
|
+
- **Ralph Loop**: Complex, high risk, iterative approach needed
|
|
29
|
+
|
|
30
|
+
## Step 3: Generate Prompt
|
|
31
|
+
|
|
32
|
+
Read `workshop/knowledge/07-prompt-templates.md` for the appropriate template.
|
|
33
|
+
|
|
34
|
+
Build the complete prompt:
|
|
35
|
+
|
|
36
|
+
1. **Context Section**: Project name, tech stack, relevant context from PROJECT.md.
|
|
37
|
+
2. **PRD Content**: Embed the complete PRD.
|
|
38
|
+
3. **Workflow Instructions**: According to the chosen mode.
|
|
39
|
+
4. **Quality Gates**: Quality criteria adopted from the PRD.
|
|
40
|
+
5. **Completion Criteria**: When is the implementation done.
|
|
41
|
+
6. **Autonomy Rules**: What the implementing agent may decide on its own.
|
|
42
|
+
|
|
43
|
+
## Step 4: Save Prompt
|
|
44
|
+
|
|
45
|
+
Save the prompt under: `workshop/projects/{slug}/prompts/{number}-{name}-handoff.md`
|
|
46
|
+
|
|
47
|
+
## Step 5: Display Prompt
|
|
48
|
+
|
|
49
|
+
Show the complete prompt in a code block so the user can easily copy it.
|
|
50
|
+
|
|
51
|
+
## Step 6: Explain Mode
|
|
52
|
+
|
|
53
|
+
Briefly explain (2-3 sentences) why this workflow mode was chosen. For example:
|
|
54
|
+
|
|
55
|
+
- "Full-Auto, because the PRD is clearly defined, affects few files, and has no external dependencies."
|
|
56
|
+
- "Ralph Loop, because the feature is security-critical and needs iterative review."
|
|
57
|
+
|
|
58
|
+
## Communication
|
|
59
|
+
|
|
60
|
+
Follow the language settings defined in CLAUDE.md.
|
|
61
|
+
All file content must be written in English.
|
|
62
|
+
User-facing communication uses the language configured in CLAUDE.md.
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# /prd:resume — Resume Work on an Existing Project/PRD
|
|
2
|
+
|
|
3
|
+
You resume work on an existing project or PRD. Read the current state, summarize, and continue where things left off.
|
|
4
|
+
|
|
5
|
+
## Step 1: Identify Project
|
|
6
|
+
|
|
7
|
+
Interpret `$ARGUMENTS`:
|
|
8
|
+
|
|
9
|
+
- Format `project-slug` → Resume work on the entire project.
|
|
10
|
+
- Format `project-slug/001` → Focus on this specific PRD.
|
|
11
|
+
- If empty: Scan `workshop/projects/` and show available projects with status. Ask the user which one to continue.
|
|
12
|
+
|
|
13
|
+
## Step 2: Load Full Context
|
|
14
|
+
|
|
15
|
+
Read ALL existing files of the project:
|
|
16
|
+
|
|
17
|
+
- `workshop/projects/{slug}/PROJECT.md` — Status, metadata, PRD list
|
|
18
|
+
- `workshop/projects/{slug}/vision.md` — Project vision (if present)
|
|
19
|
+
- `workshop/projects/{slug}/requirements-map.md` — Requirements map (if present)
|
|
20
|
+
- `workshop/projects/{slug}/prds/*.md` — All PRDs
|
|
21
|
+
- `workshop/projects/{slug}/network-map.mmd` — Network map (if present)
|
|
22
|
+
- `workshop/projects/{slug}/notes/discovery-log.md` — Discovery notes
|
|
23
|
+
- `workshop/projects/{slug}/notes/decisions.md` — Decision log
|
|
24
|
+
- `workshop/projects/{slug}/prompts/*.md` — Existing handoff prompts
|
|
25
|
+
|
|
26
|
+
## Step 3: Determine Current State
|
|
27
|
+
|
|
28
|
+
Analyze the project status and determine the current phase:
|
|
29
|
+
|
|
30
|
+
| Status in PROJECT.md | Current Phase | Next Step |
|
|
31
|
+
| -------------------- | ------------------------ | -------------------------------------------- |
|
|
32
|
+
| `discovery` | Vision/Problem Discovery | Continue or conclude questioning |
|
|
33
|
+
| `scoping` | Scope & Requirements | Refine requirements, check for decomposition |
|
|
34
|
+
| `decomposing` | Decomposition | Finalize PRD splitting |
|
|
35
|
+
| `drafting` | PRD Creation | Continue writing open PRDs |
|
|
36
|
+
| `discussing` | Feature Deep-Dive | Continue deep-dive |
|
|
37
|
+
| `review` | Quality Review | Conclude review or apply improvements |
|
|
38
|
+
| `ready` | Ready for Handoff | Perform handoff |
|
|
39
|
+
| `handed-off` | Completed | Archiving or additional PRDs |
|
|
40
|
+
|
|
41
|
+
## Step 4: Present Summary
|
|
42
|
+
|
|
43
|
+
Give the user a compact overview:
|
|
44
|
+
|
|
45
|
+
1. **Project name and vision** (1-2 sentences)
|
|
46
|
+
2. **Current status** and phase
|
|
47
|
+
3. **What has been accomplished so far** (PRDs, decisions, open questions)
|
|
48
|
+
4. **What comes next** (concrete suggestion)
|
|
49
|
+
|
|
50
|
+
## Step 5: Continue Working
|
|
51
|
+
|
|
52
|
+
Offer the user to continue with the next logical step:
|
|
53
|
+
|
|
54
|
+
- If a specific PRD is referenced: Focus on that.
|
|
55
|
+
- If the overall project: Suggest the most important next step.
|
|
56
|
+
- Wait for the user's confirmation before starting.
|
|
57
|
+
|
|
58
|
+
## Communication
|
|
59
|
+
|
|
60
|
+
Follow the language settings defined in CLAUDE.md.
|
|
61
|
+
All file content must be written in English.
|
|
62
|
+
User-facing communication uses the language configured in CLAUDE.md.
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# /prd:review — Quality Review and Readiness Scoring (Phase 7)
|
|
2
|
+
|
|
3
|
+
You perform a systematic quality review of one or more PRDs.
|
|
4
|
+
|
|
5
|
+
## Step 1: Load PRDs
|
|
6
|
+
|
|
7
|
+
Interpret `$ARGUMENTS`:
|
|
8
|
+
|
|
9
|
+
- Format `project-slug/001` → Review only this single PRD: `workshop/projects/{project-slug}/prds/001-*.md`
|
|
10
|
+
- Format `project-slug` (without number) → Review ALL PRDs in the project: `workshop/projects/{project-slug}/prds/*.md`
|
|
11
|
+
- If empty: List available projects, ask the user.
|
|
12
|
+
|
|
13
|
+
Read all PRDs to be reviewed completely.
|
|
14
|
+
|
|
15
|
+
## Step 2: Load Quality Checklist
|
|
16
|
+
|
|
17
|
+
Read `workshop/knowledge/05-quality-checklist.md` for the evaluation criteria.
|
|
18
|
+
|
|
19
|
+
## Step 3: Systematic Review
|
|
20
|
+
|
|
21
|
+
Review each PRD against all categories of the Quality Checklist. Rate each category on a scale of 0-3:
|
|
22
|
+
|
|
23
|
+
| Score | Meaning |
|
|
24
|
+
| ----- | --------------------------------- |
|
|
25
|
+
| 0 | Missing completely or unusable |
|
|
26
|
+
| 1 | Present but incomplete or unclear |
|
|
27
|
+
| 2 | Solid, minor gaps acceptable |
|
|
28
|
+
| 3 | Excellent, no improvements needed |
|
|
29
|
+
|
|
30
|
+
## Step 4: Present Results
|
|
31
|
+
|
|
32
|
+
Show for each PRD:
|
|
33
|
+
|
|
34
|
+
1. **Scoring table**: Each category with score and concrete justification.
|
|
35
|
+
2. **Weighted average**: Calculate overall score.
|
|
36
|
+
3. **Improvement suggestions**: Specific, actionable recommendations per category with score < 3.
|
|
37
|
+
4. **Open items**: List of all `[ASSUMPTION]` and `[NEEDS CLARIFICATION]` markers.
|
|
38
|
+
5. **Red Flags Check**: Review the red flag criteria from the Quality Checklist.
|
|
39
|
+
|
|
40
|
+
## Step 5: Update Status
|
|
41
|
+
|
|
42
|
+
Based on the overall score:
|
|
43
|
+
|
|
44
|
+
- **Score >= 2.0**: Update the PRD status in `PROJECT.md` to `ready`. Inform the user that the PRD is ready for handoff.
|
|
45
|
+
- **Score < 2.0**: Keep the status at `review`. Clearly list what needs improvement. Suggest using `/prd:discuss` for the weak areas.
|
|
46
|
+
|
|
47
|
+
## Step 6: Summary
|
|
48
|
+
|
|
49
|
+
Give the user a clear recommendation:
|
|
50
|
+
|
|
51
|
+
- Ready for handoff? → Suggest `/prd:handoff`.
|
|
52
|
+
- Rework needed? → Suggest concrete next steps.
|
|
53
|
+
- For multiple PRDs: Sort by readiness, show which should be addressed first.
|
|
54
|
+
|
|
55
|
+
## Communication
|
|
56
|
+
|
|
57
|
+
Follow the language settings defined in CLAUDE.md.
|
|
58
|
+
All file content must be written in English.
|
|
59
|
+
User-facing communication uses the language configured in CLAUDE.md.
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
# /prd:status — Dashboard of All Projects and PRDs
|
|
2
|
+
|
|
3
|
+
You display an overview of all projects and their PRD statuses.
|
|
4
|
+
|
|
5
|
+
## Step 1: Determine Scope
|
|
6
|
+
|
|
7
|
+
Interpret `$ARGUMENTS`:
|
|
8
|
+
|
|
9
|
+
- If empty: Show overview of ALL projects.
|
|
10
|
+
- If project-slug is provided: Show detailed view for that project.
|
|
11
|
+
|
|
12
|
+
## Step 2: Collect Project Data
|
|
13
|
+
|
|
14
|
+
Scan all directories under `workshop/projects/`.
|
|
15
|
+
|
|
16
|
+
For each project:
|
|
17
|
+
|
|
18
|
+
1. Read `PROJECT.md` for status, metadata, PRD list.
|
|
19
|
+
2. Count PRDs under `prds/`.
|
|
20
|
+
3. Determine the status of each PRD (discovery, draft, review, ready, handed-off).
|
|
21
|
+
4. Determine the last modification date.
|
|
22
|
+
|
|
23
|
+
## Step 3: Display Overview (all projects)
|
|
24
|
+
|
|
25
|
+
Present a formatted table:
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
| Project | Status | PRDs | Last Update |
|
|
29
|
+
|-----------------|------------|-------------------------------|----------------|
|
|
30
|
+
| my-saas-app | drafting | 001 (ready), 002 (draft) | 2026-03-18 |
|
|
31
|
+
| portfolio-site | discovery | — | 2026-03-20 |
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## Step 4: Detailed View (single project)
|
|
35
|
+
|
|
36
|
+
If a specific project is requested, additionally show:
|
|
37
|
+
|
|
38
|
+
- Vision summary (from vision.md)
|
|
39
|
+
- Each PRD with: number, name, status, readiness score (if reviewed)
|
|
40
|
+
- Network map status (present yes/no, stage)
|
|
41
|
+
- Open `[ASSUMPTION]` and `[NEEDS CLARIFICATION]` counts per PRD
|
|
42
|
+
- Existing handoff prompts
|
|
43
|
+
|
|
44
|
+
## Step 5: Update STATUS.md
|
|
45
|
+
|
|
46
|
+
Write the current overview to `STATUS.md` in the workshop root directory.
|
|
47
|
+
Format: Markdown table with timestamp.
|
|
48
|
+
|
|
49
|
+
## Step 6: Suggest Next Actions
|
|
50
|
+
|
|
51
|
+
For each project, provide a concrete recommendation:
|
|
52
|
+
|
|
53
|
+
- `discovery` → "Start `/prd:new {slug}` to continue"
|
|
54
|
+
- `drafting` → "Use `/prd:discuss {slug}/001` for the next deep-dive"
|
|
55
|
+
- `review` → "Run `/prd:review {slug}`"
|
|
56
|
+
- `ready` → "Ready for `/prd:handoff {slug}/001`"
|
|
57
|
+
- `handed-off` → "All PRDs handed off. `/workshop:archive {slug}` is available."
|
|
58
|
+
|
|
59
|
+
## Communication
|
|
60
|
+
|
|
61
|
+
Follow the language settings defined in CLAUDE.md.
|
|
62
|
+
All file content must be written in English.
|
|
63
|
+
User-facing communication uses the language configured in CLAUDE.md.
|
|
@@ -0,0 +1,158 @@
|
|
|
1
|
+
# /setup — Install Autonomous Development Workflow
|
|
2
|
+
|
|
3
|
+
Install the complete autonomous development workflow into a target project.
|
|
4
|
+
|
|
5
|
+
## Step 1: Determine Target
|
|
6
|
+
|
|
7
|
+
If `$ARGUMENTS` contains a path, use it as the target project path.
|
|
8
|
+
If `$ARGUMENTS` is empty, ask: **[in configured language] "What is the path to your project?"** — wait for a response.
|
|
9
|
+
|
|
10
|
+
Validate:
|
|
11
|
+
|
|
12
|
+
- The path exists. If not, ask: "This directory does not exist. Should I create it?"
|
|
13
|
+
- Check for an existing `.claude/` directory at the target path.
|
|
14
|
+
- If found, ask: **"A .claude/ directory already exists. Overwrite, merge, or abort?"**
|
|
15
|
+
- **Overwrite**: Delete existing `.claude/` and replace with fresh installation.
|
|
16
|
+
- **Merge**: Keep existing files, only add missing ones. Warn about conflicts.
|
|
17
|
+
- **Abort**: Stop the installation.
|
|
18
|
+
|
|
19
|
+
## Step 2: Gather Configuration
|
|
20
|
+
|
|
21
|
+
Ask these questions one at a time. Skip any that you can auto-detect from the project.
|
|
22
|
+
|
|
23
|
+
### 2.1 Project Name
|
|
24
|
+
|
|
25
|
+
Derive from the directory name. Confirm with the user:
|
|
26
|
+
**"Project name: {derived-name} — correct?"**
|
|
27
|
+
|
|
28
|
+
### 2.2 Tech Stack
|
|
29
|
+
|
|
30
|
+
Auto-detect first:
|
|
31
|
+
|
|
32
|
+
- If `package.json` exists with `"next"` dependency → suggest **Next.js + Supabase**
|
|
33
|
+
- If `pyproject.toml` or `requirements.txt` exists → suggest **Python + FastAPI**
|
|
34
|
+
- If `Package.swift` exists → suggest **Swift/SwiftUI**
|
|
35
|
+
- If none match → suggest **Generic**
|
|
36
|
+
|
|
37
|
+
Offer presets:
|
|
38
|
+
|
|
39
|
+
1. **Next.js + Supabase** — Full-stack web (TypeScript, App Router, Tailwind, Shadcn, Supabase)
|
|
40
|
+
2. **Python + FastAPI** — Backend/API (Python 3.12+, FastAPI, SQLAlchemy, pytest)
|
|
41
|
+
3. **Swift/SwiftUI** — iOS/macOS (Swift 6, SwiftUI, SwiftData, XCTest)
|
|
42
|
+
4. **Generic** — Stack-agnostic (universal quality rules, no framework-specific config)
|
|
43
|
+
5. **Custom** — Ask detailed questions about the stack
|
|
44
|
+
|
|
45
|
+
### 2.3 Communication Language
|
|
46
|
+
|
|
47
|
+
**"Communication language? (default: English)"**
|
|
48
|
+
Options: English, German (du/informal), or specify another.
|
|
49
|
+
|
|
50
|
+
### 2.4 Autonomy Level
|
|
51
|
+
|
|
52
|
+
**"Autonomy level?"**
|
|
53
|
+
|
|
54
|
+
1. **Conservative** — Claude asks before most actions. Best for learning the workflow or sensitive projects.
|
|
55
|
+
2. **Standard** (recommended) — Autonomous within guardrails. Stops for plan approval, ambiguous scope, and breaking changes.
|
|
56
|
+
3. **Full autonomy** — Decides everything. Only stops on errors or genuinely ambiguous scope.
|
|
57
|
+
|
|
58
|
+
## Step 3: Read Templates and Stack Preset
|
|
59
|
+
|
|
60
|
+
Read these files from the repo root:
|
|
61
|
+
|
|
62
|
+
1. `system/templates/CLAUDE.md.tmpl` — Main configuration template
|
|
63
|
+
2. `system/templates/settings.json.tmpl` — Settings template
|
|
64
|
+
3. `system/templates/guardrails.md.tmpl` — Guardrails template
|
|
65
|
+
4. `system/stacks/{selected-stack}.md` — Stack-specific content (nextjs-supabase.md, python-fastapi.md, swift-ios.md, or generic.md)
|
|
66
|
+
|
|
67
|
+
The stack preset file contains values for these placeholders:
|
|
68
|
+
|
|
69
|
+
- `{{TECH_STACK}}` — Technology list
|
|
70
|
+
- `{{ARCHITECTURE_PRINCIPLES}}` — Architecture rules
|
|
71
|
+
- `{{PROJECT_STRUCTURE}}` — Directory layout
|
|
72
|
+
- `{{QUALITY_GATES}}` — Build/test/lint commands
|
|
73
|
+
- `{{STACK_SPECIFIC_GUARDRAILS}}` — Framework-specific guardrails
|
|
74
|
+
- `{{FORMATTER}}` — Code formatter name
|
|
75
|
+
- `{{PACKAGE_MANAGER}}` — Package manager command
|
|
76
|
+
|
|
77
|
+
## Step 4: Generate and Install Files
|
|
78
|
+
|
|
79
|
+
Substitute all `{{PLACEHOLDER}}` values with the gathered configuration and stack preset values:
|
|
80
|
+
|
|
81
|
+
| Placeholder | Source |
|
|
82
|
+
| ------------------------------- | ------------------------------------------------------------------------------------- |
|
|
83
|
+
| `{{PROJECT_NAME}}` | Step 2.1 |
|
|
84
|
+
| `{{LANGUAGE}}` | Step 2.3 (formatted as instruction, e.g., "Speak German (du/informal) with the user") |
|
|
85
|
+
| `{{TECH_STACK}}` | Stack preset |
|
|
86
|
+
| `{{ARCHITECTURE_PRINCIPLES}}` | Stack preset |
|
|
87
|
+
| `{{PROJECT_STRUCTURE}}` | Stack preset |
|
|
88
|
+
| `{{QUALITY_GATES}}` | Stack preset |
|
|
89
|
+
| `{{STACK_SPECIFIC_GUARDRAILS}}` | Stack preset |
|
|
90
|
+
| `{{FORMATTER}}` | Stack preset |
|
|
91
|
+
| `{{PACKAGE_MANAGER}}` | Stack preset |
|
|
92
|
+
|
|
93
|
+
Create these files in the target project:
|
|
94
|
+
|
|
95
|
+
### Configuration Files (3)
|
|
96
|
+
|
|
97
|
+
1. **`{target}/CLAUDE.md`** — From `CLAUDE.md.tmpl` with all placeholders substituted
|
|
98
|
+
2. **`{target}/.claude/settings.json`** — From `settings.json.tmpl` with placeholders substituted
|
|
99
|
+
3. **`{target}/.claude/guardrails.md`** — From `guardrails.md.tmpl` with placeholders substituted
|
|
100
|
+
|
|
101
|
+
### Reference Guide (1)
|
|
102
|
+
|
|
103
|
+
4. **`{target}/AUTONOMOUS-WORKFLOW.md`** — Copy `system/templates/AUTONOMOUS-WORKFLOW.md` as-is
|
|
104
|
+
|
|
105
|
+
### Workflow Commands (10)
|
|
106
|
+
|
|
107
|
+
Copy ALL files from `system/commands/` to `{target}/.claude/commands/`:
|
|
108
|
+
|
|
109
|
+
5. `plan.md` — Analysis + implementation plan + wait for approval
|
|
110
|
+
6. `tdd.md` — Test-first development (RED → GREEN → REFACTOR)
|
|
111
|
+
7. `verify.md` — Build + types + lint + tests verification
|
|
112
|
+
8. `e2e.md` — End-to-end test creation and execution
|
|
113
|
+
9. `code-review.md` — Security + quality audit
|
|
114
|
+
10. `build-fix.md` — Incremental build error resolution
|
|
115
|
+
11. `refactor-clean.md` — Dead code removal and cleanup
|
|
116
|
+
12. `ralph-loop.md` — Iterative autonomous implementation loop
|
|
117
|
+
13. `cancel-ralph.md` — Stop a running Ralph Loop
|
|
118
|
+
14. `checkpoint.md` — Create a git restore point
|
|
119
|
+
|
|
120
|
+
## Step 5: Verify Installation
|
|
121
|
+
|
|
122
|
+
List all created files with their absolute paths in a table:
|
|
123
|
+
|
|
124
|
+
```
|
|
125
|
+
| # | File | Status |
|
|
126
|
+
|---|------|--------|
|
|
127
|
+
| 1 | {target}/CLAUDE.md | Created |
|
|
128
|
+
| 2 | {target}/.claude/settings.json | Created |
|
|
129
|
+
| ... | ... | ... |
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
Show a configuration summary:
|
|
133
|
+
|
|
134
|
+
```
|
|
135
|
+
| Setting | Value |
|
|
136
|
+
|---------|-------|
|
|
137
|
+
| Project | {name} |
|
|
138
|
+
| Stack | {stack} |
|
|
139
|
+
| Language | {language} |
|
|
140
|
+
| Autonomy | {level} |
|
|
141
|
+
| Commands installed | 10 |
|
|
142
|
+
| Files created | {total count} |
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
## Step 6: Next Steps
|
|
146
|
+
|
|
147
|
+
Tell the user:
|
|
148
|
+
|
|
149
|
+
1. **"Open Claude Code in `{target}` to use the workflow"**
|
|
150
|
+
2. **Available commands:** `/plan`, `/tdd`, `/verify`, `/e2e`, `/code-review`, `/build-fix`, `/refactor-clean`, `/ralph-loop`, `/cancel-ralph`, `/checkpoint`
|
|
151
|
+
3. **"To create a PRD: come back to this repo and run `/prd:new`"**
|
|
152
|
+
4. **"Read `AUTONOMOUS-WORKFLOW.md` for the complete reference guide"**
|
|
153
|
+
5. **"Customize `CLAUDE.md` to match your specific project conventions"**
|
|
154
|
+
|
|
155
|
+
## Communication
|
|
156
|
+
|
|
157
|
+
Follow the language settings defined in CLAUDE.md for user-facing communication.
|
|
158
|
+
All installed file content must be in English.
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
# /workshop:archive — Archive a Completed Project
|
|
2
|
+
|
|
3
|
+
You archive a completed project by moving it from `workshop/projects/` to `workshop/archive/`.
|
|
4
|
+
|
|
5
|
+
## Step 1: Identify Project
|
|
6
|
+
|
|
7
|
+
Interpret `$ARGUMENTS` as project-slug.
|
|
8
|
+
|
|
9
|
+
- If empty: List available projects under `workshop/projects/`, ask the user.
|
|
10
|
+
|
|
11
|
+
Check if `workshop/projects/{slug}/` exists. If not: Inform the user, check whether it already exists under `workshop/archive/`.
|
|
12
|
+
|
|
13
|
+
## Step 2: Check Readiness
|
|
14
|
+
|
|
15
|
+
Read `workshop/projects/{slug}/PROJECT.md`.
|
|
16
|
+
|
|
17
|
+
Check the status of all PRDs:
|
|
18
|
+
|
|
19
|
+
- **All PRDs `handed-off`**: All good, proceed.
|
|
20
|
+
- **Not all PRDs `handed-off`**: Warn the user with a list of incomplete PRDs and their current status. Explicitly ask: [in configured language] "Archive anyway?"
|
|
21
|
+
- Wait for confirmation before proceeding.
|
|
22
|
+
|
|
23
|
+
## Step 3: Ensure Archive Directory
|
|
24
|
+
|
|
25
|
+
Check if `workshop/archive/` exists. If not, create it.
|
|
26
|
+
|
|
27
|
+
## Step 4: Move Project
|
|
28
|
+
|
|
29
|
+
Move the project directory:
|
|
30
|
+
|
|
31
|
+
- From: `workshop/projects/{slug}/`
|
|
32
|
+
- To: `archive/{YYYY-MM-DD}_{slug}/`
|
|
33
|
+
|
|
34
|
+
Use today's date as the prefix.
|
|
35
|
+
|
|
36
|
+
## Step 5: Update STATUS.md
|
|
37
|
+
|
|
38
|
+
Read `STATUS.md` in the root directory (if present).
|
|
39
|
+
Update the project list:
|
|
40
|
+
|
|
41
|
+
- Remove the project from the active list.
|
|
42
|
+
- Add it to the archive section (with archiving date).
|
|
43
|
+
|
|
44
|
+
If `STATUS.md` does not exist, create it with the archive entry.
|
|
45
|
+
|
|
46
|
+
## Step 6: Confirmation
|
|
47
|
+
|
|
48
|
+
Confirm to the user:
|
|
49
|
+
|
|
50
|
+
- Which project was archived.
|
|
51
|
+
- Where it was moved to.
|
|
52
|
+
- Whether all PRDs were in `handed-off` status.
|
|
53
|
+
|
|
54
|
+
## Communication
|
|
55
|
+
|
|
56
|
+
Follow the language settings defined in CLAUDE.md.
|
|
57
|
+
All file content must be written in English.
|
|
58
|
+
User-facing communication uses the language configured in CLAUDE.md.
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
# /workshop:init — Initialize a New Project Workspace
|
|
2
|
+
|
|
3
|
+
You create the complete directory structure and template files for a new project.
|
|
4
|
+
|
|
5
|
+
## Step 1: Validate Slug
|
|
6
|
+
|
|
7
|
+
Interpret `$ARGUMENTS` as project-slug.
|
|
8
|
+
|
|
9
|
+
If empty: Ask the user for a project name and derive the slug from it.
|
|
10
|
+
|
|
11
|
+
Validate the slug format:
|
|
12
|
+
|
|
13
|
+
- Only lowercase letters, digits, and hyphens allowed.
|
|
14
|
+
- No spaces, no special characters, no umlauts.
|
|
15
|
+
- Must start with a letter.
|
|
16
|
+
- Examples: `my-saas-app`, `portfolio-2026`, `ai-agent-framework`
|
|
17
|
+
|
|
18
|
+
If invalid: Suggest a corrected slug and ask the user.
|
|
19
|
+
|
|
20
|
+
Check if `workshop/projects/{slug}/` already exists. If yes: Inform the user and ask whether `/prd:resume` was intended.
|
|
21
|
+
|
|
22
|
+
## Step 2: Create Directory Structure
|
|
23
|
+
|
|
24
|
+
Create the following structure:
|
|
25
|
+
|
|
26
|
+
```
|
|
27
|
+
workshop/projects/{slug}/
|
|
28
|
+
prds/
|
|
29
|
+
prompts/
|
|
30
|
+
notes/
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
## Step 3: Create PROJECT.md
|
|
34
|
+
|
|
35
|
+
Read `workshop/templates/PROJECT.md` as a template.
|
|
36
|
+
|
|
37
|
+
Create `workshop/projects/{slug}/PROJECT.md` with:
|
|
38
|
+
|
|
39
|
+
- Project name (from slug, Title Case)
|
|
40
|
+
- Today's date as creation date
|
|
41
|
+
- Status: `discovery`
|
|
42
|
+
- Empty PRD list
|
|
43
|
+
- Empty fields for target_repo, tech_stack, etc.
|
|
44
|
+
|
|
45
|
+
## Step 4: Create Notes Files
|
|
46
|
+
|
|
47
|
+
Create `workshop/projects/{slug}/notes/discovery-log.md`:
|
|
48
|
+
|
|
49
|
+
```markdown
|
|
50
|
+
# Discovery Log
|
|
51
|
+
|
|
52
|
+
## Session 1 — {today's date}
|
|
53
|
+
|
|
54
|
+
(Notes will be added during discovery phase)
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
Create `workshop/projects/{slug}/notes/decisions.md`:
|
|
58
|
+
|
|
59
|
+
```markdown
|
|
60
|
+
# Decision Log
|
|
61
|
+
|
|
62
|
+
| # | Date | Decision | Rationale | Status |
|
|
63
|
+
| --- | ---- | -------- | --------- | ------ |
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
## Step 5: Confirmation
|
|
67
|
+
|
|
68
|
+
Confirm to the user:
|
|
69
|
+
|
|
70
|
+
- Which directory was created.
|
|
71
|
+
- Which files were set up.
|
|
72
|
+
- Suggest continuing with `/prd:new {slug}`.
|
|
73
|
+
|
|
74
|
+
## Communication
|
|
75
|
+
|
|
76
|
+
Follow the language settings defined in CLAUDE.md.
|
|
77
|
+
All file content must be written in English.
|
|
78
|
+
User-facing communication uses the language configured in CLAUDE.md.
|