@hopla/claude-setup 1.8.0 → 1.8.1
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/cli.js +13 -1
- package/files/skills/hopla-code-review/SKILL.md +5 -0
- package/files/skills/hopla-execution-report/SKILL.md +5 -0
- package/package.json +1 -1
- package/files/commands/hopla-code-review.md +0 -96
- package/files/commands/hopla-execution-report.md +0 -116
- package/files/commands/hopla-prime.md +0 -60
package/cli.js
CHANGED
|
@@ -80,6 +80,14 @@ async function uninstall() {
|
|
|
80
80
|
fs.statSync(path.join(FILES_DIR, "commands", f)).isDirectory()
|
|
81
81
|
);
|
|
82
82
|
|
|
83
|
+
// Also include any hopla-* files in ~/.claude/commands/ not in current source
|
|
84
|
+
// (leftovers from previous versions)
|
|
85
|
+
const installedHoplaFiles = fs.existsSync(COMMANDS_DIR)
|
|
86
|
+
? fs.readdirSync(COMMANDS_DIR).filter((f) =>
|
|
87
|
+
f.startsWith("hopla-") && fs.statSync(path.join(COMMANDS_DIR, f)).isFile() && !srcFiles.includes(f)
|
|
88
|
+
)
|
|
89
|
+
: [];
|
|
90
|
+
|
|
83
91
|
const itemsToRemove = [
|
|
84
92
|
{ dest: path.join(CLAUDE_DIR, "CLAUDE.md"), label: "~/.claude/CLAUDE.md", isDir: false },
|
|
85
93
|
...srcFiles.map((file) => ({
|
|
@@ -87,6 +95,11 @@ async function uninstall() {
|
|
|
87
95
|
label: `~/.claude/commands/${file}`,
|
|
88
96
|
isDir: false,
|
|
89
97
|
})),
|
|
98
|
+
...installedHoplaFiles.map((file) => ({
|
|
99
|
+
dest: path.join(COMMANDS_DIR, file),
|
|
100
|
+
label: `~/.claude/commands/${file}`,
|
|
101
|
+
isDir: false,
|
|
102
|
+
})),
|
|
90
103
|
...srcDirs.map((dir) => ({
|
|
91
104
|
dest: path.join(COMMANDS_DIR, dir),
|
|
92
105
|
label: `~/.claude/commands/${dir}/`,
|
|
@@ -149,7 +162,6 @@ function removeStaleCommands(currentCommandFiles) {
|
|
|
149
162
|
|
|
150
163
|
const PLANNING_COMMANDS = [
|
|
151
164
|
"hopla-init-project.md",
|
|
152
|
-
"hopla-prime.md",
|
|
153
165
|
"hopla-create-prd.md",
|
|
154
166
|
"hopla-plan-feature.md",
|
|
155
167
|
"hopla-review-plan.md",
|
|
@@ -89,3 +89,8 @@ If no issues found: "Code review passed. No technical issues detected."
|
|
|
89
89
|
- Focus on real bugs, not style preferences (linting handles that)
|
|
90
90
|
- Flag security issues as `critical`
|
|
91
91
|
- Suggest fixes, don't just identify problems
|
|
92
|
+
|
|
93
|
+
## Next Step
|
|
94
|
+
|
|
95
|
+
After the review, suggest:
|
|
96
|
+
> "Code review saved to `.agents/code-reviews/[name].md`. If issues were found, run `/hopla-code-review-fix .agents/code-reviews/[name].md` to fix them. If the review passed clean, proceed to `/hopla-execution-report`."
|
|
@@ -110,3 +110,8 @@ Based on this implementation, what should change for next time?
|
|
|
110
110
|
- Plan command improvements: [suggestions]
|
|
111
111
|
- Execute command improvements: [suggestions]
|
|
112
112
|
- CLAUDE.md additions: [suggestions]
|
|
113
|
+
|
|
114
|
+
## Next Step
|
|
115
|
+
|
|
116
|
+
After the report is saved, suggest:
|
|
117
|
+
> "Execution report saved to `.agents/execution-reports/[name].md`. Run `/hopla-git-commit` to commit your changes."
|
package/package.json
CHANGED
|
@@ -1,96 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Technical code review on recently changed files
|
|
3
|
-
argument-hint: "[optional: branch or commit range, defaults to HEAD]"
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
> 🌐 **Language:** All user-facing output must match the user's language. Code, paths, and commands stay in English.
|
|
7
|
-
|
|
8
|
-
Perform a technical code review focused on finding real bugs and issues.
|
|
9
|
-
|
|
10
|
-
## Step 1: Load Context
|
|
11
|
-
|
|
12
|
-
Read `CLAUDE.md` or `AGENTS.md` to understand project standards and patterns.
|
|
13
|
-
|
|
14
|
-
If `.agents/guides/` exists, read any guides relevant to the files being reviewed (e.g. `@.agents/guides/api-guide.md` when reviewing API changes). These guides define the expected patterns for specific task types.
|
|
15
|
-
|
|
16
|
-
If `.agents/guides/review-checklist.md` exists, read it and apply the project-specific checks it defines in addition to the standard checks below. Project-specific checklists cover framework gotchas and domain anti-patterns unique to the project (e.g., AG Grid stale closures, Hono route ordering).
|
|
17
|
-
|
|
18
|
-
## Step 2: Identify Changed Files
|
|
19
|
-
|
|
20
|
-
```bash
|
|
21
|
-
git diff --stat HEAD
|
|
22
|
-
git diff HEAD
|
|
23
|
-
git ls-files --others --exclude-standard
|
|
24
|
-
```
|
|
25
|
-
|
|
26
|
-
Read each changed or new file in its entirety — not just the diff.
|
|
27
|
-
|
|
28
|
-
## Step 3: Analyze for Issues
|
|
29
|
-
|
|
30
|
-
For each changed file, look for:
|
|
31
|
-
|
|
32
|
-
**1. Logic Errors**
|
|
33
|
-
- Off-by-one errors, incorrect conditionals
|
|
34
|
-
- Missing error handling, unhandled edge cases
|
|
35
|
-
- Race conditions or async issues
|
|
36
|
-
- Stale closures — callbacks passed to imperative APIs (grids, charts, maps) that capture stale state instead of using refs or stable references
|
|
37
|
-
- Unhandled promise rejections — `.then()` without `.catch()`, async calls without `try/catch` in non-void contexts
|
|
38
|
-
- Side effects inside JSX render — mutations of arrays/objects inside `.map()` in JSX (breaks React strict mode, causes double-execution bugs)
|
|
39
|
-
|
|
40
|
-
**2. Security Issues**
|
|
41
|
-
- Exposed secrets or API keys
|
|
42
|
-
- SQL/command injection vulnerabilities
|
|
43
|
-
- Missing input validation on API endpoints — required fields, format constraints (regex, length), payload size limits
|
|
44
|
-
- Insecure data handling — raw user input in queries, responses exposing internal data or stack traces
|
|
45
|
-
- XSS vulnerabilities (frontend)
|
|
46
|
-
|
|
47
|
-
**3. Performance Problems**
|
|
48
|
-
- Unnecessary re-renders (React)
|
|
49
|
-
- N+1 queries or redundant API calls
|
|
50
|
-
- Memory leaks
|
|
51
|
-
|
|
52
|
-
**4. Code Quality**
|
|
53
|
-
- DRY violations — before flagging, search for similar functions/constants elsewhere in the codebase; suggest extraction to a shared module if the same logic exists in multiple places
|
|
54
|
-
- Poor naming or overly complex functions
|
|
55
|
-
- Missing TypeScript types or `any` usage
|
|
56
|
-
|
|
57
|
-
**5. Pattern Adherence**
|
|
58
|
-
- Follows project conventions from CLAUDE.md
|
|
59
|
-
- Consistent with existing codebase style
|
|
60
|
-
|
|
61
|
-
**6. Route & Middleware Ordering**
|
|
62
|
-
- Static routes defined AFTER parameterized routes (e.g., `/users/all` after `/users/:id`) causing shadowing — the parameterized route captures requests meant for the static one
|
|
63
|
-
- Middleware applied in incorrect order (e.g., auth after route handler, CORS after response sent)
|
|
64
|
-
|
|
65
|
-
## Step 4: Verify Issues Are Real
|
|
66
|
-
|
|
67
|
-
Before reporting, confirm each issue is legitimate:
|
|
68
|
-
- Run relevant tests if applicable
|
|
69
|
-
- Check if the pattern is intentional based on context
|
|
70
|
-
|
|
71
|
-
## Step 5: Output Report
|
|
72
|
-
|
|
73
|
-
Save to `.agents/code-reviews/[descriptive-name].md`
|
|
74
|
-
|
|
75
|
-
**Format for each issue:**
|
|
76
|
-
```
|
|
77
|
-
severity: critical | high | medium | low
|
|
78
|
-
file: path/to/file.ts
|
|
79
|
-
line: 42
|
|
80
|
-
issue: [one-line description]
|
|
81
|
-
detail: [why this is a problem]
|
|
82
|
-
suggestion: [how to fix it]
|
|
83
|
-
```
|
|
84
|
-
|
|
85
|
-
If no issues found: "Code review passed. No technical issues detected."
|
|
86
|
-
|
|
87
|
-
**Rules:**
|
|
88
|
-
- Be specific — line numbers, not vague complaints
|
|
89
|
-
- Focus on real bugs, not style preferences (linting handles that)
|
|
90
|
-
- Flag security issues as `critical`
|
|
91
|
-
- Suggest fixes, don't just identify problems
|
|
92
|
-
|
|
93
|
-
## Next Step
|
|
94
|
-
|
|
95
|
-
After the review, suggest:
|
|
96
|
-
> "Code review saved to `.agents/code-reviews/[name].md`. If issues were found, run `/hopla-code-review-fix .agents/code-reviews/[name].md` to fix them. If the review passed clean, proceed to `/hopla-execution-report`."
|
|
@@ -1,116 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Generate an implementation report for system review
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
> 🌐 **Language:** All user-facing output must match the user's language. Code, paths, and commands stay in English.
|
|
6
|
-
|
|
7
|
-
Review and document the implementation you just completed. Run this immediately after finishing a feature — before committing or starting the next task.
|
|
8
|
-
|
|
9
|
-
## Step 1: Gather Implementation Data
|
|
10
|
-
|
|
11
|
-
```bash
|
|
12
|
-
git diff HEAD --stat
|
|
13
|
-
git diff HEAD
|
|
14
|
-
git ls-files --others --exclude-standard
|
|
15
|
-
```
|
|
16
|
-
|
|
17
|
-
Also check for recent code reviews:
|
|
18
|
-
|
|
19
|
-
```bash
|
|
20
|
-
ls -t .agents/code-reviews/ 2>/dev/null | head -5
|
|
21
|
-
```
|
|
22
|
-
|
|
23
|
-
If a code review exists for this feature, note its path for the Code Review Findings section below.
|
|
24
|
-
|
|
25
|
-
## Step 2: Generate Report
|
|
26
|
-
|
|
27
|
-
Save to: `.agents/execution-reports/[feature-name].md`
|
|
28
|
-
|
|
29
|
-
Use the following structure:
|
|
30
|
-
|
|
31
|
-
---
|
|
32
|
-
|
|
33
|
-
### Meta Information
|
|
34
|
-
|
|
35
|
-
- **Plan file:** [path to the plan that guided this implementation]
|
|
36
|
-
- **Files added:** [list with paths]
|
|
37
|
-
- **Files modified:** [list with paths]
|
|
38
|
-
- **Lines changed:** +X -Y
|
|
39
|
-
|
|
40
|
-
### Validation Results
|
|
41
|
-
|
|
42
|
-
- Syntax & Linting: ✓/✗ [details if failed]
|
|
43
|
-
- Type Checking: ✓/✗ [details if failed]
|
|
44
|
-
- Unit Tests: ✓/✗ [X passed, Y failed]
|
|
45
|
-
- Integration Tests: ✓/✗ [X passed, Y failed]
|
|
46
|
-
|
|
47
|
-
### Code Review Findings
|
|
48
|
-
|
|
49
|
-
- **Code review file:** [path to `.agents/code-reviews/[name].md`, or "Not run"]
|
|
50
|
-
- **Issues found:** [count by severity: X critical, Y high, Z medium, W low]
|
|
51
|
-
- **Issues fixed before this report:** [count]
|
|
52
|
-
- **Key findings:** [1-2 sentence summary of the most significant issues found]
|
|
53
|
-
|
|
54
|
-
### What Went Well
|
|
55
|
-
|
|
56
|
-
List specific things that worked smoothly:
|
|
57
|
-
- [concrete examples]
|
|
58
|
-
|
|
59
|
-
### Challenges Encountered
|
|
60
|
-
|
|
61
|
-
List specific difficulties encountered:
|
|
62
|
-
- [what was difficult and why]
|
|
63
|
-
|
|
64
|
-
### Bugs Encountered
|
|
65
|
-
|
|
66
|
-
Categorize each bug found during implementation:
|
|
67
|
-
|
|
68
|
-
| Bug | Category | Found By | Severity |
|
|
69
|
-
|-----|----------|----------|----------|
|
|
70
|
-
| [description] | stale closure / validation / race condition / styling / scope mismatch / type error / route ordering / other | lint / types / tests / code review / manual testing | critical / high / medium / low |
|
|
71
|
-
|
|
72
|
-
If no bugs were encountered, write "No bugs encountered during implementation."
|
|
73
|
-
|
|
74
|
-
### Divergences from Plan
|
|
75
|
-
|
|
76
|
-
For each divergence from the original plan:
|
|
77
|
-
|
|
78
|
-
**[Divergence Title]**
|
|
79
|
-
- **Planned:** [what the plan specified]
|
|
80
|
-
- **Actual:** [what was implemented instead]
|
|
81
|
-
- **Reason:** [why this divergence occurred]
|
|
82
|
-
- **Type:** Better approach found | Plan assumption wrong | Security concern | Performance issue | Other
|
|
83
|
-
|
|
84
|
-
### Scope Assessment
|
|
85
|
-
|
|
86
|
-
- **Planned tasks:** [number of tasks in the original plan]
|
|
87
|
-
- **Executed tasks:** [number of tasks actually completed]
|
|
88
|
-
- **Unplanned additions:** [count and brief description of work not in the original plan]
|
|
89
|
-
- **Scope accuracy:** On target | Under-scoped (took more work than planned) | Over-scoped (simpler than expected)
|
|
90
|
-
|
|
91
|
-
### Skipped Items
|
|
92
|
-
|
|
93
|
-
List anything from the plan that was not implemented:
|
|
94
|
-
- [what was skipped] — Reason: [why]
|
|
95
|
-
|
|
96
|
-
### Technical Patterns Discovered
|
|
97
|
-
|
|
98
|
-
New gotchas, patterns, or conventions learned during this implementation that should be documented:
|
|
99
|
-
|
|
100
|
-
- **Pattern/Gotcha:** [description]
|
|
101
|
-
- **Where it applies:** [what type of feature or context triggers this]
|
|
102
|
-
- **Suggested documentation:** [which file should capture this: CLAUDE.md, `.agents/guides/review-checklist.md`, or a new guide]
|
|
103
|
-
|
|
104
|
-
If nothing new was discovered, write "No new patterns discovered."
|
|
105
|
-
|
|
106
|
-
### Recommendations
|
|
107
|
-
|
|
108
|
-
Based on this implementation, what should change for next time?
|
|
109
|
-
- Plan command improvements: [suggestions]
|
|
110
|
-
- Execute command improvements: [suggestions]
|
|
111
|
-
- CLAUDE.md additions: [suggestions]
|
|
112
|
-
|
|
113
|
-
## Next Step
|
|
114
|
-
|
|
115
|
-
After the report is saved, suggest:
|
|
116
|
-
> "Execution report saved to `.agents/execution-reports/[name].md`. Run `/hopla-git-commit` to commit your changes."
|
|
@@ -1,60 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Load project context at the start of a session
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
> 🌐 **Language:** All user-facing output must match the user's language. Code, paths, and commands stay in English.
|
|
6
|
-
|
|
7
|
-
Get oriented in this project before doing any work.
|
|
8
|
-
|
|
9
|
-
## Step 1: Project Structure
|
|
10
|
-
|
|
11
|
-
Use the Glob tool to list project files (up to 60):
|
|
12
|
-
- Pattern: `**/*` with head_limit: 60
|
|
13
|
-
|
|
14
|
-
Use the Glob tool to find key config files:
|
|
15
|
-
- `**/CLAUDE.md`
|
|
16
|
-
- `**/AGENTS.md`
|
|
17
|
-
- `**/README.md`
|
|
18
|
-
|
|
19
|
-
## Step 2: Read Key Files
|
|
20
|
-
|
|
21
|
-
Read in this order:
|
|
22
|
-
1. `CLAUDE.md` or `AGENTS.md` at project root (project-specific rules)
|
|
23
|
-
2. `README.md` (project overview)
|
|
24
|
-
3. `package.json` or `pyproject.toml` (dependencies and scripts)
|
|
25
|
-
|
|
26
|
-
## Step 3: Understand Git State
|
|
27
|
-
|
|
28
|
-
```bash
|
|
29
|
-
git branch --show-current
|
|
30
|
-
git log --oneline -10
|
|
31
|
-
git status
|
|
32
|
-
```
|
|
33
|
-
|
|
34
|
-
## Step 4: Check Pending Work
|
|
35
|
-
|
|
36
|
-
Use the Glob tool to check for pending plans:
|
|
37
|
-
- Pattern: `.agents/plans/*.md`
|
|
38
|
-
|
|
39
|
-
If `.agents/plans/` exists, identify:
|
|
40
|
-
- `.draft.md` files — unfinished drafts waiting for review
|
|
41
|
-
- `.md` files (without `.draft`) — finalized plans ready to execute
|
|
42
|
-
|
|
43
|
-
## Step 5: Summary Report
|
|
44
|
-
|
|
45
|
-
Write a short, conversational message addressed directly to the user. Mention:
|
|
46
|
-
- What the project is and what it does
|
|
47
|
-
- The current branch and what it's for
|
|
48
|
-
- Whether there are uncommitted changes or pending work
|
|
49
|
-
- The command to start the project (if available)
|
|
50
|
-
|
|
51
|
-
If there are pending plans, list them clearly after the prose summary:
|
|
52
|
-
```
|
|
53
|
-
Pending plans:
|
|
54
|
-
- inventory-page.draft.md ← draft, not finalized yet
|
|
55
|
-
- add-user-authentication.md ← ready to execute with /hopla-execute
|
|
56
|
-
```
|
|
57
|
-
|
|
58
|
-
End with a sentence like: "All caught up — what are we working on today?"
|
|
59
|
-
|
|
60
|
-
Do NOT use headers in the prose summary. Write it as natural, friendly prose, then the pending plans list if applicable.
|