mindforge-cc 11.3.0 → 11.4.0

package/.agent/mindforge/market-research.md

@@ -0,0 +1,94 @@
+---
+description: "Competitive analysis and market sizing (TAM/SAM/SOM). Usage: /mindforge:market-research [market] [--competitors url1,url2]"
+---
+
+<objective>
+Conduct structured market research including TAM/SAM/SOM sizing, competitive landscape analysis, SWOT assessment per competitor, opportunity scoring, and positioning recommendations.
+</objective>
+
+<execution_context>
+@.mindforge/skills/market-researcher/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (market vertical or product category, optional --competitors with URLs)
+Knowledge: PROJECT.md, existing product briefs, industry reports, competitor intelligence.
+</context>
+
+<process>
+1. **Define market boundaries**: Establish the scope of the market:
+   - Industry vertical and sub-segment
+   - Geographic scope (global, regional, country-specific)
+   - Customer segments (enterprise, SMB, consumer, developer)
+   - Price tier (free, freemium, mid-market, enterprise)
+   - Adjacent markets that may converge
+
+2. **Size TAM/SAM/SOM**: Calculate market opportunity using both top-down and bottom-up:
+   - **TAM** (Total Addressable Market): Total revenue opportunity if 100% market share
+   - **SAM** (Serviceable Addressable Market): Segment reachable with current product/channel
+   - **SOM** (Serviceable Obtainable Market): Realistic capture in 3 years given competition
+   - Document assumptions, data sources, and confidence level for each estimate
+   - Express in both revenue ($) and units (customers/seats)
+
+3. **Analyze competitors**: For each competitor (from --competitors flag or discovered):
+   - Product overview and core value proposition
+   - Target customer segment and ICP
+   - Pricing model and tiers
+   - Key features and differentiators
+   - Known weaknesses and customer complaints
+   - Estimated market share and revenue
+   - Recent strategic moves (funding, acquisitions, pivots)
+
+4. **SWOT each competitor**: For each analyzed competitor:
+   - **Strengths**: What they do better than anyone else
+   - **Weaknesses**: Where they consistently underperform
+   - **Opportunities**: Market shifts they could capitalize on
+   - **Threats**: Risks to their current position
+   - Rate each dimension 1-5 for severity/importance
+
+5. **Score opportunities**: Evaluate market entry/expansion opportunities:
+   - Market attractiveness (size, growth rate, profitability)
+   - Competitive intensity (number of players, switching costs, differentiation)
+   - Capability fit (how well our strengths match the opportunity)
+   - Time-to-value (how quickly we can capture share)
+   - Risk level (regulatory, technical, market timing)
+   - Composite score and ranking
+
+6. **Identify market gaps**: Find underserved segments or unmet needs:
+   - Features competitors lack that customers request (review mining)
+   - Customer segments ignored by incumbents
+   - Pricing gaps (overserved premium, underserved value tier)
+   - Geographic gaps (markets without localized solutions)
+   - Integration gaps (ecosystems with no good solution)
+
+7. **Recommend positioning**: Based on analysis, propose:
+   - Primary positioning statement (for whom, what, unlike, because)
+   - Differentiation axes (where to compete vs where to concede)
+   - Messaging pillars (3-4 key claims supported by evidence)
+   - Category strategy (create new category vs redefine existing)
+   - Pricing strategy recommendation with rationale
+
+8. **Trend analysis**: Identify market dynamics:
+   - Growth trends (CAGR, seasonal patterns)
+   - Technology shifts impacting the market
+   - Regulatory changes on the horizon
+   - Buyer behavior evolution
+   - Consolidation patterns (M&A activity)
+
+9. **Output research report**: Write structured report to `.planning/MARKET-RESEARCH-[slug].md`:
+   - Executive Summary (key findings in 5 bullets)
+   - Market Sizing (TAM/SAM/SOM with methodology)
+   - Competitive Landscape (matrix comparison table)
+   - SWOT Analyses (per competitor)
+   - Opportunity Assessment (scored and ranked)
+   - Positioning Recommendation
+   - Risks and Uncertainties
+   - Appendix (data sources, methodology notes)
+
+10. **Confidence assessment**: Rate the overall research confidence:
+    - Data recency (when were sources last updated)
+    - Source diversity (single source vs triangulated)
+    - Assumptions requiring validation
+    - Recommended next steps for higher-confidence data
+    - Expiry date (when this research should be refreshed)
+</process>

package/.agent/mindforge/marketplace.md

@@ -0,0 +1,124 @@
+---
+description: Discover, evaluate, and install community-published MindForge skills from the
+---
+
+# MindForge v2 — Marketplace Command
+# Usage: /mindforge:marketplace [search|featured|trending|install|publish]
+# Version: v2.0.0-alpha.6
+
+## Purpose
+Discover, evaluate, and install community-published MindForge skills from the
+marketplace — a curated layer on top of the npm registry.
+
+The marketplace is the shortcut: instead of learning from documentation yourself,
+install skills that the community has already created, validated, and battle-tested.
+
+## Sub-commands
+
+### search [query]
+Find skills relevant to your tech stack or domain.
+```
+/mindforge:marketplace search "prisma"
+/mindforge:marketplace search "stripe payment processing"
+/mindforge:marketplace search "HIPAA compliance"
+/mindforge:marketplace search "graphql api"
+```
+
+Output:
+```
+🔍 Marketplace search: "prisma" (6 results)
+
+  1. prisma-advanced (v1.2.3)
+     Advanced Prisma patterns: relations, migrations, performance, cursor pagination
+     847 installs this week
+
+  2. prisma-schema (v1.0.1)
+     Prisma schema design: models, relations, enums, cascade rules
+     234 installs this week
+
+  3. prisma-testing (v1.0.0)
+     Testing Prisma with Jest: database seeding, teardown, transaction rollback
+     156 installs this week
+
+Install: /mindforge:marketplace install prisma-advanced
+```
+
+### featured
+Show curated featured skills by category.
+```
+/mindforge:marketplace featured
+```
+
+Output:
+```
+🏪 MindForge Community Skills — Featured
+
+  Database:
+    db-postgres-advanced v2.1.0  — Advanced PostgreSQL patterns, indexes, partitioning
+    db-prisma-advanced   v1.2.0  — Prisma relations, migrations, query optimisation
+    db-drizzle           v1.0.0  — Drizzle ORM type-safe patterns
+
+  API:
+    api-graphql v1.4.0  — GraphQL schema, resolvers, N+1 prevention
+    api-rest    v2.0.0  — REST API design, versioning, error schemas
+
+  Compliance:
+    fintech-pci-compliance  v1.1.0 — PCI DSS Level 1 safeguards
+    healthtech-hipaa        v1.0.1 — HIPAA Security Rule for PHI
+    [more...]
+```
+
+### trending
+Show most-installed skills this month.
+```
+/mindforge:marketplace trending
+```
+
+### install [name] [--tier project|org]
+Install a marketplace skill.
+```
+/mindforge:marketplace install prisma-advanced
+/mindforge:marketplace install mindforge-skill-api-graphql --tier org
+/mindforge:marketplace install fintech-pci-compliance --tier project
+```
+
+Short names work (without `mindforge-skill-` prefix).
+Delegates to `/mindforge:install-skill` for actual installation.
+Shows quality score and session_quality_lift before installing.
+
+### publish [skill-dir]
+Publish a skill to the community marketplace.
+```
+/mindforge:marketplace publish .mindforge/skills/my-skill/
+```
+
+Requirements:
+- Quality score ≥ 80/100
+- No injection patterns
+- Has complete version history
+- Has author contact (GitHub issues URL)
+
+## Skill quality display format
+
+```
+📊 Skill: prisma-advanced v1.2.3
+   Quality score: 94/100 (Excellent)
+   ★★★★★ Session quality lift: +8.2 points (over 1,247 sessions)
+   847 installs/week | Published by: @prisma-community
+
+   Top trigger keywords: "prisma schema", "@relation", "prisma migrate",
+                          "prisma generate", "onDelete", "cursor pagination"
+
+   [Install] [Preview SKILL.md] [View on npm]
+```
+
+## AUDIT entry
+```json
+{
+  "event": "marketplace_action",
+  "action": "search|install|publish",
+  "query": "[search query if search]",
+  "skill_name": "[name if install/publish]",
+  "quality_score": 94
+}
+```

package/.agent/mindforge/mcp-server.md

@@ -0,0 +1,88 @@
+---
+description: "Scaffold MCP server implementation with tools, resources, and prompts. Usage: /mindforge:mcp-server [name] [--transport stdio|http] [--tools list]"
+---
+
+<objective>
+Scaffold a complete MCP (Model Context Protocol) server implementation with well-designed tools, resources, and prompts — ready for integration with Claude, VS Code, or any MCP-compatible client.
+</objective>
+
+<execution_context>
+@.mindforge/skills/mcp-server-patterns/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (server name, optional --transport stdio|http, optional --tools comma-separated list)
+Knowledge: MCP specification, existing server patterns, client capabilities, Zod schema patterns.
+</context>
+
+<process>
+1. **Identify capabilities**: Based on the server name and --tools flag, determine:
+   - What domain does this server expose? (database, API, file system, service)
+   - What operations should be available as tools? (CRUD, queries, actions)
+   - What data should be exposed as resources? (documents, schemas, configs)
+   - What prompts would help users interact effectively?
+   - What permissions/scopes are needed?
+
+2. **Design tool schemas**: For each tool, define with Zod:
+   - Tool name (verb-noun format: `query_database`, `create_issue`)
+   - Description (clear, concise, explains when to use it)
+   - Input schema (Zod object with descriptions per field)
+   - Required vs optional parameters
+   - Validation rules (min/max, regex patterns, enums)
+   - Example inputs for documentation
+
+3. **Design resources**: For each resource, define:
+   - URI pattern (e.g., `myserver://projects/{id}/config`)
+   - MIME type (application/json, text/markdown, etc.)
+   - Description of what the resource represents
+   - Whether it supports subscriptions (live updates)
+   - Access pattern (list → read, or direct URI)
+
+4. **Choose transport**: Based on --transport flag or requirements:
+   - `stdio`: For local CLI integration (simpler, lower latency, single client)
+   - `http`: For remote/multi-client access (SSE for server→client, HTTP POST for client→server)
+   - Document the connection lifecycle and reconnection behavior
+   - Configure appropriate timeouts and keep-alive settings
+
+5. **Scaffold implementation**: Generate the project structure:
+   - `src/index.ts` — Server entry point and transport setup
+   - `src/tools/` — One file per tool with handler and schema
+   - `src/resources/` — Resource providers with URI routing
+   - `src/prompts/` — Prompt templates with argument schemas
+   - `package.json` — Dependencies (@modelcontextprotocol/sdk, zod)
+   - `tsconfig.json` — Strict TypeScript configuration
+
+6. **Add error handling**: Implement robust error handling:
+   - Typed error codes (InvalidParams, MethodNotFound, InternalError)
+   - User-friendly error messages (not stack traces)
+   - Graceful degradation when external services are unavailable
+   - Request validation before processing (fail fast)
+   - Timeout handling for long-running operations
+
+7. **Implement tool handlers**: For each tool:
+   - Parse and validate input against Zod schema
+   - Execute the operation with proper error boundaries
+   - Return structured results (content array with type and text/image)
+   - Log operations for debugging (structured JSON logs)
+   - Handle cancellation for long-running tools
+
+8. **Add prompts**: Design prompt templates that:
+   - Guide users toward effective tool usage
+   - Include argument schemas for dynamic prompts
+   - Provide context about server capabilities
+   - Suggest workflows combining multiple tools
+
+9. **Test with MCP Inspector**: Generate test configuration:
+   - Inspector connection config (transport settings)
+   - Test cases for each tool (valid inputs, edge cases, error cases)
+   - Resource listing and read verification
+   - Prompt rendering with sample arguments
+   - Connection lifecycle testing (connect, disconnect, reconnect)
+
+10. **Output documentation**: Generate:
+    - README.md with installation and usage instructions
+    - Tool reference (auto-generated from schemas)
+    - Resource URI reference
+    - Example client configuration for Claude Desktop / VS Code
+    - Troubleshooting guide (common connection issues)
+</process>

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

@@ -0,0 +1,37 @@
+---
+name: mindforge:meeting-design
+description: "Design effective meeting or async process. Usage: /mindforge:meeting-design [purpose] [--format sync|async|hybrid] [--size small|large]"
+argument-hint: "[purpose] [--format sync|async|hybrid] [--size small|large]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design meetings or async processes that maximize output per minute of team time. Applies forcing functions to eliminate unnecessary sync time and optimize for decision quality over meeting cadence.
+</objective>
+
+<execution_context>
+@.mindforge/skills/meeting-architecture/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/meeting-architecture/`
+State: Evaluates meeting purpose, applies async-first heuristics, designs agendas with decision protocols, outputs structured meeting artifact templates.
+</context>
+
+<process>
+1. **Async-First Filter**: Ask "Can this be a doc + comment thread?" If yes (status update, one-way announcement, information gathering) → reject meeting, design async artifact instead (RFC, decision doc, survey). Only proceed to sync if: requires real-time debate, builds team rapport, or resolves ambiguity that written async cannot.
+
+2. **Purpose Classification**: Decision (choose between options) → design with pre-read + decision protocol (DACI/RACI). Brainstorm (generate options) → structure with divergent → convergent phases. Alignment (shared understanding) → pre-read heavy, meeting for Q&A only. Planning (decompose work) → prepare draft plan async, sync to resolve dependencies only.
+
+3. **Attendee Optimization**: Required (can't make decision without them), Optional (contribute but not block), FYI (read notes after). Default everyone to FYI. Promote to Required only if they have unique context or decision authority. Cap Required at 5 people. If >5 Required → meeting scope too broad, split into separate sessions.
+
+4. **Pre-Work Design**: Distribute artifact 48h before (1-pager for 30min meeting, 3-pager for 60min). Include: context (why now), options (what are we choosing between), recommendation (what I think we should do), decision needed (what must be resolved in sync). Set expectation: no pre-read = no attendance. Meeting time is for synthesis, not information transfer.
+
+5. **Agenda Structure**: 5min - Restate decision/goal from pre-read. 15min - Surface objections/alternatives (round-robin, everyone speaks). 20min - Debate trade-offs (timebox per topic). 15min - Converge on decision (decision maker calls it). 5min - Document outcomes, next actions, owner. Total 60min max. If more needed → insufficient pre-work or wrong format.
+
+6. **Decision Protocol**: DACI (Driver owns outcome, Approver makes call, Contributors give input, Informed are notified). Identify each role before meeting. During debate, label contributions (this is input vs this is a block). At decision point, Approver explicitly states decision + rationale. Driver documents decision in shared log within 24h.
+
+7. **Async Alternative Design**: For rejected meetings → create structured artifact. Status update → written update in Slack with (accomplished, in-progress, blocked, help-needed). Brainstorm → Miro board with 48h async contribution window. Alignment → Loom video + doc with comment thread. Planning → draft plan in Notion, async review with inline feedback, sync only for dependency resolution.
+</process>

package/.agent/mindforge/metrics.md

@@ -0,0 +1,26 @@
+---
+description: Display session and phase quality trends with early warning signals.
+---
+
+# MindForge — Metrics Command
+# Usage: /mindforge:metrics [--phase N] [--window short|medium|long] [--export path]
+
+Display session and phase quality trends with early warning signals.
+
+## Data sources
+- `.mindforge/metrics/session-quality.jsonl`
+- `.mindforge/metrics/phase-metrics.jsonl`
+- `.mindforge/metrics/skill-usage.jsonl`
+- `.mindforge/metrics/compaction-quality.jsonl`
+- `.planning/AUDIT.jsonl` for correlation
+
+## Dashboard sections
+- session quality trend
+- verify pass/security/failure/compaction summary
+- skill usage distribution
+- early warnings + recommendations
+
+## AUDIT
+```json
+{ "event": "metrics_viewed", "window": "short", "early_warnings": 0 }
+```

package/.agent/mindforge/microservices.md

@@ -0,0 +1,64 @@
+---
+description: "Design microservice boundaries, API contracts, and communication patterns. Usage: /mindforge:microservices [component] [--style event-driven|request-reply]"
+---
+
+<objective>
+Decompose a system into well-bounded microservices with clearly defined API contracts, communication patterns, and saga orchestration. Ensures no circular dependencies and validates domain alignment.
+</objective>
+
+<execution_context>
+@.mindforge/skills/microservices-patterns/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (target component or domain area, optional --style flag)
+Knowledge: Domain model from ARCHITECTURE.md, bounded contexts, existing service inventory.
+</context>
+
+<process>
+1. **Identify domain boundaries**: Analyze the target component against the domain model. Map nouns to aggregates, verbs to commands/events. List candidate service boundaries.
+
+2. **Define bounded contexts**: For each candidate service, define its bounded context — what data it owns, what language it uses, what invariants it enforces. Write context map showing relationships (Shared Kernel, Customer-Supplier, Conformist, ACL).
+
+3. **Design API contracts**: For each service boundary, define the public API contract:
+   - REST endpoints (OpenAPI 3.1 schema) or gRPC proto definitions
+   - Request/response types with validation rules (Zod schemas)
+   - Versioning strategy (URL path vs header)
+   - Error contract (RFC 7807 Problem Details)
+
+4. **Choose communication style**: Based on `--style` flag or inferred from requirements:
+   - `event-driven`: Define event schemas, topic naming, ordering guarantees, idempotency keys
+   - `request-reply`: Define sync call chains, circuit breaker placement, timeout budgets
+   - Hybrid: identify which interactions need sync vs async
+
+5. **Document saga flows**: For operations spanning multiple services, design compensation-based sagas:
+   - Sequence diagram for happy path
+   - Compensation steps for each failure point
+   - Saga orchestrator vs choreography decision with rationale
+
+6. **Define data ownership**: Each service owns its data store. Document:
+   - Which entities belong to which service
+   - How cross-service queries are resolved (API composition, CQRS read models, event sourcing)
+   - Data consistency model (eventual vs strong, per boundary)
+
+7. **Validate no circular dependencies**: Build a directed dependency graph of all services. Run topological sort — if it fails, circular dependency exists. Propose resolution (extract shared service, merge services, or introduce event-based decoupling).
+
+8. **Design resilience patterns**: For each inter-service call:
+   - Circuit breaker configuration (thresholds, half-open behavior)
+   - Retry policy (exponential backoff, max attempts, jitter)
+   - Bulkhead isolation (thread pool or semaphore)
+   - Timeout budget allocation across the call chain
+
+9. **Output service catalog**: Write a structured service catalog document containing:
+   - Service name, owner, bounded context
+   - Public API summary
+   - Dependencies (upstream/downstream)
+   - Communication style per dependency
+   - Data store type and ownership
+
+10. **Verify alignment**: Cross-reference the decomposition against:
+    - Team structure (Conway's Law alignment)
+    - Deployment independence (can each service deploy without coordinating?)
+    - Failure isolation (does one service failure cascade?)
+    Report any violations with recommended fixes.
+</process>

package/.agent/mindforge/migrate.md

@@ -0,0 +1,44 @@
+---
+description: Run explicit schema migrations for .planning/ files.
+---
+
+# MindForge — Migrate Command
+# Usage: /mindforge:migrate [--from X.Y.Z] [--to X.Y.Z] [--dry-run] [--force]
+
+## Purpose
+Run explicit schema migrations for .planning/ files.
+Normally triggered automatically by /mindforge:update.
+Use this command manually when: auto-migration failed, manual version jump, recovery.
+
+## Flow
+
+### Auto-detect migration need
+Read `schema_version` from HANDOFF.json.
+Compare against current `package.json` version.
+Determine migration path.
+
+### Dry-run mode (--dry-run)
+Show: which migrations would run, what each changes.
+Show: breaking changes for the migration path.
+Make NO changes to any file.
+
+### Backup first
+Before any changes: create `.planning/migration-backup-[timestamp]/`
+Verify backup integrity (file count, non-empty).
+If backup fails: ABORT. Explain disk space issue.
+
+### Execute migrations
+Run `node bin/migrations/migrate.js`.
+Show progress for each migration.
+If any migration fails: auto-restore from backup.
+
+### Verify
+Run /mindforge:health after migration.
+If health errors: report with specific fix instructions.
+Preserve backup until user is satisfied — they must delete it manually.
+
+## Manual version override
+`/mindforge:migrate --from 0.1.0 --to 1.0.0` — forces migration between specified versions.
+Use with care: intended for recovery scenarios where HANDOFF.json schema_version is wrong.
+
+## AUDIT entry

package/.agent/mindforge/migration-mgmt.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:migration-mgmt
+description: "Design migration orchestration platform. Usage: /mindforge:migration-mgmt [scope] [--type schema|data|infrastructure] [--downtime zero|planned]"
+argument-hint: "[scope] [--type schema|data|infrastructure] [--downtime zero|planned]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design comprehensive migration-mgmt system architecture with best practices and production-ready patterns.
+</objective>
+
+<execution_context>
+@.mindforge/skills/migration-platform/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/migration-platform/`
+State: Analyzes requirements, constraints, and scale to generate optimized migration-mgmt 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/milestone.md

@@ -0,0 +1,16 @@
+---
+description: Create or update a milestone definition in .planning/milestones/ and track the
+---
+
+Create or update a milestone definition in `.planning/milestones/` and track the
+ health of grouped phases. Usage: `/mindforge:milestone <name> [phase list]`
+
+## Outputs
+- milestone document with included phases
+- health summary (on track, at risk, blocked)
+- linked approvals, blockers, and verification status
+
+## Health rules
+- any blocked phase makes the milestone at risk
+- missing verification keeps milestone status yellow
+- completed verified phases count toward release readiness

package/.agent/mindforge/mobile.md

@@ -0,0 +1,37 @@
+---
+name: mindforge:mobile
+description: "Design mobile app architecture. Usage: /mindforge:mobile [app] [--platform ios|android|cross] [--framework rn|flutter|native]"
+argument-hint: "[app] [--platform ios|android|cross] [--framework rn|flutter|native]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design mobile-first architectures that balance native performance with cross-platform developer velocity. Addresses offline-first, app size, battery optimization, and platform-specific patterns.
+</objective>
+
+<execution_context>
+@.mindforge/skills/mobile-performance/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/mobile-performance/`
+State: Analyzes target platforms, performance requirements, team expertise to recommend architecture (native/hybrid/cross-platform) with specific implementation patterns.
+</context>
+
+<process>
+1. **Platform Strategy**: Single platform (iOS or Android native, best performance) vs Cross-platform (React Native/Flutter, 70% code sharing). Consider team skills (Swift/Kotlin vs JS/Dart), time-to-market, performance needs (gaming/AR → native, content apps → cross-platform).
+
+2. **Architecture Pattern**: MV* pattern selection (MVVM for iOS, MVP for Android, BLoC for Flutter, Redux for React Native). Layer separation (UI/Business Logic/Data). Navigation architecture (stack-based, tab-based, drawer). State management (local vs global, persistence strategy).
+
+3. **Performance Optimization**: App size budget (<50MB for emerging markets). Launch time target (<2s cold start). Frame rate (maintain 60fps scrolling). Battery impact (background tasks, network polling, location tracking). Memory management (image caching, list virtualization).
+
+4. **Offline-First Design**: Local database (SQLite, Realm, WatermelonDB). Sync strategy (optimistic UI, conflict resolution). Queue outgoing requests. Cache images/assets. Handle network transitions gracefully.
+
+5. **Native Integration**: Bridge patterns for platform-specific features (camera, biometrics, push notifications). Third-party SDK integration (analytics, crash reporting). App extensions (widgets, share extensions, Siri shortcuts).
+
+6. **Testing Strategy**: Unit tests (business logic, data layer). UI tests (critical user flows). Screenshot tests (visual regression). Device matrix testing (5-10 representative devices). Performance benchmarking (startup time, frame drops).
+
+7. **Release Pipeline**: CI/CD setup (Fastlane, Bitrise, GitHub Actions). Code signing automation. Beta distribution (TestFlight, Firebase App Distribution). Staged rollout (5% → 25% → 100%). Crash monitoring with auto-rollback triggers.
+</process>

package/.agent/mindforge/monorepo.md

@@ -0,0 +1,30 @@
+---
+description: Set up monorepo with task pipelines. Usage - /mindforge:monorepo [--tool nx|turborepo] [--packages N]
+---
+
+<objective>
+Design and configure a monorepo architecture with efficient task pipelines,
+dependency-aware build ordering, and intelligent caching. Optimizes for
+developer velocity while maintaining clear package boundaries.
+</objective>
+
+<execution_context>
+@.mindforge/skills/monorepo-management/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Choose the monorepo tool based on --tool flag or project needs. Nx for larger projects needing computation caching and module federation; Turborepo for simpler pipeline orchestration with minimal config.
+2. Define workspace structure: separate `apps/` (deployable applications) from `packages/` (shared libraries). Establish naming conventions and package scoping (@org/package-name).
+3. Configure the task pipeline with dependency relationships — build depends on ^build (dependencies first), test depends on ^build, lint runs in parallel with no dependencies.
+4. Set up affected analysis so only packages impacted by a change are built/tested. Configure the base branch for comparison and ignore patterns (docs, README).
+5. Configure caching at two levels: local cache (filesystem, immediate hits on repeated runs) and remote cache (shared across team/CI for cross-machine cache hits).
+6. Define package boundaries and enforce them: no circular dependencies, explicit public API exports, lint rules preventing deep imports across package boundaries.
+7. Set up publishing workflow for shared packages: conventional commits, automated versioning (independent or fixed), changelog generation, and npm/registry publishing.
+8. Configure CI to leverage affected analysis and remote cache — skip unchanged packages, parallelize independent tasks, fail fast on first error.
+9. Document the monorepo conventions: how to add a new package, how to add cross-package dependencies, how to run tasks for specific packages, and troubleshooting cache misses.
+10. Log monorepo invocation in AUDIT with: tool selected, package count, cache strategy, pipeline definition.
+</process>

package/.agent/mindforge/multi-tenant.md

@@ -0,0 +1,31 @@
+---
+description: Design multi-tenancy isolation strategy. Usage - /mindforge:multi-tenant [app] [--isolation rls|schema|database] [--routing subdomain|header]
+---
+
+<objective>
+Design a multi-tenancy architecture that provides appropriate data isolation
+based on regulatory and security requirements, implements tenant context
+propagation through all layers, prevents data leakage between tenants,
+and supports efficient tenant provisioning and onboarding.
+</objective>
+
+<execution_context>
+@.mindforge/skills/multi-tenancy-patterns/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Assess isolation requirements based on the application domain: regulatory constraints (HIPAA/SOC2 may require physical separation), data sensitivity (financial data needs stronger isolation), performance requirements (noisy neighbor concerns), and compliance certifications per tenant.
+2. Choose isolation level based on --isolation flag: RLS (Row-Level Security — shared schema, best for most SaaS with cost efficiency), schema-per-tenant (logical separation, good for regulated industries), or database-per-tenant (physical separation, required for enterprise with data residency requirements). Document trade-offs.
+3. Implement tenant context middleware: extract tenant identifier from request (subdomain, header, JWT claim, or API key), validate tenant exists and is active, inject tenant context into request lifecycle (AsyncLocalStorage/cls-hooked), and propagate to all downstream service calls.
+4. Add query guards for data isolation: for RLS implement PostgreSQL policies (CREATE POLICY tenant_isolation ON table USING (tenant_id = current_setting('app.tenant_id'))), for schema isolation set search_path per request, for DB isolation route connection per tenant. Never rely solely on application-level WHERE clauses.
+5. Configure tenant routing based on --routing flag: subdomain routing (tenant1.app.com — DNS wildcard + middleware extraction), header routing (X-Tenant-ID — simpler but less user-friendly), path-prefix routing (/tenant1/api — SEO-friendly). Implement routing at load balancer level for efficiency.
+6. Test isolation rigorously: verify no data leakage between tenants (create data as tenant A, query as tenant B must return empty), test with concurrent requests from different tenants, verify tenant context survives async operations, and run automated isolation tests in CI.
+7. Plan tenant provisioning workflow: automated tenant creation (database/schema/RLS setup), initial data seeding (defaults, templates), DNS configuration (if subdomain routing), welcome email with onboarding steps, and billing activation. Target <30 seconds for new tenant provisioning.
+8. Document onboarding flow: admin creates tenant via API/dashboard, system provisions resources, tenant admin receives invite, configures settings (branding, users, integrations), and begins using the platform. Include self-service tier for instant provisioning.
+9. Design tenant-aware observability: tag all logs/metrics/traces with tenant_id, per-tenant dashboards for resource consumption, tenant-level SLO tracking, and usage-based billing data collection. Alert on tenants exceeding resource quotas.
+10. Log multi-tenancy design in AUDIT with: app, isolation level, routing strategy, provisioning time target, isolation test coverage, and compliance requirements met.
+</process>