@leeovery/claude-technical-workflows 2.0.19 → 2.0.20
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
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
|
@@ -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
|
|
@@ -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
|
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
|