@hopla/claude-setup 1.0.3 → 1.0.5

package/cli.js

@@ -90,6 +90,36 @@ async function uninstall() {
     log(`\n${GREEN}${BOLD}Done!${RESET} Files removed.\n`);
 }
 
+const LEGACY_FILES = [
+    "code-review-fix.md",
+    "code-review.md",
+    "commit.md",
+    "create-prd.md",
+    "execute.md",
+    "execution-report.md",
+    "plan-feature.md",
+    "prime.md",
+    "system-review.md",
+];
+
+function removeLegacyFiles() {
+    const removed = [];
+    for (const file of LEGACY_FILES) {
+        const dest = path.join(COMMANDS_DIR, file);
+        if (fs.existsSync(dest)) {
+            fs.rmSync(dest);
+            removed.push(file);
+        }
+    }
+    if (removed.length > 0) {
+        log(`${CYAN}Cleaning up legacy commands...${RESET}`);
+        for (const file of removed) {
+            log(`  ${YELLOW}↷${RESET}  Removed legacy: ~/.claude/commands/${file}`);
+        }
+        log("");
+    }
+}
+
 async function install() {
     log(`\n${BOLD}@hopla/claude-setup${RESET} — Agentic Coding System\n`);
 
@@ -97,6 +127,9 @@ async function install() {
     fs.mkdirSync(CLAUDE_DIR, { recursive: true });
     fs.mkdirSync(COMMANDS_DIR, { recursive: true });
 
+    // Remove old non-prefixed commands from previous versions
+    removeLegacyFiles();
+
     log(`${CYAN}Installing global rules...${RESET}`);
     await installFile(
         path.join(FILES_DIR, "CLAUDE.md"),

package/files/commands/hopla-create-prd.md

@@ -0,0 +1,202 @@
+---
+description: Create a Product Requirements Document (PRD) for a project through guided questions
+---
+
+Create a PRD for this project following the Layer 1 Planning approach: an exploratory conversation that defines scope, reduces assumptions, and generates both a `PRD.md` and supporting on-demand context documents.
+
+> Layer 1 Planning = Global Rules + On-Demand Context + PRD
+
+## Step 1: Load Existing Context
+
+Before asking anything, read what already exists:
+- `CLAUDE.md` or `AGENTS.md` — extract product name, tech stack, business context
+- `README.md` — extract any existing product description
+- Any existing `PRD.md` — understand what's already defined
+
+Use this to avoid asking questions that are already answered.
+
+## Step 2: Detect Project Mode
+
+Before starting the conversation, determine which mode to use based on what exists:
+
+**Greenfield mode** (project is new or nearly empty):
+- No significant source code found
+- No existing architecture or stack decisions
+- Proceed with the full exploratory conversation below
+
+**Existing project mode** (project has code, structure, or a prior PRD):
+- Source code, architecture, or stack already exist
+- Skip feasibility and stack topics — read the code instead
+- Focus the conversation only on gaps: what's undocumented, what's next, what's changing
+- Announce to the user: "I can see this project already has code. I'll read the existing structure first and only ask about what's missing or unclear."
+
+---
+
+### Greenfield Mode — Full Exploratory Conversation
+
+Start with an informal, open-ended exploration — not a rigid questionnaire. The goal is to understand the project deeply before structuring anything.
+
+Ask one topic at a time and wait for the answer before continuing. Adapt follow-up questions based on the answers — this is a conversation, not a form.
+
+**Topic A — The Product Vision**
+- What is this product? Describe it as if explaining to someone who has never heard of it.
+- What problem does it solve? What was the situation before this product existed?
+- What is the MVP goal — the minimum that makes this useful?
+
+**Topic B — The Users**
+- Who are the primary users? (role, context, technical level)
+- How and how often do they use it?
+
+**Topic C — Feasibility & Stack**
+- What technology stack are you thinking? Any hard constraints or preferences?
+- Are there existing integrations, APIs, or services this must work with?
+- What are the biggest technical risks or unknowns?
+
+**Topic D — Scope**
+- What are the 3-5 core features the MVP must have?
+- What is explicitly OUT of scope for the MVP? (things users might expect but won't be built)
+
+**Topic E — Architecture & Key Decisions**
+- What architectural pattern makes sense for this? (e.g., monolith, microservices, vertical slices)
+- Are there key technical decisions that need to be made upfront? (e.g., auth approach, data model, tool design)
+- Are there external resources, docs, or best practices we should factor in?
+
+**Topic F — Success**
+- How do you know the MVP is working well? What are the measurable success criteria?
+
+---
+
+### Existing Project Mode — Documentation Conversation
+
+First, explore the codebase to understand what's already built:
+
+```bash
+git ls-files | head -60
+git log --oneline -10
+```
+
+Read key files: entry points, main modules, config files, existing tests.
+
+Then ask only about what's unclear or missing after reading the code:
+
+**Topic A — Confirm Understanding**
+- "Based on what I've read, this project does X using Y. Is that accurate?"
+- Correct any misunderstandings before continuing.
+
+**Topic B — Scope Gaps**
+- What features are planned but not yet built?
+- What is explicitly out of scope going forward?
+
+**Topic C — Users (if not documented)**
+- Who uses this? What's their technical level and usage pattern?
+
+**Topic D — Success**
+- How do you measure whether this project is working well?
+
+## Step 3: Extract On-Demand Context Documents
+
+After the conversation, identify technical decisions complex enough to warrant their own document. For each one, create a separate file in the project root or a `docs/` folder.
+
+Common examples:
+- `mvp-tool-designs.md` — detailed tool/API specifications
+- `architecture-decisions.md` — key architectural decisions and rationale
+- `data-model.md` — core entities and relationships
+
+These become **on-demand context** referenced from the PRD and used in future planning commands.
+
+## Step 4: Generate the PRD
+
+Save to `PRD.md` at the project root. Use this structure:
+
+```markdown
+# PRD — [Product Name]
+
+## Executive Summary
+
+[2-3 sentences: what it does, who it's for, and why it exists.]
+
+## Mission
+
+[What this product aims to achieve. Include core principles if relevant.]
+
+## Problem
+
+[What problem does this solve? What was the situation before this product?]
+
+## Target Users
+
+**Primary users:** [Role and context]
+**Technical level:** [Technical comfort expected]
+**Usage pattern:** [How often and in what context they use it]
+
+## MVP Scope
+
+### In Scope
+- [Feature/capability 1]
+- [Feature/capability 2]
+- [Feature/capability 3]
+
+### Out of Scope
+- [Thing 1 — why it's excluded]
+- [Thing 2 — why it's excluded]
+
+## User Stories
+
+1. **As a [user], I want to [action]**, so that [outcome].
+   - Example: "[concrete usage example]"
+
+[Add the most important 3-5 user stories]
+
+## Core Architecture & Patterns
+
+[Describe the chosen architecture, key patterns, and rationale. Reference on-demand context docs for details.]
+
+## Technology Stack
+
+- **[Layer/role]:** [Technology and version]
+- **[Layer/role]:** [Technology and version]
+
+## Success Criteria
+
+The MVP is working when:
+- [ ] [Specific, testable criterion]
+- [ ] [Specific, testable criterion]
+- [ ] [Specific, testable criterion]
+
+## Implementation Phases
+
+### Phase 1: [Name] — Goal: [one line]
+- [ ] [Deliverable]
+- [ ] [Deliverable]
+**Validation:** [How to know this phase is done]
+
+### Phase 2: [Name] — Goal: [one line]
+[Same structure]
+
+## Risks & Mitigations
+
+| Risk | Mitigation |
+|------|------------|
+| [Risk 1] | [How to address it] |
+| [Risk 2] | [How to address it] |
+
+## Future Considerations (Post-MVP)
+
+- [Enhancement 1]
+- [Enhancement 2]
+
+## Related Documents
+
+- [on-demand context doc] — [what it contains]
+```
+
+## Step 5: Confirm and Save
+
+Show the draft PRD to the user and ask:
+> "Does this accurately reflect the product? Any corrections before I save it?"
+
+Once confirmed:
+1. Save `PRD.md` to the project root
+2. Save any on-demand context documents created in Step 3
+3. List all files created
+4. Suggest running `/hopla-commit` to save everything to the repository

package/files/commands/{prime.md → hopla-prime.md}

@@ -31,13 +31,12 @@ git status
 
 ## Step 4: Summary Report
 
-Provide a concise summary with:
+Write a short, conversational message (2-4 sentences) addressed directly to the user. Mention:
+- What the project is and what it does
+- The current branch and what it's for
+- Whether there are uncommitted changes or pending work
+- The command to start the project (if available)
 
-**Project:** [name and purpose in one sentence]
-**Stack:** [languages, frameworks, key libraries]
-**Current branch:** [branch name and what it's for]
-**Key structure:** [main folders and their purpose]
-**Useful commands:** [how to run, test, build]
-**Git status:** [clean / changes pending / uncommitted files]
+End with a sentence like: "Listo para continuar — ¿por dónde empezamos?" or "All caught up — what are we working on today?" depending on the language the user writes in.
 
-Keep it scannable — this is for human review in under 30 seconds.
+Do NOT use headers, labels, or bullet points in this final message. Write it as natural, friendly prose.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hopla/claude-setup",
-  "version": "1.0.3",
+  "version": "1.0.5",
   "description": "Hopla team agentic coding system for Claude Code",
   "type": "module",
   "bin": {

package/files/commands/create-prd.md

@@ -1,85 +0,0 @@
----
-description: Create a Product Requirements Document (PRD) for a project through guided questions
----
-
-Create a PRD for this project by gathering the necessary information through a structured conversation.
-
-## Step 1: Gather Context
-
-Before asking questions, read what already exists:
-- `CLAUDE.md` or `AGENTS.md` — extract product name, tech stack, and any business context
-- `README.md` — extract any existing product description
-
-Use this to avoid asking questions that are already answered.
-
-## Step 2: Ask Key Questions
-
-Ask the following questions **one section at a time** — do not dump all questions at once. Wait for the answer before continuing.
-
-**Section A — The Product**
-1. In 1-2 sentences, what does this product do?
-2. What problem does it solve? What was happening before this product existed?
-
-**Section B — The Users**
-3. Who are the primary users? (role, context, technical level)
-4. How do they use it? (daily, weekly, ad-hoc?)
-
-**Section C — Scope**
-5. What are the 3-5 most important features the product must have?
-6. What is explicitly OUT of scope? (things users might expect but won't be built)
-
-**Section D — Success**
-7. How do you know the product is working well? (key outcomes or metrics)
-
-## Step 3: Generate the PRD
-
-Once all questions are answered, generate the PRD and save it to `PRD.md` at the project root.
-
-Use this structure:
-
----
-
-```markdown
-# PRD — [Product Name]
-
-## What is it?
-
-[2-3 sentence executive summary. What it does, who it's for, and why it exists.]
-
-## Problem
-
-[What problem does this solve? What was the situation before this product?]
-
-## Users
-
-**Primary users:** [Role and context]
-**Usage pattern:** [How often and in what context they use it]
-
-## Core Features (In Scope)
-
-- [Feature 1 — one line description]
-- [Feature 2 — one line description]
-- [Feature 3 — one line description]
-[Add as many as needed]
-
-## Out of Scope
-
-These are explicitly NOT part of this product:
-- [Thing 1 — why it's excluded]
-- [Thing 2 — why it's excluded]
-
-## Success Criteria
-
-The product is working well when:
-- [Measurable outcome 1]
-- [Measurable outcome 2]
-```
-
----
-
-## Step 4: Confirm and Save
-
-Show the draft PRD to the user and ask:
-> "Does this accurately reflect the product? Any corrections before I save it?"
-
-Once confirmed, save to `PRD.md` and suggest running `/commit` to add it to the repository.