@wbern/claude-instructions 2.4.1 → 2.6.0
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 +17 -3
- package/package.json +1 -1
- package/src/README.md +8 -2
- package/src/fragments/complexity-signals.md +11 -0
- package/src/sources/forever.md +91 -0
- package/src/sources/refactor.md +3 -0
- package/src/sources/research.md +83 -0
- package/src/sources/simplify.md +64 -0
package/README.md
CHANGED
|
@@ -1,3 +1,8 @@
|
|
|
1
|
+
<!--
|
|
2
|
+
⚠️ DO NOT EDIT THIS FILE DIRECTLY
|
|
3
|
+
Edit src/README.md instead - this file is auto-generated by pnpm build
|
|
4
|
+
-->
|
|
5
|
+
|
|
1
6
|
# @wbern/claude-instructions
|
|
2
7
|
|
|
3
8
|
[](https://www.npmjs.com/package/@wbern/claude-instructions)
|
|
@@ -9,7 +14,7 @@
|
|
|
9
14
|
[](https://claude.ai/code)
|
|
10
15
|
[](https://github.com/wbern/claude-instructions/graphs/contributors)
|
|
11
16
|
[](https://github.com/wbern/claude-instructions/pulls)
|
|
12
|
-
[](https://github.com/wbern/claude-instructions#available-commands)
|
|
13
18
|
|
|
14
19
|
```
|
|
15
20
|
_==/ i i \==_
|
|
@@ -28,7 +33,13 @@ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
|
28
33
|
|
|
29
34
|
**TDD workflow commands for Claude Code CLI.**
|
|
30
35
|
|
|
31
|
-
|
|
36
|
+
Claude Code supports [custom slash commands](https://docs.anthropic.com/en/docs/claude-code/slash-commands)—type `/foo` and Claude receives the contents of `foo.md` as instructions (from `.claude/commands/` in your repo or `~/.claude/commands/` in your home directory). This repo provides ready-made commands for Test-Driven Development workflows.
|
|
37
|
+
|
|
38
|
+
While custom commands themselves is really just a glorified method of copy-paste, the way they can be used to bring stability to software development is what's worth trying out.
|
|
39
|
+
|
|
40
|
+
Instead of explaining TDD principles each session, type `/red` to write a failing test, `/green` to make it pass, `/refactor` to clean up. The commands guide Claude through each step methodically—you focus on what to build, Claude handles the how.
|
|
41
|
+
|
|
42
|
+
Also included are commands for commits, PRs, code reviews, and other tasks that come up during day-to-day development.
|
|
32
43
|
|
|
33
44
|
## Installation
|
|
34
45
|
|
|
@@ -63,7 +74,7 @@ Then add a postinstall script to your `package.json`:
|
|
|
63
74
|
"postinstall": "npx @wbern/claude-instructions --scope=project --overwrite"
|
|
64
75
|
},
|
|
65
76
|
"devDependencies": {
|
|
66
|
-
"@wbern/claude-instructions": "^
|
|
77
|
+
"@wbern/claude-instructions": "^2.6.0"
|
|
67
78
|
}
|
|
68
79
|
}
|
|
69
80
|
```
|
|
@@ -191,6 +202,7 @@ flowchart TB
|
|
|
191
202
|
- `/green` - Execute TDD Green Phase - write minimal implementation to pass the failing test
|
|
192
203
|
- `/refactor` - Execute TDD Refactor Phase - improve code structure while keeping tests green
|
|
193
204
|
- `/cycle` - Execute complete TDD cycle - Red, Green, and Refactor phases in sequence
|
|
205
|
+
- `/simplify` - Reduce code complexity while keeping tests green
|
|
194
206
|
- `/tdd-review` - Review test suite quality against FIRST principles and TDD anti-patterns
|
|
195
207
|
|
|
196
208
|
### Workflow
|
|
@@ -200,6 +212,7 @@ flowchart TB
|
|
|
200
212
|
- `/pr` - Creates a pull request using GitHub MCP
|
|
201
213
|
- `/summarize` - Summarize conversation progress and next steps
|
|
202
214
|
- `/gap` - Analyze conversation context for unaddressed items and gaps
|
|
215
|
+
- `/forever` - Run autonomously until stopped or stuck
|
|
203
216
|
- `/code-review` - Code review using dynamic category detection and domain-specific analysis
|
|
204
217
|
|
|
205
218
|
### Ship / Show / Ask
|
|
@@ -218,6 +231,7 @@ flowchart TB
|
|
|
218
231
|
- `/beepboop` - Communicate AI-generated content with transparent attribution
|
|
219
232
|
- `/add-command` - Guide for creating new slash commands
|
|
220
233
|
- `/kata` - Generate a TDD practice challenge with boilerplate test setup
|
|
234
|
+
- `/research` - Research a problem in parallel via web docs, web search, codebase exploration, and deep ultrathink
|
|
221
235
|
|
|
222
236
|
## Getting Started
|
|
223
237
|
|
package/package.json
CHANGED
package/src/README.md
CHANGED
|
@@ -29,7 +29,13 @@ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
|
29
29
|
|
|
30
30
|
**TDD workflow commands for Claude Code CLI.**
|
|
31
31
|
|
|
32
|
-
|
|
32
|
+
Claude Code supports [custom slash commands](https://docs.anthropic.com/en/docs/claude-code/slash-commands)—type `/foo` and Claude receives the contents of `foo.md` as instructions (from `.claude/commands/` in your repo or `~/.claude/commands/` in your home directory). This repo provides ready-made commands for Test-Driven Development workflows.
|
|
33
|
+
|
|
34
|
+
While custom commands themselves is really just a glorified method of copy-paste, the way they can be used to bring stability to software development is what's worth trying out.
|
|
35
|
+
|
|
36
|
+
Instead of explaining TDD principles each session, type `/red` to write a failing test, `/green` to make it pass, `/refactor` to clean up. The commands guide Claude through each step methodically—you focus on what to build, Claude handles the how.
|
|
37
|
+
|
|
38
|
+
Also included are commands for commits, PRs, code reviews, and other tasks that come up during day-to-day development.
|
|
33
39
|
|
|
34
40
|
## Installation
|
|
35
41
|
|
|
@@ -64,7 +70,7 @@ Then add a postinstall script to your `package.json`:
|
|
|
64
70
|
"postinstall": "npx @wbern/claude-instructions --scope=project --overwrite"
|
|
65
71
|
},
|
|
66
72
|
"devDependencies": {
|
|
67
|
-
"@wbern/claude-instructions": "
|
|
73
|
+
"@wbern/claude-instructions": "^<!-- docs VERSION --><!-- /docs -->"
|
|
68
74
|
}
|
|
69
75
|
}
|
|
70
76
|
```
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
## Code Complexity Signals
|
|
2
|
+
|
|
3
|
+
Look for these refactoring opportunities:
|
|
4
|
+
|
|
5
|
+
- [ ] Nesting > 3 levels deep
|
|
6
|
+
- [ ] Functions > 20 lines
|
|
7
|
+
- [ ] Duplicate code blocks
|
|
8
|
+
- [ ] Abstractions with single implementation
|
|
9
|
+
- [ ] "Just in case" parameters or config
|
|
10
|
+
- [ ] Magic values without names
|
|
11
|
+
- [ ] Dead/unused code
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Run autonomously until stopped or stuck
|
|
3
|
+
argument-hint: [optional: initial task or focus area]
|
|
4
|
+
_hint: Autonomous mode
|
|
5
|
+
_category: Workflow
|
|
6
|
+
_order: 20
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
<!-- docs INCLUDE path='src/fragments/universal-guidelines.md' -->
|
|
10
|
+
<!-- /docs -->
|
|
11
|
+
|
|
12
|
+
<!-- docs INCLUDE path='src/fragments/beads-awareness.md' featureFlag='beads' -->
|
|
13
|
+
<!-- /docs -->
|
|
14
|
+
|
|
15
|
+
# Forever Mode: $ARGUMENTS
|
|
16
|
+
|
|
17
|
+
Run autonomously, finding and completing work until interrupted or truly stuck.
|
|
18
|
+
|
|
19
|
+
## Operating Loop
|
|
20
|
+
|
|
21
|
+
Execute this cycle continuously:
|
|
22
|
+
|
|
23
|
+
### 1. Find Work
|
|
24
|
+
|
|
25
|
+
Check in order until something is found:
|
|
26
|
+
|
|
27
|
+
1. **Arguments above** - If provided, start there
|
|
28
|
+
2. **Conversation context** - Any unfinished discussion
|
|
29
|
+
3. **Gaps** - Incomplete implementations or missing tests
|
|
30
|
+
4. **Git status** - Uncommitted changes to address
|
|
31
|
+
5. **Think** - If nothing else, consider: What would improve this codebase?
|
|
32
|
+
|
|
33
|
+
### 2. Execute Work
|
|
34
|
+
|
|
35
|
+
- Make atomic, committable progress
|
|
36
|
+
- Leave clear trail via commits
|
|
37
|
+
|
|
38
|
+
### 3. Continue or Pivot
|
|
39
|
+
|
|
40
|
+
After completing a unit of work:
|
|
41
|
+
|
|
42
|
+
- If more related work exists - continue
|
|
43
|
+
- If blocked - note blocker, find different work
|
|
44
|
+
- If genuinely nothing to do - report status and wait
|
|
45
|
+
|
|
46
|
+
**Do not stop unless:**
|
|
47
|
+
|
|
48
|
+
- User interrupts (Escape)
|
|
49
|
+
- Genuinely no work can be identified
|
|
50
|
+
- A decision requires human judgment (ambiguous requirements, architectural choices)
|
|
51
|
+
|
|
52
|
+
## Anti-Stuck Tactics
|
|
53
|
+
|
|
54
|
+
When progress stalls:
|
|
55
|
+
|
|
56
|
+
| Situation | Action |
|
|
57
|
+
|-----------|--------|
|
|
58
|
+
| Test failures | Make the failing tests pass |
|
|
59
|
+
| Unclear requirements | Make reasonable assumption, document it, proceed |
|
|
60
|
+
| Build errors | Fix incrementally, commit fixes |
|
|
61
|
+
| Context confusion | Re-read recent commits and task tracker to reorient |
|
|
62
|
+
| Repeated failures | Try different approach, or move to different task |
|
|
63
|
+
|
|
64
|
+
## Work Discovery Heuristics
|
|
65
|
+
|
|
66
|
+
When thinking about what to do:
|
|
67
|
+
|
|
68
|
+
- Tests that could be added (coverage gaps)
|
|
69
|
+
- Code that could be simplified
|
|
70
|
+
- Documentation that's missing or stale
|
|
71
|
+
- TODOs or FIXMEs in code
|
|
72
|
+
- Dependencies that could be updated
|
|
73
|
+
- Performance improvements
|
|
74
|
+
- Refactoring opportunities
|
|
75
|
+
|
|
76
|
+
## Session Continuity
|
|
77
|
+
|
|
78
|
+
Every few completed tasks:
|
|
79
|
+
|
|
80
|
+
- Update task tracker with progress notes
|
|
81
|
+
- Commit work in progress
|
|
82
|
+
- Brief self-summary of what's been done
|
|
83
|
+
|
|
84
|
+
This ensures work survives context limits.
|
|
85
|
+
|
|
86
|
+
## Communication Style
|
|
87
|
+
|
|
88
|
+
- Work silently - don't narrate every step
|
|
89
|
+
- Report meaningful completions (commits, closed issues)
|
|
90
|
+
- Surface decisions that need human input
|
|
91
|
+
- Keep responses concise to preserve context
|
package/src/sources/refactor.md
CHANGED
|
@@ -23,6 +23,9 @@ Apply this document (specifically the Refactor phase), to the info given by user
|
|
|
23
23
|
<!-- docs INCLUDE path='src/fragments/tdd-fundamentals.md' -->
|
|
24
24
|
<!-- /docs -->
|
|
25
25
|
|
|
26
|
+
<!-- docs INCLUDE path='src/fragments/complexity-signals.md' -->
|
|
27
|
+
<!-- /docs -->
|
|
28
|
+
|
|
26
29
|
<!-- docs INCLUDE path='src/fragments/peeping-tom-warning.md' -->
|
|
27
30
|
<!-- /docs -->
|
|
28
31
|
|
|
@@ -0,0 +1,83 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Research a problem in parallel via web docs, web search, codebase exploration, and deep ultrathink
|
|
3
|
+
argument-hint: <research topic or question>
|
|
4
|
+
_hint: Deep research
|
|
5
|
+
_category: Utilities
|
|
6
|
+
_order: 20
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
<!-- docs INCLUDE path='src/fragments/universal-guidelines.md' -->
|
|
10
|
+
<!-- /docs -->
|
|
11
|
+
|
|
12
|
+
<!-- docs INCLUDE path='src/fragments/beads-awareness.md' featureFlag='beads' -->
|
|
13
|
+
<!-- /docs -->
|
|
14
|
+
|
|
15
|
+
# Research: $ARGUMENTS
|
|
16
|
+
|
|
17
|
+
Research the following problem or question thoroughly, like a senior developer would.
|
|
18
|
+
|
|
19
|
+
## Step 1: Launch Parallel Research Agents
|
|
20
|
+
|
|
21
|
+
Use the Task tool to spawn these subagents **in parallel** (all in a single message):
|
|
22
|
+
|
|
23
|
+
1. **Web Documentation Agent** (subagent_type: general-purpose)
|
|
24
|
+
- Search official documentation for the topic
|
|
25
|
+
- Find best practices and recommended patterns
|
|
26
|
+
- Locate relevant GitHub issues or discussions
|
|
27
|
+
|
|
28
|
+
2. **Web Search Agent** (subagent_type: general-purpose)
|
|
29
|
+
- Perform broad web searches for solutions and discussions
|
|
30
|
+
- Find Stack Overflow answers, blog posts, and tutorials
|
|
31
|
+
- Note common pitfalls and gotchas
|
|
32
|
+
|
|
33
|
+
3. **Codebase Explorer Agent** (subagent_type: Explore)
|
|
34
|
+
- Search the codebase for related patterns
|
|
35
|
+
- Find existing solutions to similar problems
|
|
36
|
+
- Identify relevant files, functions, or components
|
|
37
|
+
|
|
38
|
+
## Step 2: Library Documentation (Optional)
|
|
39
|
+
|
|
40
|
+
If the research involves specific frameworks or libraries:
|
|
41
|
+
- Use Context7 MCP tools (mcp__context7__resolve-library-id, then get-library-docs)
|
|
42
|
+
- Get up-to-date API references and code examples
|
|
43
|
+
- If Context7 is unavailable, note this in findings so user knows library docs were harder to obtain
|
|
44
|
+
|
|
45
|
+
## Step 3: Deep Analysis
|
|
46
|
+
|
|
47
|
+
With all gathered context, perform extended reasoning (ultrathink) to:
|
|
48
|
+
- Analyze the problem from first principles
|
|
49
|
+
- Consider edge cases and trade-offs
|
|
50
|
+
- Synthesize insights across all sources
|
|
51
|
+
- Identify conflicts between sources
|
|
52
|
+
|
|
53
|
+
## Step 4: Present Findings
|
|
54
|
+
|
|
55
|
+
Present a structured summary to the user:
|
|
56
|
+
|
|
57
|
+
### Problem Statement
|
|
58
|
+
Describe the problem and why it matters.
|
|
59
|
+
|
|
60
|
+
### Key Findings
|
|
61
|
+
Summarize the most relevant solutions and approaches.
|
|
62
|
+
|
|
63
|
+
### Codebase Patterns
|
|
64
|
+
Document how the current codebase handles similar cases.
|
|
65
|
+
|
|
66
|
+
### Recommended Approach
|
|
67
|
+
Provide your recommendation based on all research.
|
|
68
|
+
|
|
69
|
+
### Conflicts
|
|
70
|
+
Highlight where sources disagree and provide assessment of which is more reliable.
|
|
71
|
+
|
|
72
|
+
### Sources
|
|
73
|
+
List all source links with brief descriptions. This section is required.
|
|
74
|
+
|
|
75
|
+
## Research Guidelines
|
|
76
|
+
|
|
77
|
+
- Prioritize official documentation over blog posts
|
|
78
|
+
- Prefer solutions that match existing codebase patterns
|
|
79
|
+
- Note major.minor versions for libraries/frameworks (patch versions only if critical)
|
|
80
|
+
- Flag conflicting information across sources
|
|
81
|
+
- Write concise, actionable content
|
|
82
|
+
- Use active voice throughout
|
|
83
|
+
- **Do not create output files** - present findings directly in conversation unless user explicitly requests a file
|
|
@@ -0,0 +1,64 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Reduce code complexity while keeping tests green
|
|
3
|
+
argument-hint: [file, function, or area to simplify]
|
|
4
|
+
_hint: Reduce complexity
|
|
5
|
+
_category: Test-Driven Development
|
|
6
|
+
_order: 16
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
<!-- docs INCLUDE path='src/fragments/universal-guidelines.md' -->
|
|
10
|
+
<!-- /docs -->
|
|
11
|
+
|
|
12
|
+
<!-- docs INCLUDE path='src/fragments/beads-awareness.md' featureFlag='beads' -->
|
|
13
|
+
<!-- /docs -->
|
|
14
|
+
|
|
15
|
+
# Simplify: $ARGUMENTS
|
|
16
|
+
|
|
17
|
+
<!-- docs INCLUDE path='src/fragments/fallback-arguments.md' -->
|
|
18
|
+
<!-- /docs -->
|
|
19
|
+
|
|
20
|
+
Reduce complexity while keeping tests green.
|
|
21
|
+
|
|
22
|
+
## Core Principles
|
|
23
|
+
|
|
24
|
+
**YAGNI** - Don't build until actually needed. Delete "just in case" code.
|
|
25
|
+
|
|
26
|
+
**KISS** - Simplest solution that works. Clever is the enemy of clear.
|
|
27
|
+
|
|
28
|
+
**Rule of Three** - Don't abstract until 3rd occurrence. "Prefer duplication over wrong abstraction" (Sandi Metz).
|
|
29
|
+
|
|
30
|
+
## When NOT to Simplify
|
|
31
|
+
|
|
32
|
+
- Essential domain complexity (regulations, business rules)
|
|
33
|
+
- Performance-critical optimized code
|
|
34
|
+
- Concurrency/thread-safety requirements
|
|
35
|
+
- Security-sensitive explicit checks
|
|
36
|
+
|
|
37
|
+
## Prerequisites
|
|
38
|
+
|
|
39
|
+
Tests must be green. If failing, use `/green` first.
|
|
40
|
+
|
|
41
|
+
<!-- docs INCLUDE path='src/fragments/complexity-signals.md' -->
|
|
42
|
+
<!-- /docs -->
|
|
43
|
+
|
|
44
|
+
## Techniques
|
|
45
|
+
|
|
46
|
+
| Pattern | Before | After |
|
|
47
|
+
|---------|--------|-------|
|
|
48
|
+
| Guard clause | Nested `if/else` | Early `return` |
|
|
49
|
+
| Named condition | Complex boolean | `const isValid = ...` |
|
|
50
|
+
| Extract constant | `if (x > 3)` | `if (x > MAX_RETRIES)` |
|
|
51
|
+
| Flatten callback | `.then().then()` | `async/await` |
|
|
52
|
+
|
|
53
|
+
**Also apply:** Consolidate duplicates, inline unnecessary abstractions, delete dead code.
|
|
54
|
+
|
|
55
|
+
## Validate
|
|
56
|
+
|
|
57
|
+
1. Tests still green
|
|
58
|
+
2. Code reads more clearly
|
|
59
|
+
3. No behavioral changes
|
|
60
|
+
|
|
61
|
+
**Simplify** removes complexity locally. **Refactor** improves architecture broadly. Use `/refactor` if changes require structural reorganization.
|
|
62
|
+
|
|
63
|
+
<!-- docs INCLUDE path='src/fragments/peeping-tom-warning.md' -->
|
|
64
|
+
<!-- /docs -->
|