@leeovery/claude-technical-workflows 2.0.6 → 2.0.8
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 +76 -22
- package/commands/start-implementation.md +1 -0
- package/commands/start-planning.md +1 -1
- package/package.json +1 -1
- package/skills/technical-implementation/SKILL.md +2 -1
- package/skills/technical-implementation/references/environment-setup.md +6 -0
- package/skills/technical-planning/references/output-formats.md +2 -0
package/README.md
CHANGED
|
@@ -1,10 +1,11 @@
|
|
|
1
1
|
<h1 align="center">Claude Technical Workflows</h1>
|
|
2
2
|
|
|
3
3
|
<p align="center">
|
|
4
|
-
<strong>
|
|
4
|
+
<strong>From Idea to Implementation: Software Engineering Workflows for Claude Code</strong>
|
|
5
5
|
</p>
|
|
6
6
|
|
|
7
7
|
<p align="center">
|
|
8
|
+
<a href="#how-do-i-use-this">How to Use</a> •
|
|
8
9
|
<a href="#installation">Installation</a> •
|
|
9
10
|
<a href="#the-six-phase-workflow">Workflow</a> •
|
|
10
11
|
<a href="#skills">Skills</a> •
|
|
@@ -24,12 +25,63 @@
|
|
|
24
25
|
|
|
25
26
|
## About
|
|
26
27
|
|
|
27
|
-
A
|
|
28
|
+
A six-phase workflow for Claude Code that captures context, decisions, and rationale before any code is written, then implements and validates the work against those artifacts.
|
|
28
29
|
|
|
29
|
-
|
|
30
|
+
```
|
|
31
|
+
Research → Explore ideas
|
|
32
|
+
↓
|
|
33
|
+
Discussion → Debate and decide
|
|
34
|
+
↓
|
|
35
|
+
Specification → Validate and refine
|
|
36
|
+
↓
|
|
37
|
+
Planning → Structure the work
|
|
38
|
+
↓
|
|
39
|
+
Implementation → Build via TDD
|
|
40
|
+
↓
|
|
41
|
+
Review → Validate against spec
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
**Why this matters:** Complex features benefit from thorough discussion before implementation. These skills help you document the *what* and *why* before diving into the *how*, preserving architectural decisions, edge cases, and the reasoning behind choices that would otherwise be lost.
|
|
30
45
|
|
|
31
46
|
**This is a work in progress.** The workflow is being refined through real-world usage. Expect updates as patterns evolve.
|
|
32
47
|
|
|
48
|
+
**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.
|
|
49
|
+
|
|
50
|
+
## How do I use this?
|
|
51
|
+
|
|
52
|
+
You have two entry points:
|
|
53
|
+
|
|
54
|
+
| Start here... | When... | Command |
|
|
55
|
+
|---------------|---------|---------|
|
|
56
|
+
| **Research** | You have a fresh idea to explore: feasibility, market, viability, early thoughts | `/start-research` |
|
|
57
|
+
| **Discussion** | You already know what you're building and need to iron out the details | `/start-discussion` |
|
|
58
|
+
|
|
59
|
+
**Research** is a free-for-all. Explore broadly, follow tangents, challenge assumptions. Not everything researched gets built, and that's fine. Use this for ideas that need validating before you commit.
|
|
60
|
+
|
|
61
|
+
**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.
|
|
62
|
+
|
|
63
|
+
Then follow the flow:
|
|
64
|
+
|
|
65
|
+
```
|
|
66
|
+
Research → Discussion → Specification → Planning → Implementation → Review
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
Each phase builds on the previous. Specification validates your discussions into a standalone doc. Planning breaks that into tasks. Implementation executes via TDD. Review validates against the spec.
|
|
70
|
+
|
|
71
|
+
### Commands
|
|
72
|
+
|
|
73
|
+
Each phase has a command designed as its entry point:
|
|
74
|
+
|
|
75
|
+
| Phase | Command |
|
|
76
|
+
|----------------|-------------------------|
|
|
77
|
+
| Research | `/start-research` |
|
|
78
|
+
| Discussion | `/start-discussion` |
|
|
79
|
+
| Specification | `/start-specification` |
|
|
80
|
+
| Planning | `/start-planning` |
|
|
81
|
+
| Implementation | `/start-implementation` |
|
|
82
|
+
|
|
83
|
+
Run the command directly or ask Claude to run it. Each command gathers the context it needs, asking what you're researching, discussing, or planning. Where relevant, it looks at outputs from the previous phase and offers you a choice from the list.
|
|
84
|
+
|
|
33
85
|
## Installation
|
|
34
86
|
|
|
35
87
|
### npm
|
|
@@ -56,7 +108,7 @@ Due to bugs in npm 7+ ([issue #3042](https://github.com/npm/cli/issues/3042)) an
|
|
|
56
108
|
npx claude-manager remove @leeovery/claude-technical-workflows && npm rm @leeovery/claude-technical-workflows
|
|
57
109
|
```
|
|
58
110
|
|
|
59
|
-
The [Claude Manager](https://github.com/leeovery/claude-manager) copies skills to `.claude/` automatically.
|
|
111
|
+
The [Claude Manager](https://github.com/leeovery/claude-manager) copies skills, commands, and agents to `.claude/` automatically.
|
|
60
112
|
|
|
61
113
|
## The Six-Phase Workflow
|
|
62
114
|
|
|
@@ -110,6 +162,7 @@ Documents are stored using a **phase-first** organization:
|
|
|
110
162
|
```
|
|
111
163
|
docs/workflow/
|
|
112
164
|
├── research/ # Phase 1 - flat, semantically named files
|
|
165
|
+
│ ├── exploration.md
|
|
113
166
|
│ ├── competitor-analysis.md
|
|
114
167
|
│ └── pricing-models.md
|
|
115
168
|
├── discussion/ # Phase 2 - one file per topic
|
|
@@ -120,7 +173,7 @@ docs/workflow/
|
|
|
120
173
|
└── {topic}.md
|
|
121
174
|
```
|
|
122
175
|
|
|
123
|
-
Research
|
|
176
|
+
Research starts with `exploration.md` and splits into topic files as themes emerge. From discussion onwards, each topic gets its own file per phase.
|
|
124
177
|
|
|
125
178
|
### Package Structure
|
|
126
179
|
|
|
@@ -148,14 +201,14 @@ agents/
|
|
|
148
201
|
|
|
149
202
|
## Skills
|
|
150
203
|
|
|
151
|
-
| Skill
|
|
152
|
-
|
|
153
|
-
| [**technical-research**](skills/technical-research/)
|
|
154
|
-
| [**technical-discussion**](skills/technical-discussion/)
|
|
155
|
-
| [**technical-specification**](skills/technical-specification/)
|
|
156
|
-
| [**technical-planning**](skills/technical-planning/)
|
|
157
|
-
| [**technical-implementation**](skills/technical-implementation/) | 5
|
|
158
|
-
| [**technical-review**](skills/technical-review/)
|
|
204
|
+
| Skill | Phase | Description |
|
|
205
|
+
|------------------------------------------------------------------|-------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
206
|
+
| [**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. |
|
|
207
|
+
| [**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. |
|
|
208
|
+
| [**technical-specification**](skills/technical-specification/) | 3 | Build validated specifications from discussion documents through collaborative refinement. Filters hallucinations, enriches gaps, produces standalone spec. |
|
|
209
|
+
| [**technical-planning**](skills/technical-planning/) | 4 | Transform specifications into actionable implementation plans with phases, tasks, and acceptance criteria. Supports multiple output formats. |
|
|
210
|
+
| [**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. |
|
|
211
|
+
| [**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. |
|
|
159
212
|
|
|
160
213
|
### technical-research
|
|
161
214
|
|
|
@@ -254,20 +307,21 @@ Reviews completed work with fresh perspective. Validates implementation against
|
|
|
254
307
|
|
|
255
308
|
Slash commands to quickly invoke the workflow.
|
|
256
309
|
|
|
257
|
-
| Command
|
|
258
|
-
|
|
259
|
-
| [**/start-research**](commands/start-research.md)
|
|
260
|
-
| [**/start-discussion**](commands/start-discussion.md)
|
|
261
|
-
| [**/start-specification**](commands/start-specification.md)
|
|
262
|
-
| [**/start-planning**](commands/start-planning.md)
|
|
263
|
-
| [**/
|
|
310
|
+
| Command | Description |
|
|
311
|
+
|---------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
312
|
+
| [**/start-research**](commands/start-research.md) | Begin research exploration. For early-stage ideas, feasibility checks, and broad exploration before formal discussion. |
|
|
313
|
+
| [**/start-discussion**](commands/start-discussion.md) | Begin a new technical discussion. Gathers topic, context, background information, and relevant codebase areas before starting documentation. |
|
|
314
|
+
| [**/start-specification**](commands/start-specification.md) | Start a specification session from an existing discussion. Validates and refines discussion content into a standalone specification. |
|
|
315
|
+
| [**/start-planning**](commands/start-planning.md) | Start a planning session from an existing specification. Creates implementation plans with phases, tasks, and acceptance criteria. Supports multiple output formats (markdown, Linear, Backlog.md, Beads). |
|
|
316
|
+
| [**/start-implementation**](commands/start-implementation.md) | Start implementing a plan. Executes tasks via strict TDD, committing after each passing test. |
|
|
317
|
+
| [**/interview**](commands/interview.md) | Shift into focused questioning mode during research or discussion. Probes ideas with non-obvious questions, challenges assumptions, and surfaces concerns. |
|
|
264
318
|
|
|
265
319
|
## Agents
|
|
266
320
|
|
|
267
321
|
Subagents that skills can spawn for parallel task execution.
|
|
268
322
|
|
|
269
|
-
| Agent
|
|
270
|
-
|
|
323
|
+
| Agent | Used By | Description |
|
|
324
|
+
|------------------------------------------------|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
271
325
|
| [**chain-verifier**](agents/chain-verifier.md) | technical-review | Verifies a single plan task was implemented correctly. Checks implementation, tests (not under/over-tested), and code quality. Multiple chain-verifiers run in parallel to verify ALL tasks efficiently. |
|
|
272
326
|
|
|
273
327
|
## Requirements
|
|
@@ -59,6 +59,7 @@ After the user selects a plan:
|
|
|
59
59
|
2. If it exists, note the file location for the skill handoff
|
|
60
60
|
3. If missing, ask: "Are there any environment setup instructions I should follow?"
|
|
61
61
|
- If the user provides instructions, save them to `docs/workflow/environment-setup.md`, commit and push to Git
|
|
62
|
+
- If the user says no, create `docs/workflow/environment-setup.md` with "No special setup required." and commit. This prevents asking again in future sessions.
|
|
62
63
|
- See `skills/technical-implementation/references/environment-setup.md` for format guidance
|
|
63
64
|
|
|
64
65
|
## Step 4: Ask About Scope
|
|
@@ -62,7 +62,7 @@ Ask: **Which specification would you like to plan?**
|
|
|
62
62
|
|
|
63
63
|
Ask: **Where should this plan live?**
|
|
64
64
|
|
|
65
|
-
Load **[output-formats.md](skills/technical-planning/references/output-formats.md)** and present the available formats to help the user choose. Then load the corresponding output adapter for that format's setup requirements.
|
|
65
|
+
Load **[output-formats.md](../skills/technical-planning/references/output-formats.md)** and present the available formats to help the user choose. Then load the corresponding output adapter for that format's setup requirements.
|
|
66
66
|
|
|
67
67
|
## Step 5: Gather Additional Context
|
|
68
68
|
|
package/package.json
CHANGED
|
@@ -39,7 +39,8 @@ Complete ALL setup steps before proceeding to implementation work.
|
|
|
39
39
|
|
|
40
40
|
1. **Check environment setup** (if not already done)
|
|
41
41
|
- Look for `docs/workflow/environment-setup.md`
|
|
42
|
-
- If exists
|
|
42
|
+
- If exists and states "No special setup required", skip to step 2
|
|
43
|
+
- If exists with instructions, follow the setup before proceeding
|
|
43
44
|
- If missing, ask: "Are there any environment setup instructions I should follow?"
|
|
44
45
|
|
|
45
46
|
See **[environment-setup.md](references/environment-setup.md)** for details.
|
|
@@ -44,6 +44,12 @@ If they provide instructions, offer to save them:
|
|
|
44
44
|
|
|
45
45
|
> "Would you like me to save these instructions to `docs/workflow/environment-setup.md` for future sessions?"
|
|
46
46
|
|
|
47
|
+
If they say no setup is needed, create `docs/workflow/environment-setup.md` with "No special setup required." and commit. This prevents asking the same question in future sessions.
|
|
48
|
+
|
|
49
|
+
## No Setup Required
|
|
50
|
+
|
|
51
|
+
If the environment setup document contains only "No special setup required" (or similar), skip environment setup and proceed directly to reading the plan.
|
|
52
|
+
|
|
47
53
|
## Plan Format Setup
|
|
48
54
|
|
|
49
55
|
Some plan formats require specific tools. Check the plan's `format` field and load the corresponding output adapter from the planning skill for setup instructions:
|
|
@@ -6,6 +6,8 @@
|
|
|
6
6
|
|
|
7
7
|
Plans can be stored in different formats. **Ask the user which format they prefer** - present the benefits from each adapter file and let them decide.
|
|
8
8
|
|
|
9
|
+
**IMPORTANT**: Only offer formats listed below. Do not invent or suggest formats that don't have corresponding `output-*.md` files in this directory.
|
|
10
|
+
|
|
9
11
|
## Available Formats
|
|
10
12
|
|
|
11
13
|
- **[Local Markdown](output-local-markdown.md)** - Single markdown file, no external tools
|