mindforge-cc 10.0.3 → 11.0.0

package/.mindforge/skills/payment-integration/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: payment-integration
+version: 1.0.0
+min_mindforge_version: 10.0.4
+status: stable
+triggers: payment integration, stripe architecture, payment webhook, idempotent charge, refund flow, PCI scope, payment state machine, subscription billing, payment retry, payment reconciliation, checkout flow, payment method tokenization
+compose: security-review
+---
+
+# Skill — Payment Integration (Idempotent Payment Architecture)
+
+## When this skill activates
+When building or modifying payment flows, integrating payment providers (Stripe,
+PayPal, Braintree), handling subscriptions, processing refunds, or dealing with
+any money movement in the system. Also activates for PCI compliance considerations.
+
+Core principle: **Idempotency is life** — every payment operation must be safe to
+retry without charging the customer twice. When in doubt, err on the side of NOT
+charging.
+
+## Mandatory actions when this skill is active
+
+### Payment State Machine
+
+1. **Every payment has a well-defined state machine:**
+   ```
+   States:
+   created → processing → succeeded
+                        → failed → (retry) → processing
+   succeeded → refund_pending → refunded
+   succeeded → disputed → dispute_won (funds returned)
+                        → dispute_lost (funds lost)
+
+   State transitions:
+   - created → processing: charge initiated with provider
+   - processing → succeeded: provider confirms capture
+   - processing → failed: provider declines or errors
+   - succeeded → refund_pending: refund initiated
+   - refund_pending → refunded: provider confirms refund
+   ```
+
+   Rules:
+   - State transitions are APPEND-ONLY (never delete payment records)
+   - Every transition logged with timestamp, actor, and reason
+   - Failed payments can retry (max 3 attempts with exponential backoff)
+   - Terminal states: succeeded, refunded, dispute_won, dispute_lost
+
+### Idempotency
+
+2. **Idempotency key on every charge call:**
+   ```
+   Idempotency key format: [user_id]-[order_id]-[attempt_number]
+   Example: usr_abc123-ord_xyz789-1
+
+   Rules:
+   - Generate idempotency key BEFORE calling payment provider
+   - Store key in database alongside payment intent
+   - If retry needed: increment attempt number, generate new key
+   - Provider stores result by key — retrying same key returns same result
+   - Key expiry: 24 hours (Stripe default) — don't retry after that
+   ```
+
+   Critical: If the client retries (network timeout, unclear response), the
+   idempotency key ensures no double charge. This is non-negotiable.
+
+### Webhook Processing
+
+3. **Webhook handler requirements:**
+   ```
+   1. Verify signature FIRST (reject if invalid — no processing)
+   2. Respond 200 immediately (within 5 seconds)
+   3. Process the event ASYNCHRONOUSLY (queue for background processing)
+   4. Process IDEMPOTENTLY (same webhook delivered twice = same outcome)
+   5. Handle OUT-OF-ORDER delivery (payment_intent.succeeded before payment_intent.created)
+   ```
+
+   Implementation:
+   ```
+   POST /webhooks/stripe
+   1. Verify: stripe.webhooks.constructEvent(body, sig, secret)
+   2. Dedup: check event.id against processed_events table
+   3. If already processed: return 200 (idempotent)
+   4. Queue: enqueue event for async processing
+   5. Return 200
+   6. [Async worker]: process event, update payment state, mark as processed
+   ```
+
+   Rules:
+   - NEVER do business logic synchronously in the webhook handler
+   - Store raw webhook payload for debugging/replay
+   - Implement webhook replay for missed events (fetch from provider API)
+   - Monitor webhook lag (time between event creation and processing)
+
+### PCI Scope Minimization
+
+4. **Never touch raw card numbers:**
+   ```
+   Client-side tokenization flow:
+   1. User enters card → Stripe.js/Elements captures it
+   2. Card data goes DIRECTLY to Stripe (never touches your server)
+   3. Stripe returns a token/PaymentMethod ID
+   4. Your server uses the token to create charges
+
+   Your server NEVER sees: card number, CVV, expiration date
+   Your PCI scope: SAQ-A (lowest level — just a questionnaire)
+   ```
+
+   Rules:
+   - Use Stripe Elements, PayPal JS SDK, or equivalent client-side tokenization
+   - Never log request bodies that might contain card data
+   - Never store card data in your database (only token references)
+   - If using iframes: ensure they're from the payment provider's domain
+   - PCI-DSS audit not required if you stay at SAQ-A level
+
+### Subscription Billing
+
+5. **Subscription lifecycle:**
+   ```
+   States: trial → active → past_due → canceled → expired
+
+   trial → active: trial period ends, first charge succeeds
+   active → past_due: renewal charge fails
+   past_due → active: retry succeeds
+   past_due → canceled: all retries exhausted + grace period ended
+   canceled → active: user resubscribes (new subscription)
+   ```
+
+   Dunning (failed payment recovery):
+   ```
+   Day 0: Charge fails → retry immediately
+   Day 1: Second retry
+   Day 3: Third retry + email notification ("update payment method")
+   Day 7: Final retry + urgent email + in-app banner
+   Day 14: Cancel subscription + final email ("your subscription has ended")
+   ```
+
+   Rules:
+   - Dunning schedule is configurable per plan tier
+   - Always give users a way to update payment method without re-subscribing
+   - Prorate upgrades/downgrades (charge difference immediately or credit)
+   - Webhook: handle invoice.payment_failed for dunning triggers
+
+### Reconciliation
+
+6. **Daily reconciliation process:**
+   ```
+   Every 24 hours:
+   1. Fetch all payments from provider API (last 48 hours, overlap for safety)
+   2. Match against internal payment records
+   3. Flag discrepancies:
+      - Payment in provider but not in our DB (missed webhook)
+      - Payment in our DB but not in provider (ghost record)
+      - Amount mismatch (partial capture, currency conversion)
+      - Status mismatch (we say succeeded, provider says failed)
+   4. Auto-resolve simple cases (missed webhook → replay)
+   5. Alert on unresolvable discrepancies (requires human review)
+   ```
+
+   Rules:
+   - Reconciliation runs daily minimum, hourly for high-volume systems
+   - Use 48-hour overlap window to catch delayed settlements
+   - Discrepancy alerts go to finance + engineering
+   - Never auto-resolve amount mismatches (always flag for human)
+
+## Self-check before task completion
+
+Before marking a task done when this skill was active:
+
+- [ ] Is there a well-defined state machine for payment lifecycle?
+- [ ] Does every charge call include an idempotency key?
+- [ ] Are webhooks verified (signature), deduplicated, and processed async?
+- [ ] Is PCI scope minimized (client-side tokenization, no raw card data on server)?
+- [ ] For subscriptions: is the dunning sequence defined with escalating notifications?
+- [ ] Is daily reconciliation implemented (provider vs internal records)?
+- [ ] Are all payment state transitions logged with timestamp and reason?
+- [ ] Has the security-review skill been co-activated for this payment code?

package/.mindforge/skills/performance-reviews/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: performance-reviews
+version: 1.0.0
+min_mindforge_version: 10.3.0
+status: stable
+triggers: performance review engineering, promotion case writing, feedback framework, calibration session, engineering evaluation criteria, performance improvement plan, impact documentation, promotion packet, peer feedback engineering, engineering levels, growth assessment, performance calibration
+---
+
+# Performance Reviews
+
+## When this skill activates
+
+This skill activates when conducting engineering performance evaluations, writing promotion cases, designing feedback frameworks, participating in calibration sessions, creating performance improvement plans, or assessing growth against engineering levels. It applies to engineering managers, tech leads, and senior engineers involved in performance management.
+
+## Mandatory actions when this skill is active
+
+### Before performance reviews
+
+1. **Define evaluation criteria explicitly** — What does success look like at each engineering level? Common dimensions: technical execution, system design, code quality, communication, collaboration, ownership, impact, mentorship. Map criteria to levels (junior, mid, senior, staff, principal).
+2. **Collect evidence throughout the cycle** — Don't rely on memory. Keep a running doc of: projects shipped, PRs reviewed, incidents handled, design docs written, mentoring moments. Real-time logging prevents recency bias.
+3. **Gather 360-degree feedback** — Ask peers, cross-functional partners, and direct reports (if applicable) for input. Single-source feedback is incomplete. Use structured prompts: "What does [Engineer] do well?" "Where could they grow?"
+4. **Review the engineer's self-assessment** — Ask them to evaluate their own performance before writing your review. Gaps between self-assessment and manager assessment are learning opportunities.
+
+### During performance evaluation
+
+#### Engineering Level Expectations
+
+Use a competency matrix to define clear expectations at each level. Example dimensions:
+
+| Dimension | Junior | Mid-Level | Senior | Staff | Principal |
+|-----------|--------|-----------|--------|-------|-----------|
+| Scope of Work | Well-defined tasks | Small features | Full features/services | Multi-team projects | Org-wide initiatives |
+| Technical Complexity | Low complexity | Medium complexity | High complexity | Architectural decisions | Strategic direction |
+| Autonomy | Needs guidance | Some autonomy | Fully autonomous | Defines direction | Sets vision |
+| Code Quality | Learns best practices | Applies best practices | Role models best practices | Defines standards | Elevates org quality |
+| Design | Implements designs | Designs small features | Designs systems | Designs platforms | Shapes architecture |
+| Mentorship | Learns from others | Helps peers | Mentors 1-2 juniors | Mentors team | Mentors org |
+| Communication | Within team | Cross-team (technical) | Cross-functional | Executives + external | Industry thought leader |
+| Impact | Individual tasks | Team features | Service/product | Organization | Company/industry |
+
+#### Evaluation Process
+
+- **Rate performance on each dimension** — Use a 1-5 scale: 1 = Below expectations, 2 = Partially meets, 3 = Meets, 4 = Exceeds, 5 = Greatly exceeds.
+- **Provide specific examples** — Don't say "Strong communicator." Say "Led design review for Payment Service rewrite, clearly articulated tradeoffs, and incorporated feedback from 5 engineers."
+- **Distinguish between performance at level vs readiness for next level** — Meeting expectations at Senior level doesn't automatically mean ready for Staff. Promotion requires sustained performance at the next level.
+- **Identify growth areas** — Every engineer has gaps. Name them specifically and provide actionable guidance: "To reach Staff, you need to mentor 2-3 engineers and lead a cross-team project."
+
+#### Feedback Framework: SBI + Coaching
+
+Use **Situation-Behavior-Impact (SBI)** for developmental feedback:
+- **Situation**: "In last week's design review..."
+- **Behavior**: "...you dismissed Sarah's concern about edge cases without discussing it..."
+- **Impact**: "...which made the team hesitant to raise concerns in future reviews."
+
+Follow SBI with **Coaching**:
+- "Next time, try acknowledging the concern and discussing it openly. Even if you ultimately disagree, demonstrating openness builds trust."
+
+#### Writing Performance Reviews
+
+**Structure:**
+1. **Summary** — Overall performance (meets/exceeds expectations), 2-3 key strengths, 1-2 growth areas.
+2. **Key Accomplishments** — 3-5 most impactful projects or contributions with specific outcomes (metrics, launches, quality improvements).
+3. **Dimension-by-Dimension Assessment** — Rate and provide examples for each competency (technical execution, collaboration, ownership, etc.).
+4. **Growth Areas** — 1-3 specific areas for development with actionable suggestions.
+5. **Career Development** — If promotion-track, outline path to next level. If not promotion-track, outline how to grow within current level.
+
+**Tone:**
+- Be direct but supportive. Sugarcoating developmental feedback doesn't help.
+- Use "I observed" not "you are." Focus on behavior, not identity.
+- Balance positive and developmental. If someone is strong, say so. If they have gaps, name them.
+
+#### Promotion Case Writing
+
+**Promotion Readiness Criteria:**
+- **Sustained performance at the next level** — For 6-12 months, not just one stellar project. Consistency matters.
+- **Demonstrated scope expansion** — Taking on bigger, more complex, more ambiguous work.
+- **Organizational impact** — Contributed beyond their immediate team (mentoring, tooling, process improvements).
+
+**Promotion Packet Structure:**
+1. **Summary** — Candidate name, current level, target level, tenure, manager endorsement.
+2. **Case for Promotion** — Why are they ready? Use the competency matrix. Show where they meet or exceed next-level expectations.
+3. **Key Accomplishments** — 3-5 high-impact projects with measurable outcomes. Align each to next-level competencies.
+4. **Peer Feedback** — 3-5 quotes from peers, cross-functional partners, or senior engineers. Shows they operate at the next level already.
+5. **Growth Areas** — Even strong candidates have gaps. Acknowledge them but show they're manageable.
+6. **Comparison to Peers** — How does this candidate compare to others at the target level? Calibration context matters.
+
+**Pitfall:** Nominating someone for promotion because they've been around a long time, not because they perform at the next level. Tenure is not a promotion criterion.
+
+#### Performance Improvement Plans (PIPs)
+
+**When to Use PIPs:**
+- Performance is significantly below expectations for 2+ months.
+- Specific, documented performance issues that haven't improved despite feedback.
+- Not a surprise. PIP should be the culmination of ongoing feedback, not a sudden shock.
+
+**PIP Structure:**
+1. **Performance Gaps** — Specific areas where performance is below expectations. Use examples.
+2. **Success Criteria** — What does improvement look like? Measurable, time-bound goals (e.g., "Ship 2 features with <2 rounds of rework within 60 days").
+3. **Support Provided** — What will the manager, mentor, or team do to support improvement? (e.g., weekly 1:1s, pairing sessions, dedicated mentor).
+4. **Timeline** — Typically 30-60 days. Clear checkpoints (15 days, 30 days).
+5. **Consequences** — If performance doesn't improve, what happens? (Usually termination or role change.)
+
+**Facilitation:**
+- Weekly check-ins during the PIP period. Don't wait until the end to give feedback.
+- Document everything. Notes from 1:1s, progress on goals, feedback given.
+- Be honest but supportive. The goal is improvement, not punishment.
+
+#### Calibration Sessions
+
+**Purpose:** Ensure consistency in performance ratings across managers. Prevents rating inflation or deflation.
+
+**Process:**
+1. **Managers submit preliminary ratings** — Each manager rates their team members on the 1-5 scale.
+2. **Group discussion** — Managers present outlier cases (all 5s, any 1s or 2s). Justify ratings with evidence.
+3. **Identify inconsistencies** — If Manager A rates their team higher than Manager B for similar performance, probe why. Normalize.
+4. **Adjust ratings** — Based on discussion, managers adjust ratings to reflect consistent standards.
+
+**Best Practices:**
+- Come prepared with evidence. Don't rely on vague impressions.
+- Challenge inflation. If someone rates their entire team 4s and 5s, that's not a high-performing team; that's grade inflation.
+- Use the competency matrix as the source of truth. Ratings should map to observable behaviors at each level.
+
+### After performance reviews
+
+- **Deliver feedback in 1:1s** — Don't just send the written review. Walk through it together. Give the engineer space to ask questions or disagree.
+- **Create a growth plan** — Based on the review, define 30-60-90 day goals tied to growth areas. Make it concrete and actionable.
+- **Follow up regularly** — Check progress on growth goals in 1:1s. Don't wait for the next review cycle to give feedback.
+- **Track promotion pipeline** — Identify engineers who are on a promotion track. Ensure they get the projects and visibility needed to demonstrate readiness.
+- **Document outcomes** — If performance improves or worsens, note it. Builds a longitudinal record that's useful for calibration and promotion discussions.
+
+## Self-check before task completion
+
+- [ ] Evaluation criteria are explicitly defined with clear expectations at each engineering level
+- [ ] Evidence is collected throughout the review cycle (projects, PRs, incidents, mentoring)
+- [ ] 360-degree feedback is gathered from peers, cross-functional partners, and reports
+- [ ] Performance review includes specific examples for each competency, not vague statements
+- [ ] Developmental feedback uses SBI framework (Situation-Behavior-Impact) with coaching
+- [ ] Promotion case demonstrates sustained performance at the next level for 6-12 months
+- [ ] Promotion packet includes key accomplishments, peer feedback, and calibration context
+- [ ] PIPs include specific performance gaps, measurable success criteria, and support plan

package/.mindforge/skills/platform-observability/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: platform-observability
+version: 1.0.0
+min_mindforge_version: 10.7.0
+status: stable
+triggers: platform observability design, unified observability stack, trace correlation platform, log aggregation architecture, metrics cardinality management, observability platform, telemetry pipeline, distributed tracing platform, observability cost, observability data model, observability self-service, alert routing platform
+compose: observability-stack
+---
+
+# Skill — Platform Observability
+
+## When this skill activates
+
+This skill activates when the user is designing or implementing platform observability capabilities. This includes unified observability stacks, trace correlation, log aggregation architecture, metrics cardinality management, telemetry pipelines, distributed tracing platforms, observability cost optimization, observability data models, self-service observability, and alert routing platforms.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+
+1. Audit current observability tooling: metrics (Prometheus, Datadog), logs (Elasticsearch, Splunk), traces (Jaeger, Honeycomb). Identify gaps and redundancies.
+2. Assess observability cost: cost per service, cost per metric, cost per log line, cost per trace. Identify high-cardinality metrics and expensive log patterns.
+3. Define observability requirements per service tier: critical services need full traces, non-critical services need sampled traces.
+4. Map existing alert sprawl: how many alerts fire per week, what percentage are actionable. Target: reduce noise by 70-90%.
+5. Establish observability SLOs: query latency (p95 < 3 seconds), data freshness (under 30 seconds), retention (metrics 30 days, logs 7 days, traces 7 days).
+
+### During implementation
+
+- **Unified Observability Stack:** Use OpenTelemetry for instrumentation (vendor-neutral). Collect metrics, logs, and traces via single SDK. Export to backend(s) of choice (Prometheus, Loki, Tempo). Avoids vendor lock-in.
+- **Trace Correlation:** Link traces, logs, and metrics via trace ID. Every log line should include trace ID and span ID. Enables root-cause analysis by jumping from metric spike → trace → logs.
+- **Log Aggregation Architecture:** Centralized log storage (Elasticsearch, Loki, CloudWatch). Use structured logging (JSON) with consistent schema. Index on: service, environment, level, trace_id. Retain logs for 7-30 days (compliance may require longer).
+- **Metrics Cardinality Management:** High-cardinality labels (user_id, request_id) explode metric storage cost. Use exemplars (link to trace) instead. Limit labels to: service, environment, region, status_code. Target: under 10,000 time series per service.
+- **Telemetry Pipeline:** Decouple collection from storage. Use OpenTelemetry Collector as aggregation layer. Enables: sampling, filtering, enrichment, multi-backend export. Pipeline should handle 100k+ events/second.
+- **Distributed Tracing:** Instrument all services with OpenTelemetry. Use head-based sampling (sample 1-10% of traces) or tail-based sampling (sample slow/error traces at 100%, fast traces at 1%). Traces should include: service name, operation, duration, status, attributes (http.method, db.statement).
+- **Observability Cost Optimization:** Sample aggressively (1-10% for most services). Drop high-volume, low-value logs (health checks, debug logs in prod). Use tiered storage (hot: 7 days, warm: 30 days, cold: 90 days). Target: observability cost under 5% of infrastructure cost.
+- **Observability Data Model:** Use semantic conventions (OpenTelemetry) for consistent attribute naming. Define standard labels: service.name, deployment.environment, service.version. Enables cross-service queries and dashboards.
+- **Self-Service Observability:** Developers provision dashboards and alerts via IaC (Terraform, Jsonnet). Pre-built dashboard templates for common patterns (RED, USE, Golden Signals). Query language accessible to non-SREs (LogQL, PromQL with examples).
+- **Alert Routing:** Route alerts to appropriate team via PagerDuty, Opsgenie, or Slack. Use severity levels: SEV1 (page), SEV2 (urgent Slack), SEV3 (non-urgent Slack). Alerts should include: runbook link, suggested queries, recent changes.
+
+### After implementation
+
+- Verify all services emit metrics, logs, and traces via OpenTelemetry.
+- Confirm trace IDs are propagated and linked across logs, metrics, and traces.
+- Validate metrics cardinality is under 10,000 time series per service.
+- Ensure telemetry pipeline handles 100k+ events/second with sampling and filtering.
+- Check that observability cost is under 5% of infrastructure cost.
+
+## Self-check before task completion
+
+- [ ] Unified observability stack uses OpenTelemetry for vendor-neutral instrumentation.
+- [ ] Trace correlation links metrics, logs, and traces via trace ID and span ID.
+- [ ] Log aggregation uses structured logging (JSON) with consistent schema.
+- [ ] Metrics cardinality is managed: under 10,000 time series per service.
+- [ ] Telemetry pipeline decouples collection from storage and handles 100k+ events/second.
+- [ ] Distributed tracing uses sampling (head or tail-based) to control costs.
+- [ ] Observability cost is under 5% of infrastructure cost via sampling and tiered storage.
+- [ ] Observability data model uses OpenTelemetry semantic conventions.
+- [ ] Self-service observability enables developers to provision dashboards and alerts via IaC.
+- [ ] Alert routing uses severity levels and includes runbook links.

package/.mindforge/skills/platform-reliability/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: platform-reliability
+version: 1.0.0
+min_mindforge_version: 10.7.0
+status: stable
+triggers: platform reliability engineering, SLO management platform, error budget policy, platform availability design, capacity management platform, platform SLA, reliability target, platform health metric, platform uptime, error budget spending, toil reduction platform, platform incident prevention
+compose: incident-management
+---
+
+# Skill — Platform Reliability
+
+## When this skill activates
+
+This skill activates when the user is designing or implementing platform reliability capabilities. This includes SLO management systems, error budget policies, platform availability design, capacity management, platform health metrics, reliability targets, uptime monitoring, error budget tracking, toil reduction initiatives, and platform incident prevention strategies.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+
+1. Inventory all platform services and their current reliability posture (uptime, error rates, latency, throughput).
+2. Define SLOs for each platform capability (e.g., 99.9% for APIs, 99.5% for batch jobs, 99.99% for critical path services).
+3. Establish error budget policy: what happens when budget is exhausted (freeze launches, prioritize reliability work).
+4. Identify toil sources (manual escalations, runbook execution, repetitive debugging) and quantify hours spent per week.
+5. Map platform dependencies and identify single points of failure that require redundancy.
+
+### During implementation
+
+- **SLO Management:** Define SLOs as percentiles over rolling windows (e.g., 99th percentile latency < 200ms over 28 days). Avoid averages (they hide outliers). Each SLO should have: objective, measurement window, error budget calculation, and owner.
+- **Error Budget Policy:** If error budget is exhausted, automatically freeze non-critical deployments and redirect engineering time to reliability improvements. Budget resets monthly or quarterly. Include exemptions for security patches.
+- **Platform Availability Design:** Use multi-region active-active for critical path services. Implement circuit breakers, rate limiting, and graceful degradation. Platform should survive single availability zone failure with zero downtime.
+- **Capacity Management:** Track resource utilization (CPU, memory, disk, network) and predict exhaustion 30-90 days in advance. Automate horizontal scaling for stateless services. Capacity alerts should fire before user-visible impact.
+- **Platform Health Metrics:** Track: request rate, error rate, latency (p50, p95, p99), saturation, and throughput. Use RED (Rate, Errors, Duration) for services and USE (Utilization, Saturation, Errors) for infrastructure. Dashboards should load in under 3 seconds.
+- **Toil Reduction:** Automate repetitive tasks that consume more than 2 hours per week. Toil reduction should free up 30-50% of on-call time within 6 months. Track toil hours saved as a platform metric.
+- **Incident Prevention:** Use chaos engineering to validate failure modes (kill instances, partition networks, inject latency). Run game days quarterly. Each incident should produce at least one actionable prevention task.
+
+### After implementation
+
+- Verify each platform service has defined SLOs, error budgets, and dashboards tracking compliance.
+- Confirm error budget policy is enforced automatically (deployment freezes when budget exhausted).
+- Validate multi-region failover works via chaos engineering tests (kill a region, verify zero downtime).
+- Ensure capacity management predicts exhaustion 30-90 days in advance with alerts.
+- Check that toil reduction initiatives have freed up measurable on-call time (tracked weekly).
+
+## Self-check before task completion
+
+- [ ] Each platform service has SLOs defined as percentiles over rolling windows.
+- [ ] Error budget policy automatically freezes non-critical deployments when budget exhausted.
+- [ ] Platform survives single availability zone failure with zero user-visible downtime.
+- [ ] Capacity management predicts resource exhaustion 30-90 days in advance.
+- [ ] Platform health metrics use RED for services and USE for infrastructure.
+- [ ] Toil reduction initiatives free up 30-50% of on-call time within 6 months.
+- [ ] Chaos engineering validates failure modes quarterly via game days.

package/.mindforge/skills/post-incident-learning/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: post-incident-learning
+version: 1.0.0
+min_mindforge_version: 10.1.0
+status: stable
+triggers: post-incident learning, systemic pattern, defense mechanism, recurrence prevention, incident class, contributing factor analysis, improvement measurement, learning review, incident pattern, failure class prevention, defense layer, systemic fix
+compose: incident-management
+---
+
+# Post-Incident Learning
+
+## When this skill activates
+
+This skill activates after an incident has been resolved and the team needs to extract
+lasting organizational learning. It goes beyond traditional postmortems (which document
+what happened) to identify failure classes, build defense mechanisms, and measure
+whether the organization is actually getting better at preventing recurrence.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. **Gather incident data** — Timeline, logs, communications, actions taken, resolution
+   steps. Ensure the raw facts are documented before memory fades.
+2. **Identify participants** — Who was involved in detection, response, and resolution?
+   Schedule the learning review within 72 hours of resolution.
+3. **Set the frame** — This is a learning exercise, not a blame exercise. Establish
+   psychological safety explicitly. No individual fault-finding.
+
+### During
+
+4. **Distinguish postmortem from learning:**
+   - Postmortem = What happened? (timeline, root cause, impact)
+   - Learning = What patterns do we now defend against? (systemic improvement)
+   - This skill focuses on the LEARNING phase that follows the postmortem.
+
+5. **Contributing factor analysis (go beyond root cause):**
+   - **Proximate cause** — The immediate trigger (e.g., bad deploy, config change).
+   - **Contributing factors** — Conditions that allowed the trigger to cause harm
+     (e.g., missing validation, no canary, insufficient monitoring).
+   - **Systemic conditions** — Organizational patterns that created the contributing
+     factors (e.g., time pressure, unclear ownership, technical debt tolerance).
+   - Map all three levels. Fixes at only the proximate level guarantee recurrence.
+
+6. **Identify the incident CLASS:**
+   - This is not just one incident — what CLASS of failure does it represent?
+   - Examples: "deploy without validation," "silent dependency failure," "config
+     drift between environments," "cascading timeout."
+   - Name the class explicitly. Search history for past incidents of the same class.
+   - If this class has occurred before, the previous fixes were insufficient.
+
+7. **Design defense mechanisms (layered):**
+   - **Layer 1: Automated prevention** — Make the failure impossible through code,
+     infrastructure, or tooling changes (strongest defense).
+   - **Layer 2: Automated detection** — If prevention is impossible, detect instantly
+     and auto-remediate or alert within seconds.
+   - **Layer 3: Process improvement** — Checklists, review steps, approval gates
+     (weakest defense — humans forget).
+   - Never accept "be more careful" as a defense mechanism.
+   - Prefer Layer 1 > Layer 2 > Layer 3 always.
+
+8. **Define improvement measurements:**
+   - **Mean time between incidents of same class** — Trending up means defenses work.
+   - **Detection time** — Time from failure occurrence to human awareness.
+   - **Recovery time** — Time from awareness to full resolution.
+   - **Blast radius** — Users/systems affected (should shrink over time).
+   - Set specific targets for each metric.
+
+9. **Create action items with teeth:**
+   - Each action item must have: owner, deadline, definition of done, and verification
+     method.
+   - Classify priority: P0 (fix this week), P1 (fix this sprint), P2 (fix this quarter).
+   - Track completion publicly. Incomplete incident actions are organizational debt.
+
+### After
+
+10. **Share the learning broadly** — Publish findings to the engineering organization.
+    Other teams may have the same class of vulnerability.
+11. **Update runbooks and alerts** — Ensure the detection and response improvements are
+    codified in operational documentation.
+12. **Schedule verification** — In 30 days, verify that defense mechanisms are in place
+    and metrics show improvement. If not, escalate.
+13. **Feed into incident class tracker** — Maintain an organizational record of incident
+    classes, their defenses, and recurrence rates.
+
+## Self-check before task completion
+
+- [ ] Contributing factors analyzed at all three levels (proximate, contributing, systemic)
+- [ ] Incident class identified and named (not just this one incident)
+- [ ] Historical incidents of same class searched and referenced
+- [ ] Defense mechanisms designed with preference for automation over process
+- [ ] No action item says "be more careful" or equivalent
+- [ ] Metrics defined with specific improvement targets
+- [ ] All action items have owner, deadline, and verification method
+- [ ] Learning shared beyond the immediate team
+- [ ] 30-day verification scheduled

package/.mindforge/skills/product-manager/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: product-manager
+version: 1.0.0
+min_mindforge_version: 10.0.6
+status: stable
+triggers: user story, PRD, product requirements, backlog prioritization, RICE score, MoSCoW, jobs to be done, feature scoring, sprint planning, product backlog, acceptance criteria, user journey
+---
+
+# Skill — Product Manager
+
+## When this skill activates
+Any task involving product requirements, user story writing, backlog prioritization,
+feature scoring, sprint planning, PRD creation, or user journey mapping.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. **Define the problem** — Articulate the user problem with evidence (tickets, data, interviews). No solutions yet.
+2. **Identify personas** — 1-3 specific personas with context, goals, and frustrations.
+3. **State success metrics** — Define how to measure success BEFORE designing the solution.
+
+### During
+
+#### PRD structure (6 mandatory sections)
+1. **Problem Statement** — data-backed, who has it, how we know
+2. **User Personas** — context, goal, frustration per persona
+3. **Requirements** — functional (numbered, prioritized) + non-functional (perf, a11y)
+4. **Success Metrics** — current baseline, target, measurement method per metric
+5. **Scope + Timeline** — phases with explicit out-of-scope items
+6. **Risks + Mitigations** — risk, probability, impact, mitigation plan
+
+#### User story format
+```
+As a [persona], I want [action] so that [outcome/value].
+
+Rules:
+  - One story = one testable behavior
+  - Always include "so that" (forces value articulation)
+  - Completable in one sprint (split if larger)
+  - Every story has acceptance criteria attached
+```
+
+#### Acceptance criteria (Given/When/Then)
+```gherkin
+Scenario: [descriptive name]
+  Given [precondition/context]
+  When [action taken]
+  Then [observable outcome]
+  And [additional assertions]
+```
+Cover: happy path, edge cases, error states, boundary conditions.
+
+#### RICE scoring
+```
+Score = (Reach * Impact * Confidence) / Effort
+  Reach: users affected per quarter
+  Impact: 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal
+  Confidence: 100%=high, 80%=medium, 50%=low
+  Effort: person-weeks
+```
+Show the math. Rank by score. Communicate rationale for top picks.
+
+#### MoSCoW prioritization
+- Must Have: non-negotiable for launch (failure without these)
+- Should Have: expected, but launch survives without them
+- Could Have: nice-to-have if time permits
+- Won't Have: explicitly deferred (prevents scope creep)
+
+#### Jobs-to-be-Done framework
+```
+Interview structure (45-60 min):
+  1. First Thought — trigger that started the search
+  2. Passive Looking — alternatives considered
+  3. Active Looking — event that forced action NOW
+  4. Decision — why this solution, what almost stopped them
+  5. Satisfaction — does it deliver, what would cause switching
+
+Output: "When [situation], I want to [motivation], so I can [outcome]."
+```
+
+#### User journey mapping
+```
+Stages: Awareness → Consideration → Setup → First Value → Expansion
+Per stage: Actions, Touchpoints, Emotions, Pain Points, Opportunities, Metrics
+```
+Identify the critical drop-off points and design interventions for each.
+
+### After
+
+1. **Validate with users** — Show PRD to 2-3 target users. Confirm problem resonates.
+2. **Engineering feasibility** — Tech lead confirms effort estimates and constraints.
+3. **Stakeholder sign-off** — Explicit agreement on v1 scope vs deferred.
+4. **Define done** — What must be true (metrics hit, not just code deployed).
+
+## Self-check before task completion
+- [ ] Problem statement evidence-backed (data, quotes, ticket volume)
+- [ ] Personas specific with context, goals, and frustrations
+- [ ] Success metrics have baseline, target, and measurement method
+- [ ] Stories follow "As a... I want... So that..." with acceptance criteria
+- [ ] Backlog prioritized with visible math (RICE/MoSCoW/WSJF)
+- [ ] Scope states what is OUT as well as IN
+- [ ] User journey maps full experience from awareness to expansion
+- [ ] Engineering validated feasibility and effort