mindforge-cc 11.2.1 → 11.3.1

package/.claude/commands/mindforge/orchestrate.md

@@ -0,0 +1,74 @@
+---
+description: "Design multi-agent orchestration pattern for a task. Usage: /mindforge:orchestrate [task] [--pattern supervisor|pipeline|debate|consensus|mapreduce]"
+---
+
+<objective>
+Design and implement a multi-agent orchestration pattern for a complex task, defining agent roles, handoff protocols, failure propagation, and coordination mechanisms.
+</objective>
+
+<execution_context>
+@.mindforge/skills/agent-orchestration-patterns/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (task description, optional --pattern supervisor|pipeline|debate|consensus|mapreduce)
+Knowledge: Available agent patterns, existing personas, swarm templates, coordination protocols.
+</context>
+
+<process>
+1. **Assess if multi-agent needed**: Evaluate single-agent vs multi-agent:
+   - Does the task require multiple distinct skill domains?
+   - Would sequential processing create unacceptable latency?
+   - Does the task benefit from adversarial validation?
+   - Is the task decomposable into independent subtasks?
+   - Would a single agent exceed context window constraints?
+   - If single-agent suffices, recommend that and stop
+
+2. **Select pattern from matrix**: Choose orchestration pattern:
+   - `supervisor`: Central coordinator delegates to specialists, aggregates results. Best for: heterogeneous subtasks with dependencies
+   - `pipeline`: Sequential handoff between stages. Best for: transformation chains (draft→review→edit→publish)
+   - `debate`: Multiple agents argue positions, judge synthesizes. Best for: architectural decisions, trade-off analysis
+   - `consensus`: All agents propose, vote on best approach. Best for: code review, quality assessment
+   - `mapreduce`: Fan-out identical tasks, merge results. Best for: parallel search, batch processing
+   - Document why the selected pattern fits this specific task
+
+3. **Define agent roles**: For each agent in the pattern:
+   - Role name and persona reference (from personas registry)
+   - Specific responsibility and decision authority
+   - Input contract (what it receives, in what format)
+   - Output contract (what it produces, schema)
+   - Knowledge requirements (which skills/context it needs)
+   - Trust tier (1=autonomous, 2=review, 3=HITL approval)
+
+4. **Design handoff protocol**: Define JSON contracts for agent communication:
+   - Message envelope schema (from, to, type, payload, correlation_id)
+   - State passing mechanism (full state vs delta vs reference)
+   - Acknowledgment requirements (fire-and-forget vs confirmed delivery)
+   - Timeout per handoff (prevent infinite waits)
+   - Schema validation at each boundary (reject malformed handoffs)
+   - Context budget per agent (prevent token overflow)
+
+5. **Define failure propagation**: For each failure mode:
+   - Agent timeout → retry with backoff, then escalate to supervisor
+   - Agent error → log, attempt recovery, propagate if unrecoverable
+   - Consensus failure → add tiebreaker agent or escalate to human
+   - Cascade failure → circuit breaker pattern, fail fast
+   - Partial completion → checkpoint state, enable resume
+   - Define maximum retry count and escalation path
+
+6. **Implement coordination**: Build the orchestration logic:
+   - Supervisor: task queue, assignment logic, result aggregation
+   - Pipeline: stage transitions, backpressure handling, error short-circuit
+   - Debate: round management, argument collection, verdict synthesis
+   - Consensus: proposal collection, voting mechanism, quorum rules
+   - MapReduce: work partitioning, parallel dispatch, merge strategy
+   - Add observability (trace each agent invocation, measure latency)
+
+7. **Test the orchestration**: Validate the design:
+   - Happy path: all agents succeed, results merge correctly
+   - Partial failure: one agent fails, system recovers gracefully
+   - Timeout: slow agent detected and handled within SLA
+   - Conflict: agents disagree, resolution mechanism activates
+   - Load: pattern scales with task size (10x input, linear cost)
+   - Output: orchestration spec with diagram and runnable configuration
+</process>

package/.claude/commands/mindforge/payments.md

@@ -0,0 +1,28 @@
+---
+description: "Design payment flow architecture with PCI minimization. Usage: /mindforge:payments [flow] [--provider stripe|braintree] [--recurring]"
+---
+
+<objective>
+Design a robust payment flow architecture that minimizes PCI compliance scope through client-side tokenization, handles webhooks reliably, ensures idempotency across all charge operations, and accounts for the full lifecycle including refunds and disputes.
+</objective>
+
+<execution_context>
+@.mindforge/skills/payment-integration/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (payment flow type, optional --provider, optional --recurring flag)
+Knowledge: PCI DSS requirements, payment provider documentation, existing payment infrastructure, business rules for pricing/billing.
+</context>
+
+<process>
+1. **Design Payment State Machine**: Model all payment states (pending, processing, succeeded, failed, refunded, disputed) and valid transitions. Include timeout states and partial states (partial refund, partial capture). Visualize as a state diagram.
+2. **Implement Client-Side Tokenization**: Use the provider's client-side SDK (Stripe Elements, Braintree Drop-in) to tokenize card data in the browser. Server never sees raw card numbers — this reduces PCI scope to SAQ-A or SAQ-A-EP.
+3. **Set Up Webhook Handling**: Implement webhook endpoint with: signature verification (reject unverified), idempotent processing (dedup by event ID), async processing (acknowledge quickly, process in background), and ordered handling for related events.
+4. **Add Idempotency Keys To All Charges**: Every charge request must include an idempotency key (client-generated UUID). Store key-to-result mapping. On retry, return cached result instead of double-charging.
+5. **Implement Retry Logic For Failures**: Design retry strategy: exponential backoff for transient failures (network, 5xx), immediate fail for permanent errors (card declined, insufficient funds), and alert on repeated failures for the same customer.
+6. **Design Refund Flow**: Support full and partial refunds. Track refund reason codes. Implement refund limits (cannot refund more than charged). Handle refund-after-dispute edge case. Update accounting records atomically.
+7. **Set Up Daily Reconciliation**: Implement automated daily reconciliation between: internal payment records, provider settlement reports, and accounting system. Alert on discrepancies > threshold. Resolve within 24 hours.
+8. **Handle Disputes And Chargebacks**: Design dispute response workflow: auto-collect evidence (receipts, delivery proof, usage logs), notify team within SLA, track win rate, and implement prevention measures for common dispute reasons.
+9. **Document Edge Cases**: Catalog and handle: currency conversion timing, 3D Secure flows, subscription payment retries, card expiration mid-subscription, account updater responses, and cross-border payment restrictions.
+</process>

package/.claude/commands/mindforge/pipeline.md

@@ -0,0 +1,84 @@
+---
+description: "Design CI/CD pipeline architecture. Usage: /mindforge:pipeline [--platform github|gitlab|jenkins] [--stages N]"
+---
+
+<objective>
+Design a comprehensive CI/CD pipeline architecture with quality gates, caching, secret management, parallelism, environment promotion, and rollback mechanisms.
+</objective>
+
+<execution_context>
+@.mindforge/skills/ci-cd-pipeline/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (optional --platform github|gitlab|jenkins, optional --stages N for stage count)
+Knowledge: Current repository structure, existing CI configuration, deployment targets, test suite characteristics.
+</context>
+
+<process>
+1. **Define stages**: Design the pipeline stages in order:
+   - **Lint**: Static analysis, formatting check, type-check (parallel)
+   - **Build**: Compile, bundle, generate artifacts
+   - **Test**: Unit tests, integration tests, contract tests (parallel by suite)
+   - **Scan**: Security scan (SAST, dependency audit, secret detection)
+   - **Package**: Container build, artifact versioning, manifest generation
+   - **Deploy**: Environment promotion (dev → staging → production)
+   - Each stage has clear entry/exit criteria (quality gates)
+
+2. **Add quality gates**: Define pass/fail criteria per stage:
+   - Lint: zero errors (warnings allowed with suppression comments)
+   - Build: successful compilation, artifact size within budget
+   - Test: 100% pass rate, coverage >= threshold (80% default)
+   - Scan: zero critical/high vulnerabilities, no leaked secrets
+   - Package: image builds successfully, passes container scan
+   - Deploy: health check passes within 60s, no error spike in 5min
+   - Gate failure blocks pipeline progression (no manual override without approval)
+
+3. **Configure caching**: Optimize pipeline speed:
+   - Dependencies: cache node_modules/pip/cargo by lockfile hash
+   - Build artifacts: cache intermediate compilation outputs
+   - Docker layers: cache base layers, invalidate on Dockerfile change
+   - Test results: cache unchanged test file results (incremental testing)
+   - Cache key strategy: OS + lockfile hash + branch (with fallback to main)
+   - Cache TTL: 7 days for dependencies, 1 day for build artifacts
+
+4. **Manage secrets**: Secure credential handling:
+   - Environment-specific secrets (dev, staging, prod) in vault/secrets manager
+   - Short-lived tokens for deployment (OIDC where possible)
+   - No secrets in pipeline YAML (reference by name only)
+   - Secret rotation: automated rotation with zero-downtime
+   - Audit log: track which pipeline accessed which secret
+   - Least privilege: each stage only accesses secrets it needs
+
+5. **Enable parallelism**: Maximize pipeline throughput:
+   - Independent stages run in parallel (lint + type-check + unit-test)
+   - Test suite splitting by file/timing data across N runners
+   - Matrix builds for multi-platform/multi-version testing
+   - Fan-out/fan-in for independent service deployments
+   - Resource constraints: limit concurrent deployments to prevent thundering herd
+   - Estimated total pipeline time: < 10 minutes for PR, < 20 minutes for deploy
+
+6. **Set up environment promotion**: Define the deployment ladder:
+   - Dev: auto-deploy on push to feature branch (ephemeral environments)
+   - Staging: auto-deploy on merge to main (persistent, production-mirror)
+   - Production: manual approval gate or automated canary with auto-promote
+   - Promotion criteria: all tests pass + no new alerts + stakeholder approval
+   - Environment parity: same container, same config structure, different values
+   - Feature flags: decouple deploy from release (dark launches)
+
+7. **Add rollback mechanism**: Design recovery paths:
+   - Automated rollback: revert to last-known-good on health check failure
+   - Manual rollback: one-click revert in CI UI with confirmation
+   - Database rollback: backward-compatible migrations only (expand-contract)
+   - Canary rollback: automatic if error rate exceeds baseline by 2x
+   - Rollback verification: post-rollback health check confirms recovery
+   - Incident tracking: auto-create incident ticket on rollback trigger
+
+8. **Output pipeline specification**: Deliver:
+   - Pipeline YAML/configuration for the target platform
+   - Stage dependency graph (DAG visualization)
+   - Timing estimates per stage
+   - Secret inventory and access matrix
+   - Rollback runbook
+   - Cost estimate (runner minutes per PR and per deploy)
+</process>

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

@@ -0,0 +1,131 @@
+---
+description: Plan a project phase. Usage: /mindforge:plan-phase [N]
+---
+
+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. `AGENTS_LEARNING.md` (MUST READ to avoid repeating past mistakes)
+2. `.planning/PROJECT.md`
+3. `.planning/REQUIREMENTS.md`
+4. `.planning/ARCHITECTURE.md`
+5. `.planning/STATE.md`
+6. `.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. Project-specific anti-patterns from `AGENTS_LEARNING.md`
+4. Relevant architectural patterns (with tradeoffs)
+5. 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/plan-write.md

@@ -0,0 +1,95 @@
+---
+description: "Generate no-placeholder implementation plan with complete steps. Usage: /mindforge:plan-write [spec-or-description] [--steps N] [--verify]"
+---
+
+<objective>
+Produce a complete, zero-placeholder implementation plan where every step contains exact file paths, complete code, and verification commands. No TODOs, no "implement here", no ambiguity — every step is directly executable.
+</objective>
+
+<execution_context>
+@.mindforge/skills/writing-plans/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (specification text or file path, optional --steps N for target step count, optional --verify to include verification per step)
+Knowledge: ARCHITECTURE.md, CONVENTIONS.md, current codebase structure, dependency graph.
+</context>
+
+<process>
+1. **Parse spec**: Read and understand the specification or description:
+   - If argument is a file path: read the file content
+   - If argument is inline text: parse as the requirement
+   - Identify the scope: what files need to change, what new files are needed
+   - Identify constraints: performance, security, backward compatibility
+   - Determine target step count (--steps N, default: auto-size based on complexity)
+
+2. **Decompose into bite-sized steps**: Break the work into atomic steps where each step:
+   - Changes 1-3 files maximum
+   - Can be verified independently
+   - Builds on the previous step (no forward references)
+   - Is small enough to hold entirely in working memory
+   - Has a clear "done" state visible from the outside
+
+3. **For each step — specify exact file paths**: Every step must state:
+   - Full absolute file path(s) being created or modified
+   - Whether the file is new (create) or existing (modify)
+   - The specific location within the file (after which function, which line range)
+   - Import/dependency changes needed for this step
+
+4. **For each step — provide complete code**: Every step must include:
+   - The exact code to write or the exact diff to apply
+   - No placeholder comments ("// TODO: implement this")
+   - No ellipsis ("...")  or abbreviated code
+   - No "similar to above" references — repeat if needed
+   - Complete import statements at the top of new files
+   - Full function signatures with types
+
+5. **Add verification per step** (always if --verify, otherwise for critical steps):
+   - Command to run that proves the step works (test, build, lint, curl)
+   - Expected output or success criteria
+   - What to do if verification fails (specific fix, not "debug")
+   - Verification must be automated (no manual "check in browser")
+
+6. **Number dependencies**: For each step, declare:
+   - `depends_on: [step numbers]` — which steps must complete first
+   - `parallelizable_with: [step numbers]` — which steps can run concurrently
+   - `blocks: [step numbers]` — which steps are waiting on this one
+   - This enables parallel execution where possible
+
+7. **Handle existing code**: When modifying existing files:
+   - Show the exact lines being replaced (old code)
+   - Show the exact replacement (new code)
+   - Include enough context (3-5 surrounding lines) for unambiguous placement
+   - Note if the change requires changes in other files (ripple effects)
+
+8. **Include rollback instructions**: For risky steps:
+   - What to revert if the step causes problems
+   - Git command to undo (specific commit or file checkout)
+   - Whether downstream steps need adjustment after rollback
+
+9. **Output plan document**: Write the plan in structured format:
+   ```
+   # Implementation Plan: [title]
+   ## Metadata
+   - Total steps: N
+   - Estimated effort: [time]
+   - Risk level: low|medium|high
+   - Parallelizable steps: [list]
+   
+   ## Step 1: [descriptive title]
+   - Files: [exact paths]
+   - Depends on: none
+   - Code: [complete implementation]
+   - Verify: [command + expected output]
+   
+   ## Step 2: ...
+   ```
+
+10. **Final validation**: Before outputting, verify the plan:
+    - Every file referenced actually exists (for modifications) or has a create step
+    - No circular dependencies between steps
+    - Import graph is consistent (nothing imports from a file not yet created)
+    - All types/interfaces referenced are defined somewhere in the plan
+    - Running all steps in order produces a working, compilable result
+    - No placeholders, TODOs, or ambiguous instructions remain
+</process>

package/.claude/commands/mindforge/plant-seed.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:plant-seed
+description: Capture speculative ideas with triggers that surface automatically when relevant
+argument-hint: <idea>
+allowed-tools:
+  - list_dir
+  - write_to_file
+  - view_file
+---
+
+<objective>
+Capture speculative or long-term ideas (seeds) and store them in a way that they can be automatically resurfaced when a relevant future milestone or phase is started.
+</objective>
+
+<execution_context>
+.claude/commands/mindforge/plant-seed.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (The speculative idea)
+Storage: .planning/seeds/
+Trigger mechanism: Files in this directory are checked during `init-project` or `milestone` creation.
+</context>
+
+<process>
+1. **Ensure storage**: Verify `.planning/seeds/` exists; create if not.
+2. **Generate filename**: Create a slugified filename based on the idea or a timestamp.
+3. **Write seed**: Create a markdown file with the idea, any inferred triggers (tags/keywords), and the current timestamp.
+4. **Link to system**: Add a note to the master seed index if one exists.
+5. **Confirm**: Let the user know the seed has been planted and what might trigger its resurrection.
+</process>

package/.claude/commands/mindforge/platform.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:platform
+description: "Design internal developer platform. Usage: /mindforge:platform [scope] [--tool backstage|custom] [--teams number]"
+argument-hint: "[scope] [--tool backstage|custom] [--teams number]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design comprehensive platform system architecture with best practices and production-ready patterns.
+</objective>
+
+<execution_context>
+@.mindforge/skills/internal-developer-platform/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/internal-developer-platform/`
+State: Analyzes requirements, constraints, and scale to generate optimized platform architecture.
+</context>
+
+<process>
+1. **Requirement Analysis**: Analyze domain-specific requirements, performance constraints, and scalability needs.
+2. **Architecture Design**: Design system architecture with component interaction patterns and data flow.
+3. **Technology Selection**: Evaluate and select appropriate technologies, tools, and frameworks.
+4. **Integration Strategy**: Define integration patterns with existing systems and external dependencies.
+5. **Optimization Approach**: Implement performance, cost, and resource optimization strategies.
+6. **Monitoring Framework**: Design observability, alerting, and debugging mechanisms.
+7. **Deployment Planning**: Create deployment strategy with rollback procedures and disaster recovery.
+</process>

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

@@ -0,0 +1,44 @@
+---
+description: Read PLUGINS-MANIFEST.md. Display installed plugins with version and permissions.
+---
+
+# 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,45 @@
+---
+description: Run the AI PR review engine on a pull request diff.
+---
+
+# 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/privacy-eng.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:privacy-eng
+description: "Design data privacy engineering system. Usage: /mindforge:privacy-eng [system] [--regulation gdpr|ccpa|hipaa] [--technique anonymization|differential|encryption]"
+argument-hint: "[system] [--regulation gdpr|ccpa|hipaa] [--technique anonymization|differential|encryption]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design comprehensive privacy-eng system architecture with best practices and production-ready patterns.
+</objective>
+
+<execution_context>
+@.mindforge/skills/data-privacy-engineering/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/data-privacy-engineering/`
+State: Analyzes requirements, constraints, and scale to generate optimized privacy-eng architecture.
+</context>
+
+<process>
+1. **Requirement Analysis**: Analyze domain-specific requirements, performance constraints, and scalability needs.
+2. **Architecture Design**: Design system architecture with component interaction patterns and data flow.
+3. **Technology Selection**: Evaluate and select appropriate technologies, tools, and frameworks.
+4. **Integration Strategy**: Define integration patterns with existing systems and external dependencies.
+5. **Optimization Approach**: Implement performance, cost, and resource optimization strategies.
+6. **Monitoring Framework**: Design observability, alerting, and debugging mechanisms.
+7. **Deployment Planning**: Create deployment strategy with rollback procedures and disaster recovery.
+</process>