mindforge-cc 10.0.3 → 10.7.0

package/.mindforge/skills/streaming-architecture/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: streaming-architecture
+version: 1.0.0
+min_mindforge_version: 10.0.9
+status: stable
+triggers: streaming architecture, server sent events, chunked transfer, real-time pipeline, stream processing, backpressure stream, event stream, streaming response, stream consumer, data stream design, stream partitioning, stream windowing
+---
+
+# Skill — Streaming Architecture
+
+## When this skill activates
+Any task involving real-time data streaming, SSE, chunked transfer encoding,
+stream processing pipelines, backpressure, partitioning, or windowing strategies.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Choose transport (SSE vs WebSocket vs long-polling) using the decision matrix.
+2. Define stream data format (NDJSON, chunked binary, protobuf frames).
+3. Identify backpressure requirements and partition strategy.
+
+### During implementation
+- Implement backpressure handling at every pipeline stage.
+- Use chunked transfer encoding for HTTP streaming responses.
+- Apply appropriate windowing strategy for aggregation needs.
+- Partition by key for ordering, round-robin for throughput.
+
+### After implementation
+- Load test under sustained high-throughput conditions.
+- Verify consumer groups scale horizontally without message loss.
+- Document partition strategy and windowing semantics.
+
+## Transport Decision Matrix
+
+| Transport | Direction | Use For | Limitation |
+|-----------|-----------|---------|------------|
+| SSE | Server→Client | Notifications, feeds, progress, logs | Text-only, unidirectional |
+| WebSocket | Bidirectional | Chat, collaboration, gaming | Proxy complexity, reconnection logic |
+| Long-Polling | Client→Server→Client | Legacy envs, infrequent updates | High latency, resource overhead |
+
+- SSE: auto-reconnect via Last-Event-ID, works through load balancers.
+- WebSocket: lower per-message overhead after handshake, requires connection management.
+- Long-Polling: universally compatible, highest resource cost at scale.
+
+## Streaming Response Patterns
+
+- **Chunked Transfer**: `Transfer-Encoding: chunked` — each chunk is a parseable unit.
+- **NDJSON**: one JSON object per `\n`-separated line, parse incrementally.
+- Use NDJSON for LLM token streaming, batch results, log streams.
+
+## Stream Processing Windows
+
+- **Tumbling**: fixed-size, non-overlapping. Use for per-minute aggregations.
+- **Sliding**: fixed-size, overlapping by step. Use for moving averages.
+- **Session**: dynamic size, closes after inactivity gap. Use for user sessions.
+
+## Backpressure Strategies
+
+- **Buffer and Batch**: bounded buffer, process in batches at threshold or timer.
+- **Drop Oldest** (lossy): discard stale messages when buffer full. Never for transactions.
+- **Signal Producer** (reactive): consumer signals demand, producer throttles emission.
+
+## Partition Strategies
+
+- **Key-Based**: same key → same partition. Guarantees per-key ordering. Risk: hot partitions.
+- **Round-Robin**: even distribution, max throughput, no ordering guarantees.
+
+## Consumer Groups
+- Multiple consumers share partitions (one partition per consumer max).
+- Scale up to partition count (more consumers = idle).
+- Rebalancing on consumer join/leave. Track offsets for resume-from-failure.
+
+## Self-check before task completion
+
+- [ ] Is the transport correct for the use case (SSE/WebSocket/long-polling)?
+- [ ] Is backpressure handled at every pipeline stage?
+- [ ] Are streaming responses chunked with parseable units?
+- [ ] Is windowing strategy appropriate for aggregation needs?
+- [ ] Are partitions designed for the right ordering vs throughput trade-off?
+- [ ] Can consumers scale horizontally without message loss?
+- [ ] Is reconnection logic implemented for client-side streams?

package/.mindforge/skills/supply-chain-security/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: supply-chain-security
+version: 1.0.0
+min_mindforge_version: 0.1.0
+status: stable
+triggers: supply chain security, dependency audit strategy, lockfile integrity verification, provenance verification, SBOM generation, sigstore signing, reproducible build, dependency scanning pipeline, package integrity check, npm audit strategy, supply chain attack prevention, software composition analysis
+---
+
+# Skill — Supply Chain Security
+
+## When this skill activates
+Any task involving dependency management, package auditing, build integrity,
+software bill of materials, or defending against supply chain attacks.
+
+## Mandatory actions when this skill is active
+
+### Before making changes
+1. Verify lockfile is committed and checksums match.
+2. Run dependency audit (`npm audit`, `pip audit`, or equivalent).
+3. Check for known malicious packages in the dependency tree.
+
+### During implementation
+- Pin all dependencies to exact versions in lockfiles.
+- Pin CI actions to full SHA (not tags): `actions/checkout@abc123def`.
+- Generate SBOM on every release build.
+- Verify package provenance when available.
+- Use minimal base images for containers (distroless/alpine).
+
+### After implementation
+- Confirm no new critical/high vulnerabilities introduced.
+- Verify the build is reproducible (same source → same artifact).
+- Ensure SBOM is attached to release artifacts.
+
+## Core practices
+
+### Lockfile Integrity
+```bash
+# Verify lockfile hasn't been tampered with
+npm ci  # Uses lockfile exactly (fails if lockfile/package.json mismatch)
+
+# Alert on unexpected lockfile changes in CI
+git diff --name-only | grep -q "package-lock.json" && echo "LOCKFILE CHANGED"
+```
+- Always commit lockfiles (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`).
+- Use `npm ci` (not `npm install`) in CI — it respects the lockfile exactly.
+- Review lockfile diffs in PRs (look for unexpected new packages or registry changes).
+
+### Dependency Auditing
+```bash
+# Node.js
+npm audit --audit-level=high
+npx socket-security/cli scan
+
+# Python
+pip-audit
+safety check
+
+# Go
+govulncheck ./...
+```
+- Run in CI on every PR (block on critical/high).
+- Schedule weekly full audits for transitive dependency updates.
+- Use Socket.dev or Snyk for behavioral analysis (detect install scripts, network access).
+
+### SBOM Generation
+```bash
+# CycloneDX format (preferred for security)
+npx @cyclonedx/cyclonedx-npm --output-file sbom.json
+
+# SPDX format (preferred for compliance)
+syft . -o spdx-json > sbom.spdx.json
+```
+- Generate on every release (attach to GitHub release, container image).
+- Include direct AND transitive dependencies.
+- Choose format: CycloneDX for security analysis, SPDX for license compliance.
+
+### Provenance Verification
+```bash
+# npm provenance (verify publisher identity)
+npm publish --provenance
+npm audit signatures  # Verify all installed packages
+
+# Container image provenance
+cosign verify --certificate-identity=... --certificate-oidc-issuer=... image:tag
+```
+- Enable npm provenance on all published packages.
+- Verify signatures of consumed packages in CI.
+- Use Sigstore for keyless signing of artifacts.
+
+### Reproducible Builds
+- Pin ALL dependencies (including transitive) via lockfile.
+- Pin build tool versions (Node.js via `.nvmrc`, Go via `go.mod`).
+- Use deterministic build flags (no timestamps in artifacts).
+- Verify: build twice from same source → compare artifact hashes.
+
+### CI/CD Hardening
+```yaml
+# Pin actions to SHA, not tag
+- uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608  # v4.1.0
+
+# Minimal permissions
+permissions:
+  contents: read
+  packages: write
+
+# Restrict network in build steps
+# Use dependency caching to reduce fetch surface
+```
+
+## Threat vectors to defend against
+
+| Attack | Defense |
+|--------|---------|
+| Typosquatting | Verify package name carefully, use scoped packages |
+| Dependency confusion | Configure `.npmrc` with registry scoping |
+| Compromised maintainer | Pin versions, verify provenance, review changelogs |
+| Malicious install scripts | Use `--ignore-scripts` where possible, audit scripts |
+| Hijacked CI action | Pin to SHA, fork critical actions |
+| Registry compromise | Verify signatures, use multiple registries |
+
+## Dependency confusion prevention
+```ini
+# .npmrc — scope internal packages to private registry
+@mycompany:registry=https://npm.internal.company.com/
+# Everything else falls through to public npm
+```
+
+## Anti-patterns to avoid
+- Using `latest` or `^` in production lockfiles without CI audit gates.
+- Pinning CI actions to tags (`v4`) instead of SHAs (tags can be force-pushed).
+- Running `npm install` instead of `npm ci` in CI.
+- Ignoring audit warnings because "it's a dev dependency" (devDeps run in CI).
+- No SBOM generation (you can't defend what you can't inventory).
+- Allowing arbitrary install scripts without review.
+
+## Self-check before task completion
+
+Before marking a task done when this skill was active:
+
+- [ ] Lockfile committed and CI uses `npm ci` (or equivalent)?
+- [ ] Dependency audit passes with no critical/high findings?
+- [ ] CI actions pinned to full SHA?
+- [ ] SBOM generated and attached to release?
+- [ ] No new dependencies added without justification?
+- [ ] Provenance verification enabled for published packages?

package/.mindforge/skills/synthetic-data-generation/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: synthetic-data-generation
+version: 1.0.0
+min_mindforge_version: 10.5.0
+status: stable
+triggers: synthetic data generation, training data creation, privacy-preserving synthetic, data augmentation strategy, synthetic dataset pipeline, differential privacy data, fake data generation, synthetic data validation, data anonymization, tabular synthetic data, text synthetic generation, synthetic data quality
+compose:
+---
+
+# Synthetic Data Generation
+
+## When this skill activates
+
+This skill activates when creating training datasets from scratch, augmenting real data with synthetic examples, anonymizing sensitive data while preserving utility, or generating privacy-preserving datasets for model training. It applies when real data is scarce, expensive, biased, or subject to privacy regulations.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+
+1. **Assess data requirements** — Define target schema (columns, data types, constraints), target size (number of rows), and statistical properties that must match real data (distributions, correlations, cardinality). Synthetic data is only useful if it mimics real-world structure.
+2. **Choose generation strategy** — Select based on data type: rule-based (deterministic logic for structured data), generative models (GANs, VAEs for complex distributions), LLM-based (text generation, code synthesis), or hybrid. Rule-based is fastest but least realistic. GANs are slow but highest fidelity.
+3. **Establish privacy guarantees** — If replacing real data due to privacy concerns, define the privacy level: k-anonymity (each record matches k others), differential privacy (mathematical guarantee on information leakage), or synthetic twin (structurally similar but no direct correspondence). Validate that synthetic data passes privacy audits.
+4. **Define quality metrics** — Synthetic data must be useful for downstream tasks. Define metrics: statistical similarity (KL divergence, Wasserstein distance), downstream model accuracy (train on synthetic, test on real), and privacy preservation (can you reverse-engineer real data from synthetic?).
+
+### During implementation
+
+- **Preserve statistical properties** — Maintain distributions (mean, variance, skewness), correlations (covariance matrix), and cardinality (unique counts) from real data. Use statistical tests (Kolmogorov-Smirnov for distributions, chi-square for categorical) to validate similarity.
+- **Respect constraints** — Enforce domain constraints: referential integrity (foreign keys), range limits (age 0-120), uniqueness (no duplicate IDs), format rules (email regex, phone numbers). Synthetic data that violates constraints is unusable.
+- **Augment minority classes** — Use synthetic data to balance class distributions. If real data has 95% negative, 5% positive examples, oversample the minority class synthetically. Validate that synthetic minority examples are diverse and realistic, not copies.
+- **Generate edge cases explicitly** — Real data often lacks edge cases (extreme values, rare combinations). Generate these explicitly: maximum field lengths, boundary values, rare categorical combinations. Models trained on synthetic data should handle edge cases better, not worse.
+- **Validate generation reproducibility** — Use fixed random seeds for deterministic generation. Synthetic datasets should be versioned and reproducible. Document the generation process (model, hyperparameters, seed) so datasets can be regenerated exactly.
+- **Avoid mode collapse** — Generative models (GANs, VAEs) often generate repetitive outputs. Measure diversity: count unique rows, check for duplicates, visualize latent space. If diversity is low (<80% unique rows), retrain with higher capacity or different architecture.
+
+### After implementation
+
+- **Measure statistical fidelity** — Compare synthetic vs. real data distributions using statistical tests. Target: p-value >0.05 for K-S test (distributions are statistically indistinguishable). Visualize distributions with histograms and Q-Q plots.
+- **Validate downstream utility** — Train a model on synthetic data, test on real data. Compare accuracy to a model trained on real data. Target: <5% accuracy drop. If drop is larger, synthetic data lacks critical patterns.
+- **Audit for privacy leaks** — Attempt to re-identify real individuals from synthetic data using membership inference attacks. Measure attack success rate. Target: <1% success (no better than random guessing). If higher, strengthen privacy guarantees.
+- **Test for bias amplification** — Synthetic data can amplify biases from real data. Measure demographic parity and calibration across protected attributes. If bias metrics worsen (compared to real data), adjust generation to debias.
+
+## Self-check before task completion
+
+- [ ] Target schema, size, and statistical properties are explicitly defined
+- [ ] Generation strategy (rule-based/GAN/LLM/hybrid) is chosen and justified
+- [ ] Domain constraints (referential integrity, ranges, formats) are enforced
+- [ ] Statistical similarity is validated with formal tests (K-S, chi-square) and p-values documented
+- [ ] Minority classes are balanced and synthetic examples are diverse (no duplicates)
+- [ ] Edge cases are explicitly generated (boundary values, rare combinations)
+- [ ] Downstream model accuracy on synthetic data is within 5% of real data performance
+- [ ] Privacy guarantees are validated via membership inference attack success rate <1%
+- [ ] Synthetic data is versioned and generation process is documented for reproducibility
+- [ ] Bias metrics are measured and do not amplify demographic disparities

package/.mindforge/skills/system-design/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: system-design
+version: 1.0.0
+min_mindforge_version: 10.0.6
+status: stable
+triggers: system design, load balancer, sharding strategy, replication, CAP theorem, horizontal scaling, vertical scaling, message queue, distributed cache, high availability, fault tolerance
+---
+
+# Skill — System Design
+
+## When this skill activates
+Any task involving large-scale system architecture, scaling strategy,
+distributed infrastructure, or high-availability design.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. **Quantify requirements** — Peak QPS, latency SLA (p50/p95/p99), data volume, read/write ratio, availability target.
+2. **Identify constraints** — Budget, team size, existing stack, compliance, geographic needs.
+3. **Establish scope** — Distinguish MVP from full-scale target. Design for target, implement in phases.
+
+### During
+
+#### Capacity planning math (always do first)
+```
+DAU * actions_per_user / 86400 = avg QPS
+avg QPS * peak_multiplier (3x) = peak QPS
+records_per_day * bytes_per_record = daily storage growth
+annual_storage * hot_data_fraction = cache cluster sizing
+```
+Document all calculations in the design document.
+
+#### Load balancing
+- L4 (TCP): high-throughput, gRPC, WebSocket — NLB, HAProxy TCP mode
+- L7 (HTTP): path routing, header inspection, A/B — ALB, Nginx, Envoy
+- Algorithms: Round Robin, Least Connections, Consistent Hashing (sticky without state)
+- Health checks: active (ping /health 5s interval, 3 fails = remove)
+
+#### Sharding strategies
+```
+Hash-based: shard_id = hash(key) % N — even distribution, resharding needs consistent hashing
+Range-based: key ranges per shard — good for range queries, risk of hot spots
+Geographic: shard by region — data locality + compliance, cross-region queries expensive
+```
+Partition key must: exist in every query, distribute evenly, align with access patterns.
+
+#### Replication
+- Leader-Follower: one leader writes, N followers read. 10ms-1s lag. Most common.
+- Multi-Leader: multi-region writes, conflict resolution (LWW or app-level merge).
+- Quorum: W+R>N for strong consistency. Tunable read/write tradeoff.
+
+#### CAP theorem
+- Partitions WILL happen — choose CP or AP per subsystem
+- CP (refuse stale reads): financial transactions, inventory, leader election
+- AP (serve during partition): shopping carts, feeds, analytics, DNS
+- PACELC: if no partition, choose Latency vs Consistency (most systems: PA/EL)
+
+#### Caching layers
+```
+L1 (in-process): 100MB-1GB, TTL 30s-5min, local HashMap/node-cache
+L2 (distributed): 10GB-1TB, TTL 5min-1hr, Redis Cluster/Memcached
+L3 (CDN/edge): unlimited, TTL 1hr-1day, CloudFront/Cloudflare
+```
+Invalidation: TTL expiry | write-through | pub/sub invalidation events.
+
+#### Message queues
+- Kafka: high-throughput, ordered per partition, replay-capable
+- SQS: serverless, simple, built-in DLQ
+- RabbitMQ: flexible routing, priority queues
+- Use when: decoupling, spike buffering, guaranteed delivery, fan-out
+
+### After
+
+1. **Validate with numbers** — Confirm design handles peak QPS with 2-3x headroom.
+2. **No SPOF** — Every component has a failover path in the critical path.
+3. **Document tradeoffs** — State what was sacrificed and why it is acceptable.
+4. **Define SLOs** — Latency p99, error rate, availability with alerting thresholds.
+
+## Self-check before task completion
+- [ ] Requirements quantified (QPS, latency, storage, availability)
+- [ ] Capacity math documented with back-of-envelope calculations
+- [ ] No single points of failure in the critical path
+- [ ] Sharding strategy defined with partition key rationale
+- [ ] Caching layers specified with invalidation strategy
+- [ ] CAP tradeoff explicitly stated and justified
+- [ ] Message queues used for async and spike buffering
+- [ ] SLOs defined with alerting thresholds

package/.mindforge/skills/team-topology-design/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: team-topology-design
+version: 1.0.0
+min_mindforge_version: 10.1.0
+status: stable
+triggers: team topology, stream-aligned team, platform team, enabling team, complicated-subsystem team, cognitive load, team interaction mode, team API, team boundary, Conway law, team coupling, team autonomy
+---
+
+# Team Topology Design
+
+## When this skill activates
+
+This skill activates when designing, reorganizing, or evaluating team structures
+and their interactions. It applies the Team Topologies framework to align team
+boundaries with software architecture, manage cognitive load, and define clear
+interaction modes between teams.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. **Map current state** — Document existing team structures, their responsibilities,
+   communication patterns, and pain points.
+2. **Identify architecture goals** — What system architecture do you want? Conway's Law
+   means team structure will produce matching architecture.
+3. **Assess cognitive load** — Survey teams on whether their responsibilities feel
+   manageable or overwhelming. Overload is the primary signal for restructuring.
+
+### During
+
+4. **Apply the four fundamental team types:**
+
+   - **Stream-aligned team** — The primary type. Aligned to a single flow of business
+     value (feature, product, user journey, or persona). Delivers end-to-end without
+     hand-offs. Has full ownership from ideation through production operation.
+     Most teams should be this type.
+
+   - **Platform team** — Provides self-service capabilities that stream-aligned teams
+     consume via well-defined APIs. Reduces cognitive load by abstracting away
+     infrastructure complexity. Treats internal teams as customers. Measures success
+     by adoption and developer satisfaction, not features shipped.
+
+   - **Enabling team** — Helps stream-aligned teams adopt new technologies or practices.
+     Temporary collaboration, not permanent dependency. Measures success by the
+     stream-aligned team's growing independence. Detects capability gaps across teams
+     and bridges them through coaching, documentation, and pairing.
+
+   - **Complicated-subsystem team** — Owns a component requiring deep specialist
+     knowledge (ML model, video codec, financial calculation engine). Provides a
+     simplified interface to stream-aligned teams. Only justified when the specialist
+     knowledge truly cannot be distributed across stream-aligned teams.
+
+5. **Define interaction modes (how teams work together):**
+
+   - **Collaboration** — Two teams working closely together for a defined period.
+     High bandwidth, high cost. Time-box to weeks/months, not permanent.
+     Use when: discovering new interfaces, bootstrapping new capabilities.
+
+   - **X-as-a-Service** — One team provides capability via API/platform that another
+     team consumes. Low coupling, clear contract. The provider defines the interface.
+     Use when: the boundary is well-understood and stable.
+
+   - **Facilitating** — One team coaches another. No code ownership transfer, no
+     permanent dependency. The facilitating team's goal is to make themselves
+     unnecessary. Use when: enabling teams help stream-aligned teams grow.
+
+6. **Manage cognitive load:**
+   - A team should own no more domains than fit in collective working memory.
+   - Signs of overload: constant context switching, shallow knowledge across many areas,
+     slow delivery, high bug rates, burnout.
+   - Response to overload: split the team, transfer ownership to a platform team, or
+     reduce scope.
+   - Intrinsic load (problem complexity) cannot be reduced — manage it with specialists.
+   - Extraneous load (poor tooling, unclear ownership) — eliminate it aggressively.
+
+7. **Apply Conway's Law intentionally:**
+   - Do not fight Conway's Law. Design teams to match desired architecture.
+   - If you want microservices, create teams with clear service boundaries.
+   - If you want a cohesive platform, create a platform team.
+   - Team boundaries become API boundaries. Choose them deliberately.
+
+8. **Define team APIs:**
+   - Every team should have a clear "team API" — how others interact with them.
+   - Includes: code/service interfaces, documentation, on-call escalation paths,
+     request intake process, SLA commitments.
+   - Make team APIs explicit and discoverable.
+
+### After
+
+9. **Validate with evolution paths** — Team structures must evolve. Define how teams
+   will split, merge, or change interaction modes as the system grows.
+10. **Communicate the design** — Share team topology decisions with the full org.
+    Explain the WHY, not just the WHAT.
+11. **Set review cadence** — Reassess team topology quarterly. Look for: growing cognitive
+    load, increasing inter-team dependencies, delivery bottlenecks.
+
+## Self-check before task completion
+
+- [ ] Every team classified as exactly one of the four types
+- [ ] Stream-aligned teams can deliver end-to-end without blocking dependencies
+- [ ] Platform teams have clear self-service interfaces (not ticket queues)
+- [ ] Interaction modes explicitly defined for each team pair that collaborates
+- [ ] Cognitive load assessed and within manageable bounds per team
+- [ ] Conway's Law applied intentionally (team structure matches desired architecture)
+- [ ] Team APIs documented and discoverable
+- [ ] Evolution paths defined for growth scenarios
+- [ ] Review cadence established

package/.mindforge/skills/technical-debt-management/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: technical-debt-management
+version: 1.0.0
+min_mindforge_version: 10.0.9
+status: stable
+triggers: technical debt management, debt inventory, debt interest, refactoring ROI, debt prioritization, debt budget, tech debt tracker, code health score, debt payoff plan, maintenance burden, debt classification, technical liability
+---
+
+# Skill — Technical Debt Management
+
+## When this skill activates
+Any task involving debt identification, classification, prioritization,
+ROI-based refactoring, budget allocation, code health scoring, or payoff planning.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Classify the debt (deliberate vs inadvertent, prudent vs reckless).
+2. Estimate interest rate (hours lost per sprint due to this debt).
+3. Calculate payoff ROI before prioritizing.
+
+### During implementation
+- Track all debt in backlog with `tech-debt` label + severity + affected area.
+- Boy-scout rule: leave code cleaner than found.
+- Never create debt without acknowledgment and payoff timeline.
+- Fix debt in atomic PRs — never bundle with feature work.
+
+### After implementation
+- Update debt inventory with resolved items.
+- Recalculate code health score after significant payoffs.
+- Document lessons to prevent similar accumulation.
+
+## Debt Classification
+
+| Type | Description | Example |
+|------|-------------|---------|
+| Deliberate + Prudent | "We know, ship now, fix Sprint N" | Hardcoded config needing config service |
+| Deliberate + Reckless | "We know, don't care" | Skipping auth "because VPN" |
+| Inadvertent + Prudent | "Didn't know better then" | Hand-rolled state before finding library |
+| Inadvertent + Reckless | "Didn't know what we were doing" | N+1 queries from ORM misuse |
+
+## Interest Calculation
+
+```
+Weekly Interest = incidents_caused * avg_hours
+               + developer_workaround_time
+               + onboarding_friction
+               + blocked_feature_delays
+```
+
+- **High** (>4 hrs/sprint): fix immediately.
+- **Medium** (1-4 hrs/sprint): schedule within 2 sprints.
+- **Low** (<1 hr/sprint): fix opportunistically.
+
+## Prioritization Formula
+
+```
+Priority Score = interest_per_sprint / effort_to_fix_hours
+Higher score = fix first (best ROI)
+```
+
+## Debt Budget (The 20% Rule)
+- 20% of sprint capacity for debt payoff (non-negotiable).
+- 10% targeted high-interest debt. 5% boy-scout cleanup. 5% prevention tooling.
+- Increase when: health score < 60, velocity declining 3+ sprints, incidents rising.
+
+## Code Health Score (0-100)
+
+```
+Health = test_coverage(25%) + dependency_freshness(20%)
+       + complexity(25%) + documentation(15%) + incident_inverse(15%)
+```
+
+- Test coverage: 80%+ = 100pts, 60-80% = 75, 40-60% = 50, <40% = 25.
+- Complexity: avg cyclomatic per function. <5 = 100, 5-10 = 75, >10 = 50.
+- Track monthly. Alert if drops >10 points in one month.
+
+## Self-check before task completion
+
+- [ ] Is all identified debt logged with classification and severity?
+- [ ] Is interest rate estimated for each item?
+- [ ] Is payoff prioritized by ROI (interest / effort)?
+- [ ] Is the 20% debt budget respected in sprint planning?
+- [ ] Are new debts acknowledged with a payoff timeline?
+- [ ] Is code health score calculated and tracked?
+- [ ] Are debt fixes in isolated PRs (not bundled with features)?

package/.mindforge/skills/technical-interview-design/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: technical-interview-design
+version: 1.0.0
+min_mindforge_version: 10.1.0
+status: stable
+triggers: technical interview, coding challenge design, system design interview, evaluation rubric, interview signal, interview bias reduction, hiring assessment, take-home challenge, interview scorecard, coding round design, debrief calibration, interview fairness
+---
+
+# Technical Interview Design
+
+## When this skill activates
+
+This skill activates when designing, improving, or evaluating technical interview
+processes. It covers coding challenges, system design rounds, evaluation rubrics,
+bias reduction techniques, and debrief calibration to ensure interviews extract
+meaningful signal while treating candidates fairly.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. **Define the role clearly** — What does this person actually do day-to-day? What
+   skills are essential vs. nice-to-have? What level of seniority?
+2. **Identify signals to extract** — Map each interview round to specific competencies
+   being evaluated. No round should exist without a clear signal target.
+3. **Audit for relevance** — Every question and challenge must relate to actual work
+   the candidate would perform. No puzzle questions, no trivia, no gotchas.
+
+### During
+
+4. **Coding challenge design principles:**
+   - Relevant to actual work the team does (not algorithmic puzzles unless role requires)
+   - Time-boxed with clear expectations communicated upfront
+   - Multiple valid solution paths (not one "correct" answer)
+   - Clear evaluation criteria shared with interviewers before use
+   - Scaffolding provided (no time wasted on boilerplate setup)
+   - Accommodations available (extra time, alternative formats)
+
+5. **Evaluation rubric (score each dimension 1-4):**
+   - **Problem decomposition** — Breaks problem into manageable parts, identifies
+     unknowns, asks clarifying questions before diving in.
+   - **Communication** — Explains thinking clearly, responds to hints, collaborates
+     with interviewer, articulates tradeoffs.
+   - **Code quality** — Readable, well-structured, appropriate abstractions, handles
+     edge cases, follows conventions.
+   - **Testing mindset** — Considers test cases, validates assumptions, identifies
+     failure modes, demonstrates correctness.
+   - **Tradeoff awareness** — Articulates time/space tradeoffs, discusses scalability,
+     acknowledges limitations of chosen approach.
+
+6. **Bias reduction techniques:**
+   - Score independently before debrief discussion (prevent anchoring)
+   - Use structured scorecards with specific evidence required per score
+   - Same questions for all candidates at same level (allow follow-ups to vary)
+   - Diverse interview panels (varied backgrounds, roles, tenure)
+   - Evaluate against rubric, not against other candidates or "culture fit"
+   - Train interviewers on common biases (halo effect, similarity bias, confirmation)
+
+7. **System design round structure:**
+   - Phase 1: Scope and requirements (candidate drives, interviewer clarifies)
+   - Phase 2: High-level design (components, data flow, API boundaries)
+   - Phase 3: Deep dive (interviewer picks area to explore in depth)
+   - Phase 4: Tradeoffs and evolution (scalability, failure modes, future changes)
+   - Evaluate: scalability thinking, tradeoff articulation, communication clarity,
+     ability to handle ambiguity, depth of technical knowledge.
+
+8. **Take-home challenge guidelines:**
+   - Maximum 3-4 hours of work (state this explicitly)
+   - Provide clear submission criteria and evaluation rubric upfront
+   - Allow technology choice where possible
+   - Pay candidates for take-homes exceeding 2 hours
+   - Review within 48 hours (respect candidate time)
+
+9. **Debrief calibration:**
+   - Each interviewer presents evidence and scores before group discussion
+   - No "veto without evidence" — strong no requires specific rubric failures
+   - Calibrate scores across interviewers quarterly using past candidates
+   - Track hire-to-performance correlation to improve signal extraction
+
+### After
+
+10. **Provide candidate feedback** — Specific, actionable, kind. Even for rejections,
+    share what went well and areas for growth.
+11. **Iterate on the process** — Track interviewer consistency, candidate satisfaction
+    scores, and time-to-decision. Improve quarterly.
+12. **Document interview guides** — Maintain living documents with questions, rubrics,
+    and calibration notes for each role type.
+
+## Self-check before task completion
+
+- [ ] Every round maps to specific, documented signals
+- [ ] Challenges are relevant to actual work (no trivia or puzzles)
+- [ ] Rubric uses 1-4 scale with clear behavioral anchors per level
+- [ ] Bias reduction measures in place (structured scoring, diverse panels)
+- [ ] Time expectations clearly communicated to candidates
+- [ ] Debrief process requires evidence-backed scores before discussion
+- [ ] Candidate feedback mechanism exists
+- [ ] Process review cadence established (at least quarterly)