mindforge-cc 1.0.0

package/.claude/commands/mindforge/plan-phase.md

@@ -0,0 +1,125 @@
+Plan a project phase. Usage: /mindforge:plan-phase [N]
+
+## Pre-check
+If N is not given, read STATE.md for the current phase number and increment by 1.
+Read PROJECT.md, REQUIREMENTS.md, ARCHITECTURE.md, and STATE.md before proceeding.
+
+## Pre-read (before any questions or planning)
+
+Read these files in order:
+1. `.planning/PROJECT.md`
+2. `.planning/REQUIREMENTS.md`
+3. `.planning/ARCHITECTURE.md`
+4. `.planning/STATE.md`
+5. `.planning/phases/phase-[N]/CONTEXT.md` (if it exists)
+
+### If CONTEXT.md exists for phase [N]:
+This means `/mindforge:discuss-phase [N]` was already run.
+The user's implementation decisions are already captured.
+DO NOT re-ask questions that CONTEXT.md already answers.
+Read CONTEXT.md completely before asking any clarifying questions.
+Report: "I've read the phase discussion context. [N] decisions were captured.
+Planning will follow these decisions."
+
+### If CONTEXT.md has open questions:
+Read the "Open questions" section in CONTEXT.md.
+Present unresolved questions to the user NOW, before planning begins.
+Do not create plans that assume answers to open questions without confirming first.
+
+### If CONTEXT.md does NOT exist for phase [N]:
+Proceed normally with the discussion → planning flow.
+
+## Step 1 — Discuss phase scope
+Ask:
+1. "Describe what Phase [N] should accomplish. 2-3 sentences."
+2. "Have you already made any implementation decisions for this phase?
+    (libraries, patterns, approaches) If yes, list them."
+3. "Are there any constraints I should know about?
+    (deadlines, dependencies on other teams, tech limitations)"
+
+Write answers to `.planning/phases/phase-[N]/CONTEXT.md`.
+
+If `.planning/phases/phase-[N]/CONTEXT.md` already exists:
+1. Read it first.
+2. If it has "Open questions", ask the user to resolve them before planning.
+3. Update CONTEXT.md with the answers and mark those questions as resolved.
+
+### If CONTEXT.md exists — skip already-answered questions
+Only ask about areas NOT covered in CONTEXT.md.
+Example: if CONTEXT.md captures the layout decision, do not ask "What layout do you want?"
+Respect the prior discussion. Build on it. Do not repeat it.
+
+## Step 2 — Domain research (spawn subagent)
+Spawn a research subagent with this context only:
+- The tech stack from PROJECT.md
+- The phase scope from CONTEXT.md
+- CONVENTIONS.md
+
+Instruct it to investigate:
+1. Best available libraries for this phase's requirements (with version numbers)
+2. Common pitfalls and anti-patterns for this tech domain
+3. Relevant architectural patterns (with tradeoffs)
+4. Any known security considerations specific to this domain
+
+Write findings to `.planning/phases/phase-[N]/RESEARCH.md`.
+
+## Step 3 — Create atomic task plans
+Based on CONTEXT.md and RESEARCH.md, create 3-6 PLAN files.
+Each plan must be completable in a single fresh context window.
+Each plan targets specific files — no plan should touch more than 6 files.
+
+File naming: `.planning/phases/phase-[N]/PLAN-[N]-[NN].md`
+Example: `.planning/phases/1/PLAN-1-01.md`
+
+Each plan uses this XML format:
+
+```xml
+<task type="auto">
+  <n>Short descriptive task name</n>
+  <persona>developer</persona>
+  <phase>[N]</phase>
+  <plan>[NN]</plan>
+  <dependencies>List any PLAN files that must complete before this one, or "none"</dependencies>
+  <files>
+    src/exact/file/path.ts
+    src/another/file.ts
+  </files>
+  <context>
+    Relevant decisions from ARCHITECTURE.md:
+    - [decision]
+    Skills to load before starting:
+    - [skill name if applicable, or "none"]
+  </context>
+  <action>
+    Precise implementation instructions.
+    Include exact library names and versions.
+    Include the approach, not just the goal.
+    Include specific anti-patterns to avoid.
+  </action>
+  <verify>
+    [Exact runnable command or check]
+    Example: curl -X POST localhost:3000/api/auth/login -d '{"email":"test@test.com","password":"test"}' | jq .status
+    Must produce a deterministic pass/fail result.
+  </verify>
+  <done>One sentence definition of done.</done>
+</task>
+```
+
+## Step 4 — Validate plans
+Check every plan against REQUIREMENTS.md:
+- Does this plan implement anything out of scope? If yes: revise.
+- Does this plan contradict ARCHITECTURE.md? If yes: create an ADR first.
+- Is the `<verify>` step actually runnable? If no: rewrite it.
+
+## Step 5 — Update state and confirm
+Update STATE.md: current phase = N, status = "Phase N planned, ready to execute".
+
+Tell the user:
+"✅ Phase [N] planned. [X] task plans created.
+
+Plans:
+  PLAN-[N]-01: [task name]
+  PLAN-[N]-02: [task name]
+  ...
+
+Run /mindforge:execute-phase [N] to begin execution."

package/.claude/commands/mindforge/plugins.md

@@ -0,0 +1,40 @@
+# MindForge — Plugins Command
+# Usage: /mindforge:plugins [list|install|uninstall|info|validate|create] [name]
+
+## list
+Read PLUGINS-MANIFEST.md. Display installed plugins with version and permissions.
+If no plugins: "No plugins installed. Find plugins: npm search mindforge-plugin"
+
+## install [plugin-name]
+Full installation protocol per plugin-loader.md:
+1. Resolve package: `mindforge-plugin-[name]` convention
+2. Download to chmod 700 temp directory
+3. Validate plugin.json manifest
+4. Check plugin_api_version compatibility (1.0.0 required)
+5. Run injection guard on ALL .md files in the plugin
+6. Run Level 1 + 2 skill validation on all SKILL.md files
+7. Display permission list for user approval:
+   ```
+   Plugin: mindforge-plugin-jira-advanced v1.0.0
+   Requests these permissions:
+     • read_audit_log:  read AUDIT.jsonl ✅ (safe)
+     • write_audit_log: append to AUDIT.jsonl ⚠️
+     • network_access:  make HTTP requests ⚠️
+   Install? (yes/no)
+   ```
+8. Install components (commands, skills, personas, hooks)
+9. Add to PLUGINS-MANIFEST.md
+10. Write AUDIT entry
+
+## uninstall [plugin-name]
+Remove all installed components. Update PLUGINS-MANIFEST.md.
+Confirm: "This will remove [N] commands, [N] skills from this plugin."
+
+## info [plugin-name]
+Display: version, description, author, permissions, commands, skills, personas, hooks.
+
+## validate
+Validate all installed plugins for compatibility, injection safety, permission scope.
+
+## create [plugin-name]
+Generate a plugin scaffold:

package/.claude/commands/mindforge/pr-review.md

@@ -0,0 +1,41 @@
+# MindForge — PR Review Command
+# Usage: /mindforge:pr-review [--diff path] [--sha base..head] [--output github|json|markdown]
+
+Run the AI PR review engine on a pull request diff.
+
+Steps:
+1. Determine diff source:
+   - `--diff path`: read diff from file
+   - `--sha base..head`: run `git diff base..head`
+   - Default: `git diff HEAD~1` (last commit) or `git diff --staged` (staged changes)
+
+2. Load review context (per ai-reviewer.md):
+   - PROJECT.md, ARCHITECTURE.md, CONVENTIONS.md, SECURITY.md
+   - Current phase's CONTEXT.md (if in an active phase)
+   - Any active ADRs relevant to changed files
+
+3. Detect change type and select review template:
+   - Auth/security changes → Security-focused review template
+   - Database migrations → Database migration review template
+   - API changes → API breaking change review template
+   - Default → Standard review template
+
+4. Check API availability:
+   - ANTHROPIC_API_KEY set? If not: warn and skip AI review
+   - Check daily review limit (from ai-reviewer.md)
+   - Check cache: has this SHA been reviewed in the last 60 minutes?
+
+5. Call Claude API (per ai-reviewer.md buildSystemPrompt + buildReviewPrompt)
+   - Handle errors gracefully — API unavailable is NOT a build failure
+   - Timeout: 60 seconds
+
+6. Format output per --output flag:
+   - github: GitHub-flavoured markdown for PR comment
+   - json: structured JSON with findings array
+   - markdown: standard markdown
+
+7. Write to output:
+   - If in CI: write to /tmp/mindforge-review.md (read by GitHub Actions step)
+   - If interactive: display to user
+
+8. Write AUDIT entry

package/.claude/commands/mindforge/profile-team.md

@@ -0,0 +1,23 @@
+# MindForge — Profile Team Command
+# Usage: /mindforge:profile-team [--refresh] [--developer email] [--questionnaire]
+
+Generate and maintain team/developer profiles for response personalization.
+
+## Data sources
+1. Declared questionnaire preferences
+2. Inferred patterns from AUDIT + git history + metrics
+3. Defaults from org conventions
+
+## Outputs
+- `.mindforge/team/TEAM-PROFILE.md`
+- `.mindforge/team/profiles/PROFILE-[dev-id].md`
+
+## Modes
+- `--refresh`: inference-only update
+- `--developer`: target one developer profile
+- `--questionnaire`: prompt preference questions before writing
+
+## AUDIT
+```json
+{ "event": "team_profile_updated", "developers_profiled": 1, "method": "inferred" }
+```

package/.claude/commands/mindforge/publish-skill.md

@@ -0,0 +1,19 @@
+# MindForge — Publish Skill Command
+# Usage: /mindforge:publish-skill [skill-dir] [--registry URL] [--dry-run]
+
+Publish a skill to the npm registry (or private registry).
+
+Pre-publication checklist:
+1. Run full skill validation (Level 1 + 2 + 3 from skill-validator.md)
+   Fail if Level 1 or 2 fails. Warn if Level 3 fails.
+2. Verify package.json has `mindforge` field with all required sub-fields
+3. Verify CHANGELOG.md has an entry for the current version
+4. Check if version already published: `npm info [package-name]@[version]`
+   If already published: error "Version already exists. Bump the version."
+5. Run `npm pack --dry-run` to preview what will be published
+6. Confirm with user: "These files will be published: [list]. Proceed? (yes/no)"
+7. If --dry-run: stop here, show preview only
+8. Publish: `npm publish --access public`
+9. Verify: `npm info [package-name]@[version]` — confirm publication succeeded
+10. Write AUDIT: `{ "event": "skill_published", "package": "...", "version": "..." }`
+11. Report: "✅ [package-name]@[version] published to npm registry"

package/.claude/commands/mindforge/quick.md

@@ -0,0 +1,135 @@
+# MindForge — Quick Command
+# Usage: /mindforge:quick [--research] [--review] [--full]
+# For ad-hoc tasks that don't need full lifecycle management.
+
+## When to use quick vs plan-phase
+Use QUICK for:
+- Bug fixes not tied to a current phase
+- Small improvements (< 3 files, < 2 hours)
+- Dependency updates
+- Documentation corrections
+- One-off scripts or utilities
+
+Use PLAN-PHASE for:
+- Feature development
+- Anything touching more than 6 files
+- Anything requiring research before implementation
+- Anything with external dependencies or stakeholder requirements
+
+## Step 1 — Task intake
+
+Ask the user:
+"What do you want to do?"
+
+Listen to the description. If the task sounds larger than "quick" scope
+(more than 6 files, architectural change, new feature), say:
+"This sounds like more than a quick task. I recommend using /mindforge:plan-phase
+ instead to ensure it's properly planned and verified. Want to proceed with quick anyway?"
+
+## Step 2 — Optional research (--research flag or user requests it)
+
+If `--research` is provided or the task involves unfamiliar libraries:
+Spawn a focused research subagent. Give it:
+- The task description
+- The current tech stack from PROJECT.md
+Ask it to: investigate the best approach, identify gotchas, recommend specific
+libraries (with versions), and write a brief research note.
+
+Report research findings to the user before proceeding.
+
+## Step 3 — Create a quick plan
+
+### Sequential quick task numbering
+Determine the next quick task number by scanning `.planning/quick/`:
+1. List directories matching `[0-9][0-9][0-9]-*`
+2. Take the max numeric prefix and add 1 (start at 001 if none exist)
+3. If a directory already exists for the chosen number, require `--force` to proceed
+
+Create `.planning/quick/[NNN]-[slug]/PLAN.md` where NNN is a sequential number
+and slug is a 2-4 word kebab-case description.
+
+Example: `.planning/quick/001-fix-login-null-check/PLAN.md`
+
+Use the standard XML plan format:
+```xml
+<task type="quick">
+  <n>[task name]</n>
+  <persona>[appropriate persona]</persona>
+  <files>[files to touch]</files>
+  <context>[relevant context]</context>
+  <action>[implementation instructions]</action>
+  <verify>[verification command]</verify>
+  <done>[definition of done]</done>
+</task>
+```
+
+Show the plan to the user. Wait for approval before executing.
+
+## Step 4 — Execute the quick plan
+
+### Security auto-trigger (mandatory)
+Before execution, scan the task description and files for security keywords:
+auth, authentication, login, password, token, JWT, session, payment, PII, upload,
+credential, secret, key.
+
+If any keyword matches: load `security-review/SKILL.md` and activate
+`security-reviewer.md` persona for the implementation. This is required even
+without the `--full` flag.
+
+1. Load persona from `.mindforge/personas/`
+2. Load any relevant skills based on task keywords
+3. Execute the plan
+4. Run `<verify>` — must pass before committing
+5. Commit: `[type](quick/[NNN]): [task name]`
+6. Write `.planning/quick/[NNN]-[slug]/SUMMARY.md`
+
+### STATE.md update policy
+Quick tasks do not change phase status. If there is no active phase, note the
+quick task completion in STATE.md under "Last completed task".
+
+## Step 5 — Optional review (--review flag)
+
+If `--review` is provided:
+Activate `code-quality.md` skill on the diff.
+Report any issues before committing.
+If BLOCKING issues found: fix before commit.
+
+## Step 6 — Optional full mode (--full flag)
+
+If `--full` is provided, additionally:
+- Run the project's full test suite (not just task-specific verify)
+- Run the type checker and linter
+- Activate `security-reviewer.md` if the task touches any security-sensitive code
+- Write an AUDIT entry for the quick task
+
+## Linting always runs
+Regardless of flags, after every quick task execution:
+1. Run the project's linter (from CONVENTIONS.md — check which linter applies)
+2. If lint errors found: fix them before committing.
+3. Linting is not part of `--full` — it is always part of quick.
+
+## Flags are composable
+```
+/mindforge:quick                     # minimal — task, plan, execute
+/mindforge:quick --research          # adds domain research step
+/mindforge:quick --review            # adds code quality review of diff
+/mindforge:quick --full              # adds full test suite + linting + security
+/mindforge:quick --research --full   # all of the above
+```
+
+## AUDIT entry for quick tasks
+```json
+{
+  "id": "uuid",
+  "timestamp": "ISO-8601",
+  "event": "quick_task_completed",
+  "agent": "mindforge-orchestrator",
+  "phase": null,
+  "session_id": "sess_abc",
+  "quick_id": "001",
+  "task_name": "Fix login null check",
+  "commit_sha": "abc1234",
+  "files_changed": ["src/auth/login.ts"],
+  "flags_used": ["--review"]
+}
+```

package/.claude/commands/mindforge/release.md

@@ -0,0 +1,10 @@
+# MindForge — Release Command
+# Usage: /mindforge:release [--version X.Y.Z] [--dry-run] [--checklist-only]
+# ⚠️  This command is for releasing the MindForge framework itself.
+#     For releasing your project phases, use /mindforge:ship instead.
+
+## Purpose
+Execute the complete MindForge v1.0.0 (or any version) release pipeline.
+Intended for the MindForge core team.
+
+## Gate: Production Readiness Checklist

package/.claude/commands/mindforge/retrospective.md

@@ -0,0 +1,26 @@
+# MindForge — Retrospective Command
+# Usage: /mindforge:retrospective [phase N|milestone M] [--template agile|4ls|starfish]
+
+Facilitate a structured retrospective with objective metrics + qualitative insights.
+
+## Workflow
+1. Gather quantitative signals (tasks, verify pass rate, findings, UAT, approvals).
+2. Run structured discussion by template.
+3. Write retrospective artifact in `.planning/phases/...` or `.planning/milestones/...`.
+4. Create follow-up tasks/tickets for action items.
+5. Update metrics with retrospective-completed event.
+
+## Step 5 — Apply learnings to MINDFORGE.md
+Ask explicitly:
+`Based on this retrospective, should we update MINDFORGE.md to improve future phases?`
+
+If yes:
+- propose exact config changes
+- apply only after confirmation
+- commit with clear rationale
+
+Common mappings:
+- vague plans -> lower discuss threshold / enable auto-discuss
+- low verify pass rate -> lower max tasks per phase
+- rising security findings -> force-load `security-review,data-privacy`
+- frequent compaction pressure -> lower compaction threshold

package/.claude/commands/mindforge/review.md

@@ -0,0 +1,157 @@
+# MindForge — Review Command
+# Usage: /mindforge:review [path|phase N|--staged|--last-commit]
+# Performs a comprehensive code review using code-quality and security skills.
+
+## Review targets
+- `/mindforge:review` (no args) → review all uncommitted changes (`git diff`)
+- `/mindforge:review --staged` → review staged changes (`git diff --cached`)
+- `/mindforge:review --last-commit` → review the last commit (`git diff HEAD~1`)
+- `/mindforge:review phase [N]` → review all commits in phase N
+- `/mindforge:review [file-path]` → review a specific file
+- `/mindforge:review [dir-path]` → review all files in a directory
+
+## Step 1 — Establish review scope
+
+Based on the target argument, build the file list to review:
+```bash
+# Uncommitted changes
+git diff --name-only
+
+# Staged changes
+git diff --cached --name-only
+
+# Last commit
+git diff HEAD~1 --name-only
+
+# Phase N (all commits between phase start and phase end tags)
+git log --oneline --name-only [phase-start-sha]..[phase-end-sha]
+```
+
+Display the file list to the user before reviewing:
+"Reviewing [N] files: [list]"
+
+## Step 2 — Load review personas and skills
+
+Activate TWO personas simultaneously for a comprehensive review:
+
+**Primary:** `code-quality.md` — structural quality, conventions, complexity
+**Secondary:** `security-reviewer.md` — security issues, data exposure, auth
+
+Load these skills:
+- `code-quality/SKILL.md` — always
+- `security-review/SKILL.md` — always
+- Contextual skills based on file types detected in the diff:
+  - `.ts`/`.tsx` → also load `api-design/SKILL.md` (if routes present)
+  - Database migration files → also load `database-patterns/SKILL.md`
+  - UI component files → also load `accessibility/SKILL.md`
+
+## Step 3 — Review each file
+
+For each file in the review scope:
+
+**Read the full file content** (not just the diff — context matters).
+**Read the diff for this file** to understand what changed.
+
+Apply ALL of the following checks:
+
+### Code quality checks
+- [ ] Functions within length limits (CONVENTIONS.md standard)
+- [ ] Cyclomatic complexity ≤ 10 (count if/else/switch/catch/ternary branches)
+- [ ] No magic numbers (named constants used instead)
+- [ ] No commented-out code
+- [ ] No `TODO` or `FIXME` left uncommitted
+- [ ] Error handling is explicit (no empty catch blocks)
+- [ ] Naming is precise and unambiguous (no `data`, `info`, `temp`)
+- [ ] Every exported function has a JSDoc/docstring
+- [ ] DRY: no logic duplicated 3+ times
+- [ ] No dead code (imports/variables defined but never used)
+
+### Convention checks (from CONVENTIONS.md)
+- [ ] File naming follows convention
+- [ ] Import order follows the defined order
+- [ ] All forbidden patterns are absent
+- [ ] Architecture boundaries respected (services don't import routes, etc.)
+
+### Security checks (from security-review SKILL)
+- [ ] No hardcoded credentials or secrets
+- [ ] User input validated at boundaries
+- [ ] SQL queries parameterised
+- [ ] Sensitive data not in logs or error messages
+- [ ] New dependencies CVE-scanned
+
+### Type safety (TypeScript projects)
+- [ ] No `any` types without justification comment
+- [ ] No `as unknown as X` casting without justification
+- [ ] All function parameters typed (no implicit any)
+- [ ] Return types explicitly declared on public functions
+
+## Step 4 — Write the review report
+
+Create `.planning/phases/[current-phase]/CODE-REVIEW-[timestamp].md`
+or `.planning/quick/review-[timestamp].md` for ad-hoc reviews:
+
+```markdown
+# Code Review Report
+**Date:** [ISO-8601]
+**Reviewer:** MindForge (code-quality + security-reviewer)
+**Scope:** [what was reviewed]
+**Files reviewed:** [N]
+
+## Summary
+[2-3 sentences: overall quality, major themes, recommendation]
+
+## Findings
+
+### 🔴 Blocking (must fix before merge)
+| # | File | Line | Issue | Recommendation |
+|---|---|---|---|---|
+| 1 | src/auth/login.ts | 47 | Parameterised query not used | Use `db.query('SELECT * FROM users WHERE id = $1', [id])` |
+
+### 🟠 Major (should fix in this PR)
+| # | File | Line | Issue | Recommendation |
+|---|---|---|---|---|
+| 1 | src/api/users.ts | 23 | Function is 67 lines (limit: 40) | Extract `validateUserInput` to separate function |
+
+### 🟡 Minor (fix in follow-up)
+| # | File | Line | Issue | Recommendation |
+|---|---|---|---|---|
+| 1 | src/models/order.ts | 8 | Missing JSDoc on exported function | Add `@param`, `@returns`, `@throws` |
+
+### 💡 Suggestions (optional improvements)
+| # | File | Line | Suggestion |
+|---|---|---|---|
+| 1 | src/services/email.ts | 15 | Consider memoising the template compilation |
+
+## Metrics
+- Files reviewed: [N]
+- Lines reviewed: [N]  
+- Blocking findings: [N]
+- Major findings: [N]
+- Minor findings: [N]
+- Suggestions: [N]
+
+## Verdict
+✅ APPROVED — No blocking or major findings
+⚠️  APPROVED WITH CONDITIONS — Fix [N] major findings
+❌ CHANGES REQUIRED — [N] blocking findings must be fixed
+```
+
+## Step 5 — Write AUDIT entry
+
+```json
+{
+  "event": "code_review_completed",
+  "scope": "[what was reviewed]",
+  "files_reviewed": [N],
+  "blocking_findings": [N],
+  "major_findings": [N],
+  "verdict": "approved | changes_required",
+  "report_path": ".planning/.../CODE-REVIEW-[timestamp].md"
+}
+```
+
+## Step 6 — Report to user
+
+Display a summary of findings.
+If blocking findings exist: do not allow merge.
+Tell the user: "Fix the [N] blocking issues, then run /mindforge:review again to re-check."