@leeovery/claude-technical-workflows 2.0.19 → 2.0.21
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/README.md +115 -175
- package/commands/workflow:status.md +71 -0
- package/commands/workflow:view-plan.md +63 -0
- package/package.json +1 -1
- package/skills/technical-discussion/SKILL.md +2 -2
- package/skills/technical-discussion/references/meeting-assistant.md +3 -3
- package/skills/technical-implementation/SKILL.md +3 -3
- package/skills/technical-planning/SKILL.md +3 -3
- package/skills/technical-planning/references/formal-planning.md +1 -1
- package/skills/technical-planning/references/output-backlog-md.md +3 -3
- package/skills/technical-planning/references/output-beads.md +3 -3
- package/skills/technical-planning/references/output-linear.md +3 -3
- package/skills/technical-planning/references/output-local-markdown.md +3 -3
- package/skills/technical-research/SKILL.md +4 -4
- package/skills/technical-research/references/interview.md +35 -0
- package/skills/technical-review/SKILL.md +2 -2
- package/skills/technical-specification/SKILL.md +9 -8
- package/skills/technical-specification/references/specification-guide.md +4 -4
- package/commands/interview.md +0 -54
package/README.md
CHANGED
|
@@ -16,27 +16,23 @@
|
|
|
16
16
|
|
|
17
17
|
## What is this?
|
|
18
18
|
|
|
19
|
-
A
|
|
19
|
+
A complete development workflow for Claude Code: explore ideas, capture decisions, build actionable plans, implement via strict TDD, and validate the result.
|
|
20
|
+
|
|
21
|
+
Use it as a **six-phase workflow** or pick individual capabilities as needed:
|
|
20
22
|
|
|
21
23
|
```
|
|
22
|
-
Research
|
|
23
|
-
↓
|
|
24
|
-
Discussion → Debate and decide
|
|
25
|
-
↓
|
|
26
|
-
Specification → Validate and refine
|
|
27
|
-
↓
|
|
28
|
-
Planning → Structure the work
|
|
29
|
-
↓
|
|
30
|
-
Implementation → Build via TDD
|
|
31
|
-
↓
|
|
32
|
-
Review → Validate against spec
|
|
24
|
+
Research → Discussion → Specification → Planning → Implementation → Review
|
|
33
25
|
```
|
|
34
26
|
|
|
35
|
-
**Why this matters:** Complex features benefit from thorough discussion before implementation.
|
|
27
|
+
**Why this matters:** Complex features benefit from thorough discussion before implementation. This toolkit documents the *what* and *why* before diving into the *how*, preserving architectural decisions, edge cases, and the reasoning behind choices that would otherwise be lost.
|
|
36
28
|
|
|
37
|
-
**
|
|
29
|
+
**Flexible entry points:** Need the full workflow? Start at Research or Discussion and progress through each phase. Already know what you're building? Jump straight to Specification with `/start-feature`. Skills are input-agnostic - commands gather context and feed it to them.
|
|
38
30
|
|
|
39
|
-
|
|
31
|
+
> [!NOTE]
|
|
32
|
+
> **Work in progress.** The workflow is being refined through real-world usage. Expect updates as patterns evolve.
|
|
33
|
+
|
|
34
|
+
> [!IMPORTANT]
|
|
35
|
+
> **Model compatibility:** These skills have been developed and refined for Claude Code running on **Opus 4.5**. Different models may exhibit different edge cases, and future model releases may require adjustments to the prompts and workflows.
|
|
40
36
|
|
|
41
37
|
### Quick Install
|
|
42
38
|
|
|
@@ -55,28 +51,55 @@ See [Installation](#installation) for details and trade-offs.
|
|
|
55
51
|
|
|
56
52
|
## How do I use it?
|
|
57
53
|
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
| Start here... | When... | Command |
|
|
61
|
-
|---------------|---------|---------|
|
|
62
|
-
| **Research** | You have a fresh idea to explore: feasibility, market, viability, early thoughts | `/workflow:start-research` |
|
|
63
|
-
| **Discussion** | You already know what you're building and need to iron out the details | `/workflow:start-discussion` |
|
|
54
|
+
### Two Ways to Use the Skills
|
|
64
55
|
|
|
65
|
-
**
|
|
66
|
-
|
|
67
|
-
**Discussion** is where you work through the challenging parts: core architecture, edge cases, non-obvious decisions. The key value is that it captures *how* you arrived at decisions, not just the decisions themselves. When you explore four approaches and pick one, the document explains why you rejected the others. This context is invaluable later.
|
|
68
|
-
|
|
69
|
-
Then follow the flow:
|
|
56
|
+
**1. Full Workflow** - Sequential phases that build on each other:
|
|
70
57
|
|
|
71
58
|
```
|
|
72
59
|
Research → Discussion → Specification → Planning → Implementation → Review
|
|
73
60
|
```
|
|
74
61
|
|
|
75
|
-
|
|
62
|
+
Start with `/workflow:start-research` or `/workflow:start-discussion` and follow the flow. Each phase outputs files that the next phase consumes.
|
|
63
|
+
|
|
64
|
+
**2. Standalone Commands** - Jump directly to a skill with flexible inputs:
|
|
65
|
+
|
|
66
|
+
| Command | What it does |
|
|
67
|
+
|---------|-------------|
|
|
68
|
+
| `/start-feature` | Create a spec directly from inline context (skip research/discussion) |
|
|
69
|
+
|
|
70
|
+
*More standalone commands coming soon.*
|
|
71
|
+
|
|
72
|
+
### The Command/Skill Architecture
|
|
73
|
+
|
|
74
|
+
**Skills are input-agnostic.** They don't know or care where their inputs came from: a discussion document, inline context, or external sources. They just process what they receive.
|
|
75
|
+
|
|
76
|
+
**Commands are the input layer.** They gather context (from files, prompts, or inline) and pass it to skills. This separation means:
|
|
77
|
+
|
|
78
|
+
- The same skill can be invoked from different entry points
|
|
79
|
+
- You can create custom commands that feed skills in new ways
|
|
80
|
+
- Skills remain reusable without coupling to specific workflows
|
|
76
81
|
|
|
77
|
-
|
|
82
|
+
```
|
|
83
|
+
┌─────────────────────────────────────────────────────────────┐
|
|
84
|
+
│ COMMANDS │
|
|
85
|
+
│ (gather inputs from files, prompts, inline context) │
|
|
86
|
+
├─────────────────────────────────────────────────────────────┤
|
|
87
|
+
│ /workflow:start-spec /start-feature (your custom) │
|
|
88
|
+
│ │ │ │ │
|
|
89
|
+
│ └───────────┬───────────┘ │ │
|
|
90
|
+
│ ▼ ▼ │
|
|
91
|
+
├─────────────────────────────────────────────────────────────┤
|
|
92
|
+
│ SKILLS │
|
|
93
|
+
│ (process inputs without knowing their source) │
|
|
94
|
+
├─────────────────────────────────────────────────────────────┤
|
|
95
|
+
│ technical-specification skill │
|
|
96
|
+
│ technical-planning skill │
|
|
97
|
+
│ technical-implementation skill │
|
|
98
|
+
│ etc. │
|
|
99
|
+
└─────────────────────────────────────────────────────────────┘
|
|
100
|
+
```
|
|
78
101
|
|
|
79
|
-
|
|
102
|
+
### Workflow Commands
|
|
80
103
|
|
|
81
104
|
| Phase | Command |
|
|
82
105
|
|----------------|----------------------------------|
|
|
@@ -87,7 +110,7 @@ Each phase has a command designed as its entry point. Commands are prefixed with
|
|
|
87
110
|
| Implementation | `/workflow:start-implementation` |
|
|
88
111
|
| Review | `/workflow:start-review` |
|
|
89
112
|
|
|
90
|
-
Run the command directly or ask Claude to run it. Each
|
|
113
|
+
Run the command directly or ask Claude to run it. Each gathers context from previous phase outputs and passes it to the skill.
|
|
91
114
|
|
|
92
115
|
## Installation
|
|
93
116
|
|
|
@@ -111,7 +134,7 @@ Skills are cached globally. They won't be available in Claude Code for Web since
|
|
|
111
134
|
npm install -D @leeovery/claude-technical-workflows
|
|
112
135
|
```
|
|
113
136
|
|
|
114
|
-
Skills are copied to `.claude/` and can be committed
|
|
137
|
+
Skills are copied to `.claude/` and can be committed, giving you ownership and making them available everywhere including Claude Code for Web.
|
|
115
138
|
|
|
116
139
|
<details>
|
|
117
140
|
<summary>pnpm users</summary>
|
|
@@ -137,7 +160,7 @@ npx claude-manager remove @leeovery/claude-technical-workflows && npm rm @leeove
|
|
|
137
160
|
|
|
138
161
|
## The Six-Phase Workflow
|
|
139
162
|
|
|
140
|
-
|
|
163
|
+
When using the full workflow, it progresses through six distinct phases:
|
|
141
164
|
|
|
142
165
|
```
|
|
143
166
|
┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐
|
|
@@ -158,7 +181,7 @@ This package enforces a deliberate progression through six distinct phases:
|
|
|
158
181
|
|
|
159
182
|
**Phase 1 - Research:** Explore ideas from their earliest seed. Investigate market fit, technical feasibility, business viability. Free-flowing exploration that may or may not lead to building something.
|
|
160
183
|
|
|
161
|
-
**Phase 2 - Discussion:** Captures the back-and-forth exploration of a problem. Documents competing solutions, why certain approaches won or lost, edge cases discovered, and the journey to decisions
|
|
184
|
+
**Phase 2 - Discussion:** Captures the back-and-forth exploration of a problem. Documents competing solutions, why certain approaches won or lost, edge cases discovered, and the journey to decisions, not just the decisions themselves.
|
|
162
185
|
|
|
163
186
|
**Phase 3 - Specification:** Transforms discussion documentation into a validated, standalone specification. Filters hallucinations and inaccuracies, enriches gaps through discussion, and builds a document that planning can execute against without referencing other sources.
|
|
164
187
|
|
|
@@ -166,23 +189,13 @@ This package enforces a deliberate progression through six distinct phases:
|
|
|
166
189
|
|
|
167
190
|
**Phase 5 - Implementation:** Executes the plan using strict TDD. Writes tests first, implements to pass, commits frequently, and stops for user approval between phases.
|
|
168
191
|
|
|
169
|
-
**Phase 6 - Review:** Validates completed work against specification requirements and plan acceptance criteria. The specification is the validated source of truth
|
|
170
|
-
|
|
171
|
-
## How It Works
|
|
192
|
+
**Phase 6 - Review:** Validates completed work against specification requirements and plan acceptance criteria. The specification is the validated source of truth; earlier phases may contain rejected ideas that were intentionally filtered out. Provides structured feedback without fixing code directly.
|
|
172
193
|
|
|
173
|
-
|
|
194
|
+
## Project Structure
|
|
174
195
|
|
|
175
|
-
|
|
176
|
-
2. **Copies commands** into your project's `.claude/commands/` directory
|
|
177
|
-
3. **Copies agents** into your project's `.claude/agents/` directory
|
|
178
|
-
4. **Tracks installed plugins** via a manifest file
|
|
179
|
-
5. **Handles installation/removal** automatically via npm hooks
|
|
196
|
+
### Output Files
|
|
180
197
|
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
### Output Structure
|
|
184
|
-
|
|
185
|
-
Documents are stored using a **phase-first** organization:
|
|
198
|
+
Documents are stored in your project using a **phase-first** organisation:
|
|
186
199
|
|
|
187
200
|
```
|
|
188
201
|
docs/workflow/
|
|
@@ -202,141 +215,51 @@ Research starts with `exploration.md` and splits into topic files as themes emer
|
|
|
202
215
|
|
|
203
216
|
### Package Structure
|
|
204
217
|
|
|
205
|
-
This package provides:
|
|
206
|
-
|
|
207
218
|
```
|
|
208
|
-
skills/
|
|
209
|
-
├── technical-research/
|
|
210
|
-
├── technical-discussion/
|
|
211
|
-
├── technical-specification/
|
|
212
|
-
├── technical-planning/
|
|
213
|
-
├── technical-implementation/
|
|
214
|
-
└── technical-review/
|
|
215
|
-
|
|
216
|
-
commands/
|
|
217
|
-
├── workflow:start-research.md #
|
|
218
|
-
├── workflow:start-discussion.md #
|
|
219
|
-
├── workflow:start-specification.md #
|
|
220
|
-
├── workflow:start-planning.md #
|
|
221
|
-
├── workflow:start-implementation.md #
|
|
222
|
-
├── workflow:start-review.md #
|
|
223
|
-
├──
|
|
224
|
-
├──
|
|
225
|
-
|
|
219
|
+
skills/ # Input-agnostic processors
|
|
220
|
+
├── technical-research/ # Explore and validate ideas
|
|
221
|
+
├── technical-discussion/ # Document discussions
|
|
222
|
+
├── technical-specification/ # Build validated specifications
|
|
223
|
+
├── technical-planning/ # Create implementation plans
|
|
224
|
+
├── technical-implementation/ # Execute via TDD
|
|
225
|
+
└── technical-review/ # Validate against artefacts
|
|
226
|
+
|
|
227
|
+
commands/ # Input layer (gather context → invoke skills)
|
|
228
|
+
├── workflow:start-research.md # Sequential: begin research
|
|
229
|
+
├── workflow:start-discussion.md # Sequential: begin discussions
|
|
230
|
+
├── workflow:start-specification.md # Sequential: begin specification
|
|
231
|
+
├── workflow:start-planning.md # Sequential: begin planning
|
|
232
|
+
├── workflow:start-implementation.md # Sequential: begin implementation
|
|
233
|
+
├── workflow:start-review.md # Sequential: begin review
|
|
234
|
+
├── workflow:status.md # Utility: show workflow status and next steps
|
|
235
|
+
├── workflow:view-plan.md # Utility: view plan tasks and progress
|
|
236
|
+
├── start-feature.md # Standalone: spec from inline context
|
|
237
|
+
└── link-dependencies.md # Standalone: wire cross-topic deps
|
|
226
238
|
|
|
227
239
|
agents/
|
|
228
|
-
└── chain-verifier.md
|
|
240
|
+
└── chain-verifier.md # Parallel task verification for review
|
|
229
241
|
```
|
|
230
242
|
|
|
231
243
|
## Skills
|
|
232
244
|
|
|
233
|
-
|
|
234
|
-
|------------------------------------------------------------------|-------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
235
|
-
| [**technical-research**](skills/technical-research/) | 1 | Explore ideas from their earliest seed. Investigate market fit, technical feasibility, business viability. Free-flowing exploration across technical, business, and market domains. |
|
|
236
|
-
| [**technical-discussion**](skills/technical-discussion/) | 2 | Document technical discussions as expert architect and meeting assistant. Captures context, decisions, edge cases, competing solutions, debates, and rationale. |
|
|
237
|
-
| [**technical-specification**](skills/technical-specification/) | 3 | Build validated specifications from discussion documents through collaborative refinement. Filters hallucinations, enriches gaps, produces standalone spec. |
|
|
238
|
-
| [**technical-planning**](skills/technical-planning/) | 4 | Transform specifications into actionable implementation plans with phases, tasks, and acceptance criteria. Supports multiple output formats. |
|
|
239
|
-
| [**technical-implementation**](skills/technical-implementation/) | 5 | Execute implementation plans using strict TDD workflow. Writes tests first, implements to pass, commits frequently, and gates phases on user approval. |
|
|
240
|
-
| [**technical-review**](skills/technical-review/) | 6 | Review completed implementation against specification requirements and plan acceptance criteria. Uses parallel subagents for efficient chain verification. Produces structured feedback without fixing code. |
|
|
241
|
-
|
|
242
|
-
### technical-research
|
|
243
|
-
|
|
244
|
-
Acts as **research partner** with broad expertise spanning technical, product, business, and market domains.
|
|
245
|
-
|
|
246
|
-
**Use when:**
|
|
247
|
-
- Exploring a new idea from its earliest seed
|
|
248
|
-
- Investigating market fit, competitors, or positioning
|
|
249
|
-
- Validating technical feasibility before committing to build
|
|
250
|
-
- Learning and exploration without necessarily building anything
|
|
251
|
-
- Brain dumping early thoughts before formal discussion
|
|
252
|
-
|
|
253
|
-
**What it does:**
|
|
254
|
-
- Explores ideas freely across technical, business, and market domains
|
|
255
|
-
- Prompts before documenting: "Shall I capture that?"
|
|
256
|
-
- Creates research documents that may seed the discussion phase
|
|
257
|
-
- Follows tangents and goes broad when useful
|
|
258
|
-
|
|
259
|
-
### technical-discussion
|
|
260
|
-
|
|
261
|
-
Acts as both **expert software architect** (participating in discussions) and **documentation assistant** (capturing them) simultaneously.
|
|
245
|
+
Skills are **input-agnostic processors**: they receive inputs and process them without knowing where the inputs came from. This makes them reusable across different commands and workflows.
|
|
262
246
|
|
|
263
|
-
|
|
264
|
-
|
|
265
|
-
-
|
|
266
|
-
-
|
|
267
|
-
-
|
|
268
|
-
|
|
269
|
-
**
|
|
270
|
-
|
|
271
|
-
- Small details and edge cases that were discussed
|
|
272
|
-
- Competing solutions and why some won over others
|
|
273
|
-
- The journey—false paths, "aha" moments, course corrections
|
|
274
|
-
|
|
275
|
-
### technical-specification
|
|
276
|
-
|
|
277
|
-
Acts as **expert technical architect** and **specification builder**. Transforms discussion documents into validated, standalone specifications.
|
|
278
|
-
|
|
279
|
-
**Use when:**
|
|
280
|
-
- Ready to validate and refine discussion content
|
|
281
|
-
- Need to filter potential hallucinations or inaccuracies from source material
|
|
282
|
-
- Building a standalone document that planning can execute against
|
|
283
|
-
- Converting discussions into verified requirements
|
|
284
|
-
|
|
285
|
-
**What it produces:**
|
|
286
|
-
- Validated, standalone specification document
|
|
287
|
-
- Filtered content (hallucinations and inaccuracies removed)
|
|
288
|
-
- Enriched content (gaps filled through discussion)
|
|
289
|
-
- Clear bridge document for formal planning
|
|
290
|
-
|
|
291
|
-
### technical-planning
|
|
292
|
-
|
|
293
|
-
Converts specifications into structured implementation plans.
|
|
294
|
-
|
|
295
|
-
**Use when:**
|
|
296
|
-
- Ready to plan implementation after specification is complete
|
|
297
|
-
- Need to structure how to build something with phases and concrete steps
|
|
298
|
-
- Converting specification into actionable developer guidance
|
|
299
|
-
|
|
300
|
-
**What it produces:**
|
|
301
|
-
- Phased implementation plans with specific tasks
|
|
302
|
-
- Acceptance criteria at phase and task levels
|
|
303
|
-
- Multiple output formats: local markdown, Linear, Backlog.md, or Beads
|
|
304
|
-
|
|
305
|
-
### technical-implementation
|
|
306
|
-
|
|
307
|
-
Executes plans through strict TDD. Acts as an expert senior developer who builds quality software through disciplined test-driven development.
|
|
308
|
-
|
|
309
|
-
**Use when:**
|
|
310
|
-
- Implementing a plan from `docs/workflow/planning/{topic}.md`
|
|
311
|
-
- Ad hoc coding that should follow TDD and quality standards
|
|
312
|
-
- Bug fixes or features benefiting from structured implementation
|
|
313
|
-
|
|
314
|
-
**Hard rules:**
|
|
315
|
-
- No code before tests—write the failing test first
|
|
316
|
-
- No test changes to pass—fix the code, not the tests
|
|
317
|
-
- No scope expansion—if it's not in the plan, don't build it
|
|
318
|
-
- Commit after green—every passing test is a commit point
|
|
319
|
-
|
|
320
|
-
### technical-review
|
|
321
|
-
|
|
322
|
-
Reviews completed work with fresh perspective. Validates implementation against prior workflow artifacts without fixing code directly.
|
|
323
|
-
|
|
324
|
-
**Use when:**
|
|
325
|
-
- Implementation phase is complete
|
|
326
|
-
- User wants validation before merging/shipping
|
|
327
|
-
- Quality gate check needed after implementation
|
|
328
|
-
|
|
329
|
-
**What it checks:**
|
|
330
|
-
- Were specification requirements implemented?
|
|
331
|
-
- Were all plan acceptance criteria met?
|
|
332
|
-
- Do tests actually verify requirements?
|
|
333
|
-
- Does code follow project conventions?
|
|
247
|
+
| Skill | Description |
|
|
248
|
+
|------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
249
|
+
| [**technical-research**](skills/technical-research/) | Explore ideas from their earliest seed. Investigate market fit, technical feasibility, business viability. Free-flowing exploration across technical, business, and market domains. |
|
|
250
|
+
| [**technical-discussion**](skills/technical-discussion/) | Document technical discussions as expert architect and meeting assistant. Captures context, decisions, edge cases, competing solutions, debates, and rationale. |
|
|
251
|
+
| [**technical-specification**](skills/technical-specification/) | Build validated specifications from source material through collaborative refinement. Filters hallucinations, enriches gaps, produces standalone spec. |
|
|
252
|
+
| [**technical-planning**](skills/technical-planning/) | Transform specifications into actionable implementation plans with phases, tasks, and acceptance criteria. Supports multiple output formats. |
|
|
253
|
+
| [**technical-implementation**](skills/technical-implementation/) | Execute implementation plans using strict TDD workflow. Writes tests first, implements to pass, commits frequently, and gates phases on user approval. |
|
|
254
|
+
| [**technical-review**](skills/technical-review/) | Review completed implementation against specification requirements and plan acceptance criteria. Uses parallel subagents for efficient chain verification. Produces structured feedback without fixing code. |
|
|
334
255
|
|
|
335
256
|
## Commands
|
|
336
257
|
|
|
258
|
+
Commands are the input layer: they gather context and pass it to skills. Two types:
|
|
259
|
+
|
|
337
260
|
### Workflow Commands
|
|
338
261
|
|
|
339
|
-
Sequential
|
|
262
|
+
Sequential commands prefixed with `workflow:`. They expect files from previous phases and pass content to skills.
|
|
340
263
|
|
|
341
264
|
| Command | Description |
|
|
342
265
|
|--------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
@@ -347,16 +270,33 @@ Sequential workflow commands are prefixed with `workflow:` and expect files from
|
|
|
347
270
|
| [**/workflow:start-implementation**](commands/workflow:start-implementation.md) | Start implementing a plan. Executes tasks via strict TDD, committing after each passing test. |
|
|
348
271
|
| [**/workflow:start-review**](commands/workflow:start-review.md) | Start reviewing completed work. Validates implementation against plan tasks and acceptance criteria. |
|
|
349
272
|
|
|
273
|
+
### Utility Commands
|
|
274
|
+
|
|
275
|
+
Helpers for navigating and understanding the workflow.
|
|
276
|
+
|
|
277
|
+
| Command | Description |
|
|
278
|
+
|--------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
279
|
+
| [**/workflow:status**](commands/workflow:status.md) | Show workflow status - what topics exist at each phase, and suggested next steps. |
|
|
280
|
+
| [**/workflow:view-plan**](commands/workflow:view-plan.md) | View a plan's tasks and progress, regardless of output format. |
|
|
281
|
+
|
|
350
282
|
### Standalone Commands
|
|
351
283
|
|
|
352
|
-
|
|
284
|
+
Independent commands that gather inputs flexibly (inline context, files, or prompts) and invoke skills directly. Use these when you want skill capabilities without the full workflow structure.
|
|
353
285
|
|
|
354
286
|
| Command | Description |
|
|
355
287
|
|---------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
356
|
-
| [**/start-feature**](commands/start-feature.md) | Create a specification directly from inline context.
|
|
357
|
-
| [**/interview**](commands/interview.md) | Shift into focused questioning mode. Probes ideas with non-obvious questions, challenges assumptions, and surfaces concerns. |
|
|
288
|
+
| [**/start-feature**](commands/start-feature.md) | Create a specification directly from inline context. Invokes the specification skill without requiring a discussion document. |
|
|
358
289
|
| [**/link-dependencies**](commands/link-dependencies.md) | Link external dependencies across topics. Scans plans and wires up unresolved cross-topic dependencies. |
|
|
359
290
|
|
|
291
|
+
### Creating Custom Commands
|
|
292
|
+
|
|
293
|
+
Since skills are input-agnostic, you can create your own commands that feed them in new ways. A command just needs to:
|
|
294
|
+
|
|
295
|
+
1. Gather the inputs the skill expects
|
|
296
|
+
2. Invoke the skill with those inputs
|
|
297
|
+
|
|
298
|
+
See `/start-feature` as an example: it provides inline context to the specification skill instead of a discussion document.
|
|
299
|
+
|
|
360
300
|
## Agents
|
|
361
301
|
|
|
362
302
|
Subagents that skills can spawn for parallel task execution.
|
|
@@ -383,9 +323,9 @@ Please open an issue first to discuss significant changes.
|
|
|
383
323
|
|
|
384
324
|
## Related Packages
|
|
385
325
|
|
|
386
|
-
- [**@leeovery/claude-manager**](https://github.com/leeovery/claude-manager)
|
|
387
|
-
- [**@leeovery/claude-laravel**](https://github.com/leeovery/claude-laravel)
|
|
388
|
-
- [**@leeovery/claude-nuxt**](https://github.com/leeovery/claude-nuxt)
|
|
326
|
+
- [**@leeovery/claude-manager**](https://github.com/leeovery/claude-manager) - The plugin manager that powers skill installation
|
|
327
|
+
- [**@leeovery/claude-laravel**](https://github.com/leeovery/claude-laravel) - Laravel development skills for Claude Code
|
|
328
|
+
- [**@leeovery/claude-nuxt**](https://github.com/leeovery/claude-nuxt) - Nuxt.js development skills for Claude Code
|
|
389
329
|
|
|
390
330
|
## License
|
|
391
331
|
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Show workflow status - what exists, where you are, and what to do next.
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Show the current state of the workflow for this project.
|
|
6
|
+
|
|
7
|
+
## Step 1: Scan Directories
|
|
8
|
+
|
|
9
|
+
Check for files in each workflow directory:
|
|
10
|
+
|
|
11
|
+
```
|
|
12
|
+
docs/workflow/research/
|
|
13
|
+
docs/workflow/discussion/
|
|
14
|
+
docs/workflow/specification/
|
|
15
|
+
docs/workflow/planning/
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
## Step 2: Present Status
|
|
19
|
+
|
|
20
|
+
Research is project-wide exploration. From discussion onwards, work is organised by **topic** - different topics may be at different stages.
|
|
21
|
+
|
|
22
|
+
Show a summary like this:
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
## Workflow Status
|
|
26
|
+
|
|
27
|
+
**Research:** 2 files (exploration.md, market-analysis.md)
|
|
28
|
+
|
|
29
|
+
**Topics:**
|
|
30
|
+
|
|
31
|
+
| Topic | Discussion | Spec | Plan | Implemented |
|
|
32
|
+
|--------------|------------|------|------|-------------|
|
|
33
|
+
| auth-system | ✓ | ✓ | ✓ | in progress |
|
|
34
|
+
| payment-flow | ✓ | ✓ | - | - |
|
|
35
|
+
| notifications| ✓ | - | - | - |
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
Adapt based on what exists:
|
|
39
|
+
- If a directory is empty or missing, show "Not started"
|
|
40
|
+
- For planning, note the output format if specified in frontmatter
|
|
41
|
+
- Match topics across phases by filename
|
|
42
|
+
|
|
43
|
+
## Step 3: Suggest Next Steps
|
|
44
|
+
|
|
45
|
+
Based on what exists, offer relevant options. Don't assume linear progression - topics may have dependencies on each other.
|
|
46
|
+
|
|
47
|
+
**If nothing exists:**
|
|
48
|
+
- "Start with `/workflow:start-research` to explore ideas, or `/workflow:start-discussion` if you already know what you're building."
|
|
49
|
+
|
|
50
|
+
**If topics exist at various stages**, summarise options without being prescriptive:
|
|
51
|
+
- Topics in discussion can move to specification
|
|
52
|
+
- Topics with specs can move to planning
|
|
53
|
+
- Topics with plans can move to implementation
|
|
54
|
+
- Completed implementations can be reviewed
|
|
55
|
+
|
|
56
|
+
Example: "auth-system has a plan ready. payment-flow needs a spec before planning. You might want to complete planning for related topics before implementing if there are dependencies."
|
|
57
|
+
|
|
58
|
+
Keep suggestions brief - the user knows their project's dependencies better than we do.
|
|
59
|
+
|
|
60
|
+
## Step 4: Mention Plan Viewing
|
|
61
|
+
|
|
62
|
+
If planning files exist, let the user know they can view plan details:
|
|
63
|
+
|
|
64
|
+
```
|
|
65
|
+
To view a plan's tasks and progress, use /workflow:view-plan
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
## Notes
|
|
69
|
+
|
|
70
|
+
- Keep output concise - this is a quick status check
|
|
71
|
+
- Use tables for scannable information
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: View a plan's tasks and progress, regardless of output format.
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Display a readable summary of a plan's phases, tasks, and status.
|
|
6
|
+
|
|
7
|
+
## Step 1: Identify the Plan
|
|
8
|
+
|
|
9
|
+
If no topic is specified, list available plans:
|
|
10
|
+
|
|
11
|
+
```bash
|
|
12
|
+
ls docs/workflow/planning/
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
Ask the user which plan to view.
|
|
16
|
+
|
|
17
|
+
## Step 2: Read the Plan Index
|
|
18
|
+
|
|
19
|
+
Read the plan file from `docs/workflow/planning/{topic}.md` and check the `format:` field in the frontmatter.
|
|
20
|
+
|
|
21
|
+
## Step 3: Load Format Reference
|
|
22
|
+
|
|
23
|
+
Load the corresponding output format reference:
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
skills/technical-planning/references/output-{format}.md
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
This reference contains instructions for reading plans in that format.
|
|
30
|
+
|
|
31
|
+
## Step 4: Read Plan Content
|
|
32
|
+
|
|
33
|
+
Follow the "Reading" or "Implementation" section in the format reference to locate and read the actual plan content.
|
|
34
|
+
|
|
35
|
+
## Step 5: Present Summary
|
|
36
|
+
|
|
37
|
+
Display a readable summary:
|
|
38
|
+
|
|
39
|
+
```
|
|
40
|
+
## Plan: {topic}
|
|
41
|
+
|
|
42
|
+
**Format:** {format}
|
|
43
|
+
|
|
44
|
+
### Phase 1: {phase name}
|
|
45
|
+
- [ ] Task 1.1: {description}
|
|
46
|
+
- [x] Task 1.2: {description}
|
|
47
|
+
|
|
48
|
+
### Phase 2: {phase name}
|
|
49
|
+
- [ ] Task 2.1: {description}
|
|
50
|
+
...
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
Show:
|
|
54
|
+
- Phase names and acceptance criteria
|
|
55
|
+
- Task descriptions and status (if trackable)
|
|
56
|
+
- Any blocked or dependent tasks
|
|
57
|
+
|
|
58
|
+
Keep it scannable - this is for quick reference, not full detail.
|
|
59
|
+
|
|
60
|
+
## Notes
|
|
61
|
+
|
|
62
|
+
- Some formats (like external issue trackers) may not be fully readable without API access - note this if applicable
|
|
63
|
+
- If status tracking isn't available in the format, just show the task structure
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: technical-discussion
|
|
3
|
-
description: "Document technical discussions as expert architect and meeting assistant. Capture context, decisions, edge cases, debates, and rationale without jumping to specification or implementation.
|
|
3
|
+
description: "Document technical discussions as expert architect and meeting assistant. Capture context, decisions, edge cases, debates, and rationale without jumping to specification or implementation. Use when: (1) Users discuss/explore/debate architecture or design, (2) Working through edge cases before specification, (3) Need to document technical decisions and their rationale, (4) Capturing competing solutions and why choices were made. Creates documentation in docs/workflow/discussion/{topic}.md that can be used to build validated specifications."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Technical Discussion
|
|
@@ -10,7 +10,7 @@ Act as **expert software architect** participating in discussions AND **document
|
|
|
10
10
|
## Purpose in the Workflow
|
|
11
11
|
|
|
12
12
|
This skill can be used:
|
|
13
|
-
- **Sequentially
|
|
13
|
+
- **Sequentially**: After research or exploration to debate and document decisions
|
|
14
14
|
- **Standalone** (Contract entry): To document technical decisions from any source
|
|
15
15
|
|
|
16
16
|
Either way: Capture decisions, rationale, competing approaches, and edge cases.
|
|
@@ -17,12 +17,12 @@ You're an AI - do both. Engage fully while documenting. Don't dumb down.
|
|
|
17
17
|
|
|
18
18
|
## Workflow
|
|
19
19
|
|
|
20
|
-
**Your role:
|
|
20
|
+
**Your role: discuss and document only**
|
|
21
21
|
|
|
22
22
|
1. **Discuss** - Participate
|
|
23
23
|
2. **Document** - Capture
|
|
24
|
-
3. **Plan** - ❌
|
|
25
|
-
4. **Implement** - ❌
|
|
24
|
+
3. **Plan** - ❌ Not this skill's job
|
|
25
|
+
4. **Implement** - ❌ Not this skill's job
|
|
26
26
|
|
|
27
27
|
Stop after documentation. No plans, implementation steps, or code.
|
|
28
28
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: technical-implementation
|
|
3
|
-
description: "Execute implementation plans using strict TDD workflow with quality gates.
|
|
3
|
+
description: "Execute implementation plans using strict TDD workflow with quality gates. Use when: (1) Implementing a plan from docs/workflow/planning/{topic}.md, (2) User says 'implement', 'build', or 'code this' with a plan available, (3) Ad hoc coding that should follow TDD and quality standards, (4) Bug fixes or features benefiting from structured implementation. Writes tests first, implements to pass, commits frequently, stops for user approval between phases."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Technical Implementation
|
|
@@ -12,7 +12,7 @@ Execute plans through strict TDD. Write tests first, then code to pass them.
|
|
|
12
12
|
## Purpose in the Workflow
|
|
13
13
|
|
|
14
14
|
This skill can be used:
|
|
15
|
-
- **Sequentially
|
|
15
|
+
- **Sequentially**: To execute a plan created by technical-planning
|
|
16
16
|
- **Standalone** (Contract entry): To execute any plan that follows plan-format conventions
|
|
17
17
|
|
|
18
18
|
Either way: Execute via strict TDD - tests first, implementation second.
|
|
@@ -104,7 +104,7 @@ Check the specification when:
|
|
|
104
104
|
|
|
105
105
|
The specification (if available) is the source of truth for design decisions. If no specification exists, the plan is the authority.
|
|
106
106
|
|
|
107
|
-
**Important:** If
|
|
107
|
+
**Important:** If prior source material exists (research notes, discussion documents, etc.), ignore it during implementation. It may contain outdated ideas, rejected approaches, or superseded decisions. The specification filtered and validated that content - refer only to the specification and plan.
|
|
108
108
|
|
|
109
109
|
## Project-Specific Conventions
|
|
110
110
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: technical-planning
|
|
3
|
-
description: "Transform specifications into actionable implementation plans with phases, tasks, and acceptance criteria.
|
|
3
|
+
description: "Transform specifications into actionable implementation plans with phases, tasks, and acceptance criteria. Use when: (1) User asks to create/write an implementation plan, (2) User asks to plan implementation from a specification, (3) Converting specifications from docs/workflow/specification/{topic}.md into implementation plans, (4) User says 'plan this' or 'create a plan', (5) Need to structure how to build something with phases and concrete steps. Creates plans in docs/workflow/planning/{topic}.md that can be executed via strict TDD."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Technical Planning
|
|
@@ -12,7 +12,7 @@ Your role spans product (WHAT we're building and WHY) and technical (HOW to stru
|
|
|
12
12
|
## Purpose in the Workflow
|
|
13
13
|
|
|
14
14
|
This skill can be used:
|
|
15
|
-
- **Sequentially
|
|
15
|
+
- **Sequentially**: From a validated specification
|
|
16
16
|
- **Standalone** (Contract entry): From any specification meeting format requirements
|
|
17
17
|
|
|
18
18
|
Either way: Transform specifications into actionable phases, tasks, and acceptance criteria.
|
|
@@ -27,7 +27,7 @@ Either way: Transform specifications into actionable phases, tasks, and acceptan
|
|
|
27
27
|
|
|
28
28
|
## Source Material
|
|
29
29
|
|
|
30
|
-
**The specification is your sole input.** Everything you need should be in the specification - do not request details from
|
|
30
|
+
**The specification is your sole input.** Everything you need should be in the specification - do not request details from prior source material. If information is missing, ask for clarification on the specification itself.
|
|
31
31
|
|
|
32
32
|
## The Process
|
|
33
33
|
|
|
@@ -35,7 +35,7 @@ From the specification (`docs/workflow/specification/{topic}.md`), extract:
|
|
|
35
35
|
- Constraints and requirements
|
|
36
36
|
- **External dependencies** (from the Dependencies section)
|
|
37
37
|
|
|
38
|
-
**The specification is your sole input.**
|
|
38
|
+
**The specification is your sole input.** Prior source materials have already been validated, filtered, and enriched into the specification. Everything you need is in the specification - do not reference other documents.
|
|
39
39
|
|
|
40
40
|
#### Extract External Dependencies
|
|
41
41
|
|
|
@@ -261,9 +261,9 @@ project/
|
|
|
261
261
|
│ ├── task-2 - [P1] Add login endpoint.md
|
|
262
262
|
│ └── task-3 - [P2] Session management.md
|
|
263
263
|
├── docs/workflow/
|
|
264
|
-
│ ├── discussion/{topic}.md #
|
|
265
|
-
│ ├── specification/{topic}.md #
|
|
266
|
-
│ └── planning/{topic}.md #
|
|
264
|
+
│ ├── discussion/{topic}.md # Discussion output
|
|
265
|
+
│ ├── specification/{topic}.md # Specification output
|
|
266
|
+
│ └── planning/{topic}.md # Planning output (format: backlog-md - pointer)
|
|
267
267
|
```
|
|
268
268
|
|
|
269
269
|
## Implementation
|
|
@@ -375,9 +375,9 @@ project/
|
|
|
375
375
|
├── .beads/
|
|
376
376
|
│ └── issues.jsonl # Beads database
|
|
377
377
|
├── docs/workflow/
|
|
378
|
-
│ ├── discussion/{topic}.md #
|
|
379
|
-
│ ├── specification/{topic}.md #
|
|
380
|
-
│ └── planning/{topic}.md #
|
|
378
|
+
│ ├── discussion/{topic}.md # Discussion output
|
|
379
|
+
│ ├── specification/{topic}.md # Specification output
|
|
380
|
+
│ └── planning/{topic}.md # Planning output (format: beads)
|
|
381
381
|
```
|
|
382
382
|
|
|
383
383
|
## Priority Mapping
|
|
@@ -231,9 +231,9 @@ After planning:
|
|
|
231
231
|
|
|
232
232
|
```
|
|
233
233
|
docs/workflow/
|
|
234
|
-
├── discussion/{topic}.md #
|
|
235
|
-
├── specification/{topic}.md #
|
|
236
|
-
└── planning/{topic}.md #
|
|
234
|
+
├── discussion/{topic}.md # Discussion output
|
|
235
|
+
├── specification/{topic}.md # Specification output
|
|
236
|
+
└── planning/{topic}.md # Planning output (format: linear - pointer)
|
|
237
237
|
|
|
238
238
|
Linear:
|
|
239
239
|
└── Project: {topic}
|
|
@@ -234,9 +234,9 @@ After planning:
|
|
|
234
234
|
|
|
235
235
|
```
|
|
236
236
|
docs/workflow/
|
|
237
|
-
├── discussion/{topic}.md #
|
|
238
|
-
├── specification/{topic}.md #
|
|
239
|
-
└── planning/{topic}.md #
|
|
237
|
+
├── discussion/{topic}.md # Discussion output
|
|
238
|
+
├── specification/{topic}.md # Specification output
|
|
239
|
+
└── planning/{topic}.md # Planning output (format: local-markdown)
|
|
240
240
|
```
|
|
241
241
|
|
|
242
242
|
## Implementation
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: technical-research
|
|
3
|
-
description: "Explore ideas, validate concepts, and research broadly across technical, business, and market domains.
|
|
3
|
+
description: "Explore ideas, validate concepts, and research broadly across technical, business, and market domains. Use when: (1) User has a new idea to explore, (2) Need to research a topic deeply, (3) Validating feasibility - technical, business, or market, (4) Learning and exploration without necessarily building anything, (5) User says 'research this' or 'explore this idea', (6) Brain dumping early thoughts before formal discussion. Creates research documents in docs/workflow/research/ that may feed into discussion or specification."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Technical Research
|
|
@@ -10,7 +10,7 @@ Act as **research partner** with broad expertise spanning technical, product, bu
|
|
|
10
10
|
## Purpose in the Workflow
|
|
11
11
|
|
|
12
12
|
This skill can be used:
|
|
13
|
-
- **Sequentially
|
|
13
|
+
- **Sequentially**: First step - explore ideas before detailed discussion
|
|
14
14
|
- **Standalone** (Contract entry): To research and validate any idea, feature, or concept
|
|
15
15
|
|
|
16
16
|
Either way: Explore feasibility (technical, business, market), validate assumptions, document findings.
|
|
@@ -45,7 +45,7 @@ Don't constrain yourself. Research goes wherever it needs to go.
|
|
|
45
45
|
|
|
46
46
|
## Questioning
|
|
47
47
|
|
|
48
|
-
|
|
48
|
+
For structured questioning, use the interview reference (`references/interview.md`). Good research questions:
|
|
49
49
|
|
|
50
50
|
- Reveal hidden complexity
|
|
51
51
|
- Surface concerns early
|
|
@@ -62,7 +62,7 @@ Start with one file. Early research is messy - topics aren't clear, you're follo
|
|
|
62
62
|
|
|
63
63
|
**Let themes emerge**: Over multiple sessions, topics may become distinct. When they do, split into semantic files (`market-landscape.md`, `technical-feasibility.md`).
|
|
64
64
|
|
|
65
|
-
**Periodic review**: Every few sessions, assess: are themes emerging? Split them out. Still fuzzy? Keep exploring. Ready for deeper discussion? Research
|
|
65
|
+
**Periodic review**: Every few sessions, assess: are themes emerging? Split them out. Still fuzzy? Keep exploring. Ready for deeper discussion or specification? Research is complete.
|
|
66
66
|
|
|
67
67
|
## Documentation Loop
|
|
68
68
|
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
# Interview Mode
|
|
2
|
+
|
|
3
|
+
Focused questioning to probe ideas more deeply during research.
|
|
4
|
+
|
|
5
|
+
## Process
|
|
6
|
+
|
|
7
|
+
1. **Check existing context**: Read docs in `docs/workflow/research/` to understand what's already been explored.
|
|
8
|
+
|
|
9
|
+
2. **Begin interviewing**: Use the AskUserQuestion tool to probe the idea. Focus on:
|
|
10
|
+
- Non-obvious questions (not things already answered)
|
|
11
|
+
- Assumptions and unstated constraints
|
|
12
|
+
- Tradeoffs and concerns
|
|
13
|
+
- What could go wrong
|
|
14
|
+
- The "why" behind decisions
|
|
15
|
+
|
|
16
|
+
3. **Go where it leads**: Follow tangents if they reveal something valuable. This isn't a checklist - it's a conversation.
|
|
17
|
+
|
|
18
|
+
4. **Document as you go**: Don't defer writing to the end. Capture insights in `docs/workflow/research/` using semantic filenames. Ask before documenting: "Shall I capture that?"
|
|
19
|
+
|
|
20
|
+
5. **Commit frequently**: At natural breaks and before context refresh.
|
|
21
|
+
|
|
22
|
+
6. **Exit when done**: The user decides when the interview is complete.
|
|
23
|
+
|
|
24
|
+
## Question Quality
|
|
25
|
+
|
|
26
|
+
Aim for questions that:
|
|
27
|
+
- The user hasn't already answered
|
|
28
|
+
- Reveal hidden complexity
|
|
29
|
+
- Surface concerns early
|
|
30
|
+
- Challenge comfortable assumptions
|
|
31
|
+
|
|
32
|
+
Avoid:
|
|
33
|
+
- Restating what's already documented
|
|
34
|
+
- Obvious surface-level questions
|
|
35
|
+
- Leading questions that assume an answer
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: technical-review
|
|
3
|
-
description: "Validate completed implementation against plan tasks and acceptance criteria.
|
|
3
|
+
description: "Validate completed implementation against plan tasks and acceptance criteria. Use when: (1) Implementation is complete, (2) User wants validation before merging/shipping, (3) Quality gate check needed after implementation. Reviews ALL plan tasks for implementation correctness, test adequacy, and code quality. Produces structured feedback (approve, request changes, or comments) - does NOT fix code."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Technical Review
|
|
@@ -20,7 +20,7 @@ Optional but helpful:
|
|
|
20
20
|
## Purpose in the Workflow
|
|
21
21
|
|
|
22
22
|
This skill can be used:
|
|
23
|
-
- **Sequentially
|
|
23
|
+
- **Sequentially**: After implementation of a planned feature
|
|
24
24
|
- **Standalone** (Contract entry): To review any implementation against a plan
|
|
25
25
|
|
|
26
26
|
Either way: Verify every plan task was implemented, tested adequately, and meets quality standards.
|
|
@@ -1,28 +1,29 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: technical-specification
|
|
3
|
-
description: "Build validated specifications from
|
|
3
|
+
description: "Build validated specifications from source material through collaborative refinement. Use when: (1) User asks to create/build a specification from source material, (2) User wants to validate and refine content before planning, (3) Converting source material (discussions, research, requirements) into standalone specifications, (4) User says 'specify this' or 'create a spec', (5) Need to filter hallucinations and enrich gaps before formal planning. Creates specifications in docs/workflow/specification/{topic}.md that can be used to build implementation plans."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Technical Specification
|
|
7
7
|
|
|
8
|
-
Act as **expert technical architect** and **specification builder**. Collaborate with the user to transform
|
|
8
|
+
Act as **expert technical architect** and **specification builder**. Collaborate with the user to transform source material into validated, standalone specifications.
|
|
9
9
|
|
|
10
10
|
Your role is to synthesize reference material, present it for validation, and build a specification that formal planning can execute against.
|
|
11
11
|
|
|
12
12
|
## Purpose in the Workflow
|
|
13
13
|
|
|
14
14
|
This skill can be used:
|
|
15
|
-
- **Sequentially
|
|
16
|
-
- **Standalone
|
|
15
|
+
- **Sequentially**: After source material has been captured (discussions, research, etc.)
|
|
16
|
+
- **Standalone**: With reference material from any source (research docs, conversation transcripts, design documents, inline feature description)
|
|
17
17
|
|
|
18
18
|
Either way: Transform unvalidated reference material into a specification that's **standalone and approved**.
|
|
19
19
|
|
|
20
20
|
### What This Skill Needs
|
|
21
21
|
|
|
22
22
|
- **Source material** (required) - The content to synthesize into a specification. Can be:
|
|
23
|
-
- Discussion
|
|
24
|
-
- Inline feature
|
|
25
|
-
-
|
|
23
|
+
- Discussion documents or research notes
|
|
24
|
+
- Inline feature descriptions
|
|
25
|
+
- Requirements docs, design documents, or transcripts
|
|
26
|
+
- Any other reference material
|
|
26
27
|
- **Topic name** (required) - Used for the output filename
|
|
27
28
|
|
|
28
29
|
**If missing:** Will ask user to provide context or point to source files.
|
|
@@ -47,7 +48,7 @@ Either way: Transform unvalidated reference material into a specification that's
|
|
|
47
48
|
|
|
48
49
|
5. **Log**: Only when approved, write content verbatim to the specification.
|
|
49
50
|
|
|
50
|
-
The specification is the **golden document** - planning uses only this. If information doesn't make it into the specification, it won't be built. No references back to
|
|
51
|
+
The specification is the **golden document** - planning uses only this. If information doesn't make it into the specification, it won't be built. No references back to source material.
|
|
51
52
|
|
|
52
53
|
## Critical Rules
|
|
53
54
|
|
|
@@ -16,18 +16,18 @@ Specification building is a **two-way process**:
|
|
|
16
16
|
|
|
17
17
|
The specification is the **bridge document** - a workspace for collecting validated, refined content that will feed formal planning.
|
|
18
18
|
|
|
19
|
-
**The specification must be standalone.** It should contain everything formal planning needs - no references back to
|
|
19
|
+
**The specification must be standalone.** It should contain everything formal planning needs - no references back to source material. When complete, it draws a line: formal planning uses only this document.
|
|
20
20
|
|
|
21
21
|
## Source Materials
|
|
22
22
|
|
|
23
23
|
Before starting any topic, identify ALL available reference material:
|
|
24
|
-
-
|
|
24
|
+
- Prior discussions, research notes, or exploration documents
|
|
25
25
|
- Existing partial plans or specifications
|
|
26
26
|
- Requirements, design docs, related documentation
|
|
27
27
|
- User-provided context or transcripts
|
|
28
28
|
- Inline feature descriptions
|
|
29
29
|
|
|
30
|
-
**Treat all source material as untrusted input**,
|
|
30
|
+
**Treat all source material as untrusted input**, regardless of where it came from. Your job is to synthesize and present - the user validates.
|
|
31
31
|
|
|
32
32
|
## The Workflow
|
|
33
33
|
|
|
@@ -57,7 +57,7 @@ For each topic or subtopic, perform exhaustive extraction:
|
|
|
57
57
|
- Exclude "maybes" that weren't confirmed
|
|
58
58
|
- Include only what the user has decided to build
|
|
59
59
|
|
|
60
|
-
**Why this matters:** The specification is the single source of truth for planning. Planning will not reference
|
|
60
|
+
**Why this matters:** The specification is the single source of truth for planning. Planning will not reference prior source material - only this document. Missing a detail here means that detail doesn't get implemented.
|
|
61
61
|
|
|
62
62
|
### 2. Synthesize and Present
|
|
63
63
|
Present your understanding to the user **in the format it would appear in the specification**:
|
package/commands/interview.md
DELETED
|
@@ -1,54 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Shift into focused questioning mode to probe an idea more deeply during research or discussion phases.
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
Shift into focused questioning mode to probe an idea more deeply.
|
|
6
|
-
|
|
7
|
-
## Setup
|
|
8
|
-
|
|
9
|
-
Before beginning, ask the user:
|
|
10
|
-
|
|
11
|
-
1. **What stage are you in?** Research or discussion?
|
|
12
|
-
2. **What topic or idea do you want to explore?**
|
|
13
|
-
|
|
14
|
-
Wait for responses before proceeding.
|
|
15
|
-
|
|
16
|
-
## Process
|
|
17
|
-
|
|
18
|
-
1. **Check for existing context**:
|
|
19
|
-
- Research: Look for docs in `docs/workflow/research/`
|
|
20
|
-
- Discussion: Look for the topic's file in `docs/workflow/discussion/{topic}.md`
|
|
21
|
-
|
|
22
|
-
Read what exists to understand what's already been explored.
|
|
23
|
-
|
|
24
|
-
2. **Begin interviewing**: Use the AskUserQuestion tool to probe the idea. Focus on:
|
|
25
|
-
- Non-obvious questions (not things already answered)
|
|
26
|
-
- Assumptions and unstated constraints
|
|
27
|
-
- Tradeoffs and concerns
|
|
28
|
-
- What could go wrong
|
|
29
|
-
- The "why" behind decisions
|
|
30
|
-
|
|
31
|
-
3. **Go where it leads**: Follow tangents if they reveal something valuable. This isn't a checklist—it's a conversation.
|
|
32
|
-
|
|
33
|
-
4. **Document as you go**: Don't defer writing to the end. Capture insights in the appropriate location:
|
|
34
|
-
- Research: `docs/workflow/research/` (semantic filenames)
|
|
35
|
-
- Discussion: `docs/workflow/discussion/{topic}.md`
|
|
36
|
-
|
|
37
|
-
Ask before documenting: "Shall I capture that?"
|
|
38
|
-
|
|
39
|
-
5. **Commit frequently**: At natural breaks and before context refresh. Don't risk losing detail.
|
|
40
|
-
|
|
41
|
-
6. **Exit when done**: The user decides when the interview is complete.
|
|
42
|
-
|
|
43
|
-
## Question quality
|
|
44
|
-
|
|
45
|
-
Aim for questions that:
|
|
46
|
-
- The user hasn't already answered
|
|
47
|
-
- Reveal hidden complexity
|
|
48
|
-
- Surface concerns early
|
|
49
|
-
- Challenge comfortable assumptions
|
|
50
|
-
|
|
51
|
-
Avoid:
|
|
52
|
-
- Restating what's already documented
|
|
53
|
-
- Obvious surface-level questions
|
|
54
|
-
- Leading questions that assume an answer
|