@cloudstreamsoftware/claude-tools 1.2.3 → 1.2.5
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/bin/cloudstream-setup.js +21 -10
- package/commands/INDEX.md +171 -0
- package/commands/build-fix.md +44 -0
- package/commands/checkpoint.md +80 -0
- package/commands/client-switch.md +114 -0
- package/commands/code-review.md +45 -0
- package/commands/compliance-check.md +38 -0
- package/commands/create-branch.md +91 -0
- package/commands/deluge.md +72 -0
- package/commands/diagnose.md +99 -0
- package/commands/e2e.md +34 -0
- package/commands/eval.md +189 -0
- package/commands/evolve.md +170 -0
- package/commands/handoff.md +64 -0
- package/commands/health-check.md +88 -0
- package/commands/instinct-export.md +123 -0
- package/commands/instinct-import.md +150 -0
- package/commands/instinct-status.md +111 -0
- package/commands/learn.md +75 -0
- package/commands/onboard.md +133 -0
- package/commands/orchestrate.md +177 -0
- package/commands/plan.md +34 -0
- package/commands/pr-ready.md +130 -0
- package/commands/quarterly-review.md +154 -0
- package/commands/refactor-clean.md +54 -0
- package/commands/setup-pm.md +81 -0
- package/commands/skill-create.md +99 -0
- package/commands/skill-submit.md +121 -0
- package/commands/skill-sync.md +250 -0
- package/commands/tdd.md +59 -0
- package/commands/team-admin.md +179 -0
- package/commands/test-coverage.md +43 -0
- package/commands/tutorial.md +100 -0
- package/commands/update-codemaps.md +57 -0
- package/commands/update-docs.md +51 -0
- package/commands/verify-setup.md +98 -0
- package/commands/verify.md +75 -0
- package/commands/zoho-scaffold.md +159 -0
- package/package.json +2 -1
|
@@ -0,0 +1,177 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: orchestrate
|
|
3
|
+
description: Sequential agent workflow for complex multi-step tasks. Chains agents (planner → architect → tdd-guide → code-reviewer) in optimal order.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Orchestrate Command
|
|
7
|
+
|
|
8
|
+
Sequential agent workflow for complex tasks.
|
|
9
|
+
|
|
10
|
+
## Usage
|
|
11
|
+
|
|
12
|
+
`/orchestrate [workflow-type] [task-description]`
|
|
13
|
+
|
|
14
|
+
## Workflow Types
|
|
15
|
+
|
|
16
|
+
### feature
|
|
17
|
+
Full feature implementation workflow:
|
|
18
|
+
```
|
|
19
|
+
planner -> tdd-guide -> code-reviewer -> security-reviewer
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
### bugfix
|
|
23
|
+
Bug investigation and fix workflow:
|
|
24
|
+
```
|
|
25
|
+
architect -> tdd-guide -> code-reviewer
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
### refactor
|
|
29
|
+
Safe refactoring workflow:
|
|
30
|
+
```
|
|
31
|
+
architect -> code-reviewer -> tdd-guide
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
### security
|
|
35
|
+
Security-focused review:
|
|
36
|
+
```
|
|
37
|
+
security-reviewer -> code-reviewer -> architect
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
## Execution Pattern
|
|
41
|
+
|
|
42
|
+
For each agent in the workflow:
|
|
43
|
+
|
|
44
|
+
1. **Invoke agent** with context from previous agent
|
|
45
|
+
2. **Collect output** as structured handoff document
|
|
46
|
+
3. **Pass to next agent** in chain
|
|
47
|
+
4. **Aggregate results** into final report
|
|
48
|
+
|
|
49
|
+
## Handoff Document Format
|
|
50
|
+
|
|
51
|
+
Between agents, create handoff document:
|
|
52
|
+
|
|
53
|
+
```markdown
|
|
54
|
+
## HANDOFF: [previous-agent] -> [next-agent]
|
|
55
|
+
|
|
56
|
+
### Context
|
|
57
|
+
[Summary of what was done]
|
|
58
|
+
|
|
59
|
+
### Findings
|
|
60
|
+
[Key discoveries or decisions]
|
|
61
|
+
|
|
62
|
+
### Files Modified
|
|
63
|
+
[List of files touched]
|
|
64
|
+
|
|
65
|
+
### Open Questions
|
|
66
|
+
[Unresolved items for next agent]
|
|
67
|
+
|
|
68
|
+
### Recommendations
|
|
69
|
+
[Suggested next steps]
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
## Example: Feature Workflow
|
|
73
|
+
|
|
74
|
+
```
|
|
75
|
+
/orchestrate feature "Add user authentication"
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
Executes:
|
|
79
|
+
|
|
80
|
+
1. **Planner Agent**
|
|
81
|
+
- Analyzes requirements
|
|
82
|
+
- Creates implementation plan
|
|
83
|
+
- Identifies dependencies
|
|
84
|
+
- Output: `HANDOFF: planner -> tdd-guide`
|
|
85
|
+
|
|
86
|
+
2. **TDD Guide Agent**
|
|
87
|
+
- Reads planner handoff
|
|
88
|
+
- Writes tests first
|
|
89
|
+
- Implements to pass tests
|
|
90
|
+
- Output: `HANDOFF: tdd-guide -> code-reviewer`
|
|
91
|
+
|
|
92
|
+
3. **Code Reviewer Agent**
|
|
93
|
+
- Reviews implementation
|
|
94
|
+
- Checks for issues
|
|
95
|
+
- Suggests improvements
|
|
96
|
+
- Output: `HANDOFF: code-reviewer -> security-reviewer`
|
|
97
|
+
|
|
98
|
+
4. **Security Reviewer Agent**
|
|
99
|
+
- Security audit
|
|
100
|
+
- Vulnerability check
|
|
101
|
+
- Final approval
|
|
102
|
+
- Output: Final Report
|
|
103
|
+
|
|
104
|
+
## Final Report Format
|
|
105
|
+
|
|
106
|
+
```
|
|
107
|
+
ORCHESTRATION REPORT
|
|
108
|
+
====================
|
|
109
|
+
Workflow: feature
|
|
110
|
+
Task: Add user authentication
|
|
111
|
+
Agents: planner -> tdd-guide -> code-reviewer -> security-reviewer
|
|
112
|
+
|
|
113
|
+
SUMMARY
|
|
114
|
+
-------
|
|
115
|
+
[One paragraph summary]
|
|
116
|
+
|
|
117
|
+
AGENT OUTPUTS
|
|
118
|
+
-------------
|
|
119
|
+
Planner: [summary]
|
|
120
|
+
TDD Guide: [summary]
|
|
121
|
+
Code Reviewer: [summary]
|
|
122
|
+
Security Reviewer: [summary]
|
|
123
|
+
|
|
124
|
+
FILES CHANGED
|
|
125
|
+
-------------
|
|
126
|
+
[List all files modified]
|
|
127
|
+
|
|
128
|
+
TEST RESULTS
|
|
129
|
+
------------
|
|
130
|
+
[Test pass/fail summary]
|
|
131
|
+
|
|
132
|
+
SECURITY STATUS
|
|
133
|
+
---------------
|
|
134
|
+
[Security findings]
|
|
135
|
+
|
|
136
|
+
RECOMMENDATION
|
|
137
|
+
--------------
|
|
138
|
+
[SHIP / NEEDS WORK / BLOCKED]
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
## Parallel Execution
|
|
142
|
+
|
|
143
|
+
For independent checks, run agents in parallel:
|
|
144
|
+
|
|
145
|
+
```markdown
|
|
146
|
+
### Parallel Phase
|
|
147
|
+
Run simultaneously:
|
|
148
|
+
- code-reviewer (quality)
|
|
149
|
+
- security-reviewer (security)
|
|
150
|
+
- architect (design)
|
|
151
|
+
|
|
152
|
+
### Merge Results
|
|
153
|
+
Combine outputs into single report
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
## Arguments
|
|
157
|
+
|
|
158
|
+
$ARGUMENTS:
|
|
159
|
+
- `feature <description>` - Full feature workflow
|
|
160
|
+
- `bugfix <description>` - Bug fix workflow
|
|
161
|
+
- `refactor <description>` - Refactoring workflow
|
|
162
|
+
- `security <description>` - Security review workflow
|
|
163
|
+
- `custom <agents> <description>` - Custom agent sequence
|
|
164
|
+
|
|
165
|
+
## Custom Workflow Example
|
|
166
|
+
|
|
167
|
+
```
|
|
168
|
+
/orchestrate custom "architect,tdd-guide,code-reviewer" "Redesign caching layer"
|
|
169
|
+
```
|
|
170
|
+
|
|
171
|
+
## Tips
|
|
172
|
+
|
|
173
|
+
1. **Start with planner** for complex features
|
|
174
|
+
2. **Always include code-reviewer** before merge
|
|
175
|
+
3. **Use security-reviewer** for auth/payment/PII
|
|
176
|
+
4. **Keep handoffs concise** - focus on what next agent needs
|
|
177
|
+
5. **Run verification** between agents if needed
|
package/commands/plan.md
ADDED
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: plan
|
|
3
|
+
description: Restate requirements, assess risks, and create step-by-step implementation plan. WAIT for user CONFIRM before touching any code.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /plan [feature-description]
|
|
7
|
+
|
|
8
|
+
Invoke the **planner** agent to create a comprehensive implementation plan before writing any code.
|
|
9
|
+
|
|
10
|
+
## Parameters
|
|
11
|
+
- `feature-description` — What needs to be built or changed
|
|
12
|
+
|
|
13
|
+
## Workflow
|
|
14
|
+
1. Agent restates requirements in clear terms
|
|
15
|
+
2. Breaks down into phased steps with dependencies
|
|
16
|
+
3. Identifies risks and blockers
|
|
17
|
+
4. Assesses complexity (High/Medium/Low)
|
|
18
|
+
5. **WAITS for explicit user confirmation** before proceeding
|
|
19
|
+
|
|
20
|
+
## When to Use
|
|
21
|
+
- Starting a new feature
|
|
22
|
+
- Significant architectural changes
|
|
23
|
+
- Complex refactoring (multiple files/components)
|
|
24
|
+
- Unclear or ambiguous requirements
|
|
25
|
+
|
|
26
|
+
## User Responses After Plan
|
|
27
|
+
- `"yes"` / `"proceed"` — Execute the plan
|
|
28
|
+
- `"modify: [changes]"` — Adjust approach
|
|
29
|
+
- `"skip phase X"` — Reorder execution
|
|
30
|
+
|
|
31
|
+
## Integration
|
|
32
|
+
- After plan approval: `/tdd` to implement
|
|
33
|
+
- After implementation: `/code-review` to validate
|
|
34
|
+
- Final check: `/verify` to confirm everything passes
|
|
@@ -0,0 +1,130 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pr-ready
|
|
3
|
+
description: Run pre-PR checklist to verify readiness. Validates branch name, runs tests, checks for secrets, and verifies code quality.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /pr-ready
|
|
7
|
+
|
|
8
|
+
Run comprehensive pre-PR validation to ensure readiness for code review.
|
|
9
|
+
|
|
10
|
+
## Checks Performed
|
|
11
|
+
|
|
12
|
+
1. **Branch Validation**
|
|
13
|
+
- Validates branch name follows conventions
|
|
14
|
+
- Uses `scripts/branch-name-validator.js`
|
|
15
|
+
|
|
16
|
+
2. **Verification Suite**
|
|
17
|
+
- Runs `/verify` (lint, test, validate)
|
|
18
|
+
- Checks for build errors
|
|
19
|
+
- Verifies test coverage
|
|
20
|
+
|
|
21
|
+
3. **Code Review**
|
|
22
|
+
- Runs `/code-review` on changed files
|
|
23
|
+
- Flags CRITICAL and HIGH issues
|
|
24
|
+
- Reports MEDIUM issues
|
|
25
|
+
|
|
26
|
+
4. **Git Status**
|
|
27
|
+
- Verifies branch is up-to-date with main
|
|
28
|
+
- Checks for uncommitted changes
|
|
29
|
+
- Validates commit message format
|
|
30
|
+
|
|
31
|
+
5. **Security Scan**
|
|
32
|
+
- Checks for console.log statements
|
|
33
|
+
- Scans for hardcoded credentials
|
|
34
|
+
- Detects secrets in code
|
|
35
|
+
|
|
36
|
+
## Output Format
|
|
37
|
+
|
|
38
|
+
```
|
|
39
|
+
PR READINESS: [READY/NOT READY]
|
|
40
|
+
|
|
41
|
+
Branch: [VALID/INVALID] branch-name
|
|
42
|
+
Verify: [PASS/FAIL]
|
|
43
|
+
Code Review: [PASS/X issues]
|
|
44
|
+
Up-to-date: [YES/NO]
|
|
45
|
+
Commits: [X valid]
|
|
46
|
+
Secrets: [OK/X found]
|
|
47
|
+
Logs: [OK/X console.logs]
|
|
48
|
+
|
|
49
|
+
Blockers: (if any)
|
|
50
|
+
- [list of issues to fix]
|
|
51
|
+
|
|
52
|
+
Ready for PR: [YES/NO]
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
## Example Usage
|
|
56
|
+
|
|
57
|
+
```bash
|
|
58
|
+
# Run full PR readiness check
|
|
59
|
+
/pr-ready
|
|
60
|
+
|
|
61
|
+
# After fixing issues, run again
|
|
62
|
+
/pr-ready
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
## Blocker Resolution
|
|
66
|
+
|
|
67
|
+
### Branch Name Invalid
|
|
68
|
+
```bash
|
|
69
|
+
# Rename branch to follow conventions
|
|
70
|
+
git branch -m feature/CSS/correct-name
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
### Tests Failing
|
|
74
|
+
```bash
|
|
75
|
+
# Run tests and fix failures
|
|
76
|
+
npm test
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
### Code Review Issues
|
|
80
|
+
```bash
|
|
81
|
+
# Address CRITICAL and HIGH issues
|
|
82
|
+
# MEDIUM issues are optional but recommended
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
### Not Up-to-date
|
|
86
|
+
```bash
|
|
87
|
+
# Sync with main
|
|
88
|
+
git fetch origin main
|
|
89
|
+
git rebase origin/main
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
### Secrets Found
|
|
93
|
+
```bash
|
|
94
|
+
# Remove secrets from code
|
|
95
|
+
# Use environment variables instead
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
### Console.logs Found
|
|
99
|
+
```bash
|
|
100
|
+
# Remove debugging statements
|
|
101
|
+
# Use proper logging if needed
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
## Integration
|
|
105
|
+
|
|
106
|
+
- Use after `/verify` passes locally
|
|
107
|
+
- Run before `gh pr create`
|
|
108
|
+
- Pairs with `.github/workflows/pr-quality-gate.yml`
|
|
109
|
+
|
|
110
|
+
## When to Use
|
|
111
|
+
|
|
112
|
+
- Before creating any Pull Request
|
|
113
|
+
- After making significant changes to a PR
|
|
114
|
+
- When CI fails and you need to debug locally
|
|
115
|
+
- Before requesting code review
|
|
116
|
+
|
|
117
|
+
## Workflow
|
|
118
|
+
|
|
119
|
+
1. Complete feature development
|
|
120
|
+
2. Run `/verify` to validate locally
|
|
121
|
+
3. Run `/pr-ready` for comprehensive check
|
|
122
|
+
4. Fix any blockers
|
|
123
|
+
5. Create PR with `gh pr create`
|
|
124
|
+
|
|
125
|
+
## Related Commands
|
|
126
|
+
|
|
127
|
+
- `/verify` - Quick validation (build, lint, test)
|
|
128
|
+
- `/code-review` - Deep code review
|
|
129
|
+
- `/create-branch` - Create properly-named branch
|
|
130
|
+
- `/health-check` - System health verification
|
|
@@ -0,0 +1,154 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: quarterly-review
|
|
3
|
+
description: Conduct quarterly skill and agent review process
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Quarterly Review Command
|
|
7
|
+
|
|
8
|
+
Guided quarterly review process for evaluating skill effectiveness, identifying deprecation candidates, and managing skill lifecycle.
|
|
9
|
+
|
|
10
|
+
## Trigger
|
|
11
|
+
|
|
12
|
+
Use this command when:
|
|
13
|
+
- Starting a quarterly review cycle (every 12 weeks)
|
|
14
|
+
- Evaluating skill/agent effectiveness
|
|
15
|
+
- Identifying skills to deprecate or promote
|
|
16
|
+
- Generating quarterly reports
|
|
17
|
+
|
|
18
|
+
## Subcommands
|
|
19
|
+
|
|
20
|
+
### `/quarterly-review` or `/quarterly-review generate`
|
|
21
|
+
Generate the quarterly report with full analysis.
|
|
22
|
+
|
|
23
|
+
### `/quarterly-review status`
|
|
24
|
+
Show current quarter status summary only.
|
|
25
|
+
|
|
26
|
+
### `/quarterly-review deprecate <skill-name>`
|
|
27
|
+
Deprecate a specific skill with guided workflow.
|
|
28
|
+
|
|
29
|
+
## Instructions
|
|
30
|
+
|
|
31
|
+
### Generate Quarterly Report
|
|
32
|
+
|
|
33
|
+
1. Run the quarterly report generator:
|
|
34
|
+
```bash
|
|
35
|
+
npm run quarterly:report
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
2. Review the generated report at `~/.claude/knowledge/reports/quarterly-Q[X]-[YEAR].md`
|
|
39
|
+
|
|
40
|
+
3. Present key findings to user:
|
|
41
|
+
- Executive summary with metrics
|
|
42
|
+
- Deprecation candidates with justification
|
|
43
|
+
- Promotion candidates with impact
|
|
44
|
+
|
|
45
|
+
4. Ask user which recommendations to act upon
|
|
46
|
+
|
|
47
|
+
### Deprecation Workflow
|
|
48
|
+
|
|
49
|
+
When user approves a deprecation:
|
|
50
|
+
|
|
51
|
+
1. Run deprecation script:
|
|
52
|
+
```bash
|
|
53
|
+
npm run skill:deprecate <skill-name> --superseded-by <replacement> --removal-target 2.0.0
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
2. Review generated migration guide at `skills/<skill-name>/MIGRATION.md`
|
|
57
|
+
|
|
58
|
+
3. Verify CHANGELOG.md was updated
|
|
59
|
+
|
|
60
|
+
4. Show deprecation checklist to user
|
|
61
|
+
|
|
62
|
+
### Status Check
|
|
63
|
+
|
|
64
|
+
1. Run status command:
|
|
65
|
+
```bash
|
|
66
|
+
npm run quarterly:report --status
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
2. Present summary:
|
|
70
|
+
- Skills analyzed
|
|
71
|
+
- Average effectiveness
|
|
72
|
+
- Action items needed
|
|
73
|
+
|
|
74
|
+
## Output Format
|
|
75
|
+
|
|
76
|
+
```
|
|
77
|
+
╔════════════════════════════════════════════════════════════╗
|
|
78
|
+
║ QUARTERLY REVIEW: Q[X] [YEAR] ║
|
|
79
|
+
╚════════════════════════════════════════════════════════════╝
|
|
80
|
+
|
|
81
|
+
EXECUTIVE SUMMARY
|
|
82
|
+
────────────────────────────────────────
|
|
83
|
+
Total Skills/Agents: XX
|
|
84
|
+
Average Effectiveness: XX%
|
|
85
|
+
Improving: X
|
|
86
|
+
Declining: X
|
|
87
|
+
Stable: X
|
|
88
|
+
|
|
89
|
+
DEPRECATION CANDIDATES
|
|
90
|
+
────────────────────────────────────────
|
|
91
|
+
[!] skill-name
|
|
92
|
+
Effectiveness 35% after 15 uses
|
|
93
|
+
Suggested action: Deprecate, supersede with new-skill
|
|
94
|
+
|
|
95
|
+
[*] another-skill
|
|
96
|
+
Not used in 120 days
|
|
97
|
+
Suggested action: Review usage, consider deprecation
|
|
98
|
+
|
|
99
|
+
PROMOTION CANDIDATES
|
|
100
|
+
────────────────────────────────────────
|
|
101
|
+
[+] learned-pattern
|
|
102
|
+
95% effectiveness, 25 uses
|
|
103
|
+
Suggested action: Promote to bundled skill
|
|
104
|
+
|
|
105
|
+
ACTIONS
|
|
106
|
+
────────────────────────────────────────
|
|
107
|
+
Which recommendations would you like to act upon?
|
|
108
|
+
1. Deprecate skill-name
|
|
109
|
+
2. Deprecate another-skill
|
|
110
|
+
3. Promote learned-pattern
|
|
111
|
+
4. Skip all / Review later
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
## Critical Issues
|
|
115
|
+
|
|
116
|
+
### Deprecation Rules
|
|
117
|
+
- Always provide replacement skill when possible
|
|
118
|
+
- Set removal target at least one major version ahead
|
|
119
|
+
- Generate migration guide before deprecating
|
|
120
|
+
- Update CHANGELOG.md with deprecation entry
|
|
121
|
+
- Notify team of upcoming deprecations
|
|
122
|
+
|
|
123
|
+
### Quality Gates
|
|
124
|
+
Before completing quarterly review:
|
|
125
|
+
- [ ] All deprecation candidates reviewed
|
|
126
|
+
- [ ] Migration guides created and reviewed
|
|
127
|
+
- [ ] CHANGELOG updated
|
|
128
|
+
- [ ] Team notified
|
|
129
|
+
- [ ] Version numbers incremented correctly
|
|
130
|
+
|
|
131
|
+
## Related Commands
|
|
132
|
+
|
|
133
|
+
- `/health-check` - System health verification
|
|
134
|
+
- `/instinct-status` - View learned instincts with confidence
|
|
135
|
+
- `/learn` - Capture new patterns
|
|
136
|
+
|
|
137
|
+
## Related Scripts
|
|
138
|
+
|
|
139
|
+
```bash
|
|
140
|
+
npm run quarterly:report # Generate full report
|
|
141
|
+
npm run quarterly:report --status # Quick status
|
|
142
|
+
npm run quarterly:report --json # JSON output
|
|
143
|
+
npm run quarterly:report --verbose # Detailed analysis
|
|
144
|
+
npm run skill:deprecate <skill> # Deprecate a skill
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
## Documentation
|
|
148
|
+
|
|
149
|
+
See `docs/quarterly-review-process.md` for complete process documentation including:
|
|
150
|
+
- 4-week review cycle details
|
|
151
|
+
- Deprecation criteria matrix
|
|
152
|
+
- Promotion criteria
|
|
153
|
+
- Stakeholder responsibilities
|
|
154
|
+
- Quality gates checklist
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: refactor-clean
|
|
3
|
+
description: Safely identify and remove dead code with test verification. Runs analysis tools (knip, depcheck, ts-prune) and removes unused code.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Refactor Clean
|
|
7
|
+
|
|
8
|
+
Safely identify and remove dead code with test verification:
|
|
9
|
+
|
|
10
|
+
1. Run dead code analysis tools:
|
|
11
|
+
- knip: Find unused exports and files
|
|
12
|
+
- depcheck: Find unused dependencies
|
|
13
|
+
- ts-prune: Find unused TypeScript exports
|
|
14
|
+
|
|
15
|
+
2. Generate comprehensive report in .reports/dead-code-analysis.md
|
|
16
|
+
|
|
17
|
+
3. Categorize findings by severity:
|
|
18
|
+
- SAFE: Test files, unused utilities
|
|
19
|
+
- CAUTION: API routes, components
|
|
20
|
+
- DANGER: Config files, main entry points
|
|
21
|
+
|
|
22
|
+
4. Propose safe deletions only
|
|
23
|
+
|
|
24
|
+
5. Before each deletion:
|
|
25
|
+
- Run full test suite
|
|
26
|
+
- Verify tests pass
|
|
27
|
+
- Apply change
|
|
28
|
+
- Re-run tests
|
|
29
|
+
- Rollback if tests fail
|
|
30
|
+
|
|
31
|
+
6. Show summary of cleaned items
|
|
32
|
+
|
|
33
|
+
Never delete code without running tests first!
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
## Tools Used
|
|
38
|
+
|
|
39
|
+
| Tool | Purpose |
|
|
40
|
+
|------|---------|
|
|
41
|
+
| [knip](https://github.com/webpro/knip) | Find unused exports, files, dependencies |
|
|
42
|
+
| [depcheck](https://github.com/depcheck/depcheck) | Find unused npm dependencies |
|
|
43
|
+
| [ts-prune](https://github.com/nadeesha/ts-prune) | Find unused TypeScript exports |
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
## Related
|
|
48
|
+
|
|
49
|
+
- **Agent:** [refactor-cleaner](../agents/refactor-cleaner.md) - The specialized agent that executes this command
|
|
50
|
+
- **Commands:**
|
|
51
|
+
- [/verify](./verify.md) - Validate codebase after cleanup
|
|
52
|
+
- [/code-review](./code-review.md) - Review changes before committing
|
|
53
|
+
- [/test-coverage](./test-coverage.md) - Ensure tests cover remaining code
|
|
54
|
+
- **Skills:** [coding-standards](../skills/coding-standards/SKILL.md) - Best practices for maintainable code
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: setup-pm
|
|
3
|
+
description: Configure your preferred package manager (npm/pnpm/yarn/bun)
|
|
4
|
+
disable-model-invocation: true
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Package Manager Setup
|
|
8
|
+
|
|
9
|
+
Configure your preferred package manager for this project or globally.
|
|
10
|
+
|
|
11
|
+
## Usage
|
|
12
|
+
|
|
13
|
+
```bash
|
|
14
|
+
# Detect current package manager
|
|
15
|
+
node scripts/setup-package-manager.js --detect
|
|
16
|
+
|
|
17
|
+
# Set global preference
|
|
18
|
+
node scripts/setup-package-manager.js --global pnpm
|
|
19
|
+
|
|
20
|
+
# Set project preference
|
|
21
|
+
node scripts/setup-package-manager.js --project bun
|
|
22
|
+
|
|
23
|
+
# List available package managers
|
|
24
|
+
node scripts/setup-package-manager.js --list
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
## Detection Priority
|
|
28
|
+
|
|
29
|
+
When determining which package manager to use, the following order is checked:
|
|
30
|
+
|
|
31
|
+
1. **Environment variable**: `CLAUDE_PACKAGE_MANAGER`
|
|
32
|
+
2. **Project config**: `.claude/package-manager.json`
|
|
33
|
+
3. **package.json**: `packageManager` field
|
|
34
|
+
4. **Lock file**: Presence of package-lock.json, yarn.lock, pnpm-lock.yaml, or bun.lockb
|
|
35
|
+
5. **Global config**: `~/.claude/package-manager.json`
|
|
36
|
+
6. **Fallback**: First available package manager (pnpm > bun > yarn > npm)
|
|
37
|
+
|
|
38
|
+
## Configuration Files
|
|
39
|
+
|
|
40
|
+
### Global Configuration
|
|
41
|
+
```json
|
|
42
|
+
// ~/.claude/package-manager.json
|
|
43
|
+
{
|
|
44
|
+
"packageManager": "pnpm"
|
|
45
|
+
}
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
### Project Configuration
|
|
49
|
+
```json
|
|
50
|
+
// .claude/package-manager.json
|
|
51
|
+
{
|
|
52
|
+
"packageManager": "bun"
|
|
53
|
+
}
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
### package.json
|
|
57
|
+
```json
|
|
58
|
+
{
|
|
59
|
+
"packageManager": "pnpm@8.6.0"
|
|
60
|
+
}
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
## Environment Variable
|
|
64
|
+
|
|
65
|
+
Set `CLAUDE_PACKAGE_MANAGER` to override all other detection methods:
|
|
66
|
+
|
|
67
|
+
```bash
|
|
68
|
+
# Windows (PowerShell)
|
|
69
|
+
$env:CLAUDE_PACKAGE_MANAGER = "pnpm"
|
|
70
|
+
|
|
71
|
+
# macOS/Linux
|
|
72
|
+
export CLAUDE_PACKAGE_MANAGER=pnpm
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
## Run the Detection
|
|
76
|
+
|
|
77
|
+
To see current package manager detection results, run:
|
|
78
|
+
|
|
79
|
+
```bash
|
|
80
|
+
node scripts/setup-package-manager.js --detect
|
|
81
|
+
```
|