@hopla/claude-setup 1.0.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 +41 -0
- package/cli.js +86 -0
- package/files/CLAUDE.md +87 -0
- package/files/commands/code-review-fix.md +46 -0
- package/files/commands/code-review.md +77 -0
- package/files/commands/commit.md +60 -0
- package/files/commands/create-prd.md +85 -0
- package/files/commands/execute.md +103 -0
- package/files/commands/execution-report.md +67 -0
- package/files/commands/plan-feature.md +136 -0
- package/files/commands/prime.md +43 -0
- package/files/commands/system-review.md +139 -0
- package/package.json +27 -0
package/README.md
ADDED
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# @hopla/claude-setup
|
|
2
|
+
|
|
3
|
+
Hopla team agentic coding system for Claude Code. Installs global rules and commands to `~/.claude/`.
|
|
4
|
+
|
|
5
|
+
## Install
|
|
6
|
+
|
|
7
|
+
```bash
|
|
8
|
+
npx @hopla/claude-setup
|
|
9
|
+
```
|
|
10
|
+
|
|
11
|
+
To overwrite existing files without prompting:
|
|
12
|
+
|
|
13
|
+
```bash
|
|
14
|
+
npx @hopla/claude-setup --force
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
## What gets installed
|
|
18
|
+
|
|
19
|
+
**`~/.claude/CLAUDE.md`** — Global rules: language, tech preferences, Git Flow, Conventional Commits, autonomy behavior.
|
|
20
|
+
|
|
21
|
+
**`~/.claude/commands/`** — Reusable commands available in any project:
|
|
22
|
+
|
|
23
|
+
| Command | Description |
|
|
24
|
+
|---|---|
|
|
25
|
+
| `/prime` | Load project context at the start of a session |
|
|
26
|
+
| `/commit` | Create a Conventional Commit with Git Flow awareness |
|
|
27
|
+
| `/create-prd` | Create a Product Requirements Document through guided questions |
|
|
28
|
+
| `/plan-feature` | Research codebase and create a structured implementation plan |
|
|
29
|
+
| `/execute` | Execute a structured plan from start to finish with validation |
|
|
30
|
+
| `/code-review` | Technical code review on recently changed files |
|
|
31
|
+
| `/code-review-fix` | Fix issues found in a code review report |
|
|
32
|
+
| `/execution-report` | Generate an implementation report for system review |
|
|
33
|
+
| `/system-review` | Analyze implementation against plan to find process improvements |
|
|
34
|
+
|
|
35
|
+
## Update
|
|
36
|
+
|
|
37
|
+
Re-run the install command to update to the latest version:
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
npx @hopla/claude-setup@latest
|
|
41
|
+
```
|
package/cli.js
ADDED
|
@@ -0,0 +1,86 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
|
|
3
|
+
import fs from "fs";
|
|
4
|
+
import path from "path";
|
|
5
|
+
import os from "os";
|
|
6
|
+
import readline from "readline";
|
|
7
|
+
|
|
8
|
+
const FORCE = process.argv.includes("--force");
|
|
9
|
+
const CLAUDE_DIR = path.join(os.homedir(), ".claude");
|
|
10
|
+
const COMMANDS_DIR = path.join(CLAUDE_DIR, "commands");
|
|
11
|
+
const FILES_DIR = path.join(import.meta.dirname, "files");
|
|
12
|
+
|
|
13
|
+
const GREEN = "\x1b[32m";
|
|
14
|
+
const YELLOW = "\x1b[33m";
|
|
15
|
+
const CYAN = "\x1b[36m";
|
|
16
|
+
const RESET = "\x1b[0m";
|
|
17
|
+
const BOLD = "\x1b[1m";
|
|
18
|
+
|
|
19
|
+
function log(msg) {
|
|
20
|
+
console.log(msg);
|
|
21
|
+
}
|
|
22
|
+
|
|
23
|
+
async function confirm(question) {
|
|
24
|
+
if (FORCE) return true;
|
|
25
|
+
const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
|
|
26
|
+
return new Promise((resolve) => {
|
|
27
|
+
rl.question(question, (answer) => {
|
|
28
|
+
rl.close();
|
|
29
|
+
resolve(answer.toLowerCase() === "y" || answer.toLowerCase() === "yes");
|
|
30
|
+
});
|
|
31
|
+
});
|
|
32
|
+
}
|
|
33
|
+
|
|
34
|
+
async function installFile(src, dest, label) {
|
|
35
|
+
const exists = fs.existsSync(dest);
|
|
36
|
+
|
|
37
|
+
if (exists && !FORCE) {
|
|
38
|
+
const overwrite = await confirm(
|
|
39
|
+
` ${YELLOW}⚠${RESET} ${label} already exists. Overwrite? (y/N) `
|
|
40
|
+
);
|
|
41
|
+
if (!overwrite) {
|
|
42
|
+
log(` ${YELLOW}↷${RESET} Skipped: ${label}`);
|
|
43
|
+
return;
|
|
44
|
+
}
|
|
45
|
+
}
|
|
46
|
+
|
|
47
|
+
fs.copyFileSync(src, dest);
|
|
48
|
+
log(` ${GREEN}✓${RESET} ${exists ? "Updated" : "Installed"}: ${label}`);
|
|
49
|
+
}
|
|
50
|
+
|
|
51
|
+
async function main() {
|
|
52
|
+
log(`\n${BOLD}@hopla/claude-setup${RESET} — Agentic Coding System\n`);
|
|
53
|
+
|
|
54
|
+
// Create directories if needed
|
|
55
|
+
fs.mkdirSync(CLAUDE_DIR, { recursive: true });
|
|
56
|
+
fs.mkdirSync(COMMANDS_DIR, { recursive: true });
|
|
57
|
+
|
|
58
|
+
log(`${CYAN}Installing global rules...${RESET}`);
|
|
59
|
+
await installFile(
|
|
60
|
+
path.join(FILES_DIR, "CLAUDE.md"),
|
|
61
|
+
path.join(CLAUDE_DIR, "CLAUDE.md"),
|
|
62
|
+
"~/.claude/CLAUDE.md"
|
|
63
|
+
);
|
|
64
|
+
|
|
65
|
+
log(`\n${CYAN}Installing commands...${RESET}`);
|
|
66
|
+
const commandFiles = fs.readdirSync(path.join(FILES_DIR, "commands"));
|
|
67
|
+
for (const file of commandFiles.sort()) {
|
|
68
|
+
await installFile(
|
|
69
|
+
path.join(FILES_DIR, "commands", file),
|
|
70
|
+
path.join(COMMANDS_DIR, file),
|
|
71
|
+
`~/.claude/commands/${file}`
|
|
72
|
+
);
|
|
73
|
+
}
|
|
74
|
+
|
|
75
|
+
log(`\n${GREEN}${BOLD}Done!${RESET} Commands available in any Claude Code session:\n`);
|
|
76
|
+
for (const file of commandFiles.sort()) {
|
|
77
|
+
const name = file.replace(".md", "");
|
|
78
|
+
log(` ${CYAN}/${name}${RESET}`);
|
|
79
|
+
}
|
|
80
|
+
log(`\nRun with ${BOLD}--force${RESET} to overwrite all files without prompting.\n`);
|
|
81
|
+
}
|
|
82
|
+
|
|
83
|
+
main().catch((err) => {
|
|
84
|
+
console.error("Installation failed:", err.message);
|
|
85
|
+
process.exit(1);
|
|
86
|
+
});
|
package/files/CLAUDE.md
ADDED
|
@@ -0,0 +1,87 @@
|
|
|
1
|
+
# Global Rules — Agentic Coding System
|
|
2
|
+
|
|
3
|
+
## 1. Communication
|
|
4
|
+
|
|
5
|
+
- **Always respond in the same language the user writes in** — if the user writes in Spanish, respond in Spanish; if in English, respond in English
|
|
6
|
+
- Code, comments, variable names, and commit messages always in **English** regardless of the conversation language
|
|
7
|
+
- Be concise — avoid unnecessary filler text
|
|
8
|
+
- When reporting results, use ✅/❌ for clarity
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## 2. Tech Preferences
|
|
13
|
+
|
|
14
|
+
- **Frontend:** React with functional components and hooks (no class components)
|
|
15
|
+
- **Language:** TypeScript over JavaScript always
|
|
16
|
+
- **Bundler:** Vite as default for frontend projects
|
|
17
|
+
- Keep solutions simple — avoid over-engineering and premature abstractions
|
|
18
|
+
- Prefer editing existing files over creating new ones
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## 3. Behavior & Autonomy
|
|
23
|
+
|
|
24
|
+
**Always ask before:**
|
|
25
|
+
- Running `git commit`
|
|
26
|
+
- Running `git push`
|
|
27
|
+
- Installing new dependencies (`npm install <pkg>`, `pip install <pkg>`, etc.)
|
|
28
|
+
- Deleting files or directories
|
|
29
|
+
- Any destructive or hard-to-reverse operation
|
|
30
|
+
|
|
31
|
+
**Proactively suggest commits** at logical save points:
|
|
32
|
+
- After completing a feature or fix
|
|
33
|
+
- Before starting a risky refactor
|
|
34
|
+
- After passing all validation checks
|
|
35
|
+
- Explain WHY it's a good moment to commit so the team understands
|
|
36
|
+
|
|
37
|
+
**Never:**
|
|
38
|
+
- Auto-commit or auto-push without explicit approval
|
|
39
|
+
- Skip validation steps to save time
|
|
40
|
+
- Add features, refactors, or improvements beyond what was asked
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## 4. Git Workflow (Git Flow)
|
|
45
|
+
|
|
46
|
+
### Branch Strategy
|
|
47
|
+
- `main` → production only, never commit directly
|
|
48
|
+
- `develop` / `dev` → active development branch
|
|
49
|
+
- Feature branches: `feature/short-description`
|
|
50
|
+
- Bug fix branches: `fix/short-description`
|
|
51
|
+
- Hotfix branches: `hotfix/short-description`
|
|
52
|
+
|
|
53
|
+
### Commit Format — Conventional Commits
|
|
54
|
+
```
|
|
55
|
+
<type>(<optional scope>): <short description>
|
|
56
|
+
|
|
57
|
+
[optional body]
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
**Types:**
|
|
61
|
+
- `feat:` — new feature
|
|
62
|
+
- `fix:` — bug fix
|
|
63
|
+
- `refactor:` — code restructure without behavior change
|
|
64
|
+
- `docs:` — documentation only
|
|
65
|
+
- `test:` — adding or fixing tests
|
|
66
|
+
- `chore:` — build, config, dependencies
|
|
67
|
+
- `style:` — formatting, no logic change
|
|
68
|
+
|
|
69
|
+
**Examples:**
|
|
70
|
+
```
|
|
71
|
+
feat(auth): add JWT token validation
|
|
72
|
+
fix(api): handle null response from products endpoint
|
|
73
|
+
chore: update dependencies to latest versions
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
### When to Suggest a Commit
|
|
77
|
+
Explain in plain language when suggesting a commit, adapting to the user's language, e.g.:
|
|
78
|
+
> "This would be a good moment to commit — we finished feature X and all tests pass. Should we commit before continuing?"
|
|
79
|
+
|
|
80
|
+
---
|
|
81
|
+
|
|
82
|
+
## 5. Code Quality
|
|
83
|
+
|
|
84
|
+
- Validate before considering anything done (lint → types → tests)
|
|
85
|
+
- Write tests alongside implementation, not after
|
|
86
|
+
- Flag security issues immediately — never leave them for later
|
|
87
|
+
- If the same validation failure repeats, signal it as a system improvement opportunity
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Fix issues found in a code review report
|
|
3
|
+
argument-hint: "<review-file-or-description> [scope]"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Fix the issues identified in a code review.
|
|
7
|
+
|
|
8
|
+
## Inputs
|
|
9
|
+
|
|
10
|
+
- **$1** — Path to a code review report file OR a natural language description of the issues to fix
|
|
11
|
+
- **$2** (optional) — Scope: focus only on a subset of issues (e.g., "security issues only", "critical and high severity only")
|
|
12
|
+
|
|
13
|
+
## Step 1: Load the Review
|
|
14
|
+
|
|
15
|
+
If $1 is a file path, read the entire file first to understand all issues before starting any fixes.
|
|
16
|
+
If $1 is a description, treat it as the list of issues to fix.
|
|
17
|
+
|
|
18
|
+
If $2 is provided, filter to only the issues within that scope.
|
|
19
|
+
|
|
20
|
+
## Step 2: Fix Issues One by One
|
|
21
|
+
|
|
22
|
+
For each issue, in order of severity (critical → high → medium → low):
|
|
23
|
+
|
|
24
|
+
1. **Explain** what was wrong and why it's a problem
|
|
25
|
+
2. **Implement** the fix
|
|
26
|
+
3. **Verify** — create and run a relevant test or check to confirm the fix works
|
|
27
|
+
|
|
28
|
+
Do not move to the next issue until the current one is verified.
|
|
29
|
+
|
|
30
|
+
## Step 3: Run Full Validation
|
|
31
|
+
|
|
32
|
+
After all fixes are complete, run the project's validation suite.
|
|
33
|
+
|
|
34
|
+
If a `/validate` command exists in `.claude/commands/validate.md`, run it.
|
|
35
|
+
Otherwise, run the standard checks for the project stack:
|
|
36
|
+
- Linting
|
|
37
|
+
- Type checking
|
|
38
|
+
- Test suite
|
|
39
|
+
|
|
40
|
+
## Step 4: Summary Report
|
|
41
|
+
|
|
42
|
+
Provide a summary of:
|
|
43
|
+
- Issues fixed (with file and line reference)
|
|
44
|
+
- Issues skipped and why (if $2 scope was used)
|
|
45
|
+
- Validation result ✅/❌
|
|
46
|
+
- Any issues that could not be fixed automatically and require human review
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Technical code review on recently changed files
|
|
3
|
+
argument-hint: "[optional: branch or commit range, defaults to HEAD]"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Perform a technical code review focused on finding real bugs and issues.
|
|
7
|
+
|
|
8
|
+
## Step 1: Load Context
|
|
9
|
+
|
|
10
|
+
Read `CLAUDE.md` or `AGENTS.md` to understand project standards and patterns.
|
|
11
|
+
|
|
12
|
+
## Step 2: Identify Changed Files
|
|
13
|
+
|
|
14
|
+
```bash
|
|
15
|
+
git diff --stat HEAD
|
|
16
|
+
git diff HEAD
|
|
17
|
+
git ls-files --others --exclude-standard
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
Read each changed or new file in its entirety — not just the diff.
|
|
21
|
+
|
|
22
|
+
## Step 3: Analyze for Issues
|
|
23
|
+
|
|
24
|
+
For each changed file, look for:
|
|
25
|
+
|
|
26
|
+
**1. Logic Errors**
|
|
27
|
+
- Off-by-one errors, incorrect conditionals
|
|
28
|
+
- Missing error handling, unhandled edge cases
|
|
29
|
+
- Race conditions or async issues
|
|
30
|
+
|
|
31
|
+
**2. Security Issues**
|
|
32
|
+
- Exposed secrets or API keys
|
|
33
|
+
- SQL/command injection vulnerabilities
|
|
34
|
+
- Insecure data handling or missing input validation
|
|
35
|
+
- XSS vulnerabilities (frontend)
|
|
36
|
+
|
|
37
|
+
**3. Performance Problems**
|
|
38
|
+
- Unnecessary re-renders (React)
|
|
39
|
+
- N+1 queries or redundant API calls
|
|
40
|
+
- Memory leaks
|
|
41
|
+
|
|
42
|
+
**4. Code Quality**
|
|
43
|
+
- DRY violations
|
|
44
|
+
- Poor naming or overly complex functions
|
|
45
|
+
- Missing TypeScript types or `any` usage
|
|
46
|
+
|
|
47
|
+
**5. Pattern Adherence**
|
|
48
|
+
- Follows project conventions from CLAUDE.md
|
|
49
|
+
- Consistent with existing codebase style
|
|
50
|
+
|
|
51
|
+
## Step 4: Verify Issues Are Real
|
|
52
|
+
|
|
53
|
+
Before reporting, confirm each issue is legitimate:
|
|
54
|
+
- Run relevant tests if applicable
|
|
55
|
+
- Check if the pattern is intentional based on context
|
|
56
|
+
|
|
57
|
+
## Step 5: Output Report
|
|
58
|
+
|
|
59
|
+
Save to `.agents/code-reviews/[descriptive-name].md`
|
|
60
|
+
|
|
61
|
+
**Format for each issue:**
|
|
62
|
+
```
|
|
63
|
+
severity: critical | high | medium | low
|
|
64
|
+
file: path/to/file.ts
|
|
65
|
+
line: 42
|
|
66
|
+
issue: [one-line description]
|
|
67
|
+
detail: [why this is a problem]
|
|
68
|
+
suggestion: [how to fix it]
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
If no issues found: "Code review passed. No technical issues detected."
|
|
72
|
+
|
|
73
|
+
**Rules:**
|
|
74
|
+
- Be specific — line numbers, not vague complaints
|
|
75
|
+
- Focus on real bugs, not style preferences (linting handles that)
|
|
76
|
+
- Flag security issues as `critical`
|
|
77
|
+
- Suggest fixes, don't just identify problems
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Create a conventional commit with Git Flow awareness
|
|
3
|
+
argument-hint: "[optional: commit message or scope]"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Review the current git state and create an appropriate commit.
|
|
7
|
+
|
|
8
|
+
## Step 1: Gather Context
|
|
9
|
+
|
|
10
|
+
Run these commands to understand what changed:
|
|
11
|
+
|
|
12
|
+
```bash
|
|
13
|
+
git status
|
|
14
|
+
git diff --staged
|
|
15
|
+
git diff
|
|
16
|
+
git log --oneline -5
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
## Step 2: Analyze Changes
|
|
20
|
+
|
|
21
|
+
- Identify what was added, modified, or deleted
|
|
22
|
+
- Determine the appropriate commit type: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `style`
|
|
23
|
+
- Identify the scope if relevant (e.g., `auth`, `api`, `ui`)
|
|
24
|
+
- Check current branch — confirm it follows Git Flow naming (`feature/`, `fix/`, `hotfix/`, `develop`, `dev`)
|
|
25
|
+
|
|
26
|
+
## Step 3: Stage Files
|
|
27
|
+
|
|
28
|
+
Stage only the relevant files for this commit (avoid `git add -A` unless all changes belong together):
|
|
29
|
+
|
|
30
|
+
```bash
|
|
31
|
+
git add <specific files>
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## Step 4: Propose Commit
|
|
35
|
+
|
|
36
|
+
Present the proposed commit message to the user **before executing**:
|
|
37
|
+
|
|
38
|
+
> "Proposed commit:
|
|
39
|
+
> `feat(products): add price filter to search endpoint`
|
|
40
|
+
>
|
|
41
|
+
> Files included: [list files]
|
|
42
|
+
> Shall I proceed?"
|
|
43
|
+
|
|
44
|
+
Wait for explicit approval before running `git commit`.
|
|
45
|
+
|
|
46
|
+
## Step 5: Execute Commit
|
|
47
|
+
|
|
48
|
+
Once approved, create the commit:
|
|
49
|
+
|
|
50
|
+
```bash
|
|
51
|
+
git commit -m "<type>(<scope>): <description>"
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
## Step 6: Push Reminder
|
|
55
|
+
|
|
56
|
+
After committing, remind the user:
|
|
57
|
+
|
|
58
|
+
> "Commit created locally. Do you want to push to `origin/<branch>`?"
|
|
59
|
+
|
|
60
|
+
**Never push automatically** — wait for explicit confirmation.
|
|
@@ -0,0 +1,85 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Create a Product Requirements Document (PRD) for a project through guided questions
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Create a PRD for this project by gathering the necessary information through a structured conversation.
|
|
6
|
+
|
|
7
|
+
## Step 1: Gather Context
|
|
8
|
+
|
|
9
|
+
Before asking questions, read what already exists:
|
|
10
|
+
- `CLAUDE.md` or `AGENTS.md` — extract product name, tech stack, and any business context
|
|
11
|
+
- `README.md` — extract any existing product description
|
|
12
|
+
|
|
13
|
+
Use this to avoid asking questions that are already answered.
|
|
14
|
+
|
|
15
|
+
## Step 2: Ask Key Questions
|
|
16
|
+
|
|
17
|
+
Ask the following questions **one section at a time** — do not dump all questions at once. Wait for the answer before continuing.
|
|
18
|
+
|
|
19
|
+
**Section A — The Product**
|
|
20
|
+
1. In 1-2 sentences, what does this product do?
|
|
21
|
+
2. What problem does it solve? What was happening before this product existed?
|
|
22
|
+
|
|
23
|
+
**Section B — The Users**
|
|
24
|
+
3. Who are the primary users? (role, context, technical level)
|
|
25
|
+
4. How do they use it? (daily, weekly, ad-hoc?)
|
|
26
|
+
|
|
27
|
+
**Section C — Scope**
|
|
28
|
+
5. What are the 3-5 most important features the product must have?
|
|
29
|
+
6. What is explicitly OUT of scope? (things users might expect but won't be built)
|
|
30
|
+
|
|
31
|
+
**Section D — Success**
|
|
32
|
+
7. How do you know the product is working well? (key outcomes or metrics)
|
|
33
|
+
|
|
34
|
+
## Step 3: Generate the PRD
|
|
35
|
+
|
|
36
|
+
Once all questions are answered, generate the PRD and save it to `PRD.md` at the project root.
|
|
37
|
+
|
|
38
|
+
Use this structure:
|
|
39
|
+
|
|
40
|
+
---
|
|
41
|
+
|
|
42
|
+
```markdown
|
|
43
|
+
# PRD — [Product Name]
|
|
44
|
+
|
|
45
|
+
## What is it?
|
|
46
|
+
|
|
47
|
+
[2-3 sentence executive summary. What it does, who it's for, and why it exists.]
|
|
48
|
+
|
|
49
|
+
## Problem
|
|
50
|
+
|
|
51
|
+
[What problem does this solve? What was the situation before this product?]
|
|
52
|
+
|
|
53
|
+
## Users
|
|
54
|
+
|
|
55
|
+
**Primary users:** [Role and context]
|
|
56
|
+
**Usage pattern:** [How often and in what context they use it]
|
|
57
|
+
|
|
58
|
+
## Core Features (In Scope)
|
|
59
|
+
|
|
60
|
+
- [Feature 1 — one line description]
|
|
61
|
+
- [Feature 2 — one line description]
|
|
62
|
+
- [Feature 3 — one line description]
|
|
63
|
+
[Add as many as needed]
|
|
64
|
+
|
|
65
|
+
## Out of Scope
|
|
66
|
+
|
|
67
|
+
These are explicitly NOT part of this product:
|
|
68
|
+
- [Thing 1 — why it's excluded]
|
|
69
|
+
- [Thing 2 — why it's excluded]
|
|
70
|
+
|
|
71
|
+
## Success Criteria
|
|
72
|
+
|
|
73
|
+
The product is working well when:
|
|
74
|
+
- [Measurable outcome 1]
|
|
75
|
+
- [Measurable outcome 2]
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
---
|
|
79
|
+
|
|
80
|
+
## Step 4: Confirm and Save
|
|
81
|
+
|
|
82
|
+
Show the draft PRD to the user and ask:
|
|
83
|
+
> "Does this accurately reflect the product? Any corrections before I save it?"
|
|
84
|
+
|
|
85
|
+
Once confirmed, save to `PRD.md` and suggest running `/commit` to add it to the repository.
|
|
@@ -0,0 +1,103 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Execute a structured plan from start to finish with validation
|
|
3
|
+
argument-hint: "<plan-file-path>"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Execute the implementation plan provided. You are the executing agent — you have not seen the planning conversation. The plan is your only source of truth.
|
|
7
|
+
|
|
8
|
+
## Step 1: Load Context
|
|
9
|
+
|
|
10
|
+
Read in this order:
|
|
11
|
+
1. **$1** — The plan file (read it entirely before writing a single line of code)
|
|
12
|
+
2. `CLAUDE.md` or `AGENTS.md` at project root — rules and patterns to follow
|
|
13
|
+
3. All files listed in the plan's **Context References** section
|
|
14
|
+
|
|
15
|
+
Do not start implementing until you have read everything above.
|
|
16
|
+
|
|
17
|
+
## Step 2: Confirm Understanding
|
|
18
|
+
|
|
19
|
+
Before executing, summarize:
|
|
20
|
+
- What you are about to build
|
|
21
|
+
- How many tasks are in the plan
|
|
22
|
+
- Any constraints or gotchas flagged in the plan
|
|
23
|
+
- Anything unclear that needs clarification before proceeding
|
|
24
|
+
|
|
25
|
+
If anything in the plan is ambiguous or contradictory, **stop and ask** before writing code.
|
|
26
|
+
|
|
27
|
+
## Step 3: Execute Tasks in Order
|
|
28
|
+
|
|
29
|
+
Work through each task in the plan sequentially. For each task:
|
|
30
|
+
|
|
31
|
+
1. **Announce** the task you are starting (e.g., "Starting Task 2: Create the filter component")
|
|
32
|
+
2. **Follow the pattern** referenced in the plan — do not invent new patterns
|
|
33
|
+
3. **Implement** only what the task specifies — nothing more
|
|
34
|
+
4. **Validate** the task using the method specified in the plan's validate field
|
|
35
|
+
5. **Do not proceed** to the next task if the current one fails validation
|
|
36
|
+
|
|
37
|
+
If you encounter something unexpected (a file doesn't exist, a pattern is different than the plan assumed), **stop and report** before continuing — do not improvise silently.
|
|
38
|
+
|
|
39
|
+
## Step 4: Run Full Validation Pyramid
|
|
40
|
+
|
|
41
|
+
After all tasks are complete, run the full validation sequence in order.
|
|
42
|
+
**Do not skip levels. Do not proceed if a level fails.**
|
|
43
|
+
|
|
44
|
+
### Level 1 — Lint & Format
|
|
45
|
+
Run the project's lint and format check.
|
|
46
|
+
Fix any issues before continuing.
|
|
47
|
+
|
|
48
|
+
### Level 2 — Type Check
|
|
49
|
+
Run the project's type checker.
|
|
50
|
+
Fix all type errors before continuing.
|
|
51
|
+
|
|
52
|
+
### Level 3 — Unit Tests
|
|
53
|
+
Run the project's unit test suite.
|
|
54
|
+
If tests fail:
|
|
55
|
+
- Investigate the root cause
|
|
56
|
+
- Fix the code (not the tests)
|
|
57
|
+
- Re-run until all pass
|
|
58
|
+
|
|
59
|
+
### Level 4 — Integration Tests
|
|
60
|
+
Run integration tests or manual verification as specified in the plan.
|
|
61
|
+
Verify the feature works end-to-end.
|
|
62
|
+
|
|
63
|
+
### Level 5 — Human Review (flag for user)
|
|
64
|
+
List what the user should manually verify:
|
|
65
|
+
- Specific behaviors to test in the browser or CLI
|
|
66
|
+
- Edge cases to check
|
|
67
|
+
- Any decisions made during implementation that the user should review
|
|
68
|
+
|
|
69
|
+
## Step 5: Completion Report
|
|
70
|
+
|
|
71
|
+
Provide a summary of what was done:
|
|
72
|
+
|
|
73
|
+
```
|
|
74
|
+
## Execution Summary
|
|
75
|
+
|
|
76
|
+
**Plan:** [path to plan file]
|
|
77
|
+
**Status:** ✅ Complete | ⚠️ Partial | ❌ Blocked
|
|
78
|
+
|
|
79
|
+
### Tasks Completed
|
|
80
|
+
- [x] Task 1: [description]
|
|
81
|
+
- [x] Task 2: [description]
|
|
82
|
+
- [ ] Task 3: [description — if skipped, explain why]
|
|
83
|
+
|
|
84
|
+
### Validation Results
|
|
85
|
+
- Level 1 Lint: ✅ / ❌
|
|
86
|
+
- Level 2 Type Check: ✅ / ❌
|
|
87
|
+
- Level 3 Unit Tests: ✅ [X passed] / ❌ [X failed]
|
|
88
|
+
- Level 4 Integration:✅ / ❌
|
|
89
|
+
- Level 5 Human: 🔍 See items below
|
|
90
|
+
|
|
91
|
+
### For Human Review
|
|
92
|
+
- [specific thing to verify manually]
|
|
93
|
+
|
|
94
|
+
### Deviations from Plan
|
|
95
|
+
- [anything that differed from the plan and why]
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
## Step 6: Suggest Next Steps
|
|
99
|
+
|
|
100
|
+
After the summary, suggest:
|
|
101
|
+
1. Run `/execution-report` to document this implementation for system review
|
|
102
|
+
2. Run `/code-review` for a technical quality check
|
|
103
|
+
3. Run `/commit` once everything is approved
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Generate an implementation report for system review
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Review and document the implementation you just completed. Run this immediately after finishing a feature — before committing or starting the next task.
|
|
6
|
+
|
|
7
|
+
## Step 1: Gather Implementation Data
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
git diff HEAD --stat
|
|
11
|
+
git diff HEAD
|
|
12
|
+
git ls-files --others --exclude-standard
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
## Step 2: Generate Report
|
|
16
|
+
|
|
17
|
+
Save to: `.agents/execution-reports/[feature-name].md`
|
|
18
|
+
|
|
19
|
+
Use the following structure:
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
### Meta Information
|
|
24
|
+
|
|
25
|
+
- **Plan file:** [path to the plan that guided this implementation]
|
|
26
|
+
- **Files added:** [list with paths]
|
|
27
|
+
- **Files modified:** [list with paths]
|
|
28
|
+
- **Lines changed:** +X -Y
|
|
29
|
+
|
|
30
|
+
### Validation Results
|
|
31
|
+
|
|
32
|
+
- Syntax & Linting: ✓/✗ [details if failed]
|
|
33
|
+
- Type Checking: ✓/✗ [details if failed]
|
|
34
|
+
- Unit Tests: ✓/✗ [X passed, Y failed]
|
|
35
|
+
- Integration Tests: ✓/✗ [X passed, Y failed]
|
|
36
|
+
|
|
37
|
+
### What Went Well
|
|
38
|
+
|
|
39
|
+
List specific things that worked smoothly:
|
|
40
|
+
- [concrete examples]
|
|
41
|
+
|
|
42
|
+
### Challenges Encountered
|
|
43
|
+
|
|
44
|
+
List specific difficulties encountered:
|
|
45
|
+
- [what was difficult and why]
|
|
46
|
+
|
|
47
|
+
### Divergences from Plan
|
|
48
|
+
|
|
49
|
+
For each divergence from the original plan:
|
|
50
|
+
|
|
51
|
+
**[Divergence Title]**
|
|
52
|
+
- **Planned:** [what the plan specified]
|
|
53
|
+
- **Actual:** [what was implemented instead]
|
|
54
|
+
- **Reason:** [why this divergence occurred]
|
|
55
|
+
- **Type:** Better approach found | Plan assumption wrong | Security concern | Performance issue | Other
|
|
56
|
+
|
|
57
|
+
### Skipped Items
|
|
58
|
+
|
|
59
|
+
List anything from the plan that was not implemented:
|
|
60
|
+
- [what was skipped] — Reason: [why]
|
|
61
|
+
|
|
62
|
+
### Recommendations
|
|
63
|
+
|
|
64
|
+
Based on this implementation, what should change for next time?
|
|
65
|
+
- Plan command improvements: [suggestions]
|
|
66
|
+
- Execute command improvements: [suggestions]
|
|
67
|
+
- CLAUDE.md additions: [suggestions]
|
|
@@ -0,0 +1,136 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Research the codebase and create a structured implementation plan from requirements
|
|
3
|
+
argument-hint: "<feature-name-or-description>"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Transform the requirements discussed in this conversation into a structured plan that another agent can execute without access to this conversation.
|
|
7
|
+
|
|
8
|
+
## Phase 1: Understand the Requirements
|
|
9
|
+
|
|
10
|
+
Review the current conversation to extract:
|
|
11
|
+
- What feature or change is being requested?
|
|
12
|
+
- What is the expected behavior from the user's perspective?
|
|
13
|
+
- Are there any explicit constraints or preferences mentioned?
|
|
14
|
+
- What is out of scope?
|
|
15
|
+
|
|
16
|
+
If anything is ambiguous, ask clarifying questions **before** proceeding to research.
|
|
17
|
+
|
|
18
|
+
## Phase 2: Load Project Context
|
|
19
|
+
|
|
20
|
+
Read the following to understand the project:
|
|
21
|
+
|
|
22
|
+
1. `CLAUDE.md` or `AGENTS.md` at project root — architecture rules, patterns, constraints
|
|
23
|
+
2. `README.md` — project overview and setup
|
|
24
|
+
3. `package.json` or `pyproject.toml` — stack, dependencies, scripts
|
|
25
|
+
|
|
26
|
+
Then run:
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
git branch --show-current
|
|
30
|
+
git log --oneline -10
|
|
31
|
+
git status
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## Phase 3: Research the Codebase
|
|
35
|
+
|
|
36
|
+
Investigate the areas of the codebase relevant to this feature:
|
|
37
|
+
|
|
38
|
+
- Find existing files and modules related to the feature
|
|
39
|
+
- Identify the patterns already used (naming, structure, data flow)
|
|
40
|
+
- Locate similar features already implemented to use as reference
|
|
41
|
+
- Find the entry points that will need to be modified or extended
|
|
42
|
+
- Identify potential conflicts or dependencies
|
|
43
|
+
|
|
44
|
+
```bash
|
|
45
|
+
git ls-files | grep -i <relevant-keyword>
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
Read the key files in their entirety — not just the parts that seem relevant.
|
|
49
|
+
|
|
50
|
+
## Phase 4: Design the Approach
|
|
51
|
+
|
|
52
|
+
Based on research, define:
|
|
53
|
+
- What files will be created vs. modified
|
|
54
|
+
- What pattern to follow (based on existing codebase conventions)
|
|
55
|
+
- What the data flow looks like end-to-end
|
|
56
|
+
- Any risks, edge cases, or gotchas to flag
|
|
57
|
+
- What tests are needed
|
|
58
|
+
|
|
59
|
+
## Phase 5: Generate the Plan
|
|
60
|
+
|
|
61
|
+
Save the plan to: `.agents/plans/[kebab-case-feature-name].md`
|
|
62
|
+
|
|
63
|
+
Use this structure:
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
```markdown
|
|
68
|
+
# Plan: [Feature Name]
|
|
69
|
+
|
|
70
|
+
## Overview
|
|
71
|
+
[2-3 sentences describing what this feature does and why]
|
|
72
|
+
|
|
73
|
+
## Requirements Summary
|
|
74
|
+
- [Bullet list of requirements extracted from the discussion]
|
|
75
|
+
|
|
76
|
+
## Out of Scope
|
|
77
|
+
- [Anything explicitly excluded]
|
|
78
|
+
|
|
79
|
+
## Context References
|
|
80
|
+
Key files the executing agent must read before starting:
|
|
81
|
+
- `[path/to/file]` — [why it's relevant]
|
|
82
|
+
- `[path/to/file]` — [why it's relevant]
|
|
83
|
+
|
|
84
|
+
## Implementation Tasks
|
|
85
|
+
|
|
86
|
+
### Task 1: [Action verb + what]
|
|
87
|
+
- **Action:** [Specific action: create / modify / delete]
|
|
88
|
+
- **File:** `[exact file path]`
|
|
89
|
+
- **Pattern:** Follow the same pattern as `[reference file]`
|
|
90
|
+
- **Details:** [Exact description of what to implement]
|
|
91
|
+
- **Gotcha:** [Known pitfall or constraint to watch for]
|
|
92
|
+
- **Validate:** [How to verify this task is done correctly]
|
|
93
|
+
|
|
94
|
+
### Task 2: [Action verb + what]
|
|
95
|
+
[Same structure]
|
|
96
|
+
|
|
97
|
+
[Continue for all tasks...]
|
|
98
|
+
|
|
99
|
+
## Validation Checklist
|
|
100
|
+
|
|
101
|
+
Run in this order — do not proceed if a level fails:
|
|
102
|
+
|
|
103
|
+
- [ ] **Level 1 — Lint & Format:** `[project lint command]`
|
|
104
|
+
- [ ] **Level 2 — Type Check:** `[project type check command]`
|
|
105
|
+
- [ ] **Level 3 — Unit Tests:** `[project unit test command]`
|
|
106
|
+
- [ ] **Level 4 — Integration Tests:** `[project integration test or manual curl/check]`
|
|
107
|
+
- [ ] **Level 5 — Human Review:** Verify behavior matches requirements above
|
|
108
|
+
|
|
109
|
+
## Acceptance Criteria
|
|
110
|
+
- [ ] [Specific, testable criterion]
|
|
111
|
+
- [ ] [Specific, testable criterion]
|
|
112
|
+
- [ ] [Specific, testable criterion]
|
|
113
|
+
|
|
114
|
+
## Notes for Executing Agent
|
|
115
|
+
[Any important context, warnings, or decisions made during planning that the executing agent needs to know]
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
## Phase 6: Verify the Plan
|
|
121
|
+
|
|
122
|
+
Before finishing, review the plan against these criteria:
|
|
123
|
+
|
|
124
|
+
- [ ] Every task has a specific file path (no vague "update the component")
|
|
125
|
+
- [ ] Every task references an existing pattern to follow
|
|
126
|
+
- [ ] Validation commands match the actual project scripts
|
|
127
|
+
- [ ] The plan is complete enough that another agent can execute it without this conversation
|
|
128
|
+
- [ ] No ambiguous requirements left unresolved
|
|
129
|
+
|
|
130
|
+
## Final Output
|
|
131
|
+
|
|
132
|
+
Confirm to the user:
|
|
133
|
+
- Plan saved to: `.agents/plans/[feature-name].md`
|
|
134
|
+
- Summary of tasks included
|
|
135
|
+
- Any open questions or decisions that require human confirmation before execution
|
|
136
|
+
- Suggest running `/commit` to save the plan to the repository
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Load project context at the start of a session
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Get oriented in this project before doing any work.
|
|
6
|
+
|
|
7
|
+
## Step 1: Project Structure
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
git ls-files | head -60
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
```bash
|
|
14
|
+
find . -name "CLAUDE.md" -o -name "AGENTS.md" -o -name "README.md" | head -10
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
## Step 2: Read Key Files
|
|
18
|
+
|
|
19
|
+
Read in this order:
|
|
20
|
+
1. `CLAUDE.md` or `AGENTS.md` at project root (project-specific rules)
|
|
21
|
+
2. `README.md` (project overview)
|
|
22
|
+
3. `package.json` or `pyproject.toml` (dependencies and scripts)
|
|
23
|
+
|
|
24
|
+
## Step 3: Understand Git State
|
|
25
|
+
|
|
26
|
+
```bash
|
|
27
|
+
git branch --show-current
|
|
28
|
+
git log --oneline -10
|
|
29
|
+
git status
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
## Step 4: Summary Report
|
|
33
|
+
|
|
34
|
+
Provide a concise summary with:
|
|
35
|
+
|
|
36
|
+
**Project:** [name and purpose in one sentence]
|
|
37
|
+
**Stack:** [languages, frameworks, key libraries]
|
|
38
|
+
**Current branch:** [branch name and what it's for]
|
|
39
|
+
**Key structure:** [main folders and their purpose]
|
|
40
|
+
**Useful commands:** [how to run, test, build]
|
|
41
|
+
**Git status:** [clean / changes pending / uncommitted files]
|
|
42
|
+
|
|
43
|
+
Keep it scannable — this is for human review in under 30 seconds.
|
|
@@ -0,0 +1,139 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Analyze implementation against plan to find process improvements
|
|
3
|
+
argument-hint: "<plan-file> <execution-report-file>"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Perform a meta-level analysis of how well the implementation followed the plan. This is NOT code review — you're looking for bugs in the process, not the code.
|
|
7
|
+
|
|
8
|
+
## Inputs
|
|
9
|
+
|
|
10
|
+
- **$1** — Path to the structured plan file
|
|
11
|
+
- **$2** — Path to the execution report file
|
|
12
|
+
|
|
13
|
+
## Step 1: Load All Context
|
|
14
|
+
|
|
15
|
+
Read these four artifacts in order:
|
|
16
|
+
|
|
17
|
+
1. `.claude/commands/plan-feature.md` — understand how plans are created
|
|
18
|
+
2. **$1** (the plan) — what the agent was supposed to do
|
|
19
|
+
3. `.claude/commands/execute.md` — understand how execution is guided
|
|
20
|
+
4. **$2** (the execution report) — what the agent actually did and why
|
|
21
|
+
|
|
22
|
+
## Step 2: Understand the Planned Approach
|
|
23
|
+
|
|
24
|
+
From the plan ($1), extract:
|
|
25
|
+
- What features were planned?
|
|
26
|
+
- What architecture was specified?
|
|
27
|
+
- What validation steps were defined?
|
|
28
|
+
- What patterns or constraints were referenced?
|
|
29
|
+
|
|
30
|
+
## Step 3: Understand the Actual Implementation
|
|
31
|
+
|
|
32
|
+
From the execution report ($2), extract:
|
|
33
|
+
- What was actually implemented?
|
|
34
|
+
- What diverged from the plan?
|
|
35
|
+
- What challenges were encountered?
|
|
36
|
+
- What was skipped and why?
|
|
37
|
+
|
|
38
|
+
## Step 4: Classify Each Divergence
|
|
39
|
+
|
|
40
|
+
For each divergence, classify as:
|
|
41
|
+
|
|
42
|
+
**Good Divergence ✅** (justified):
|
|
43
|
+
- Plan assumed something that didn't exist in the codebase
|
|
44
|
+
- Better pattern discovered during implementation
|
|
45
|
+
- Performance optimization was needed
|
|
46
|
+
- Security issue required a different approach
|
|
47
|
+
|
|
48
|
+
**Bad Divergence ❌** (problematic):
|
|
49
|
+
- Ignored explicit constraints from the plan
|
|
50
|
+
- Created new architecture instead of following existing patterns
|
|
51
|
+
- Took shortcuts that introduce tech debt
|
|
52
|
+
- Misunderstood requirements
|
|
53
|
+
|
|
54
|
+
## Step 5: Trace Root Causes
|
|
55
|
+
|
|
56
|
+
For each problematic divergence, identify the root cause:
|
|
57
|
+
- Was the plan unclear? Where and why?
|
|
58
|
+
- Was context missing? Where and why?
|
|
59
|
+
- Was a validation step missing?
|
|
60
|
+
- Was a manual step repeated that should be automated?
|
|
61
|
+
|
|
62
|
+
## Step 6: Generate Process Improvements
|
|
63
|
+
|
|
64
|
+
Suggest specific actions based on patterns found:
|
|
65
|
+
|
|
66
|
+
- **CLAUDE.md updates** — universal patterns or anti-patterns to document
|
|
67
|
+
- **Plan command updates** — instructions that need clarification or missing steps
|
|
68
|
+
- **Execute command updates** — steps to add to the execution checklist
|
|
69
|
+
- **New commands** — manual processes repeated 3+ times that should be automated
|
|
70
|
+
|
|
71
|
+
## Output Format
|
|
72
|
+
|
|
73
|
+
Save to: `.agents/system-reviews/[feature-name]-review.md`
|
|
74
|
+
|
|
75
|
+
---
|
|
76
|
+
|
|
77
|
+
### Meta Information
|
|
78
|
+
- Plan reviewed: [path to $1]
|
|
79
|
+
- Execution report: [path to $2]
|
|
80
|
+
- Date: [current date]
|
|
81
|
+
|
|
82
|
+
### Overall Alignment Score: __/10
|
|
83
|
+
|
|
84
|
+
- **10** — Perfect adherence, all divergences justified
|
|
85
|
+
- **7–9** — Minor justified divergences
|
|
86
|
+
- **4–6** — Mix of justified and problematic divergences
|
|
87
|
+
- **1–3** — Major problematic divergences
|
|
88
|
+
|
|
89
|
+
### Divergence Analysis
|
|
90
|
+
|
|
91
|
+
For each divergence:
|
|
92
|
+
```yaml
|
|
93
|
+
divergence: [what changed]
|
|
94
|
+
planned: [what plan specified]
|
|
95
|
+
actual: [what was implemented]
|
|
96
|
+
reason: [agent's stated reason]
|
|
97
|
+
classification: good ✅ | bad ❌
|
|
98
|
+
root_cause: [unclear plan | missing context | missing validation | other]
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
### Pattern Compliance
|
|
102
|
+
- [ ] Followed codebase architecture
|
|
103
|
+
- [ ] Used patterns documented in CLAUDE.md
|
|
104
|
+
- [ ] Applied testing patterns correctly
|
|
105
|
+
- [ ] Met validation requirements
|
|
106
|
+
|
|
107
|
+
### System Improvement Actions
|
|
108
|
+
|
|
109
|
+
**Update CLAUDE.md:**
|
|
110
|
+
- [ ] [specific addition or change]
|
|
111
|
+
|
|
112
|
+
**Update Plan Command:**
|
|
113
|
+
- [ ] [specific addition or change]
|
|
114
|
+
|
|
115
|
+
**Update Execute Command:**
|
|
116
|
+
- [ ] [specific addition or change]
|
|
117
|
+
|
|
118
|
+
**Create New Command:**
|
|
119
|
+
- [ ] `/[command-name]` — [what it automates]
|
|
120
|
+
|
|
121
|
+
### Key Learnings
|
|
122
|
+
|
|
123
|
+
**What worked well:** [specific things]
|
|
124
|
+
**What needs improvement:** [specific process gaps]
|
|
125
|
+
**For next implementation:** [concrete changes to try]
|
|
126
|
+
|
|
127
|
+
---
|
|
128
|
+
|
|
129
|
+
## Decision Framework — When to Update What
|
|
130
|
+
|
|
131
|
+
After the analysis, use this to prioritize actions:
|
|
132
|
+
|
|
133
|
+
| Pattern | Action |
|
|
134
|
+
|---|---|
|
|
135
|
+
| Issue happens across ALL features | Update CLAUDE.md |
|
|
136
|
+
| Issue happens for a CLASS of features | Update on-demand reference guide or command |
|
|
137
|
+
| Same manual step done 3+ times | Create a new command |
|
|
138
|
+
| Plan was ambiguous in the same spot twice | Update plan-feature command |
|
|
139
|
+
| First time seeing this issue | Note it, don't over-engineer yet |
|
package/package.json
ADDED
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@hopla/claude-setup",
|
|
3
|
+
"version": "1.0.0",
|
|
4
|
+
"description": "Hopla team agentic coding system for Claude Code",
|
|
5
|
+
"type": "module",
|
|
6
|
+
"bin": {
|
|
7
|
+
"claude-setup": "./cli.js"
|
|
8
|
+
},
|
|
9
|
+
"files": [
|
|
10
|
+
"cli.js",
|
|
11
|
+
"files/"
|
|
12
|
+
],
|
|
13
|
+
"engines": {
|
|
14
|
+
"node": ">=18"
|
|
15
|
+
},
|
|
16
|
+
"publishConfig": {
|
|
17
|
+
"access": "public"
|
|
18
|
+
},
|
|
19
|
+
"keywords": [
|
|
20
|
+
"claude",
|
|
21
|
+
"claude-code",
|
|
22
|
+
"agentic",
|
|
23
|
+
"hopla"
|
|
24
|
+
],
|
|
25
|
+
"author": "Hopla Tools",
|
|
26
|
+
"license": "MIT"
|
|
27
|
+
}
|