mindforge-cc 9.0.0 → 10.0.1

package/.agent/skills/mindforge-thread/SKILL.md

@@ -1,123 +0,0 @@
----
-name: mindforge-thread
-description: Manage persistent context threads for cross-session work
----
-
-
-<objective>
-Create, list, or resume persistent context threads. Threads are lightweight
-cross-session knowledge stores for work that spans multiple sessions but
-doesn't belong to any specific phase.
-</objective>
-
-<process>
-
-**Parse $ARGUMENTS to determine mode:**
-
-<mode_list>
-**If no arguments or $ARGUMENTS is empty:**
-
-List all threads:
-```bash
-ls .planning/threads/*.md 2>/dev/null
-```
-
-For each thread, read the first few lines to show title and status:
-```
-## Active Threads
-
-| Thread | Status | Last Updated |
-|--------|--------|-------------|
-| fix-deploy-key-auth | OPEN | 2026-03-15 |
-| pasta-tcp-timeout | RESOLVED | 2026-03-12 |
-| perf-investigation | IN PROGRESS | 2026-03-17 |
-```
-
-If no threads exist, show:
-```
-No threads found. Create one with: /mindforge-thread <description>
-```
-</mode_list>
-
-<mode_resume>
-**If $ARGUMENTS matches an existing thread name (file exists):**
-
-Resume the thread — load its context into the current session:
-```bash
-cat ".planning/threads/${THREAD_NAME}.md"
-```
-
-Display the thread content and ask what the user wants to work on next.
-Update the thread's status to `IN PROGRESS` if it was `OPEN`.
-</mode_resume>
-
-<mode_create>
-**If $ARGUMENTS is a new description (no matching thread file):**
-
-Create a new thread:
-
-1. Generate slug from description:
-   ```bash
-   SLUG=$(node ".agent/bin/mindforge-tools.cjs" generate-slug "$ARGUMENTS")
-   ```
-
-2. Create the threads directory if needed:
-   ```bash
-   mkdir -p .planning/threads
-   ```
-
-3. Write the thread file:
-   ```bash
-   cat > ".planning/threads/${SLUG}.md" << 'EOF'
-   # Thread: {description}
-
-   ## Status: OPEN
-
-   ## Goal
-
-   {description}
-
-   ## Context
-
-   *Created from conversation on {today's date}.*
-
-   ## References
-
-   - *(add links, file paths, or issue numbers)*
-
-   ## Next Steps
-
-   - *(what the next session should do first)*
-   EOF
-   ```
-
-4. If there's relevant context in the current conversation (code snippets,
-   error messages, investigation results), extract and add it to the Context
-   section.
-
-5. Commit:
-   ```bash
-   node ".agent/bin/mindforge-tools.cjs" commit "docs: create thread — ${ARGUMENTS}" --files ".planning/threads/${SLUG}.md"
-   ```
-
-6. Report:
-   ```
-   ## 🧵 Thread Created
-
-   Thread: {slug}
-   File: .planning/threads/{slug}.md
-
-   Resume anytime with: /mindforge-thread {slug}
-   ```
-</mode_create>
-
-</process>
-
-<notes>
-- Threads are NOT phase-scoped — they exist independently of the roadmap
-- Lighter weight than /mindforge-pause-work — no phase state, no plan context
-- The value is in Context and Next Steps — a cold-start session can pick up immediately
-- Threads can be promoted to phases or backlog items when they mature:
-  /mindforge-add-phase or /mindforge-add-backlog with context from the thread
-- Thread files live in .planning/threads/ — no collision with phases or other MindForge structures
-</notes>

package/.agent/skills/mindforge-ui-phase/SKILL.md

@@ -1,24 +0,0 @@
----
-name: mindforge-ui-phase
-description: Generate UI design contract (UI-SPEC.md) for frontend phases
----
-
-<objective>
-Create a UI design contract (UI-SPEC.md) for a frontend phase.
-Orchestrates mindforge-ui-researcher and mindforge-ui-checker.
-Flow: Validate → Research UI → Verify UI-SPEC → Done
-</objective>
-
-<execution_context>
-@.agent/workflows/mindforge-ui-phase.md
-@.agent/references/ui-brand.md
-</execution_context>
-
-<context>
-Phase number: $ARGUMENTS — optional, auto-detects next unplanned phase if omitted.
-</context>
-
-<process>
-Execute @.agent/workflows/mindforge-ui-phase.md end-to-end.
-Preserve all workflow gates.
-</process>

package/.agent/skills/mindforge-ui-review/SKILL.md

@@ -1,24 +0,0 @@
----
-name: mindforge-ui-review
-description: Retroactive 6-pillar visual audit of implemented frontend code
----
-
-<objective>
-Conduct a retroactive 6-pillar visual audit. Produces UI-REVIEW.md with
-graded assessment (1-4 per pillar). Works on any project.
-Output: {phase_num}-UI-REVIEW.md
-</objective>
-
-<execution_context>
-@.agent/workflows/mindforge-ui-review.md
-@.agent/references/ui-brand.md
-</execution_context>
-
-<context>
-Phase: $ARGUMENTS — optional, defaults to last completed phase.
-</context>
-
-<process>
-Execute @.agent/workflows/mindforge-ui-review.md end-to-end.
-Preserve all workflow gates.
-</process>

package/.agent/skills/mindforge-update/SKILL.md

@@ -1,35 +0,0 @@
----
-name: mindforge-update
-description: Update MindForge to latest version with changelog display
----
-
-
-<objective>
-Check for MindForge updates, install if available, and display what changed.
-
-Routes to the update workflow which handles:
-- Version detection (local vs global installation)
-- npm version checking
-- Changelog fetching and display
-- User confirmation with clean install warning
-- Update execution and cache clearing
-- Restart reminder
-</objective>
-
-<execution_context>
-@.agent/workflows/mindforge-update.md
-</execution_context>
-
-<process>
-**Follow the update workflow** from `@.agent/workflows/mindforge-update.md`.
-
-The workflow handles all logic including:
-1. Installed version detection (local/global)
-2. Latest version checking via npm
-3. Version comparison
-4. Changelog fetching and extraction
-5. Clean install warning display
-6. User confirmation
-7. Update execution
-8. Cache clearing
-</process>

package/.agent/skills/mindforge-validate-phase/SKILL.md

@@ -1,26 +0,0 @@
----
-name: mindforge-validate-phase
-description: Retroactively audit and fill Nyquist validation gaps for a completed phase
----
-
-<objective>
-Audit Nyquist validation coverage for a completed phase. Three states:
-- (A) VALIDATION.md exists — audit and fill gaps
-- (B) No VALIDATION.md, SUMMARY.md exists — reconstruct from artifacts
-- (C) Phase not executed — exit with guidance
-
-Output: updated VALIDATION.md + generated test files.
-</objective>
-
-<execution_context>
-@.agent/workflows/mindforge-validate-phase.md
-</execution_context>
-
-<context>
-Phase: $ARGUMENTS — optional, defaults to last completed phase.
-</context>
-
-<process>
-Execute @.agent/workflows/mindforge-validate-phase.md.
-Preserve all workflow gates.
-</process>

package/.agent/skills/mindforge-verify-work/SKILL.md

@@ -1,30 +0,0 @@
----
-name: mindforge-verify-work
-description: Validate built features through conversational UAT
----
-
-<objective>
-Validate built features through conversational testing with persistent state.
-
-Purpose: Confirm what the agent built actually works from user's perspective. One test at a time, plain text responses, no interrogation. When issues are found, automatically diagnose, plan fixes, and prepare for execution.
-
-Output: {phase_num}-UAT.md tracking all test results. If issues found: diagnosed gaps, verified fix plans ready for /mindforge-execute-phase
-</objective>
-
-<execution_context>
-@.agent/workflows/mindforge-verify-work.md
-@.agent/templates/UAT.md
-</execution_context>
-
-<context>
-Phase: $ARGUMENTS (optional)
-- If provided: Test specific phase (e.g., "4")
-- If not provided: Check for active sessions or prompt for phase
-
-Context files are resolved inside the workflow (`init verify-work`) and delegated via `<files_to_read>` blocks.
-</context>
-
-<process>
-Execute the verify-work workflow from @.agent/workflows/mindforge-verify-work.md end-to-end.
-Preserve all workflow gates (session management, test presentation, diagnosis, fix planning, routing).
-</process>

package/.agent/skills/mindforge-verify-work_extended/SKILL.md

@@ -1,139 +0,0 @@
----
-name: mindforge-verify-work_extended
-description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
----
-
-# Verification Before Completion
-
-## Overview
-
-Claiming work is complete without verification is dishonesty, not efficiency.
-
-**Core principle:** Evidence before claims, always.
-
-**Violating the letter of this rule is violating the spirit of this rule.**
-
-## The Iron Law
-
-```
-NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
-```
-
-If you haven't run the verification command in this message, you cannot claim it passes.
-
-## The Gate Function
-
-```
-BEFORE claiming any status or expressing satisfaction:
-
-1. IDENTIFY: What command proves this claim?
-2. RUN: Execute the FULL command (fresh, complete)
-3. READ: Full output, check exit code, count failures
-4. VERIFY: Does output confirm the claim?
-   - If NO: State actual status with evidence
-   - If YES: State claim WITH evidence
-5. ONLY THEN: Make the claim
-
-Skip any step = lying, not verifying
-```
-
-## Common Failures
-
-| Claim | Requires | Not Sufficient |
-|-------|----------|----------------|
-| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
-| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
-| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
-| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
-| Regression test works | Red-green cycle verified | Test passes once |
-| Agent completed | VCS diff shows changes | Agent reports "success" |
-| Requirements met | Line-by-line checklist | Tests passing |
-
-## Red Flags - STOP
-
-- Using "should", "probably", "seems to"
-- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
-- About to commit/push/PR without verification
-- Trusting agent success reports
-- Relying on partial verification
-- Thinking "just this once"
-- Tired and wanting work over
-- **ANY wording implying success without having run verification**
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "Should work now" | RUN the verification |
-| "I'm confident" | Confidence ≠ evidence |
-| "Just this once" | No exceptions |
-| "Linter passed" | Linter ≠ compiler |
-| "Agent said success" | Verify independently |
-| "I'm tired" | Exhaustion ≠ excuse |
-| "Partial check is enough" | Partial proves nothing |
-| "Different words so rule doesn't apply" | Spirit over letter |
-
-## Key Patterns
-
-**Tests:**
-```
-✅ [Run test command] [See: 34/34 pass] "All tests pass"
-❌ "Should pass now" / "Looks correct"
-```
-
-**Regression tests (TDD Red-Green):**
-```
-✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
-❌ "I've written a regression test" (without red-green verification)
-```
-
-**Build:**
-```
-✅ [Run build] [See: exit 0] "Build passes"
-❌ "Linter passed" (linter doesn't check compilation)
-```
-
-**Requirements:**
-```
-✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
-❌ "Tests pass, phase complete"
-```
-
-**Agent delegation:**
-```
-✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
-❌ Trust agent report
-```
-
-## Why This Matters
-
-From 24 failure memories:
-- your human partner said "I don't believe you" - trust broken
-- Undefined functions shipped - would crash
-- Missing requirements shipped - incomplete features
-- Time wasted on false completion → redirect → rework
-- Violates: "Honesty is a core value. If you lie, you'll be replaced."
-
-## When To Apply
-
-**ALWAYS before:**
-- ANY variation of success/completion claims
-- ANY expression of satisfaction
-- ANY positive statement about work state
-- Committing, PR creation, task completion
-- Moving to next task
-- Delegating to agents
-
-**Rule applies to:**
-- Exact phrases
-- Paraphrases and synonyms
-- Implications of success
-- ANY communication suggesting completion/correctness
-
-## The Bottom Line
-
-**No shortcuts for verification.**
-
-Run the command. Read the output. THEN claim the result.
-
-This is non-negotiable.

package/.agent/skills/mindforge-workspace-isolated/SKILL.md

@@ -1,218 +0,0 @@
----
-name: using-git-worktrees
-description: Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
----
-
-# Using Git Worktrees
-
-## Overview
-
-Git worktrees create isolated workspaces sharing the same repository, allowing work on multiple branches simultaneously without switching.
-
-**Core principle:** Systematic directory selection + safety verification = reliable isolation.
-
-**Announce at start:** "I'm using the using-git-worktrees skill to set up an isolated workspace."
-
-## Directory Selection Process
-
-Follow this priority order:
-
-### 1. Check Existing Directories
-
-```bash
-# Check in priority order
-ls -d .worktrees 2>/dev/null     # Preferred (hidden)
-ls -d worktrees 2>/dev/null      # Alternative
-```
-
-**If found:** Use that directory. If both exist, `.worktrees` wins.
-
-### 2. Check CLAUDE.md
-
-```bash
-grep -i "worktree.*director" CLAUDE.md 2>/dev/null
-```
-
-**If preference specified:** Use it without asking.
-
-### 3. Ask User
-
-If no directory exists and no CLAUDE.md preference:
-
-```
-No worktree directory found. Where should I create worktrees?
-
-1. .worktrees/ (project-local, hidden)
-2. ~/.config/mindforge/worktrees/<project-name>/ (global location)
-
-Which would you prefer?
-```
-
-## Safety Verification
-
-### For Project-Local Directories (.worktrees or worktrees)
-
-**MUST verify directory is ignored before creating worktree:**
-
-```bash
-# Check if directory is ignored (respects local, global, and system gitignore)
-git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
-```
-
-**If NOT ignored:**
-
-Per Jesse's rule "Fix broken things immediately":
-1. Add appropriate line to .gitignore
-2. Commit the change
-3. Proceed with worktree creation
-
-**Why critical:** Prevents accidentally committing worktree contents to repository.
-
-### For Global Directory (~/.config/mindforge/worktrees)
-
-No .gitignore verification needed - outside project entirely.
-
-## Creation Steps
-
-### 1. Detect Project Name
-
-```bash
-project=$(basename "$(git rev-parse --show-toplevel)")
-```
-
-### 2. Create Worktree
-
-```bash
-# Determine full path
-case $LOCATION in
-  .worktrees|worktrees)
-    path="$LOCATION/$BRANCH_NAME"
-    ;;
-  ~/.config/mindforge/worktrees/*)
-    path="~/.config/mindforge/worktrees/$project/$BRANCH_NAME"
-    ;;
-esac
-
-# Create worktree with new branch
-git worktree add "$path" -b "$BRANCH_NAME"
-cd "$path"
-```
-
-### 3. Run Project Setup
-
-Auto-detect and run appropriate setup:
-
-```bash
-# Node.js
-if [ -f package.json ]; then npm install; fi
-
-# Rust
-if [ -f Cargo.toml ]; then cargo build; fi
-
-# Python
-if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
-if [ -f pyproject.toml ]; then poetry install; fi
-
-# Go
-if [ -f go.mod ]; then go mod download; fi
-```
-
-### 4. Verify Clean Baseline
-
-Run tests to ensure worktree starts clean:
-
-```bash
-# Examples - use project-appropriate command
-npm test
-cargo test
-pytest
-go test ./...
-```
-
-**If tests fail:** Report failures, ask whether to proceed or investigate.
-
-**If tests pass:** Report ready.
-
-### 5. Report Location
-
-```
-Worktree ready at <full-path>
-Tests passing (<N> tests, 0 failures)
-Ready to implement <feature-name>
-```
-
-## Quick Reference
-
-| Situation | Action |
-|-----------|--------|
-| `.worktrees/` exists | Use it (verify ignored) |
-| `worktrees/` exists | Use it (verify ignored) |
-| Both exist | Use `.worktrees/` |
-| Neither exists | Check CLAUDE.md → Ask user |
-| Directory not ignored | Add to .gitignore + commit |
-| Tests fail during baseline | Report failures + ask |
-| No package.json/Cargo.toml | Skip dependency install |
-
-## Common Mistakes
-
-### Skipping ignore verification
-
-- **Problem:** Worktree contents get tracked, pollute git status
-- **Fix:** Always use `git check-ignore` before creating project-local worktree
-
-### Assuming directory location
-
-- **Problem:** Creates inconsistency, violates project conventions
-- **Fix:** Follow priority: existing > CLAUDE.md > ask
-
-### Proceeding with failing tests
-
-- **Problem:** Can't distinguish new bugs from pre-existing issues
-- **Fix:** Report failures, get explicit permission to proceed
-
-### Hardcoding setup commands
-
-- **Problem:** Breaks on projects using different tools
-- **Fix:** Auto-detect from project files (package.json, etc.)
-
-## Example Workflow
-
-```
-You: I'm using the using-git-worktrees skill to set up an isolated workspace.
-
-[Check .worktrees/ - exists]
-[Verify ignored - git check-ignore confirms .worktrees/ is ignored]
-[Create worktree: git worktree add .worktrees/auth -b feature/auth]
-[Run npm install]
-[Run npm test - 47 passing]
-
-Worktree ready at /Users/jesse/myproject/.worktrees/auth
-Tests passing (47 tests, 0 failures)
-Ready to implement auth feature
-```
-
-## Red Flags
-
-**Never:**
-- Create worktree without verifying it's ignored (project-local)
-- Skip baseline test verification
-- Proceed with failing tests without asking
-- Assume directory location when ambiguous
-- Skip CLAUDE.md check
-
-**Always:**
-- Follow directory priority: existing > CLAUDE.md > ask
-- Verify directory is ignored for project-local
-- Auto-detect and run project setup
-- Verify clean test baseline
-
-## Integration
-
-**Called by:**
-- **brainstorming** (Phase 4) - REQUIRED when design is approved and implementation follows
-- **mindforge-swarm-execution** - REQUIRED before executing any tasks
-- **mindforge-execute-phase_extended** - REQUIRED before executing any tasks
-- Any skill needing isolated workspace
-
-**Pairs with:**
-- **mindforge-ship_extended** - REQUIRED for cleanup after work complete

package/.agent/skills/mindforge-workstreams/SKILL.md

@@ -1,65 +0,0 @@
----
-name: mindforge-workstreams
-description: Manage parallel workstreams — list, create, switch, status, progress, complete, and resume
----
-
-
-# /mindforge-workstreams
-
-Manage parallel workstreams for concurrent milestone work.
-
-## Usage
-
-`/mindforge-workstreams [subcommand] [args]`
-
-### Subcommands
-
-| Command | Description |
-|---------|-------------|
-| `list` | List all workstreams with status |
-| `create <name>` | Create a new workstream |
-| `status <name>` | Detailed status for one workstream |
-| `switch <name>` | Set active workstream |
-| `progress` | Progress summary across all workstreams |
-| `complete <name>` | Archive a completed workstream |
-| `resume <name>` | Resume work in a workstream |
-
-## Step 1: Parse Subcommand
-
-Parse the user's input to determine which workstream operation to perform.
-If no subcommand given, default to `list`.
-
-## Step 2: Execute Operation
-
-### list
-Run: `node "$MindForge_TOOLS" workstream list --raw --cwd "$CWD"`
-Display the workstreams in a table format showing name, status, current phase, and progress.
-
-### create
-Run: `node "$MindForge_TOOLS" workstream create <name> --raw --cwd "$CWD"`
-After creation, display the new workstream path and suggest next steps:
-- `/mindforge-new-milestone --ws <name>` to set up the milestone
-
-### status
-Run: `node "$MindForge_TOOLS" workstream status <name> --raw --cwd "$CWD"`
-Display detailed phase breakdown and state information.
-
-### switch
-Run: `node "$MindForge_TOOLS" workstream set <name> --raw --cwd "$CWD"`
-Also set `MindForge_WORKSTREAM` env var for the current session.
-
-### progress
-Run: `node "$MindForge_TOOLS" workstream progress --raw --cwd "$CWD"`
-Display a progress overview across all workstreams.
-
-### complete
-Run: `node "$MindForge_TOOLS" workstream complete <name> --raw --cwd "$CWD"`
-Archive the workstream to milestones/.
-
-### resume
-Set the workstream as active and suggest `/mindforge-resume-work --ws <name>`.
-
-## Step 3: Display Results
-
-Format the JSON output from mindforge-tools into a human-readable display.
-Include the `${MindForge_WS}` flag in any routing suggestions.

package/.agent/workflows/forge:help.md

@@ -1,10 +0,0 @@
----
-description: Show all available FORGE commands and what they do.
----
-Show all available FORGE commands and what they do.
-
-List every .md file in .claude/commands/forge/ and display:
-- Command name (filename without extension)
-- First line of the file as its description
-
-Format as a clean table. Also remind the user to read CLAUDE.md if they haven't yet.