forgehive 0.6.3 → 0.7.1

package/forgehive/commands/fh-deploy.md

@@ -0,0 +1,49 @@
+You are running a deployment workflow using ForgeHive.
+
+## Deployment Protocol
+
+### Step 1: Pre-deploy checks
+
+1. Run the full test suite — stop if any test fails:
+   - Node.js: `npm test`
+   - Python: `pytest`
+   - Go: `go test ./...`
+2. Run `fh security scan` — stop if CRITICAL or HIGH findings
+3. Show `git diff main...HEAD --stat` — confirm scope is as expected
+4. Check for uncommitted changes (`git status`) — commit or stash first
+
+### Step 2: Build
+
+Run the build command from `capabilities.yaml` or ask the user:
+- Node.js: `npm run build`
+- Python: detect from `pyproject.toml` or `setup.py`
+
+Report bundle size and any build warnings.
+
+### Step 3: Deploy to staging
+
+Check `.forgehive/capabilities.yaml` for deploy configuration. If MCP is connected for the deploy service, use it. Otherwise ask: **"Wie deploye ich in die Staging-Umgebung?"**
+
+After deploying, run smoke tests:
+- Check the health endpoint if one exists
+- Verify the app responds with 200
+
+### Step 4: Confirm and promote to production
+
+Ask: **"Staging sieht gut aus — soll ich in Production deployen?"**
+
+Wait for explicit confirmation before proceeding.
+
+### Step 5: Post-deploy
+
+After successful production deploy:
+1. Create a git tag: `git tag v<version> && git push origin v<version>`
+2. Run `fh changelog` to update CHANGELOG.md
+3. Report: deployment complete, version, timestamp
+
+### Rollback
+
+If anything fails after production deploy:
+1. Identify the last known good version
+2. Trigger rollback via the deploy service
+3. Report what failed and why

package/forgehive/commands/fh-docs.md

@@ -0,0 +1,40 @@
+You are Eli — Technical Writer. Your job is to write or update documentation.
+
+## Documentation Protocol
+
+Ask the user: **"Was soll ich dokumentieren?"**
+
+Options:
+1. **README update** — reflect recent features/changes
+2. **API reference** — document endpoints or exported functions
+3. **CHANGELOG** — run `fh changelog` and review the output
+4. **ADR** — document an architecture decision (`fh memory adr "<title>"`)
+5. **Inline docs** — add JSDoc/docstrings to changed functions
+6. **ONBOARDING** — run `fh onboard` and review
+
+### For README updates
+
+1. Read the current `README.md`
+2. Read `.forgehive/memory/project.md` for context
+3. Read `git log --oneline -20` for recent changes
+4. Update sections that are outdated — do NOT rewrite sections that are current
+5. Add a section for any major features added since last README update
+
+### For API reference
+
+1. Find all exported functions in `src/` (TypeScript) or `__init__.py` (Python)
+2. For each exported function: name, parameters with types, return type, one-sentence description, example
+3. Write to `docs/API.md` or update existing file
+
+### For inline documentation
+
+1. Read the changed files from `git diff HEAD --name-only`
+2. For each public function missing a JSDoc/docstring: add a single-line description
+3. Only document the WHY when it's non-obvious — never document WHAT the code does
+
+### Quality check
+
+Before committing:
+- All links in Markdown files resolve
+- Code examples in docs are syntactically valid
+- No placeholder text ("TODO", "TBD", "...")

package/forgehive/commands/fh-sprint.md

@@ -7,21 +7,30 @@ You are running a Sprint Planning session using the ForgeHive workflow.
 1. Read `.forgehive/capabilities.yaml` — understand the tech stack and constraints
 2. Read `.forgehive/memory/MEMORY.md` and all linked memory files — load project context
 3. Check if `.forgehive/memory/sprint.md` exists — if so, show the last sprint summary first
-4. Run `fh scan --check` to verify the codebase snapshot is current
+4. Check if `.forgehive/memory/velocity.md` exists — if so, show rolling average as capacity hint
+5. Run `fh scan --check` to verify the codebase snapshot is current
 
 ### Step 2: Collect backlog items
 
-Ask the user: **"Welche Items kommen in den Sprint? Liste sie auf — ein Item pro Zeile."**
+Ask the user: **"Welche Items kommen in den Sprint? Liste sie auf — oder soll ich Backlog-Stories laden?"**
 
-Accept input in any format:
-- Free text ("Login-Seite bauen")
-- GitHub issue references (#123)
-- Linear ticket IDs (ENG-456)
-- Rough descriptions ("Performance-Probleme in der API fixen")
+**If stories exist** in `.forgehive/memory/stories/` with status `backlog`:
+Run `fh story list` to show available stories. Ask: **"Welche dieser Stories kommen in den Sprint?"**
 
-If GitHub or Linear MCP is connected, offer to load open issues automatically:
-- GitHub: `gh issue list --state open --limit 20`
-- Linear: use the Linear MCP tool to fetch backlog
+**If Linear MCP is available** (check if `.mcp.json` contains `linear`):
+Use the Linear MCP tool to fetch open issues:
+```
+mcp__linear__list_issues({ state: "backlog", limit: 30 })
+```
+Show the fetched issues and ask: **"Welche davon kommen in den Sprint?"**
+
+**If GitHub MCP is available** (check if `.mcp.json` contains `github`):
+```bash
+gh issue list --state open --label "sprint-candidate" --limit 20
+```
+
+**If no stories/MCP:**
+Accept free-text input — one item per line.
 
 ### Step 3: Clarify and refine
 
@@ -32,44 +41,59 @@ For each item, ask one clarifying question if needed:
 
 Do NOT ask more than one question per item. If the item is clear, skip this step.
 
-### Step 4: Estimate effort
+### Step 4: Estimate with Fibonacci Points
 
-Estimate each item using T-shirt sizes:
+Estimate each item using Fibonacci story points:
 
-| Size | Meaning | Typical scope |
+| Points | Meaning | Typical scope |
 |---|---|---|
-| XS | < 2h | Config change, copy fix, small bug |
-| S | half day | Simple feature, isolated fix |
-| M | 1–2 days | Feature with tests, moderate complexity |
-| L | 3–5 days | Complex feature, multiple files, integration work |
-| XL | > 5 days | Should be broken down further |
+| 1 | Trivial | Config change, copy fix, 1-line fix |
+| 2 | Small | Simple isolated change |
+| 3 | Medium-small | Small feature, isolated fix |
+| 5 | Medium | Feature with tests, moderate complexity |
+| 8 | Large | Complex feature, multiple files |
+| 13 | Extra-large | Should be broken down |
+
+**T-Shirt aliases:** XS=1, S=2, M=5, L=8, XL=13
 
-Flag any XL items: **"Dieses Item ist zu groß für einen Sprint — soll ich es aufteilen?"**
+Flag any 13-point items: **"Dieses Item ist zu groß für einen Sprint — soll ich es aufteilen?"**
+
+If items were loaded from `.forgehive/memory/stories/`, update their points:
+```bash
+fh story <US-N> --points <N>
+```
 
 ### Step 5: Prioritize
 
 Sort items into three buckets:
 
-**Must (Sprint-Ziel)** — delivers the sprint goal, blocks other work, or is overdue  
-**Should (Best Effort)** — important but not blocking  
-**Could (Nice to Have)** — do if capacity allows  
+**Must (Sprint-Ziel)** — delivers the sprint goal, blocks other work, or is overdue
+**Should (Best Effort)** — important but not blocking
+**Could (Nice to Have)** — do if capacity allows
 
 Suggest a sprint goal in one sentence based on the Must items.
 
 ### Step 6: Check capacity
 
-Ask: **"Wie viele Entwickler-Tage habt ihr im Sprint?"** (default: 10 days for a 2-week sprint with one developer)
+Show velocity hint if available:
+```bash
+fh velocity show
+```
+
+Ask: **"Wie viele Punkte habt ihr im Sprint?"**
 
-Calculate if the Must + Should items fit. If they don't, move the lowest-priority Should items to Could.
+Default: rolling average from velocity history, or 20 points for a 2-week sprint with one developer.
+
+Calculate if Must + Should items fit. If they don't, move the lowest-priority Should items to Could.
 
 Show a capacity summary:
 ```
-Sprint-Kapazität: 10 Tage
-Must:   [sum] Tage
-Should: [sum] Tage  
-Could:  [sum] Tage
-─────────────────
-Geplant: [must+should] / 10 Tage
+Sprint-Kapazität: 20 Punkte
+Must:   [sum] Punkte
+Should: [sum] Punkte
+Could:  [sum] Punkte
+─────────────────────
+Geplant: [must+should] / 20 Punkte
 ```
 
 ### Step 7: Output the sprint plan
@@ -81,16 +105,16 @@ Write the sprint plan to `.forgehive/memory/sprint.md` in this format:
 
 **Ziel:** [one sentence sprint goal]
 
-**Kapazität:** [X] Entwickler-Tage
+**Kapazität:** [X] Punkte
 
 ## Must
-- [ ] [Item] ([size]) — [one-line description]
+- [ ] [ID] [Item] ([points]pt) — [one-line description]
 
-## Should  
-- [ ] [Item] ([size]) — [one-line description]
+## Should
+- [ ] [ID] [Item] ([points]pt) — [one-line description]
 
 ## Could
-- [ ] [Item] ([size]) — [one-line description]
+- [ ] [ID] [Item] ([points]pt) — [one-line description]
 
 ## Offen / Blocked
 - [any blocked items with reason]
@@ -99,10 +123,25 @@ Write the sprint plan to `.forgehive/memory/sprint.md` in this format:
 *Erstellt mit fh sprint — [timestamp]*
 ```
 
-Confirm with the user: **"Sprint Plan gespeichert in `.forgehive/memory/sprint.md`. Soll ich für jedes Must-Item direkt einen Branch anlegen?"**
+Confirm with the user: **"Sprint Plan gespeichert. Soll ich für jedes Must-Item direkt einen Branch anlegen?"**
 
-If yes: create branches for each Must item following the `git-conventions` skill (`feat/<slug>`, `fix/<slug>`, `chore/<slug>`).
+If yes: create branches following `feat/<slug>`, `fix/<slug>`, `chore/<slug>`.
 
 ### Step 8: Update project memory
 
-Append the sprint goal to `.forgehive/memory/project.md` under a `## Aktueller Sprint` section so Claude knows the current focus in every future session.
+Append the sprint goal to `.forgehive/memory/project.md` under a `## Aktueller Sprint` section.
+
+### Step 9: Record velocity (at sprint end)
+
+When the user runs `/fh-sprint` and mentions "Sprint ist fertig" or "Sprint abgeschlossen":
+
+1. Ask: **"Wie viele Punkte habt ihr tatsächlich geliefert?"**
+2. Read the committed points from `sprint.md`
+3. Record velocity:
+```bash
+fh velocity record <N> --committed <committed> --delivered <delivered>
+```
+4. Show updated velocity report:
+```bash
+fh velocity show
+```

package/forgehive/commands/fh-test-this.md

@@ -0,0 +1,48 @@
+You are Sam — QA & Test Architect. Your job is to write tests for the current changes.
+
+## Test-This Protocol
+
+### Step 1: Identify what changed
+
+1. Run `git diff HEAD --stat` to see which files changed
+2. Run `git diff HEAD` to see the actual changes
+3. Note: which functions/classes were added or modified?
+
+### Step 2: Load testing skill
+
+Read `.forgehive/skills/expert/testing-strategies.md` for the project's testing conventions.
+
+Check which test framework is in use (from `capabilities.yaml`):
+- `node:test` → use `describe/it` with `node:assert/strict`
+- `jest` → use `describe/it` with `expect`
+- `pytest` → use `def test_` functions
+- `go test` → use `func TestX(t *testing.T)`
+
+### Step 3: Write tests
+
+For each changed function or class, write:
+1. A **happy path test** — normal input, expected output
+2. An **edge case test** — empty input, boundary values, null/undefined
+3. An **error case test** — invalid input, should throw or return error
+
+Place tests in the appropriate test file (same name as source file, `test/` directory or `*.test.ts` suffix).
+
+### Step 4: Run tests
+
+Run the test suite and confirm all new tests pass:
+```bash
+npm test        # or pytest, go test, etc.
+```
+
+If tests fail, fix the implementation or the test until all pass.
+
+### Step 5: Coverage check
+
+If coverage tooling is available, run it and report the coverage percentage for the changed files.
+
+### Step 6: Commit
+
+```bash
+git add <test-files>
+git commit -m "test: add tests for <what you tested>"
+```

package/forgehive/party/defaults.yaml

@@ -3,19 +3,41 @@ sets:
     agents: [suki, viktor]
     trigger: "/design-party"
     description: "UX + Architektur parallel"
+    models:
+      suki: claude-sonnet-4-6
+      viktor: claude-opus-4-7
   build:
     agents: [viktor, kai, sam]
     trigger: "/party"
     description: "Architektur + Engineering + QA"
+    models:
+      viktor: claude-opus-4-7
+      kai: claude-sonnet-4-6
+      sam: claude-haiku-4-5
   review:
     agents: [kai, sam, eli]
     trigger: "/review-party"
     description: "Code Review + QA + Doku"
+    models:
+      kai: claude-opus-4-7
+      sam: claude-sonnet-4-6
+      eli: claude-sonnet-4-6
   full:
     agents: [nora, eli, remy, suki, viktor, kai, sam]
     trigger: "/full-party"
     description: "Alle Agenten"
+    models:
+      viktor: claude-opus-4-7
+      kai: claude-opus-4-7
+      nora: claude-sonnet-4-6
+      eli: claude-sonnet-4-6
+      sam: claude-sonnet-4-6
+      suki: claude-sonnet-4-6
+      remy: claude-haiku-4-5
   security:
     agents: [vera, sam]
     trigger: "/security-party"
     description: "Security Review + QA"
+    models:
+      vera: claude-opus-4-7
+      sam: claude-sonnet-4-6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "forgehive",
-  "version": "0.6.3",
+  "version": "0.7.1",
   "description": "Context-aware AI development environment — one binary, your stack.",
   "type": "module",
   "bin": {