mindforge-cc 10.0.3 → 11.0.0

package/.mindforge/skills/context-engineering/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: context-engineering
+version: 1.0.0
+min_mindforge_version: 10.0.7
+status: stable
+triggers: context engineering, context window management, context token budget, context priority ordering, compaction strategy, context freshness, context allocation, what to include in context, context optimization strategy, retrieval augmentation design, context pruning, context budget allocation
+---
+
+# Context Engineering
+
+## When this skill activates
+
+This skill activates when designing what information to feed into an LLM context window, how to prioritize it, and how to manage context across long-running sessions or multi-turn conversations. It applies to system prompt design, RAG pipeline tuning, agent memory management, and any scenario where token budget allocation determines output quality.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. **Measure the budget** — Determine the total context window size for the target model. Subtract the expected output length. The remainder is your input budget.
+2. **Identify the task** — Classify the task type (code generation, analysis, Q&A, creative). Different tasks require different context compositions.
+3. **Inventory available context** — List all potential context sources: files, conversation history, retrieved documents, instructions, examples, metadata.
+4. **Assess current context health** — If modifying an existing system, measure current context utilization. Identify waste (irrelevant content consuming tokens).
+
+### During
+
+#### What to Include vs Exclude
+
+**Include (high signal):**
+- Task-relevant source code (the files being modified or referenced)
+- Explicit constraints and requirements
+- Relevant examples demonstrating desired behavior
+- Error messages and stack traces when debugging
+- Schema definitions and type signatures
+- User preferences and project conventions
+
+**Exclude (low signal, high cost):**
+- Irrelevant conversation history from earlier turns
+- Verbose log output (summarize instead)
+- Unrelated files that happen to be nearby
+- Redundant information already stated elsewhere
+- Boilerplate code that follows obvious patterns
+- Full file contents when only a function is relevant
+
+#### Priority Ordering (Attention Distribution)
+
+- **Position 1 (highest attention): Instructions and constraints** — System prompts, role definitions, mandatory rules. Models attend most strongly to the beginning and end of context.
+- **Position 2: Task-specific content** — The code, document, or data being directly worked on.
+- **Position 3: Examples and references** — Few-shot examples, related patterns, documentation excerpts.
+- **Position 4: Background context** — Project structure, historical decisions, tangential information.
+- **Recency bias** — Models attend more to recent content. Place the most critical dynamic content last (just before the query).
+- **Primacy effect** — System instructions at the very start receive elevated attention. Never bury critical rules in the middle.
+
+#### Token Budget Allocation Framework
+
+| Category | Allocation | Purpose |
+|----------|-----------|---------|
+| Task-relevant content | 60% | Code, data, documents being worked on |
+| Constraints and instructions | 20% | Rules, format requirements, boundaries |
+| Examples | 10% | Few-shot demonstrations, reference patterns |
+| Meta and buffer | 10% | Conversation scaffolding, safety margin |
+
+- **Adapt per task** — Code generation: increase task-relevant to 70%, reduce examples to 5%. Creative tasks: increase examples to 20%.
+- **Never fill 100%** — Leave 10-15% buffer for the model's response and unexpected context needs.
+- **Track token counts** — Use tokenizer libraries (tiktoken, Anthropic tokenizer) to measure precisely. Estimates drift.
+
+#### Compaction Strategy
+
+- **Summarize old context** — Replace verbose conversation history with structured summaries. Keep decisions and outcomes; discard deliberation.
+- **Keep recent verbatim** — The last 2-3 turns should remain uncompacted. Recent context drives current behavior.
+- **Progressive summarization** — As context ages: verbatim (0-2 turns) → detailed summary (3-10 turns) → bullet points (10+ turns) → drop entirely.
+- **Checkpoint key decisions** — Extract and preserve: architectural decisions, user preferences, constraints discovered mid-conversation. These never compact.
+- **Lossy is acceptable** — Perfect recall is not the goal. Relevant recall is. Aggressively prune low-value history.
+
+#### Context Freshness
+
+- **Re-read files before acting** — Never rely on file content from earlier in the conversation if the file may have changed. Always re-read.
+- **Invalidate on mutation** — After any write operation, treat previously-read versions of affected files as stale.
+- **Timestamp awareness** — When including retrieved documents, note their freshness. Flag content older than the relevance threshold.
+- **Session drift** — Long sessions accumulate stale assumptions. Periodically re-ground by re-reading source-of-truth files.
+
+#### RAG Integration (Retrieval Augmented Generation)
+
+- **Chunk size** — 500-1000 tokens per chunk for code; 200-500 for prose. Smaller chunks = more precise retrieval but less surrounding context.
+- **Retrieve selectively** — Max 3-5 chunks (3-5K tokens total). More retrieved content dilutes attention on each piece.
+- **Relevance threshold** — Set a similarity score cutoff. Irrelevant retrieved content is worse than no retrieval.
+- **Cite sources** — Always attribute retrieved content to its source. This helps the model (and user) assess reliability.
+- **Hybrid search** — Combine semantic (embedding) search with keyword (BM25) search. Neither alone is sufficient.
+- **Re-ranking** — Apply a cross-encoder re-ranker after initial retrieval to improve precision before injection.
+
+#### Context Pruning Techniques
+
+- **Sliding window** — Drop oldest turns when approaching limits. Simple but lossy.
+- **Relevance scoring** — Score each context block against the current query. Drop lowest-scoring blocks first.
+- **Deduplication** — Detect and merge repeated information. Common in multi-turn conversations.
+- **Structural pruning** — Remove comments, whitespace, and formatting from code context. Preserve semantics, reduce tokens.
+- **Selective inclusion** — For large files, include only the relevant functions/classes, not the entire file.
+
+### After
+
+1. **Measure utilization** — Calculate what percentage of context was actually relevant to the output. Target >70% relevance.
+2. **Evaluate output quality** — Compare outputs with full context vs pruned context. If quality is maintained, the pruning strategy is sound.
+3. **Document the strategy** — Record the context composition pattern for this use case so it can be replicated and improved.
+4. **Monitor drift** — Track context composition over time. If quality degrades, context may have drifted from optimal allocation.
+
+## Self-check before task completion
+
+- [ ] Token budget is explicitly allocated across categories
+- [ ] Instructions and constraints occupy the highest-attention positions (start and end)
+- [ ] No irrelevant content consuming tokens (verbose logs, unrelated files, redundant info)
+- [ ] Compaction strategy handles long conversations without losing key decisions
+- [ ] File content is fresh (re-read if potentially stale)
+- [ ] RAG retrieval is limited to 3-5 relevant chunks with similarity threshold
+- [ ] At least 10% token buffer remains for response generation
+- [ ] Context composition is documented and reproducible

package/.mindforge/skills/contract-testing/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: contract-testing
+version: 1.0.0
+min_mindforge_version: 10.0.8
+status: stable
+triggers: contract testing, consumer driven contract, pact testing, provider verification, contract broker, schema compatibility, contract first, api contract test, consumer contract, provider contract, contract breaking, bilateral contract
+compose: testing-standards
+---
+
+# Contract Testing
+
+## When this skill activates
+
+This skill activates when working with API contract verification between services, consumer-driven contract workflows, schema compatibility checks, or any task involving service boundary agreements. It applies to both synchronous (HTTP/gRPC) and asynchronous (message queue) contracts.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. Identify all parties in the contract relationship (consumers and providers).
+2. Determine the contract format in use (Pact, OpenAPI, AsyncAPI, Protobuf).
+3. Check if a contract broker is already configured (Pactflow, Pact Broker, custom).
+4. Review existing contracts for the affected endpoints or messages.
+5. Confirm the environment supports contract verification (CI pipeline, broker access).
+
+### During
+
+**Consumer-Driven Contract Workflow:**
+- Consumers define the interactions they require (request/response pairs).
+- Consumer tests generate contract files (pact files, schemas).
+- Contracts are published to a broker with version metadata.
+- Providers pull contracts and verify they satisfy all consumer expectations.
+- Verification results are published back to the broker.
+
+**Schema Compatibility Levels:**
+- **Backward compatible**: New schema can read data written by old schema.
+- **Forward compatible**: Old schema can read data written by new schema.
+- **Full compatible**: Both backward and forward (safest for production).
+- Always validate compatibility BEFORE deploying schema changes.
+
+**Breaking Change Detection:**
+- Removing a field consumers depend on = BREAKING.
+- Changing a field type or format = BREAKING.
+- Adding a required field to a request = BREAKING for providers.
+- Adding an optional field = SAFE (backward compatible).
+- Run `can-i-deploy` checks in CI to gate deployments.
+
+**Contract Broker Practices:**
+- Tag contracts with environment names (dev, staging, prod).
+- Use semantic versioning for contract participants.
+- Enable webhook notifications on verification failures.
+- Maintain contract history for rollback capability.
+
+**Pact-Specific Workflow:**
+1. Write consumer test using Pact DSL (define interaction).
+2. Run consumer test to generate `.pact` JSON file.
+3. Publish pact to broker with consumer version.
+4. Provider runs verification against all registered consumer pacts.
+5. Provider publishes verification result to broker.
+6. CI runs `can-i-deploy` before any deployment proceeds.
+
+**CI Integration:**
+- Consumer pipeline: test → generate pact → publish → trigger provider verification.
+- Provider pipeline: pull pacts → verify → publish result → deploy if green.
+- Use pending pacts for new consumers (failures don't block provider).
+- Use WIP pacts for contracts not yet verified on provider's main branch.
+
+### After
+
+1. All contracts are published to the broker with correct version tags.
+2. Verification results are recorded for both consumer and provider.
+3. `can-i-deploy` passes for the target environment.
+4. Breaking changes are flagged and communicated to affected teams.
+5. Contract coverage includes all critical interactions (not just happy paths).
+
+## Self-check before task completion
+
+- [ ] Consumer tests define the minimal required interaction (no over-specification).
+- [ ] Provider verification runs against ALL registered consumer contracts.
+- [ ] Schema changes are validated for the correct compatibility level.
+- [ ] Breaking changes have been identified and a migration plan exists.
+- [ ] Contract broker has up-to-date versions for all participants.
+- [ ] CI pipeline gates deployment on `can-i-deploy` result.
+- [ ] Error scenarios and edge cases are covered in contracts (not just 200 responses).
+- [ ] Contract tests run in isolation (no network calls, no shared state).

package/.mindforge/skills/cost-estimation/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: cost-estimation
+version: 1.0.0
+min_mindforge_version: 10.0.9
+status: stable
+triggers: cost estimation, cloud cost modeling, finops, reserved instance, spot instance, cost forecast, infrastructure cost, cost per request, pricing model, cost optimization plan, resource right-sizing, cost allocation
+---
+
+# Skill — Cost Estimation
+
+## When this skill activates
+Any task involving cloud cost modeling, FinOps, instance strategy selection,
+cost forecasting, per-request cost analysis, right-sizing, or cost allocation.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Estimate costs BEFORE building: compute + storage + network + managed services.
+2. Identify cost-dominant components (usually storage or network egress).
+3. Define budget constraints and alerting thresholds.
+
+### During implementation
+- Choose instances based on workload profile (compute/memory/IO bound).
+- Implement resource tagging for cost allocation from day one.
+- Use auto-scaling with min/max bounds.
+- Prefer managed services when ops cost exceeds infrastructure savings.
+
+### After implementation
+- Set cost alerts at 50%, 80%, 100% of budget.
+- Create per-service cost dashboard.
+- Schedule monthly cost review for drift and optimization.
+
+## FinOps Phases
+
+- **Inform**: tag all resources, build dashboards, implement showback/chargeback.
+- **Optimize**: right-size, reserve steady workloads, spot for batch, eliminate waste.
+- **Operate**: automate (scheduled scaling, auto-stop dev), embed cost in PR review.
+
+## Cost Modeling
+
+```
+Monthly = Compute + Storage + Network + Managed + Support
+Compute: instances * hours * $/hour
+Storage: GB * $/GB + IOPS * $/IOP
+Network: GB egress * $/GB (ingress usually free)
+Cost/Request: total_monthly / total_requests
+```
+
+## Instance Strategy
+
+| Type | Discount | Use For | Never For |
+|------|----------|---------|-----------|
+| On-Demand | 0% | Variable, dev, testing | Steady production (wasteful) |
+| Reserved (1-3yr) | 30-72% | Steady production (>70% util for 6+ months) | Uncertain workloads |
+| Spot/Preemptible | 60-90% | Batch, CI/CD, fault-tolerant workers | Databases, user-facing |
+
+## Right-Sizing Indicators
+- CPU < 40% consistently = oversized.
+- Memory < 50% consistently = oversized.
+- Process: collect 2-4 weeks metrics → find binding constraint → resize to peak + 20%.
+
+## Cost Allocation Tags (Minimum)
+- `team`, `service`, `environment`, `cost-center`.
+- Optional: `feature` for per-feature attribution.
+- Shared infra: divide proportionally by request count or CPU time.
+
+## Forecasting
+```
+Next Month = Current * (1 + organic_growth) + planned_launch_impact
+```
+- Inputs: historical trend (3-6 months), planned launches, seasonal patterns.
+- Weekly: check for anomalies. Monthly: forecast vs actual. Quarterly: re-evaluate commitments.
+
+## Self-check before task completion
+
+- [ ] Did I estimate costs before proposing infrastructure?
+- [ ] Are resources tagged for cost allocation?
+- [ ] Is instance strategy appropriate (on-demand vs reserved vs spot)?
+- [ ] Are cost alerts configured at budget thresholds?
+- [ ] Is right-sizing based on actual utilization data?
+- [ ] Is there a cost visibility mechanism (dashboard)?
+- [ ] Are managed-vs-self-hosted trade-offs documented?

package/.mindforge/skills/cqrs-event-sourcing/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: cqrs-event-sourcing
+version: 1.0.0
+min_mindforge_version: 10.0.6
+status: stable
+triggers: cqrs, event sourcing, command query separation, event store, projection, eventual consistency, event replay, aggregate root, domain event, event versioning, read model, write model
+---
+
+# Skill — CQRS & Event Sourcing
+
+## When this skill activates
+Any task involving command/query responsibility segregation, event sourcing, event store
+design, projection building, or systems requiring full audit trails and temporal queries.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. **Validate the need** — Confirm at least one: full audit trail required, temporal queries needed, complex domain with many read views, or high read/write asymmetry.
+2. **Identify aggregates** — Define aggregate roots as consistency boundaries. Each aggregate emits domain events and enforces invariants.
+3. **Map read vs write models** — Document which queries need optimized read models separate from the event stream.
+
+### During
+
+#### Command side (write model)
+- Commands are imperative ("PlaceOrder", "CancelShipment")
+- Command handler validates invariants then emits domain events
+- State is NEVER set directly — it is derived by applying events
+- Aggregate enforces business rules before accepting the command
+
+#### Event store design
+```sql
+CREATE TABLE events (
+  event_id        UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  aggregate_id    UUID NOT NULL,
+  aggregate_type  VARCHAR(100) NOT NULL,
+  event_type      VARCHAR(100) NOT NULL,
+  event_version   INTEGER NOT NULL,
+  sequence_number BIGINT NOT NULL,
+  payload         JSONB NOT NULL,
+  metadata        JSONB NOT NULL,  -- correlation_id, causation_id, actor
+  created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+  UNIQUE (aggregate_id, sequence_number)
+);
+```
+- Events are immutable — never update or delete
+- Optimistic concurrency via expected sequence number on write
+- Event names are past tense: `OrderPlaced`, `PaymentCharged`
+- Store both payload and metadata (correlation ID, causation ID, actor)
+
+#### Projections (read models)
+- Each projection materializes a read-optimized view from the event stream
+- Projections are independently rebuildable (replay from event 0)
+- Use checkpointing: store last processed event position
+- Different projections can use different databases (SQL, Elasticsearch, Redis)
+- Mark as "rebuilding" during replay to avoid serving stale data
+
+#### Eventual consistency patterns
+- Causal consistency: return event sequence number from command, poll until projection catches up
+- Read-your-writes: optimistically update client state after command succeeds
+- Subscription-based: clients subscribe to projection update notifications
+
+#### Snapshot strategy
+- Avoid replaying entire history for long-lived aggregates
+- Load latest snapshot + events after snapshot sequence number
+- Snapshot frequency: every 50-100 events per aggregate
+- Snapshots are optimization only — system must work without them
+
+#### Event versioning and upcasting
+- Never modify existing event schemas in-place
+- Add optional fields (backward-compatible) or create new event type
+- Upcasters transform old events to current schema during replay
+- Store schema version with every event for routing to correct upcaster
+
+#### Idempotent handlers
+- Every projection/handler must be safe to process the same event twice
+- Deduplicate by event_id before processing
+- Record checkpoint after successful processing
+
+### After
+
+1. **Verify event completeness** — Every state change captured as a domain event. No silent mutations.
+2. **Test replay** — Rebuild one projection from scratch; confirm data integrity.
+3. **Validate idempotency** — Process same event twice, confirm no side effects.
+4. **Check consistency boundaries** — Each aggregate enforces invariants independently.
+
+## Self-check before task completion
+- [ ] All state changes expressed as immutable domain events
+- [ ] Event store uses optimistic concurrency (sequence number)
+- [ ] Projections independently rebuildable from event stream
+- [ ] Event handlers are idempotent (safe to replay)
+- [ ] Snapshot strategy defined for long-lived aggregates
+- [ ] Event versioning/upcasting handles schema evolution
+- [ ] Eventual consistency communicated to client layer
+- [ ] Correlation and causation IDs propagated through event chain

package/.mindforge/skills/cross-platform-testing/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: cross-platform-testing
+version: 1.0.0
+min_mindforge_version: 10.4.0
+status: stable
+triggers: cross-platform testing, device farm testing, screenshot comparison test, platform-specific testing, mobile CI pipeline, Appium testing, Detox testing, XCTest UITest, mobile test automation, device matrix coverage, mobile E2E testing, visual regression mobile
+---
+
+# Skill — Cross-Platform Mobile Testing
+
+## When this skill activates
+This skill activates when implementing comprehensive mobile testing strategies, including device farm integration, screenshot testing, platform-specific behavior validation, or CI/CD pipelines for mobile apps.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Define device matrix covering target OS versions, screen sizes, and hardware capabilities (prioritize based on user analytics)
+2. Choose testing framework appropriate for platform (XCTest/XCUITest for iOS, Espresso/UIAutomator for Android, Detox/Appium for cross-platform)
+3. Establish screenshot testing baseline images and tolerance thresholds for visual regression detection
+4. Design test data strategy — use factories/fixtures, implement proper setup/teardown, ensure test isolation
+
+### During implementation
+- Write tests at appropriate levels: unit tests for business logic, integration tests for data flows, E2E tests for critical user journeys
+- Implement proper test identifiers (testID, accessibilityIdentifier) in UI components for reliable element selection
+- Use page object pattern or similar abstraction to decouple tests from UI implementation details
+- Configure screenshot testing with proper device/OS-specific baselines to handle platform rendering differences
+- Implement retry logic for flaky tests caused by animation timing, network delays, or platform quirks
+- Set up parallel test execution on device farms (Firebase Test Lab, AWS Device Farm, BrowserStack) for faster feedback
+- Handle platform-specific behaviors explicitly in tests (Android back button, iOS swipe gestures, permission dialogs)
+
+### After implementation
+- Run full test suite on representative device matrix, not just emulators/simulators
+- Review test flakiness rates and fix or quarantine unstable tests
+- Integrate tests into CI pipeline with proper failure reporting and artifact collection (screenshots, logs, videos)
+- Validate test coverage for critical paths and high-risk areas (payments, authentication, data sync)
+
+## Self-check before task completion
+- [ ] Test suite runs reliably across multiple devices and OS versions with <5% flakiness
+- [ ] Screenshot tests catch visual regressions without excessive false positives
+- [ ] Platform-specific behaviors are tested correctly (back button, deep links, system gestures)
+- [ ] CI pipeline provides clear failure reporting with screenshots/videos for debugging
+- [ ] E2E tests cover critical user journeys end-to-end, including error scenarios
+- [ ] Test execution time is reasonable (use parallelization, split test suites if needed)

package/.mindforge/skills/data-governance/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: data-governance
+version: 1.0.0
+min_mindforge_version: 10.6.0
+status: stable
+triggers: data governance framework, data catalog implementation, data lineage tracking, data access control, data quality framework, data stewardship, metadata management, data classification, data retention policy, data discovery platform, data ownership, data compliance framework
+---
+
+# Skill — Data Governance
+
+## When this skill activates
+This skill activates when implementing data catalog systems, establishing data ownership models, building lineage tracking, or designing access control frameworks. Use when organizations need to scale data democratization while maintaining compliance and quality.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Define data classification taxonomy with clear criteria: public, internal, confidential, restricted with handling requirements for each tier
+2. Establish data ownership model: domain owners, data stewards, technical custodians with RACI matrix for responsibilities
+3. Document compliance requirements: GDPR, CCPA, HIPAA, SOC2 with specific technical controls needed for each regulation
+4. Design metadata schema capturing: business definitions, technical specifications, quality metrics, lineage, and access policies
+
+### During implementation
+- Build automated data catalog discovery scanning databases, data lakes, APIs, and file systems to populate metadata repository
+- Implement column-level lineage tracking from source systems through transformations to final consumption with impact analysis capabilities
+- Create role-based access control (RBAC) with attribute-based policies (ABAC) for dynamic access based on data classification and user context
+- Establish data quality framework with profiling rules, validation checks, and quality scores at dataset and column level
+- Implement data retention policies with automated archival and deletion workflows based on regulatory requirements and business rules
+- Build data stewardship workflows for metadata enrichment: business glossary terms, data ownership assignment, quality issue resolution
+- Create audit logging for all data access, modifications, and policy changes with immutable trail for compliance reporting
+
+### After implementation
+- Deploy self-serve data discovery portal with search, business glossary, quality indicators, and access request workflows
+- Generate automated data quality reports with trend analysis, anomaly detection, and stakeholder-specific dashboards
+- Create compliance audit packages with evidence of controls: access logs, retention proof, encryption verification, lineage documentation
+- Build data governance metrics dashboard: catalog coverage, metadata completeness, quality score trends, access request SLA
+
+## Self-check before task completion
+- [ ] Data catalog covers 90%+ of production data assets with accurate business metadata
+- [ ] Lineage tracking provides end-to-end visibility from source to consumption with transformation logic
+- [ ] Access control policies enforced at query time with separation of duties for sensitive data
+- [ ] Data quality framework monitors critical datasets with automated alerting on quality degradation
+- [ ] Compliance documentation generated automatically with evidence trails for audit requirements

package/.mindforge/skills/data-lakehouse/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: data-lakehouse
+version: 1.0.0
+min_mindforge_version: 10.6.0
+status: stable
+triggers: data lakehouse architecture, medallion architecture, schema evolution lakehouse, time travel data, partition optimization, Delta Lake implementation, Iceberg table design, lakehouse query performance, data lakehouse governance, lakehouse ingestion, lakehouse serving layer, lakehouse cost optimization
+---
+
+# Skill — Data Lakehouse
+
+## When this skill activates
+This skill activates when implementing lakehouse architectures combining data lake flexibility with data warehouse performance. Use when building Delta Lake, Iceberg, or Hudi tables with ACID guarantees, schema evolution, and time travel capabilities.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Design medallion architecture layers: bronze (raw ingestion), silver (cleansed/conformed), gold (business-level aggregates) with clear promotion criteria
+2. Select table format (Delta, Iceberg, Hudi) based on requirements: write patterns, query patterns, ecosystem compatibility, and feature needs
+3. Plan partitioning strategy based on query patterns: typically date/time for time-series, geography for location-based, or composite keys avoiding over-partitioning (<1000 partitions)
+4. Define schema evolution policy: additive changes (safe), nullable to required (breaking), type changes (migration required) with versioning strategy
+
+### During implementation
+- Implement ACID transactions for atomic writes: use table format's transaction log (Delta Log, Iceberg metadata) to ensure consistency
+- Configure file sizing for optimal query performance: target 128MB-1GB per file, run regular OPTIMIZE/COMPACT operations to prevent small files
+- Enable time travel with retention policy: maintain snapshots for point-in-time queries and audit, configure vacuum/expire based on compliance needs
+- Design incremental processing patterns: merge/upsert operations for CDC, append for event streams, overwrite partitions for batch updates
+- Implement Z-ordering or clustering on frequently filtered columns (non-partition keys) to improve query performance via data skipping
+- Build schema evolution handlers: automatic schema merging for new columns, validation for breaking changes, schema registry integration
+- Create data quality checkpoints between medallion layers: row counts, null checks, referential integrity, business rule validation with quarantine tables
+
+### After implementation
+- Monitor table health metrics: file count, average file size, partition count, metadata size, and compaction needs
+- Build cost optimization reports: storage by layer, compute for jobs, query costs, and opportunities for partition pruning or materialization
+- Create governance controls: table-level access policies, column masking, row filtering, and audit logging for sensitive data access
+- Generate performance analysis: query patterns, partition pruning effectiveness, file skipping statistics, and optimization recommendations
+
+## Self-check before task completion
+- [ ] Medallion layers clearly defined with data quality gates between bronze → silver → gold promotions
+- [ ] Partitioning strategy optimized for query patterns with validation that queries prune partitions effectively
+- [ ] ACID transactions tested with concurrent writes and failure scenarios to ensure consistency
+- [ ] Schema evolution tested with backward and forward compatibility for common evolution scenarios
+- [ ] File management strategy (OPTIMIZE/VACUUM) scheduled with monitoring for small file accumulation

package/.mindforge/skills/data-mesh/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: data-mesh
+version: 1.0.0
+min_mindforge_version: 10.6.0
+status: stable
+triggers: data mesh architecture, domain data ownership, data product design, federated data governance, self-serve data platform, data mesh implementation, data contract mesh, data domain boundary, mesh interoperability, decentralized data ownership, data product specification, domain-driven data
+---
+
+# Skill — Data Mesh
+
+## When this skill activates
+This skill activates when implementing data mesh architectures with domain-oriented ownership, federated governance, and data-as-a-product principles. Use when centralizing data management becomes a bottleneck and domains need autonomy with interoperability.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Define domain boundaries using domain-driven design: bounded contexts, ubiquitous language, core domains vs supporting domains with ownership mapping
+2. Establish data product specification template: SLAs, schemas, semantics, access controls, versioning, and quality guarantees each domain must provide
+3. Design federated computational governance: global standards (discovery, security, interoperability) enforced through platform, local decisions (tech stack, modeling) owned by domains
+4. Create self-serve data platform capabilities: provisioning automation, observability tools, discovery services, and development environments domains can use independently
+
+### During implementation
+- Build data product registry with standardized metadata: domain owner, SLAs, schemas, sample data, access request process, and consumer feedback
+- Implement data contracts between domains: schema definitions, backward compatibility guarantees, deprecation policies, and breaking change notifications
+- Create domain-agnostic platform services: infrastructure provisioning (IaC templates), CI/CD pipelines, monitoring dashboards, and cost allocation
+- Design data product APIs with consistency: REST for batch, streaming for real-time, query engines for analytical, with versioning and deprecation paths
+- Establish quality frameworks domains must implement: data validation, profiling, lineage tracking, incident response with federated monitoring
+- Build interoperability layer: common data types, standard formats (Parquet, Avro), semantic layer, and cross-domain joins through data products not direct access
+- Implement federated identity and access: domain-owned authorization, centralized authentication, audit logging, and privacy controls enforced at platform level
+
+### After implementation
+- Create data product marketplace: searchable catalog, quality scores, usage analytics, consumer reviews, and onboarding documentation
+- Build platform health metrics: provisioning time, incident resolution SLA, platform uptime, and developer satisfaction scores
+- Generate federated governance reports: compliance by domain, quality trends, cross-domain dependencies, and policy violations
+- Document domain interaction patterns: producer-consumer relationships, data sharing agreements, and conflict resolution processes
+
+## Self-check before task completion
+- [ ] Domain boundaries clearly defined with ownership assignments and RACI matrix for responsibilities
+- [ ] Data products meet platform standards for discoverability, access control, quality, and SLAs
+- [ ] Self-serve platform enables domains to provision, deploy, and monitor data products independently
+- [ ] Federated governance enforces global standards while allowing domain autonomy in implementation
+- [ ] Interoperability tested across domains through data product contracts and APIs, not direct database access