mindforge-cc 11.3.0 → 11.3.1

package/.agent/mindforge/degrade.md

@@ -0,0 +1,31 @@
+---
+description: Design graceful degradation strategy with availability tiers. Usage - /mindforge:degrade [service] [--tiers 3] [--shed-at 80%]
+---
+
+<objective>
+Design a graceful degradation strategy that classifies all features into
+availability tiers, implements fallback behaviors per tier, configures load
+shedding thresholds, and ensures the system maintains core functionality
+under extreme load or partial failure conditions.
+</objective>
+
+<execution_context>
+@.mindforge/skills/graceful-degradation/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Identify all features and external dependencies for the service: list every user-facing feature, background job, third-party integration, and internal service dependency. Map the dependency graph to understand cascade failure paths.
+2. Classify into availability tiers based on --tiers flag (default 3): Tier 1 (critical — must always work: auth, core transactions, data integrity), Tier 2 (important — degrade gracefully: search, recommendations, analytics), Tier 3 (nice-to-have — shed first: notifications, personalization, non-essential UI).
+3. Design fallback behavior per tier: Tier 1 has no fallback (must work or page), Tier 2 falls back to cached/stale data or simplified behavior, Tier 3 returns empty/disabled state with user-friendly messaging explaining reduced functionality.
+4. Implement circuit breakers for each external dependency: configure failure threshold (5 failures in 10s), half-open retry interval (30s), and success threshold to close (3 consecutive successes). Use bulkhead pattern to isolate dependency failures.
+5. Configure load shedding thresholds based on --shed-at flag (default 80%): at 80% capacity shed Tier 3, at 90% shed Tier 2, at 95% restrict Tier 1 to authenticated users only. Implement priority queuing — Tier 1 requests always processed first.
+6. Test degradation modes systematically: inject failures for each dependency, simulate load at 80/90/95/100% capacity, verify tier shedding activates correctly, confirm no data corruption during degraded operation, and validate recovery when pressure relieved.
+7. Document degraded states for operations: create runbook entries for each degradation level, define what users experience at each tier, specify which alerts fire at each transition, and provide manual override procedures.
+8. Alert on tier transitions: notify on-call when any tier begins shedding, escalate when Tier 1 is under pressure, track time-in-degraded-state metrics, and auto-page if degradation exceeds 5 minutes without improvement.
+9. Design recovery behavior: implement gradual ramp-up when pressure subsides (don't immediately restore all tiers), use hysteresis to prevent oscillation (restore at 70% if shed at 80%), and verify dependency health before reconnecting.
+10. Log degradation design in AUDIT with: service, tier classification, shedding thresholds, circuit breaker configs, fallback behaviors, and recovery strategy.
+</process>

package/.agent/mindforge/delegate.md

@@ -0,0 +1,37 @@
+---
+name: mindforge:delegate
+description: "Task decomposition and delegation planning. Usage: /mindforge:delegate [project] [--team-size number] [--timeline weeks]"
+argument-hint: "[project] [--team-size number] [--timeline weeks]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Decompose complex projects into parallelizable workstreams with clear ownership, dependencies, and handoff protocols. Maximizes team throughput while minimizing coordination overhead.
+</objective>
+
+<execution_context>
+@.mindforge/skills/delegation-patterns/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/delegation-patterns/`
+State: Analyzes project scope, team capabilities, and dependencies to generate delegation plan with task assignment matrix, communication protocols, and risk mitigation strategies.
+</context>
+
+<process>
+1. **Project Decomposition**: Break project into 5-12 work packages. Each package should be independently testable, have clear success criteria, and take 1-2 weeks for one person. Identify vertical slices (e.g., "user auth flow end-to-end") over horizontal layers ("build all APIs").
+
+2. **Dependency Mapping**: Create DAG of dependencies between work packages. Identify critical path (longest dependency chain). Flag packages with >3 dependencies as integration risk. Prioritize breaking dependency cycles (shared interfaces, feature flags, contract testing).
+
+3. **Team Capability Matrix**: Map team members to (skill, seniority, availability). Senior backend (80h), mid frontend (40h part-time), junior fullstack (80h). Match work packages to capability gaps. Flag packages requiring skills not present in team (consultant needed).
+
+4. **Parallelization Strategy**: Assign independent packages to parallel tracks. Track 1 (auth + API) → Person A. Track 2 (UI + state) → Person B. Track 3 (infra + observability) → Person C. Synchronize at integration milestones (sprint boundaries).
+
+5. **Handoff Protocol**: Define deliverable artifacts per package (code + tests + docs + runbook). Specify acceptance criteria (test coverage ≥80%, latency <200ms, accessibility AA). Set review process (PR template, required reviewers, CI gates). Schedule integration sync (twice per sprint).
+
+6. **Risk Mitigation**: Identify single points of failure (one person knows payments). Cross-train on high-risk packages. Set up knowledge transfer sessions. Document critical paths in runbook. Define escalation paths for blockers (TL → EM → Product).
+
+7. **Communication Cadence**: Daily async standup (written updates in Slack). Twice-weekly sync for blockers (30min). Weekly integration demo (show working feature). End-of-sprint retro (what slowed us down). Use DACI for decisions (Driver, Approver, Contributors, Informed).
+</process>

package/.agent/mindforge/deploy.md

@@ -0,0 +1,32 @@
+---
+description: Execute staged deployment rollout with canary and rollback. Usage - /mindforge:deploy [--depth quick|standard|deep] [--skip-canary] [--rollback]
+---
+
+<objective>
+Orchestrate a production deployment through progressive stages with health
+monitoring, decision thresholds, and always-ready rollback.
+</objective>
+
+<execution_context>
+@.mindforge/skills/deployment-workflow/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Parse depth level: quick (5-10 min), standard (15-30 min), deep (30-60 min with canary).
+2. If --rollback: execute rollback plan from last DEPLOYMENT.md, skip forward steps.
+3. **Phase 1 — Pre-Deploy**: verify git clean, tests pass, changelog updated, rollback plan documented.
+4. **Phase 2 — Build & Bundle**: compile, type check, bundle analysis (warn if >250KB main).
+5. **Phase 3 — Staging**: deploy to staging, run health checks, smoke tests, wait for confirmation.
+6. **Phase 4 — Production**: select strategy (quick=all-at-once, standard=rolling, deep=canary).
+   - If canary: deploy to 5% traffic, monitor error rate for 15 min.
+   - Check thresholds: error rate (green <10% above baseline), P95 latency, business metrics.
+   - If green: promote to 25% → 50% → 100% (deep) or 100% directly (standard).
+   - If red (>2x baseline): trigger automatic rollback.
+7. **Phase 5 — Post-Deploy**: verify health endpoints, confirm error rate <1%, compare metrics to baseline.
+8. Write DEPLOYMENT.md with: phase timestamps, commit hash, health status, rollback window.
+9. Log deployment event in AUDIT with depth level and outcome.
+</process>

package/.agent/mindforge/design-tokens.md

@@ -0,0 +1,80 @@
+---
+description: "Create design system token architecture. Usage: /mindforge:design-tokens [--layers primitive|semantic|component] [--theme dark|light]"
+---
+
+<objective>
+Create a layered design token architecture with primitive, semantic, and component tokens — supporting theming, documentation, and versioning for a consistent design system.
+</objective>
+
+<execution_context>
+@.mindforge/skills/design-system/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (optional --layers primitive|semantic|component to focus on specific layer, optional --theme dark|light)
+Knowledge: Current design system, brand guidelines, component library, accessibility requirements.
+</context>
+
+<process>
+1. **Define primitive tokens**: Establish the raw design values:
+   - Colors: full palette with numbered scales (gray-100 through gray-900, blue-100 through blue-900)
+   - Spacing: base unit (4px or 8px) with scale (0.5x, 1x, 1.5x, 2x, 3x, 4x, 6x, 8x, 12x, 16x)
+   - Typography: font families (sans, mono, serif), sizes (xs through 4xl), weights (regular, medium, semibold, bold), line heights (tight, normal, relaxed)
+   - Border radius: none, sm, md, lg, xl, full
+   - Shadows: sm, md, lg, xl (with offset, blur, spread, color)
+   - Breakpoints: sm (640px), md (768px), lg (1024px), xl (1280px), 2xl (1536px)
+   - Motion: duration (fast 100ms, normal 200ms, slow 300ms), easing (ease-in, ease-out, ease-in-out)
+
+2. **Map to semantic tokens**: Create meaningful aliases:
+   - `color-primary` → blue-600, `color-primary-hover` → blue-700
+   - `color-surface` → white, `color-surface-elevated` → gray-50
+   - `color-text-primary` → gray-900, `color-text-secondary` → gray-600
+   - `color-border` → gray-200, `color-border-focus` → blue-500
+   - `color-success` → green-600, `color-warning` → amber-600, `color-error` → red-600
+   - `spacing-page` → 6x, `spacing-section` → 4x, `spacing-element` → 2x
+   - `font-heading` → sans/bold, `font-body` → sans/regular, `font-code` → mono/regular
+   - Ensure all semantic tokens pass WCAG 2.1 AA contrast ratios (4.5:1 for text, 3:1 for UI)
+
+3. **Derive component tokens**: Map semantic tokens to component-specific usage:
+   - `button-bg` → color-primary, `button-text` → color-on-primary
+   - `button-radius` → radius-md, `button-padding` → spacing-2x spacing-4x
+   - `input-border` → color-border, `input-border-focus` → color-border-focus
+   - `input-bg` → color-surface, `input-text` → color-text-primary
+   - `card-bg` → color-surface-elevated, `card-shadow` → shadow-md
+   - `card-radius` → radius-lg, `card-padding` → spacing-4x
+   - Each component token references semantic tokens (never primitives directly)
+
+4. **Implement theming**: Support dark and light modes:
+   - Dark theme overrides semantic layer only (primitives stay constant)
+   - `color-surface` → gray-900 (dark), `color-text-primary` → gray-100 (dark)
+   - `color-border` → gray-700 (dark), `color-surface-elevated` → gray-800 (dark)
+   - Shadows: reduce opacity in dark mode, add subtle inner glow
+   - Ensure all dark theme combinations meet contrast requirements
+   - Implementation: CSS custom properties with `[data-theme="dark"]` selector
+   - System preference detection: `prefers-color-scheme` media query as default
+
+5. **Document in Storybook**: Create documentation artifacts:
+   - Token reference page: all tokens with visual swatches and values
+   - Usage guidelines: when to use which semantic token
+   - Do/Don't examples: correct vs incorrect token usage
+   - Accessibility notes: contrast ratios, focus indicators, motion preferences
+   - Migration guide: how to adopt tokens in existing components
+   - Playground: interactive token picker for designers
+
+6. **Version the token system**: Establish governance:
+   - Semantic versioning for the token package (major.minor.patch)
+   - Breaking change: removing a token or changing its type → major bump
+   - Addition: new token → minor bump
+   - Value change: updating a token value → patch bump
+   - Deprecation process: mark deprecated, provide migration path, remove in next major
+   - Change log: document every token change with rationale
+   - Distribution: npm package, Figma plugin sync, design tool integration
+
+7. **Output token architecture**: Deliver:
+   - Token definition files (JSON, CSS custom properties, SCSS variables)
+   - Theme configuration (light + dark)
+   - TypeScript type definitions for token keys
+   - Figma-compatible token export
+   - Documentation site structure
+   - Integration guide for consuming applications
+</process>

package/.agent/mindforge/discuss-phase.md

@@ -0,0 +1,142 @@
+---
+description: Planning without discussion produces generic plans.
+---
+
+# MindForge — Discuss Phase Command
+# Usage: /mindforge:discuss-phase [N] [--batch] [--auto]
+# Captures implementation decisions before planning begins.
+# Run this BEFORE /mindforge:plan-phase for complex phases.
+
+## Purpose
+Planning without discussion produces generic plans.
+Discussion captures YOUR decisions — layout preferences, library choices,
+UX specifics, edge cases you've already thought through — so the planner
+builds what you actually want, not what seems reasonable.
+
+## When to use
+- Any phase with UI/UX components (visual decisions need capturing)
+- Any phase with multiple valid implementation approaches
+- Any phase where you already have opinions on the approach
+- Any phase touching external services (your preferences on APIs matter)
+- Skip for trivial phases (e.g., "add one field to an existing form")
+
+## Step 1 — Analyse the phase scope
+
+Read:
+- ROADMAP.md for the phase description
+- REQUIREMENTS.md for the requirements in this phase
+- ARCHITECTURE.md for relevant architectural context
+
+Identify the phase's primary domain and any secondary domains.
+If multiple domains are involved, cover each relevant set of questions.
+- **Visual/UI** → ask about layout, interactions, states, empty states, animations
+- **API/Backend** → ask about response format, error handling, auth approach, versioning
+- **Data/Database** → ask about schema design, migration strategy, data volume expectations
+- **Integration** → ask about third-party API choices, error recovery, retry strategy
+- **Infrastructure** → ask about deployment strategy, scaling approach, observability
+
+## Step 2 — Structured discussion
+
+Ask questions ONE AT A TIME. Wait for the full answer before asking the next.
+Do not batch questions (unless `--batch` flag is provided).
+
+### Visual/UI phases — ask about:
+1. "Walk me through what a user sees on this screen from top to bottom."
+2. "What does the empty state look like? (nothing loaded yet / no results / error)"
+3. "Any animations or transitions you're picturing? Or keep it static?"
+4. "On mobile — stacks vertically or anything different?"
+5. "Any edge cases? (very long text, images that fail to load, loading states)"
+
+### API/Backend phases — ask about:
+1. "What's the intended consumer? Internal frontend / external developers / both?"
+2. "For errors — do you want detailed error objects with field-level info or simple messages?"
+3. "Rate limiting needed on any of these endpoints?"
+4. "Any background processing involved, or all synchronous?"
+5. "Versioning approach? /v1/ prefix or header-based?"
+
+### Data/Database phases — ask about:
+1. "What's the expected data volume? Thousands / millions / billions of rows?"
+2. "Any fields that need full-text search vs. exact match?"
+3. "Soft delete or hard delete for user-facing records?"
+4. "Any fields that change frequently vs. infrequently? (affects indexing strategy)"
+5. "Data retention requirements? When can records be deleted?"
+
+### Integration phases — ask about:
+1. "Have you already chosen the third-party service / API? If so, which? (I will query Context7 for current docs if available)"
+2. "What should happen if the third-party service is down? Queue / fail / fallback?"
+3. "Webhooks or polling for receiving updates?"
+4. "Any rate limits you know about on their end?"
+5. "Testing approach? Do they have a sandbox environment?"
+
+## --batch mode
+If `--batch` flag is provided: group related questions and present them together.
+Appropriate when the user wants faster intake and is familiar with MindForge.
+
+Example batch:
+```
+Visual decisions for Phase 2:
+  1. Layout: card grid / table / list?
+  2. Empty state: illustration / simple message / hide section?
+  3. Loading: skeleton / spinner / none?
+  4. Mobile: same layout / stacked / hidden?
+Answer 1-4:
+```
+
+## --auto mode
+If `--auto` flag is provided: skip the discussion entirely.
+The planner will make reasonable defaults for all decisions.
+Use when: the phase is straightforward and you trust the planner's judgment.
+Warn clearly: "Skipping discussion. Planner will make implementation decisions.
+              Results may not match your vision exactly. Proceeding without
+              explicit decisions can create rework later."
+
+## Step 3 — Write CONTEXT.md
+
+After discussion, write `.planning/phases/[N]/CONTEXT.md`:
+
+```markdown
+# Phase [N] Implementation Context
+# Captured: [ISO-8601]
+# Discussion mode: [interactive / batch / auto]
+
+## Phase description
+[From ROADMAP.md]
+
+## Implementation decisions (captured from discussion)
+
+### [Domain: Visual / API / Data / Integration / etc.]
+
+**Decision:** [What was decided]
+**Rationale:** [Why — from user's words]
+**Implications for planning:**
+  - [What the planner should do because of this decision]
+  - [Specific library or pattern to use]
+  - [What to avoid]
+
+[Repeat for each significant decision]
+
+## Open questions (unresolved during discussion)
+- [Question 1]: [Status — decide during planning / decide during execution]
+
+## User's explicit preferences
+[Verbatim or near-verbatim quotes from the discussion that capture specific intent]
+
+## Defaults accepted (decisions the user deferred to the planner)
+- [Area]: planner's choice
+```
+
+## Step 4 — Confirm and guide
+
+Show the user a summary of what was captured:
+
+"✅ Phase [N] discussion complete. [N] decisions captured.
+
+  Key decisions:
+  - [Decision 1 summary]
+  - [Decision 2 summary]
+  - [Decision 3 summary]
+
+  See full context: .planning/phases/[N]/CONTEXT.md
+
+  Next step: Run /mindforge:plan-phase [N] to create implementation plans
+  using these decisions."

package/.agent/mindforge/dmux.md

@@ -0,0 +1,32 @@
+---
+description: Launch parallel multi-model execution via tmux and git worktrees. Usage - /mindforge:dmux [task-file.json] [--max-panes 5] [--model-per-pane]
+---
+
+<objective>
+Split independent work across parallel tmux panes with worktree isolation,
+enabling multiple agents/models to work simultaneously without conflicts.
+</objective>
+
+<execution_context>
+@.mindforge/skills/dmux-workflows/SKILL.md
+@.mindforge/skills/rfc-pipeline/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Parse worker definitions from task-file.json (or interactive if no file provided).
+2. Verify task independence: confirm no two workers will modify the same files.
+3. Create git worktree per worker: `git worktree add .worktrees/[name] -b dmux/[name]`.
+4. Launch tmux session with one pane per worker (max --max-panes, default 5).
+5. Seed each pane with its task description and constraints.
+6. If --model-per-pane: assign different models to different panes (e.g., Sonnet for impl, Gemini for research).
+7. Monitor pane progress (check for completion signals or stuck patterns).
+8. On pane completion: review output diff before merging.
+9. Merge completed worktrees back to main branch (sequential, resolve conflicts).
+10. Cleanup: remove worktrees (`git worktree remove`), close tmux panes.
+11. Consolidate results: produce summary of what each pane accomplished.
+12. Log dmux session in AUDIT with pane count, models used, and merge status.
+</process>

package/.agent/mindforge/do.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:do
+description: Smart natural language dispatcher to route intent to the right MindForge command
+argument-hint: <text>
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Provide a high-level, natural language interface for users to interact with MindForge without needing to remember specific command names. Routes user intent to the most appropriate internal command.
+</objective>
+
+<execution_context>
+.claude/commands/mindforge/do.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (The user's intent in plain English)
+Knowledge: Must be aware of all available `.claude/commands/mindforge/*.md` definitions.
+</context>
+
+<process>
+1. **Analyze input**: Parse the user's natural language request.
+2. **Match command**: Compare the intent against the descriptions and objectives of all known MindForge commands.
+3. **Execute match**:
+    - If a clear match is found, immediately pivot to that command's logic.
+    - If multiple matches are possible, ask the user for clarification.
+    - If no match is found, suggest the most relevant command or offer `/mindforge:help`.
+4. **Learn (Optional)**: If the user confirms a routing was correct, record the mapping for future intent resolution.
+</process>

package/.agent/mindforge/ecommerce.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:ecommerce
+description: "Design ecommerce platform architecture. Usage: /mindforge:ecommerce [component] [--type marketplace|direct|hybrid]"
+argument-hint: "[component] [--type marketplace|direct|hybrid]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Designs scalable ecommerce platform architectures for marketplace, direct-to-consumer, and hybrid models. Produces system designs for catalog management, inventory systems, order processing, payment integration, and fulfillment workflows with high-availability patterns.
+</objective>
+
+<execution_context>
+@.mindforge/skills/ecommerce-architecture/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/ecommerce-architecture/`
+State: Evaluates ecommerce business model, component requirements, and produces architecture with product catalog, inventory management, order orchestration, payment flows, and omnichannel fulfillment capabilities.
+</context>
+
+<process>
+1. **Business Model Analysis**: Identify ecommerce type (marketplace with multiple sellers, direct B2C, B2B wholesale, or hybrid) and define multi-tenancy requirements, seller onboarding, commission structures, and revenue models.
+2. **Catalog Architecture**: Design product catalog system with hierarchical categories, dynamic attributes, variant management (size/color/SKU), search indexing (Elasticsearch/Algolia), and personalization engines for recommendations.
+3. **Inventory Management**: Architect real-time inventory tracking with stock reservation during checkout, multi-warehouse allocation, backorder handling, and inventory sync with ERP/WMS systems preventing overselling.
+4. **Order Processing Pipeline**: Design order state machine (cart → checkout → payment → fulfillment → delivery), orchestration patterns for split shipments, partial refunds, and idempotent order creation with distributed transaction handling.
+5. **Payment Integration**: Integrate payment gateways (Stripe, PayPal, Adyen) with tokenization, 3DS authentication, fraud detection, webhook handling for async payment confirmations, and reconciliation with order system.
+6. **Fulfillment Orchestration**: Design fulfillment workflows with carrier integration (shipping labels, tracking), warehouse management system communication, returns processing, and customer notification system.
+7. **Performance and Scale**: Implement caching strategies (CDN for product images, Redis for cart sessions), database sharding by tenant/region, read replicas for catalog queries, and queue-based processing for order workflows during traffic spikes.
+</process>

package/.agent/mindforge/edge.md

@@ -0,0 +1,34 @@
+---
+name: mindforge:edge
+description: "Design edge computing architecture. Usage: /mindforge:edge [service] [--runtime workers|vercel|deno] [--regions global|specific]"
+argument-hint: "[service] [--runtime workers|vercel|deno] [--regions global|specific]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design a latency-optimized edge computing architecture that moves computation closer to users while maintaining data consistency and graceful fallback to origin servers.
+</objective>
+
+<execution_context>
+@.mindforge/skills/edge-computing/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/edge-computing/`
+State: Evaluates service endpoints for edge eligibility and designs distributed execution topology.
+</context>
+
+<process>
+1. **Identify Latency-Sensitive Endpoints**: Audit all API routes and static assets to determine which endpoints benefit most from edge deployment (sub-50ms response budget, high geographic distribution of users).
+2. **Evaluate Edge Eligibility**: For each candidate endpoint, verify statelessness, deterministic output, and sub-50ms compute budget. Flag endpoints requiring write-through or session state as ineligible without adaptation.
+3. **Select Edge Runtime**: Based on requirements (cold start tolerance, language support, execution limits), choose between Cloudflare Workers, Vercel Edge Functions, or Deno Deploy. Document tradeoffs.
+4. **Design Data Locality Strategy**: Implement read-nearest pattern with write-to-origin routing. Map data access patterns to determine which reads can be served from edge replicas vs. which require origin round-trips.
+5. **Configure Caching Layer**: Design stale-while-revalidate caching with appropriate TTLs per endpoint. Define cache key composition to avoid over-keying while maintaining correctness.
+6. **Handle Edge Limitations**: Address runtime constraints (CPU time limits, memory caps, no filesystem access). Design workarounds for long-running computations via streaming or chunked responses.
+7. **Plan Origin Fallback**: Implement circuit breaker pattern for edge-to-origin failover. Define health check probes and automatic traffic shifting when edge nodes degrade.
+8. **Monitor Edge vs. Origin Latency**: Set up comparative latency monitoring (p50, p95, p99) between edge and origin responses. Define alerting thresholds for when edge advantage drops below acceptable margin.
+9. **Document Regional Configuration**: Produce a region map specifying which edge locations are active, any geo-restrictions, and data residency compliance constraints.
+10. **Validate with Load Profile**: Simulate expected traffic patterns against the edge topology to verify cache hit ratios and confirm latency budgets are met under load.
+</process>

package/.agent/mindforge/edtech.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:edtech
+description: "Design educational technology platform. Usage: /mindforge:edtech [component] [--type lms|assessment|adaptive]"
+argument-hint: "[component] [--type lms|assessment|adaptive]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Designs educational technology platforms including learning management systems, assessment engines, and adaptive learning systems. Produces architectures for content delivery, student progress tracking, automated grading, learning analytics, and personalized learning paths with FERPA compliance.
+</objective>
+
+<execution_context>
+@.mindforge/skills/edtech-platform/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/edtech-platform/`
+State: Evaluates edtech platform requirements, learning models, and produces architecture with content management, assessment frameworks, learning analytics, and student data privacy controls compliant with FERPA and COPPA.
+</context>
+
+<process>
+1. **Platform Type Analysis**: Identify edtech platform type (LMS for course delivery, assessment platform for testing, adaptive learning system with personalization) and define user roles (students, teachers, admins, parents), content types (video, interactive, SCORM), and scale (K-12, higher-ed, corporate training).
+2. **Content Architecture**: Design content management system with versioning, multi-format support (video, PDF, H5P interactive content), SCORM/xAPI compliance for interoperability, content tagging/metadata for searchability, and CDN delivery for global access.
+3. **Assessment Engine**: Architect assessment system with question banks, randomized test generation, multiple question types (MCQ, short answer, essay, code submission), auto-grading with rubrics, plagiarism detection, and secure browser lockdown for proctored exams.
+4. **Learning Analytics**: Implement data collection for student interactions (time on task, completion rates, quiz scores), learning record store (LRS) for xAPI statements, predictive models for at-risk student identification, and dashboard visualizations for educators and administrators.
+5. **Adaptive Learning**: Design personalization engine with student knowledge modeling (Bayesian knowledge tracing, item response theory), content recommendation algorithms based on mastery levels, dynamic difficulty adjustment, and differentiated learning paths.
+6. **Collaboration Features**: Build real-time collaboration tools (discussion forums, peer review workflows, group projects), video conferencing integration (Zoom, Teams), messaging systems with moderation, and live classroom features with breakout rooms.
+7. **Privacy and Compliance**: Implement FERPA-compliant student data handling with parental consent for minors (COPPA), role-based access controls for PII, data retention policies, audit logs for data access, and student data portability with export capabilities.
+</process>

package/.agent/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/.agent/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/.agent/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/.agent/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>