mindforge-cc 11.3.0 → 11.3.1

package/.claude/commands/mindforge/embeddings.md

@@ -0,0 +1,37 @@
+---
+name: mindforge:embeddings
+description: "Design embedding and vector search system. Usage: /mindforge:embeddings [domain] [--db pinecone|weaviate|qdrant|pgvector] [--hybrid true|false]"
+argument-hint: "[domain] [--db pinecone|weaviate|qdrant|pgvector] [--hybrid true|false]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design a comprehensive embedding and vector search system for semantic retrieval, recommendation engines, or similarity matching. This command creates architecture for embedding generation, vector database selection, indexing strategies, and hybrid search combining dense vectors with keyword search for optimal recall and precision.
+</objective>
+
+<execution_context>
+@.mindforge/skills/embedding-systems/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/embedding-systems/`
+State: Analyzes domain requirements, data characteristics, query patterns, and scale constraints to recommend embedding models, vector databases, indexing configurations, and retrieval strategies.
+</context>
+
+<process>
+1. **Domain and Data Analysis**: Characterize input data types (text, images, multimodal), assess volume and dimensionality, analyze query patterns (exact match, semantic similarity, filtering), and define latency/throughput requirements.
+
+2. **Embedding Model Selection**: Recommend models by domain (text: OpenAI ada-002/text-embedding-3, Cohere, E5; images: CLIP, DINOv2), evaluate trade-offs (dimensionality vs accuracy, speed vs quality), and specify fine-tuning requirements for domain adaptation.
+
+3. **Vector Database Architecture**: Compare database options (Pinecone for managed simplicity, Qdrant for control, Weaviate for multimodal, pgvector for SQL integration), design sharding and replication strategies for scale, and specify index types (HNSW, IVF, flat) based on query patterns.
+
+4. **Hybrid Search Implementation**: Design keyword search integration (BM25, Elasticsearch) alongside vector search, implement score fusion strategies (RRF, weighted combination), and optimize for both semantic understanding and exact term matching.
+
+5. **Indexing and Optimization**: Configure HNSW parameters (M, ef_construction) for speed/accuracy balance, implement quantization (product quantization, scalar quantization) for memory efficiency, and design incremental indexing for real-time updates.
+
+6. **Query Optimization**: Implement query preprocessing (normalization, expansion, reranking), design filtered search with metadata constraints, and create multi-stage retrieval pipelines (coarse-to-fine, two-tower reranking).
+
+7. **Monitoring and Evaluation**: Define retrieval quality metrics (precision@k, recall@k, MRR, NDCG), implement latency tracking and cost monitoring per query, and design A/B testing framework for embedding model comparisons.
+</process>

package/.claude/commands/mindforge/environments.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:environments
+description: "Design environment management system. Usage: /mindforge:environments [scope] [--type preview|ephemeral|staging] [--lifecycle hours|days|permanent]"
+argument-hint: "[scope] [--type preview|ephemeral|staging] [--lifecycle hours|days|permanent]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design comprehensive environments system architecture with best practices and production-ready patterns.
+</objective>
+
+<execution_context>
+@.mindforge/skills/environment-management/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/environment-management/`
+State: Analyzes requirements, constraints, and scale to generate optimized environments 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/eval.md

@@ -0,0 +1,33 @@
+---
+description: Score the last task using eval-harness rubrics and track pass@k metrics. Usage - /mindforge:eval [eval-name] [--grader code|model|human] [--k 5] [--type capability|regression]
+---
+
+<objective>
+Apply structured evaluation to the last task output, tracking metrics over time
+to detect capability regression and measure improvement.
+</objective>
+
+<execution_context>
+@.mindforge/skills/eval-harness/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Parse eval-name (required — identifies the evaluation being run).
+2. Load or create eval config from `.mindforge/evals/[eval-name]/config.json`.
+3. Determine grader type: --grader code (deterministic assertions) | model (LLM-as-judge) | human (flag for review).
+4. Determine eval type: --type capability (new feature) or regression (existing behavior).
+5. If pass@k requested (--k N): generate N outputs for the same input.
+6. Apply grading rubric from `.mindforge/evals/[eval-name]/rubric.md`.
+7. For code grader: run assertions, compute binary pass/fail per criterion.
+8. For model grader: score each criterion 1-5 with reasoning, compute average.
+9. For human grader: present output with rubric, collect scores interactively.
+10. Compute pass@k: how many of k attempts passed all criteria.
+11. Compare result to baseline in `results.jsonl` — detect regression (score drop > 10%).
+12. Append result to `.mindforge/evals/[eval-name]/results.jsonl`.
+13. Report: score, pass@k, trend (improving/stable/regressing), delta from baseline.
+14. Log eval event in AUDIT.
+</process>

package/.claude/commands/mindforge/events.md

@@ -0,0 +1,30 @@
+---
+description: Design event-driven message flow with ordering and delivery guarantees. Usage - /mindforge:events [domain] [--broker kafka|rabbitmq|sqs] [--guarantee at-least-once]
+---
+
+<objective>
+Design an event-driven architecture with explicit ordering guarantees, delivery
+semantics, and failure handling. Covers event schema design, partitioning
+strategy, consumer idempotency, and dead letter handling.
+</objective>
+
+<execution_context>
+@.mindforge/skills/event-driven-architecture/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Identify domain events by analyzing state transitions and side effects. Name events in past tense (OrderPlaced, PaymentProcessed). Map event flows between bounded contexts.
+2. Design event schemas using Avro or Protobuf with a schema registry. Include metadata envelope (event_id, timestamp, correlation_id, causation_id, schema_version). Plan for schema evolution (backward/forward compatibility).
+3. Configure partitioning strategy using entity ID as partition key to guarantee ordering within an entity (e.g., all events for order-123 go to same partition). Calculate partition count based on throughput needs.
+4. Set delivery guarantees based on --guarantee flag: at-least-once (default, requires idempotent consumers), at-most-once (fire-and-forget, acceptable loss), or exactly-once (transactional outbox + idempotent consumer).
+5. Implement idempotent consumers using deduplication strategies: idempotency key table (event_id + consumer_id), natural idempotency (SET operations), or conditional writes (optimistic locking with version).
+6. Configure dead letter topics/queues for messages that fail after max retries. Set up alerting on DLQ depth, implement DLQ replay tooling, and define manual review workflow for poison messages.
+7. Build an event catalog documenting every event type: schema, producer, consumers, SLA (max processing latency), retention period, and example payloads. Keep catalog as code alongside schemas.
+8. Set up monitoring: consumer lag (how far behind real-time), processing latency (event age at consumption), error rate per consumer group, and partition skew detection.
+9. Design the transactional outbox pattern for reliable event publishing: write event to outbox table in same transaction as state change, poll/CDC outbox to broker, mark as published.
+10. Log events invocation in AUDIT with: domain, broker, guarantee level, event count, partition strategy.
+</process>

package/.claude/commands/mindforge/evolve-skills.md

@@ -0,0 +1,49 @@
+---
+description: Review mature instincts and promote qualifying ones to full skills. Usage - /mindforge:evolve-skills [--dry-run] [--threshold 0.85] [--min-applications 5]
+---
+
+<objective>
+Scan the instinct store for entries that have proven themselves through repeated
+successful application, and promote them to full MindForge skills.
+</objective>
+
+<execution_context>
+@.mindforge/engine/instincts/promotion-engine.md
+@.mindforge/engine/instincts/instinct-schema.md
+@.mindforge/skills/continuous-learning/SKILL.md
+@.mindforge/org/skills/MANIFEST.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Parse flags: --dry-run (show candidates without acting), --threshold (confidence minimum, default 0.85), --min-applications (default 5).
+2. Read `.mindforge/engine/instincts/instinct-store.jsonl`.
+3. **Identify candidates** meeting ALL criteria:
+   - confidence >= threshold
+   - times_applied >= min-applications
+   - times_succeeded >= 80% of times_applied
+   - status == "active"
+   - No existing skill covers same behavior (check MANIFEST.md triggers)
+4. **Rank candidates** by impact score: confidence * times_applied.
+5. **Present candidates** to user:
+   ```
+   Promotion Candidates (ranked by impact):
+   1. [observation] — confidence: 0.92, applied: 12x, success: 11/12
+   2. [observation] — confidence: 0.88, applied: 7x, success: 6/7
+   ```
+6. If --dry-run: stop here, report what would be promoted.
+7. **For each approved candidate:**
+   a. Generate SKILL.md draft:
+      - name: derived from instinct tags
+      - triggers: derived from observation keywords
+      - content: expanded from behavior field
+   b. Create `.mindforge/skills/[name]/SKILL.md`
+   c. Add entry to MANIFEST.md (Project tier by default)
+   d. Mark instinct as promoted: `"status": "promoted", "promoted_to_skill": "[name]"`
+8. Report: "Promoted [N] instincts to skills. New skills: [list]."
+9. Log in AUDIT: skill_promoted events with instinct_id and skill_name.
+10. Remind: "Monitor promoted skills — if they prove unhelpful, they can be reverted."
+</process>

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

@@ -0,0 +1,200 @@
+---
+description: 1. Read STATE.md — confirm phase [N] is in "planned" status.
+---
+
+# MindForge — Execute Phase Command
+# Usage: /mindforge:execute-phase [N]
+
+## Pre-checks (all must pass before execution starts)
+
+1. Read STATE.md — confirm phase [N] is in "planned" status.
+   If STATE.md shows phase [N] as already "complete": ask user to confirm re-execution.
+
+2. Verify plan files exist:
+   ```
+   .planning/phases/[N]/PLAN-[N]-01.md   (minimum one plan required)
+   ```
+   If missing: stop. Tell user: "No plans found for Phase [N]. Run /mindforge:plan-phase [N] first."
+
+3. Verify REQUIREMENTS.md exists and has content.
+   If empty: warn user but allow continuation.
+
+4. Run the dependency parser (`.mindforge/engine/dependency-parser.md`).
+   If validation fails (circular deps, missing deps): stop and report. Do not execute.
+
+## Step 1 — Build and display the execution plan
+
+After dependency parsing succeeds, display the wave plan to the user:
+
+```
+Phase [N] Execution Plan
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  Wave 1 (parallel)     Wave 2 (parallel)     Wave 3
+  ┌─────────────┐       ┌─────────────┐       ┌─────────────┐
+  │ Plan 01     │       │ Plan 03     │       │ Plan 05     │
+  │ User model  │──┐    │ User API    │──┐    │ Checkout UI │
+  └─────────────┘  │    └─────────────┘  │    └─────────────┘
+  ┌─────────────┐  │    ┌─────────────┐  │
+  │ Plan 02     │──┘    │ Plan 04     │──┘
+  │ Product     │       │ Product API │
+  └─────────────┘       └─────────────┘
+
+  Total tasks: 5    Waves: 3    Est. time: depends on model speed
+
+Proceed? (yes/no)
+```
+
+If the user says no: stop. Do not execute anything.
+
+## Step 2 — Write pre-execution audit entry
+
+Append to `.planning/AUDIT.jsonl`:
+```json
+{
+  "id": "[uuid-v4]",
+  "timestamp": "[ISO-8601]",
+  "event": "phase_execution_started",
+  "phase": [N],
+  "wave_count": [total waves],
+  "task_count": [total tasks],
+  "agent": "mindforge-orchestrator",
+  "session_id": "[session identifier]"
+}
+```
+
+## Step 3 — Execute waves using the wave executor
+
+Follow the complete protocol in `.mindforge/engine/wave-executor.md`.
+
+For each wave:
+
+### Wave start
+Write to console:
+```
+━━━ Wave [W] of [total] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  Starting [X] tasks in parallel...
+```
+
+### Per-task execution (inject context per `context-injector.md`)
+For each plan in the wave:
+1. Load context package (per `context-injector.md`)
+2. Execute the plan instructions
+   - Run `<verify>` — capture exact output
+   - If verify PASSES:
+     - Run `<verify-visual>` via `visual-verify-executor.js`
+     - If visual verify FAILS: stop and report (treat as verify failure)
+     - Write SUMMARY-[N]-[M].md
+   - Execute commit: `git add [files] && git commit -m "[type]([scope]): [task name]"`
+   - Capture git SHA
+   - Write AUDIT entry for task completion
+5. If verify FAILS:
+   - Write SUMMARY-[N]-[M].md with failure details
+   - Write AUDIT entry for task failure
+   - STOP this wave immediately
+   - Report: "Task [plan ID] failed: [verify output]. Stopping Phase [N]."
+   - Do not start next wave
+   - Ask user: "Spawn debug agent to diagnose? (yes/no)"
+
+### Wave completion (before starting next wave)
+After all tasks in wave complete:
+1. Run: `[project test command]`
+2. If tests fail:
+   - Identify failing tests
+   - Run `git log --oneline -[wave-task-count]` to see wave commits
+   - Report which commit likely introduced the failure
+   - Stop. Ask user how to proceed.
+3. If tests pass:
+   - Report: "Wave [W] complete. All [X] tasks passed. Tests passing. ✅"
+   - Run `/mindforge:record-learning` if any architectural "Aha!" moments or significant anti-patterns were discovered during this wave.
+   - Write WAVE-REPORT update
+
+## Step 4 — Phase-level verification
+
+After all waves complete, run the verification pipeline:
+
+1. Read every v1 requirement from REQUIREMENTS.md for this phase
+2. For each requirement, verify it is implemented:
+   - Search the codebase for the implementation
+   - Check if a test covers it
+   - Mark: ✅ implemented + tested | ⚠️ implemented, no test | ❌ not found
+3. Write `.planning/phases/[N]/VERIFICATION.md`
+4. Run the full test suite one final time
+5. If any requirement is ❌: create a fix plan and report to user
+
+## Step 5 — Update state and write wave report
+
+Write `.planning/phases/[N]/WAVE-REPORT-[N].md` (per template in wave-executor.md)
+
+Update STATE.md:
+```markdown
+## Current phase
+[N] — Execution complete ✅
+
+## Last completed task
+Phase [N]: All [X] tasks completed across [W] waves.
+
+## Next action
+Run /mindforge:verify-phase [N] for human acceptance testing.
+```
+
+Update HANDOFF.json with completed phase info.
+
+## Step 5.1 — Final Intelligence Sync
+1. Read `AGENTS_LEARNING.md` one last time.
+2. Run `/mindforge:record-learning` to capture the final phase-level learnings (Mistakes discovered during UAT, architectural refinements).
+3. Commit `AGENTS_LEARNING.md` if updated.
+
+Write final AUDIT entry:
+```json
+{
+  "id": "[uuid-v4]",
+  "timestamp": "[ISO-8601]",
+  "event": "phase_execution_completed",
+  "phase": [N],
+  "tasks_completed": [X],
+  "waves_executed": [W],
+  "commits": ["sha1", "sha2", "..."],
+  "test_result": "passing",
+  "agent": "mindforge-orchestrator"
+}
+```
+
+## Step 6 — Report to user
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+✅ Phase [N] execution complete
+
+  Tasks completed : [X] / [X]
+  Waves executed  : [W]
+  Commits made    : [X]
+  Tests           : All passing
+  Requirements    : [X] / [X] implemented
+
+Next step: Run /mindforge:verify-phase [N] for UAT sign-off.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+## Step 7 — Auto-capture check (when AUTO_CAPTURE_SKILLS=true)
+
+After all gates pass and the phase is verified:
+
+```bash
+# Check if auto-capture is enabled
+CAPTURE=$(grep -m1 "^AUTO_CAPTURE_SKILLS=" MINDFORGE.md 2>/dev/null | cut -d= -f2 | tr -d ' ')
+if [ "$CAPTURE" = "true" ]; then
+  node -e "
+    const { detectPatterns, formatForPresentation } = require('./bin/skills-builder/pattern-detector');
+    detectPatterns(${PHASE_NUM}).then(result => {
+      const display = formatForPresentation(result);
+      console.log(display);
+    }).catch(err => console.error('[auto-capture] Error:', err.message));
+  "
+fi
+```
+
+If patterns are found: display the prompt and await user input.
+If user selects yes: run `/mindforge:learn --session` targeting this phase's SUMMARY files.
+If user selects no: write AUDIT entry `auto_capture_skipped` and continue.
+If no patterns found: exit silently (no noise in the output).
+```

package/.claude/commands/mindforge/experiment.md

@@ -0,0 +1,28 @@
+---
+description: "Design A/B test with statistical rigor. Usage: /mindforge:experiment [feature] [--metric conversion|engagement|revenue] [--duration 2w]"
+---
+
+<objective>
+Design a statistically rigorous A/B experiment with proper hypothesis formation, sample size calculation, guardrail metrics, and pre-registered decision rules to avoid p-hacking and ensure valid conclusions.
+</objective>
+
+<execution_context>
+@.mindforge/skills/experiment-design/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (feature or change being tested, optional --metric, optional --duration)
+Knowledge: Current baseline metrics, traffic volume, previous experiment results, business goals.
+</context>
+
+<process>
+1. **Form Hypothesis**: Write a falsifiable hypothesis in the format: "If we [change X], then [metric Y] will [increase/decrease] by [minimum detectable effect Z%], because [theory]." Distinguish between exploratory and confirmatory experiments.
+2. **Define Primary Metric and Guardrails**: Select one primary metric (the decision metric) and 2-4 guardrail metrics that must not degrade. Define what "degradation" means quantitatively for each guardrail.
+3. **Calculate Required Sample Size**: Using baseline conversion rate, minimum detectable effect, significance level (default alpha=0.05), and power (default 0.8), calculate the required sample size per variant. Account for multiple comparisons if testing more than 2 variants.
+4. **Choose Randomization Unit**: Select the randomization unit (user, session, device, organization). Consider: consistency of experience, network effects, and statistical independence. Document why.
+5. **Set Experiment Duration**: Run for at least 1 full business cycle (typically 1-2 weeks minimum). Account for day-of-week effects, novelty effects, and learning effects. Never peek at results before predetermined end date.
+6. **Design Variants**: Define control and treatment(s) precisely. Document the exact user experience for each variant. Ensure only one variable changes between variants (isolation).
+7. **Configure Analysis Plan**: Pre-register the statistical test (t-test, chi-squared, Mann-Whitney), correction method for multiple comparisons (Bonferroni, Holm), and segmentation plan. Document before launching.
+8. **Define Success Criteria**: Specify the exact threshold for shipping: primary metric improvement is statistically significant AND guardrails are not violated AND practical significance (effect size) justifies the complexity.
+9. **Document Decision Rules**: Pre-commit to outcomes: if significant positive = ship; if significant negative = kill; if inconclusive = extend duration or iterate on treatment. Define "inconclusive" precisely.
+</process>

package/.claude/commands/mindforge/feature-flags.md

@@ -0,0 +1,30 @@
+---
+description: Design feature flag strategy with lifecycle management. Usage - /mindforge:feature-flags [feature] [--type release|experiment|operational] [--rollout 5%]
+---
+
+<objective>
+Design a feature flag strategy with full lifecycle management — from creation
+through gradual rollout to cleanup. Covers flag typing, targeting rules,
+kill switches, success metrics, and mandatory flag removal deadlines.
+</objective>
+
+<execution_context>
+@.mindforge/skills/feature-flag-management/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Classify the flag type based on --type flag: release (temporary, gates incomplete feature, remove after launch), experiment (A/B test with metrics, remove after decision), or operational (long-lived, controls system behavior like rate limits or circuit breakers).
+2. Define targeting rules: percentage rollout (--rollout flag), user segment targeting (beta users, internal, enterprise), geographic targeting, or device/platform targeting. Use consistent hashing on user ID for sticky assignment.
+3. Set the rollout percentage and define the rollout plan: 5% (canary) -> 25% (early adopters) -> 50% (half) -> 100% (GA). Define success criteria for each stage gate (error rate, latency, business metrics).
+4. Configure kill switch: every flag must have an emergency off switch that immediately disables the feature for all users. Kill switch activation should not require a deploy — remote config only.
+5. Define success metrics that determine whether the flag should be fully enabled or rolled back: conversion rate, error rate delta, latency impact, user engagement, and business KPIs specific to the feature.
+6. Set cleanup deadline: release flags must be removed within 90 days of 100% rollout. Experiment flags within 30 days of decision. Create a tracking ticket for flag removal at flag creation time.
+7. Implement flag evaluation in code: use SDK with local caching (no network call per evaluation), provide sensible defaults for SDK initialization failure, and log flag evaluations for debugging.
+8. Plan flag removal process: remove flag check from code, remove flag from configuration, verify no references remain (grep), and deploy. Ensure removal is atomic (single PR, not split across deploys).
+9. Set up flag hygiene tooling: dashboard showing all active flags with age, lint rules that warn on flags past deadline, automated Slack notifications for stale flags, and quarterly flag audit.
+10. Log feature-flags invocation in AUDIT with: feature name, flag type, initial rollout percentage, cleanup deadline, targeting rules.
+</process>

package/.claude/commands/mindforge/feature-store.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:feature-store
+description: "Design ML feature store. Usage: /mindforge:feature-store [domain] [--store feast|tecton|vertex] [--type batch|realtime|both]"
+argument-hint: "[domain] [--store feast|tecton|vertex] [--type batch|realtime|both]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design comprehensive feature-store system architecture.
+</objective>
+
+<execution_context>
+@.mindforge/skills/ml-feature-store/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/ml-feature-store/`
+State: Analyzes requirements and constraints to generate feature-store architecture.
+</context>
+
+<process>
+1. **Requirement Analysis**: Analyze domain-specific requirements and constraints.
+2. **Architecture Design**: Design scalable system architecture with best practices.
+3. **Component Selection**: Select appropriate technologies and tools for implementation.
+4. **Integration Strategy**: Define integration patterns with existing systems.
+5. **Optimization Approach**: Implement performance and cost optimization strategies.
+6. **Monitoring Framework**: Design observability and alerting mechanisms.
+7. **Deployment Planning**: Create deployment strategy with rollback procedures.
+</process>

package/.claude/commands/mindforge/finops.md

@@ -0,0 +1,31 @@
+---
+description: Estimate and optimize cloud infrastructure costs. Usage - /mindforge:finops [service] [--forecast 6m] [--target-savings 20%]
+---
+
+<objective>
+Estimate current cloud infrastructure costs, identify optimization opportunities,
+model cost reduction alternatives, and create an actionable implementation plan
+that achieves the target savings percentage without degrading service reliability
+or performance within the forecast period.
+</objective>
+
+<execution_context>
+@.mindforge/skills/cost-estimation/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Inventory current resources by category: compute (instances, containers, serverless), storage (block, object, database), network (egress, load balancers, CDN), and managed services (queues, caches, search). Tag each with monthly cost and owner team.
+2. Measure utilization for each resource: CPU average/peak, memory average/peak, storage used vs provisioned, network bandwidth vs capacity. Flag resources with average utilization below 30% as candidates for right-sizing.
+3. Identify waste across categories: unused resources (no traffic for 7+ days), oversized instances (peak utilization < 50% of capacity), idle load balancers, unattached volumes, orphaned snapshots, and over-provisioned databases.
+4. Model cost alternatives based on --target-savings: reserved instances (1yr/3yr commitment for steady-state), spot/preemptible for fault-tolerant workloads, smaller instance families, ARM-based options, and serverless conversion for spiky workloads. Calculate break-even for each.
+5. Estimate savings per optimization: calculate monthly/annual savings, implementation effort (hours), risk level (low/medium/high), and payback period. Rank by savings-to-effort ratio.
+6. Create implementation plan with phases: Phase 1 (quick wins, <1 day, no risk), Phase 2 (right-sizing, 1 week, low risk), Phase 3 (architectural changes, 1 month, medium risk). Include rollback plan for each phase.
+7. Set up cost alerts and budgets: configure alerts at 80%/100%/120% of monthly budget, per-team cost allocation tags, anomaly detection for unexpected spikes (>20% day-over-day), and weekly cost reports to stakeholders.
+8. Track reduction over --forecast period: establish baseline month, measure actual vs projected savings, identify new cost growth areas, and adjust plan quarterly. Report ROI of optimization effort (hours saved in cost / hours invested).
+9. Design cost governance policies: mandatory resource tagging, auto-shutdown for dev/staging outside business hours, maximum instance size without approval, and reserved instance utilization monitoring.
+10. Log FinOps analysis in AUDIT with: service, current monthly cost, identified savings, target savings percentage, implementation phases, and forecast period.
+</process>

package/.claude/commands/mindforge/fintech.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:fintech
+description: "Design fintech payment/ledger architecture. Usage: /mindforge:fintech [service] [--domain payments|ledger|kyc] [--compliance pci|sox]"
+argument-hint: "[service] [--domain payments|ledger|kyc] [--compliance pci|sox]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Designs secure, compliant fintech architectures for payment processing, double-entry ledgers, and KYC/AML systems. Produces PCI-DSS and SOX-compliant designs with idempotency guarantees, audit trails, and fraud detection patterns for financial service applications.
+</objective>
+
+<execution_context>
+@.mindforge/skills/fintech-patterns/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/fintech-patterns/`
+State: Evaluates fintech service requirements, compliance domains (PCI-DSS, SOX, KYC/AML), and produces architectures with transaction integrity, idempotency, reconciliation, and fraud prevention mechanisms.
+</context>
+
+<process>
+1. **Domain Analysis**: Identify fintech domain (payment gateway, ledger system, KYC verification, lending platform) and classify transaction types, monetary precision requirements, and regulatory scope.
+2. **Compliance Framework**: Map compliance requirements (PCI-DSS SAQ levels, SOX control objectives, KYC/AML screening) to architectural layers and define cardholder data environments, change control procedures, and audit evidence collection.
+3. **Transaction Architecture**: Design idempotent transaction processing with unique transaction IDs, state machines for payment flows (authorized → captured → settled), and distributed transaction patterns (Saga, 2PC) with compensation logic.
+4. **Ledger Design**: Implement double-entry bookkeeping with immutable transaction logs, account balance reconciliation, and temporal consistency guarantees using event sourcing or append-only ledgers.
+5. **Security Controls**: Define tokenization for card data, encryption key hierarchies, secure key storage (HSM), mTLS for inter-service communication, and fraud detection rules (velocity checks, geolocation, device fingerprinting).
+6. **Reconciliation Pipeline**: Design automated reconciliation workflows comparing internal ledger against external payment processors, bank statements, and third-party APIs with alerting for discrepancies.
+7. **Audit and Reporting**: Generate immutable audit logs for all financial transactions, access to sensitive data, and configuration changes with compliance report generation (PCI quarterly scans, SOX control testing evidence).
+</process>

package/.claude/commands/mindforge/flutter.md

@@ -0,0 +1,37 @@
+---
+name: mindforge:flutter
+description: "Flutter architecture and pattern guidance. Usage: /mindforge:flutter [feature] [--state riverpod|bloc|provider]"
+argument-hint: "[feature] [--state riverpod|bloc|provider]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design Flutter applications using BLoC or Riverpod patterns with platform channels for native integration, optimized widget trees, and Dart-native performance.
+</objective>
+
+<execution_context>
+@.mindforge/skills/flutter-architecture/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/flutter-architecture/`
+State: Recommends state management approach, widget composition patterns, platform channel design, and Flutter-specific performance optimizations.
+</context>
+
+<process>
+1. **State Management**: Riverpod 2.0 → type-safe, compile-time DI, async support, testing-friendly (recommended). BLoC → event-driven, good for complex flows, reactive streams. Provider → simple but verbose, being phased out. GetX → avoid (too much magic, hard to debug).
+
+2. **Widget Architecture**: Composition over inheritance. Extract reusable widgets. Use const constructors (performance win). Separate stateful logic from UI. Keys for list performance. Avoid deep widget trees (>10 levels).
+
+3. **Platform Channels**: Method channels for one-time calls. Event channels for streams. Use pigeon for type-safe codegen. Handle threading (iOS main thread requirement). Implement proper error handling across boundary.
+
+4. **Performance**: Use ListView.builder (lazy loading). DevTools for widget rebuild analysis. Avoid setState in loops. Use RepaintBoundary strategically. Profile with Observatory. Target 60fps (120fps on ProMotion).
+
+5. **Code Generation**: Freezed for immutable models. json_serializable for JSON parsing. built_value for value objects. auto_route for type-safe navigation. Run build_runner watch during development.
+
+6. **Testing**: Unit tests (business logic). Widget tests (UI components). Integration tests (full app flows). Golden tests (pixel-perfect UI). Mock platform channels. Aim for >80% coverage.
+
+7. **Release**: Obfuscate Dart code. Minimize app size (tree-shaking, deferred loading). Configure ProGuard rules. Test on min SDK version. Set up code push (Shorebird) for hotfixes.
+</process>

package/.claude/commands/mindforge/gaming.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:gaming
+description: "Design gaming backend architecture. Usage: /mindforge:gaming [feature] [--mode realtime|turn-based] [--scale small|massive]"
+argument-hint: "[feature] [--mode realtime|turn-based] [--scale small|massive]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Designs high-performance gaming backend architectures for real-time multiplayer, turn-based games, and massively multiplayer systems. Produces designs for matchmaking, game state synchronization, leaderboards, anti-cheat systems, and live operations with low-latency requirements.
+</objective>
+
+<execution_context>
+@.mindforge/skills/gaming-backend/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/gaming-backend/`
+State: Evaluates game type, player concurrency requirements, and produces architecture with real-time communication (WebSocket/UDP), state synchronization, matchmaking algorithms, and operational analytics for live games.
+</context>
+
+<process>
+1. **Game Type Analysis**: Classify game mode (real-time shooter/MOBA, turn-based strategy, MMO, battle royale) and define latency requirements (<50ms for FPS, <200ms for turn-based), player concurrency (10s, 100s, 10000s), and session duration patterns.
+2. **Network Architecture**: Design network topology with dedicated game servers vs P2P hybrid, protocol selection (WebSocket for web, UDP for mobile/console), regional server distribution for latency optimization, and client-side prediction with server reconciliation.
+3. **Matchmaking System**: Implement matchmaking algorithms (skill-based rating like ELO/TrueSkill, latency-based region matching), queue management with backfill for in-progress games, and party system for group matchmaking with balanced team composition.
+4. **Game State Management**: Design authoritative server architecture with client input validation, tick-based simulation loops, state synchronization patterns (full snapshots, delta compression, interest management for MMOs), and cheat prevention with server-side validation.
+5. **Persistence Layer**: Architect player data storage (progression, inventory, achievements) with eventually consistent writes, caching for frequently accessed data (player profiles, loadouts), and leaderboard systems using sorted sets (Redis) or time-series databases.
+6. **Live Operations**: Implement event systems for limited-time challenges, A/B testing frameworks for game balance tuning, analytics pipelines for player behavior tracking (retention, engagement, monetization), and operational dashboards for server health monitoring.
+7. **Scalability Patterns**: Design horizontal scaling for game servers with auto-scaling based on player concurrency, stateful server migration for maintenance windows, database sharding by player ID or region, and CDN distribution for game assets and patches.
+</process>