cc-dev-template 0.1.51 → 0.1.52
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/src/skills/claude-md/SKILL.md +8 -36
- package/src/skills/claude-md/references/audit.md +33 -76
- package/src/skills/claude-md/references/modify.md +52 -0
- package/src/skills/research/SKILL.md +14 -0
- package/src/skills/research/references/step-1-check-existing.md +25 -0
- package/src/skills/research/references/step-2-conduct-research.md +63 -0
- package/src/skills/spec-interview/references/step-2-deep-dive.md +1 -1
- package/src/skills/spec-interview/references/step-3-research-needs.md +44 -0
- package/src/skills/spec-interview/references/{step-3-finalize.md → step-4-finalize.md} +1 -1
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: claude-md
|
|
3
|
-
description: Manages CLAUDE.md files
|
|
3
|
+
description: Manages CLAUDE.md files in a project. Activates when the user says "audit CLAUDE.md files", "update CLAUDE.md", "add to CLAUDE.md", or invokes /claude-md. With no arguments, audits all CLAUDE.md files. With arguments, intelligently updates the appropriate file.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# CLAUDE.md Management
|
|
@@ -9,40 +9,12 @@ Base directory for this skill: ~/.claude/skills/claude-md
|
|
|
9
9
|
|
|
10
10
|
## What To Do
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
Check if arguments were provided:
|
|
13
13
|
|
|
14
|
-
|
|
|
15
|
-
|
|
16
|
-
|
|
|
17
|
-
|
|
|
18
|
-
|
|
|
14
|
+
| Condition | Action |
|
|
15
|
+
|-----------|--------|
|
|
16
|
+
| No arguments | Read `references/audit.md` |
|
|
17
|
+
| Arguments provided (add, update, modify request) | Read `references/modify.md` |
|
|
18
|
+
| Explicitly asked to create a new CLAUDE.md | Read `references/create.md` |
|
|
19
19
|
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
CLAUDE.md files are **orientation prompts**. They answer: "Where am I? What matters here? What should I know that I can't read from the code?"
|
|
23
|
-
|
|
24
|
-
The test: **Would Claude know where it is and what matters?**
|
|
25
|
-
|
|
26
|
-
## Quick Reference
|
|
27
|
-
|
|
28
|
-
**Belongs in CLAUDE.md:**
|
|
29
|
-
- Why this folder/repo exists
|
|
30
|
-
- Current focus (what matters NOW)
|
|
31
|
-
- Where to find things (progressive disclosure)
|
|
32
|
-
- Tribal knowledge, gotchas, non-obvious learnings
|
|
33
|
-
- Project conventions not obvious from code
|
|
34
|
-
|
|
35
|
-
**Does NOT belong:**
|
|
36
|
-
- Content duplicated from parent CLAUDE.md (hierarchy is automatic)
|
|
37
|
-
- Step-by-step workflows (put in docs or skills)
|
|
38
|
-
- Detailed examples (trust the model)
|
|
39
|
-
- Operational runbooks
|
|
40
|
-
- Anything over ~100 lines (suspect)
|
|
41
|
-
|
|
42
|
-
## Hierarchy Rule
|
|
43
|
-
|
|
44
|
-
Claude automatically reads CLAUDE.md files up through the directory tree. A child file inherits everything from its parents.
|
|
45
|
-
|
|
46
|
-
**Never duplicate parent content in child files.** Each file should only contain what's specific to that folder.
|
|
47
|
-
|
|
48
|
-
For full principles, read `references/principles.md`.
|
|
20
|
+
For principles reference: `references/principles.md`
|
|
@@ -1,84 +1,52 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Audit CLAUDE.md Files
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Perform a full audit of all CLAUDE.md files in this project. Fix issues automatically.
|
|
4
4
|
|
|
5
|
-
1
|
|
6
|
-
2. **Map hierarchy** - Understand parent-child relationships
|
|
7
|
-
3. **Check each file** - Against principles
|
|
8
|
-
4. **Fix issues** - Automatically apply best practices
|
|
5
|
+
## Step 1: Discover and Map
|
|
9
6
|
|
|
10
|
-
|
|
7
|
+
Find all CLAUDE.md files: `Glob("**/CLAUDE.md")`
|
|
11
8
|
|
|
12
|
-
|
|
9
|
+
Read every file found. Build a mental map of the hierarchy — which files are parents, which are children. Content flows down: children inherit from parents.
|
|
13
10
|
|
|
14
|
-
## Step 2:
|
|
11
|
+
## Step 2: Check Each File
|
|
15
12
|
|
|
16
|
-
|
|
17
|
-
- Its parent CLAUDE.md files (walking up the tree)
|
|
18
|
-
- Its child CLAUDE.md files (in subdirectories)
|
|
13
|
+
Evaluate each file against these criteria:
|
|
19
14
|
|
|
20
|
-
|
|
15
|
+
**Length**
|
|
16
|
+
- Over 100 lines → bloated, needs pruning
|
|
17
|
+
- Over 150 lines → severely bloated
|
|
21
18
|
|
|
22
|
-
|
|
19
|
+
**Content that doesn't belong**
|
|
20
|
+
- Step-by-step workflows → move to docs/ or skills/
|
|
21
|
+
- Detailed examples → remove, trust the model
|
|
22
|
+
- Credentials/passwords → move to dedicated docs
|
|
23
|
+
- Content duplicated from parent → remove entirely
|
|
23
24
|
|
|
24
|
-
|
|
25
|
+
**Structure**
|
|
26
|
+
- Missing purpose statement at top → add one-line description
|
|
27
|
+
- Walls of text → break into sections, use bullets
|
|
25
28
|
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
| Over 150 lines | Definitely bloated | Aggressive pruning needed |
|
|
29
|
+
**Hierarchy violations**
|
|
30
|
+
- Child repeats parent content → remove from child
|
|
31
|
+
- Child has general project info → move to root CLAUDE.md
|
|
32
|
+
- Deep file (3+ levels) with no unique content → consider removing
|
|
31
33
|
|
|
32
|
-
|
|
33
|
-
| Check | Issue | Fix |
|
|
34
|
-
|-------|-------|-----|
|
|
35
|
-
| Step-by-step workflows | Doesn't belong | Move to docs/ or skills/, leave pointer |
|
|
36
|
-
| Detailed examples | Over-explaining | Remove, trust the model |
|
|
37
|
-
| Credentials/passwords | Security + bloat | Move to dedicated docs |
|
|
38
|
-
| Duplicate of parent | Redundant | Remove entirely |
|
|
34
|
+
## Step 3: Fix Issues
|
|
39
35
|
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
| Missing "Current Focus" | For active projects | Add if this is active work |
|
|
45
|
-
| Walls of text | Hard to scan | Break into sections, use bullets |
|
|
36
|
+
For each issue:
|
|
37
|
+
1. Read the file
|
|
38
|
+
2. Apply the fix using Edit
|
|
39
|
+
3. Move extracted content to appropriate location if needed
|
|
46
40
|
|
|
47
|
-
|
|
48
|
-
| Check | Issue | Fix |
|
|
49
|
-
|-------|-------|-----|
|
|
50
|
-
| Child repeats parent content | Duplication | Remove from child |
|
|
51
|
-
| Child has general project info | Wrong level | Move to root CLAUDE.md |
|
|
52
|
-
| Deep file (3+ levels) exists | Probably unnecessary | Consider removing |
|
|
41
|
+
**Extracting workflows:** Create `docs/workflows/[topic].md`, replace inline content with pointer.
|
|
53
42
|
|
|
54
|
-
|
|
43
|
+
**Removing duplication:** Verify parent has content, delete from child.
|
|
55
44
|
|
|
56
|
-
|
|
45
|
+
**Pruning over-explanation:** Reduce to 1-2 lines that trust the model.
|
|
57
46
|
|
|
58
|
-
|
|
59
|
-
2. **Apply the fix** using Edit tool
|
|
60
|
-
3. **Move extracted content** to appropriate location (docs/, etc.)
|
|
61
|
-
4. **Verify** the result
|
|
47
|
+
## Step 4: Report
|
|
62
48
|
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
**Extracting a workflow:**
|
|
66
|
-
1. Create `docs/workflows/[topic].md` with the detailed content
|
|
67
|
-
2. Replace in CLAUDE.md with: "See `docs/workflows/[topic].md` for [description]"
|
|
68
|
-
|
|
69
|
-
**Removing duplication:**
|
|
70
|
-
1. Check parent file has the content
|
|
71
|
-
2. Delete the duplicated section from child
|
|
72
|
-
3. Optionally add: "Inherits [topic] from parent CLAUDE.md"
|
|
73
|
-
|
|
74
|
-
**Pruning over-explanation:**
|
|
75
|
-
1. Identify the core point
|
|
76
|
-
2. Reduce to 1-2 lines that trust the model
|
|
77
|
-
3. Remove examples, edge cases, detailed instructions
|
|
78
|
-
|
|
79
|
-
## Audit Report
|
|
80
|
-
|
|
81
|
-
After checking all files, summarize:
|
|
49
|
+
After all fixes, summarize:
|
|
82
50
|
|
|
83
51
|
```
|
|
84
52
|
CLAUDE.md Audit Summary
|
|
@@ -89,18 +57,7 @@ Issues fixed: Z
|
|
|
89
57
|
|
|
90
58
|
Changes made:
|
|
91
59
|
- [file]: [what was fixed]
|
|
92
|
-
- [file]: [what was fixed]
|
|
93
60
|
|
|
94
61
|
Remaining concerns:
|
|
95
|
-
- [any issues
|
|
62
|
+
- [any issues needing human decision]
|
|
96
63
|
```
|
|
97
|
-
|
|
98
|
-
## Red Flags
|
|
99
|
-
|
|
100
|
-
These indicate a CLAUDE.md that needs significant rework:
|
|
101
|
-
|
|
102
|
-
- **200+ lines** - Needs major pruning
|
|
103
|
-
- **Code blocks with >10 lines** - Workflows belong in docs
|
|
104
|
-
- **Tables with >5 rows** - Probably too detailed
|
|
105
|
-
- **Multiple "how to" sections** - Wrong content type
|
|
106
|
-
- **Same content in parent and child** - Hierarchy violation
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
# Modify CLAUDE.md
|
|
2
|
+
|
|
3
|
+
The user provided a request to add, update, or modify something in the project's CLAUDE.md files. Determine the appropriate file and make the change.
|
|
4
|
+
|
|
5
|
+
## Step 1: Understand the Request
|
|
6
|
+
|
|
7
|
+
Parse what the user wants:
|
|
8
|
+
- What content to add or change?
|
|
9
|
+
- Is it project-wide or specific to a folder/component?
|
|
10
|
+
- Is it a gotcha, convention, current focus, or structural info?
|
|
11
|
+
|
|
12
|
+
## Step 2: Discover Existing Files
|
|
13
|
+
|
|
14
|
+
Find all CLAUDE.md files: `Glob("**/CLAUDE.md")`
|
|
15
|
+
|
|
16
|
+
Read each file to understand:
|
|
17
|
+
- What scope each file covers
|
|
18
|
+
- The hierarchy (root → subdirectories)
|
|
19
|
+
- What content already exists
|
|
20
|
+
|
|
21
|
+
## Step 3: Determine the Right File
|
|
22
|
+
|
|
23
|
+
Match the request to the appropriate level:
|
|
24
|
+
|
|
25
|
+
| Request Type | Appropriate File |
|
|
26
|
+
|--------------|------------------|
|
|
27
|
+
| Project-wide convention | Root CLAUDE.md |
|
|
28
|
+
| Folder-specific rule | That folder's CLAUDE.md (create if needed) |
|
|
29
|
+
| Component gotcha | Nearest parent CLAUDE.md covering that area |
|
|
30
|
+
| Current focus/priority | Root CLAUDE.md (or active work area) |
|
|
31
|
+
|
|
32
|
+
**Hierarchy principle:** Place content at the highest level where it applies. Child files only contain what's specific to that folder.
|
|
33
|
+
|
|
34
|
+
If unsure which file is appropriate, ask the user.
|
|
35
|
+
|
|
36
|
+
## Step 4: Make the Change
|
|
37
|
+
|
|
38
|
+
Read the target file, then edit:
|
|
39
|
+
|
|
40
|
+
- Add gotchas to a "Gotchas" section (create if missing)
|
|
41
|
+
- Add conventions to relevant existing sections
|
|
42
|
+
- Add current focus to "Current Focus" section
|
|
43
|
+
- Keep additions concise — 1-2 lines, trust the model
|
|
44
|
+
|
|
45
|
+
If the content would make the file exceed ~100 lines, consider:
|
|
46
|
+
- Is this the right level? Maybe it belongs deeper.
|
|
47
|
+
- Can existing content be pruned?
|
|
48
|
+
- Should a workflow be extracted to docs/?
|
|
49
|
+
|
|
50
|
+
## Step 5: Confirm
|
|
51
|
+
|
|
52
|
+
Tell the user what was added and where. If creating a new CLAUDE.md file, explain why that location was chosen.
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: research
|
|
3
|
+
description: Deep research on unfamiliar paradigms, libraries, or patterns before implementation. Activates when the user says "research X", "how should we implement X", "best practices for X", or when spec-interview identifies research needs. Outputs to docs/research/ with YAML frontmatter.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Research
|
|
7
|
+
|
|
8
|
+
Conduct deep research on a topic to inform implementation decisions.
|
|
9
|
+
|
|
10
|
+
## What To Do Now
|
|
11
|
+
|
|
12
|
+
Identify the research topic from the user's request or the invoking skill's context.
|
|
13
|
+
|
|
14
|
+
Read `references/step-1-check-existing.md` to check for existing research before conducting new research.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# Step 1: Check Existing Research
|
|
2
|
+
|
|
3
|
+
Before researching, check if this topic was already researched.
|
|
4
|
+
|
|
5
|
+
## Search for Existing Research
|
|
6
|
+
|
|
7
|
+
Look in `docs/research/` for existing research documents.
|
|
8
|
+
|
|
9
|
+
Search approach:
|
|
10
|
+
1. Glob for `docs/research/*.md`
|
|
11
|
+
2. If files exist, read them and check YAML frontmatter for matching topics
|
|
12
|
+
3. Consider semantic matches, not just exact names (e.g., "Convex real-time" matches "Convex subscriptions")
|
|
13
|
+
|
|
14
|
+
## If Match Found
|
|
15
|
+
|
|
16
|
+
Return the existing research to the caller:
|
|
17
|
+
- State that research already exists
|
|
18
|
+
- Provide the file path
|
|
19
|
+
- Summarize the key findings from that document
|
|
20
|
+
|
|
21
|
+
Do not re-research unless the user explicitly requests updated information.
|
|
22
|
+
|
|
23
|
+
## If No Match
|
|
24
|
+
|
|
25
|
+
Proceed to `references/step-2-conduct-research.md` to conduct new research.
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
# Step 2: Conduct Research
|
|
2
|
+
|
|
3
|
+
Research the topic thoroughly and produce a reference document.
|
|
4
|
+
|
|
5
|
+
## Research Strategy
|
|
6
|
+
|
|
7
|
+
Think about everything needed to implement this correctly:
|
|
8
|
+
- Core concepts and mental models
|
|
9
|
+
- Best practices and common pitfalls
|
|
10
|
+
- Integration patterns with existing tools/frameworks
|
|
11
|
+
- Error handling approaches
|
|
12
|
+
- Performance considerations if relevant
|
|
13
|
+
|
|
14
|
+
Spawn multiple subagents in parallel to research from different angles. Each subagent focuses on one aspect. Use whatever web search tools are available.
|
|
15
|
+
|
|
16
|
+
Synthesize findings into a coherent understanding. Resolve contradictions. Prioritize recent, authoritative sources.
|
|
17
|
+
|
|
18
|
+
## Output Document
|
|
19
|
+
|
|
20
|
+
Create `docs/research/<topic-slug>.md` (kebab-case, concise name).
|
|
21
|
+
|
|
22
|
+
Structure:
|
|
23
|
+
|
|
24
|
+
```markdown
|
|
25
|
+
---
|
|
26
|
+
name: <Topic Name>
|
|
27
|
+
description: <One-line description of what was researched>
|
|
28
|
+
date: <YYYY-MM-DD>
|
|
29
|
+
---
|
|
30
|
+
|
|
31
|
+
# <Topic Name>
|
|
32
|
+
|
|
33
|
+
## Overview
|
|
34
|
+
|
|
35
|
+
[2-3 sentences: what this is and why it matters for our implementation]
|
|
36
|
+
|
|
37
|
+
## Key Concepts
|
|
38
|
+
|
|
39
|
+
[Core mental models needed to work with this correctly]
|
|
40
|
+
|
|
41
|
+
## Best Practices
|
|
42
|
+
|
|
43
|
+
[What to do - actionable guidance]
|
|
44
|
+
|
|
45
|
+
## Pitfalls to Avoid
|
|
46
|
+
|
|
47
|
+
[Common mistakes and how to prevent them]
|
|
48
|
+
|
|
49
|
+
## Integration Notes
|
|
50
|
+
|
|
51
|
+
[How this fits with our stack, if relevant]
|
|
52
|
+
|
|
53
|
+
## Sources
|
|
54
|
+
|
|
55
|
+
[Key sources consulted]
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
## Complete
|
|
59
|
+
|
|
60
|
+
After writing the document:
|
|
61
|
+
1. Confirm the research is complete
|
|
62
|
+
2. Summarize the key takeaways
|
|
63
|
+
3. Return to the invoking context (spec-interview or user)
|
|
@@ -74,4 +74,4 @@ Write to `docs/specs/<name>/spec.md` with this structure:
|
|
|
74
74
|
|
|
75
75
|
## When to Move On
|
|
76
76
|
|
|
77
|
-
Move to `references/step-3-
|
|
77
|
+
Move to `references/step-3-research-needs.md` when all areas have been covered and the spec document is substantially complete.
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
# Step 3: Identify Research Needs
|
|
2
|
+
|
|
3
|
+
Before finalizing, determine if implementation requires unfamiliar paradigms.
|
|
4
|
+
|
|
5
|
+
## The Question
|
|
6
|
+
|
|
7
|
+
For each major component in the spec, ask: **Does working code using this exact pattern already exist in this codebase?**
|
|
8
|
+
|
|
9
|
+
This is not about whether Claude knows how to do something in general. It's about whether this specific project has proven, working examples of the same approach.
|
|
10
|
+
|
|
11
|
+
## Evaluate Each Component
|
|
12
|
+
|
|
13
|
+
Review the spec's integration points, data model, and behavior sections.
|
|
14
|
+
|
|
15
|
+
For each significant implementation element:
|
|
16
|
+
1. Search the codebase for existing examples of this pattern
|
|
17
|
+
2. If found → this paradigm is established, no research needed
|
|
18
|
+
3. If not found → this is a new paradigm requiring research
|
|
19
|
+
|
|
20
|
+
Examples of "new paradigm" triggers:
|
|
21
|
+
- Using a library not yet in the project
|
|
22
|
+
- A UI pattern not implemented elsewhere in the app
|
|
23
|
+
- An integration with an external service not previously connected
|
|
24
|
+
- A data structure or flow unlike existing code
|
|
25
|
+
|
|
26
|
+
## If Research Needed
|
|
27
|
+
|
|
28
|
+
For each new paradigm identified:
|
|
29
|
+
1. State what needs research and why (no existing example found)
|
|
30
|
+
2. Ask the user if they want to proceed with research, or if they have existing knowledge to share
|
|
31
|
+
3. If proceeding, invoke the `research` skill for that topic
|
|
32
|
+
|
|
33
|
+
Wait for research to complete before continuing. The research output goes to `docs/research/` and informs implementation.
|
|
34
|
+
|
|
35
|
+
## If No Research Needed
|
|
36
|
+
|
|
37
|
+
State that all paradigms have existing examples in the codebase. Proceed to `references/step-4-finalize.md`.
|
|
38
|
+
|
|
39
|
+
## When to Move On
|
|
40
|
+
|
|
41
|
+
Proceed to `references/step-4-finalize.md` when:
|
|
42
|
+
- All new paradigms have been researched, OR
|
|
43
|
+
- User confirmed no research is needed, OR
|
|
44
|
+
- All patterns have existing codebase examples
|