@zigrivers/scaffold 3.33.3 → 3.33.4

package/content/guides/mmr/index.html

@@ -1570,10 +1570,26 @@ mmr review --pr 123 --channels grok claude --sync --format json
 
 
 
-<table><thead><tr><th>Command</th><th>Purpose</th></tr></thead><tbody><tr><td><code>mmr reconcile &#x3C;job-id> --channel &#x3C;name> --input &#x3C;data></code></td><td>Inject an external channel's findings (e.g. the Superpowers agent) into an existing job and re-run the results pipeline. Input is a file, <code>-</code> for stdin, or inline JSON. <span class="fp" data-path="packages/mmr/src/commands/reconcile.ts:17">packages/mmr/src/commands/reconcile.ts:17</span></td></tr><tr><td><code>mmr status &#x3C;job-id></code></td><td>Per-channel status and elapsed time. Exit 0 = all complete, 1 = running, 2 = a channel failed, 5 = not found.</td></tr><tr><td><code>mmr results &#x3C;job-id> [--raw]</code></td><td>Re-run parse → reconcile → format on a completed job. Exit code reflects the verdict.</td></tr><tr><td><code>mmr jobs &#x3C;list|prune></code></td><td>List jobs, or prune old ones per <code>job_retention_days</code>.</td></tr><tr><td><code>mmr sessions &#x3C;start|list|show|end> &#x3C;id></code></td><td>Manage multi-round review sessions (stored under <code>~/.mmr/sessions/</code>).</td></tr><tr><td><code>mmr config &#x3C;init|show|validate…></code></td><td>Scaffold and inspect <code>.mmr.yaml</code> (including OSS-runtime example blocks).</td></tr><tr><td><code>mmr ack &#x3C;add|list|rm|prune></code></td><td>Sticky acknowledgments — silence a finding by its stable key so it stops blocking across rounds.</td></tr></tbody></table>
+
+
+
+
+<table><thead><tr><th>Command</th><th>Purpose</th></tr></thead><tbody><tr><td><code>mmr reconcile &#x3C;job-id> --channel &#x3C;name> --input &#x3C;data></code></td><td>Inject an external channel's findings (e.g. the Superpowers agent) into an existing job and re-run the results pipeline. Input is a file, <code>-</code> for stdin, or inline JSON. <span class="fp" data-path="packages/mmr/src/commands/reconcile.ts:17">packages/mmr/src/commands/reconcile.ts:17</span></td></tr><tr><td><code>mmr status &#x3C;job-id></code></td><td>Per-channel status and elapsed time. Exit 0 = all complete, 1 = running, 2 = a channel failed, 5 = not found.</td></tr><tr><td><code>mmr results &#x3C;job-id> [--raw]</code></td><td>Re-run parse → reconcile → format on a completed job. Exit code reflects the verdict.</td></tr><tr><td><code>mmr jobs &#x3C;list|prune></code></td><td>List jobs, or prune old ones per <code>job_retention_days</code>.</td></tr><tr><td><code>mmr sessions &#x3C;start|list|show|end> &#x3C;id></code></td><td>Manage multi-round review sessions (stored under <code>~/.mmr/sessions/</code>).</td></tr><tr><td><code>mmr config &#x3C;init|show|validate…></code></td><td>Scaffold and inspect <code>.mmr.yaml</code> (including OSS-runtime example blocks).</td></tr><tr><td><code>mmr ack &#x3C;add|list|rm|prune></code></td><td>Sticky acknowledgments — silence a finding by its stable key so it stops blocking across rounds.</td></tr><tr><td><code>mmr skill install --platform &#x3C;name> | --all</code></td><td>Install a "use MMR for code review" skill into a project per agent CLI: Cursor (<code>.cursor/rules/mmr-review.mdc</code>), Gemini (<code>GEMINI.md</code>), Codex + Antigravity (shared <code>AGENTS.md</code> managed block). Supports <code>--dry-run</code>, <code>--force</code>, and <code>--dir</code>. <span class="fp" data-path="packages/mmr/src/commands/skill.ts:85">packages/mmr/src/commands/skill.ts:85</span></td></tr></tbody></table>
 <pre><code class="language-bash"># Capture a job_id from a review, then fold in an agent channel:
 mmr reconcile "$JOB_ID" --channel superpowers --input findings.json
+
+# Install the MMR review skill into the current project for one or all agent CLIs:
+mmr skill install --platform cursor
+mmr skill install --all --dry-run
 </code></pre>
+<div class="callout callout-info"><p><strong>Each agent CLI reads its own instruction file</strong>, so <code>mmr skill install</code> writes the
+skill in the matching convention: a dedicated <code>.cursor/rules/mmr-review.mdc</code> for
+Cursor, and an idempotent managed block (delimited by <code>&#x3C;!-- BEGIN mmr-skill --></code> and <code>&#x3C;!-- END mmr-skill --></code>) in <code>GEMINI.md</code>
+(Gemini) or <code>AGENTS.md</code> (Codex and Antigravity share the <code>AGENTS.md</code> standard, so
+both resolve to the same block). For the block-mode files, re-running rewrites only
+the managed block and leaves the rest of the file intact; the dedicated Cursor file
+is created fresh and needs <code>--force</code> to overwrite. The skill bodies are bundled with
+the package under <code>packages/mmr/templates/skills/</code> <span class="fp" data-path="packages/mmr/templates/skills/agents/mmr-review.md:1">packages/mmr/templates/skills/agents/mmr-review.md:1</span>.</p></div>
 <h2 id="channel-architecture">Channel architecture</h2>
 <p>A channel is <strong>pure config data</strong> — there is no per-channel code. The dispatcher
 runs whatever <code>command</code> the channel defines, hands it the prompt, and parses its

package/content/guides/mmr/index.md

@@ -129,12 +129,28 @@ mmr review --pr 123 --channels grok claude --sync --format json
 | `mmr sessions <start\|list\|show\|end> <id>` | Manage multi-round review sessions (stored under `~/.mmr/sessions/`). |
 | `mmr config <init\|show\|validate…>` | Scaffold and inspect `.mmr.yaml` (including OSS-runtime example blocks). |
 | `mmr ack <add\|list\|rm\|prune>` | Sticky acknowledgments — silence a finding by its stable key so it stops blocking across rounds. |
+| `mmr skill install --platform <name> \| --all` | Install a "use MMR for code review" skill into a project per agent CLI: Cursor (`.cursor/rules/mmr-review.mdc`), Gemini (`GEMINI.md`), Codex + Antigravity (shared `AGENTS.md` managed block). Supports `--dry-run`, `--force`, and `--dir`. :cite[packages/mmr/src/commands/skill.ts:85] |
 
 ```bash
 # Capture a job_id from a review, then fold in an agent channel:
 mmr reconcile "$JOB_ID" --channel superpowers --input findings.json
+
+# Install the MMR review skill into the current project for one or all agent CLIs:
+mmr skill install --platform cursor
+mmr skill install --all --dry-run
 ```
 
+:::callout{type=info}
+**Each agent CLI reads its own instruction file**, so `mmr skill install` writes the
+skill in the matching convention: a dedicated `.cursor/rules/mmr-review.mdc` for
+Cursor, and an idempotent managed block (delimited by `<!-- BEGIN mmr-skill -->` and `<!-- END mmr-skill -->`) in `GEMINI.md`
+(Gemini) or `AGENTS.md` (Codex and Antigravity share the `AGENTS.md` standard, so
+both resolve to the same block). For the block-mode files, re-running rewrites only
+the managed block and leaves the rest of the file intact; the dedicated Cursor file
+is created fresh and needs `--force` to overwrite. The skill bodies are bundled with
+the package under `packages/mmr/templates/skills/` :cite[packages/mmr/templates/skills/agents/mmr-review.md:1].
+:::
+
 ## Channel architecture
 
 A channel is **pure config data** — there is no per-channel code. The dispatcher

package/content/knowledge/VERSION

@@ -1 +1 @@
-0.1.6
+0.1.8

package/content/knowledge/backend/backend-fintech-observability.md

@@ -1,13 +1,27 @@
 ---
 name: backend-fintech-observability
-description: Trade event correlation; market-hours aware scheduling; SLOs for fintech systems; compliance logging; alerting strategy.
-topics: [backend, fintech, observability, tracing, slos, alerting, correlation-id, market-hours]
+description: >-
+  Trade event correlation; market-hours aware scheduling; SLOs for fintech systems; compliance logging; alerting
+  strategy.
+topics:
+  - backend
+  - fintech
+  - observability
+  - tracing
+  - slos
+  - alerting
+  - correlation-id
+  - market-hours
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2026-06-04
 version-pin: null
 sources:
   - url: https://opentelemetry.io/docs/
+    hash: sha256:706e97cb13d09d70eee19f203147c630bd13148cb8c5d60fd2a9f4452dbf1559
+    retrieved: 2026-06-04
   - url: https://sre.google/sre-book/service-level-objectives/
+    hash: sha256:449fb54ce65e05102fac46c797a08b86c5ab93ade2c70c63ae25e7648d687d7d
+    retrieved: 2026-06-04
 ---
 
 Observability for a trading system is not generic APM with a finance skin — it is the ability to reconstruct any single order, end to end, across six or more services, on demand, years later, with timezone-correct timestamps and a stable correlation identifier. It is also the early-warning system that catches a sudden drop in fill rate at 09:31 ET before the desk calls. Done well it overlaps with — but does not replace — the immutable audit trail (`backend-fintech-compliance.md`).

package/content/knowledge/backend/backend-fintech-order-lifecycle.md

@@ -1,13 +1,27 @@
 ---
 name: backend-fintech-order-lifecycle
-description: Order state machine; fills, partial fills, cancellation; event-driven order tracking; idempotency; handling "unknown" states.
-topics: [backend, fintech, orders, state-machine, fills, partial-fills, event-driven, webhooks]
+description: >-
+  Order state machine; fills, partial fills, cancellation; event-driven order tracking; idempotency; handling "unknown"
+  states.
+topics:
+  - backend
+  - fintech
+  - orders
+  - state-machine
+  - fills
+  - partial-fills
+  - event-driven
+  - webhooks
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2026-06-04
 version-pin: null
 sources:
   - url: https://microservices.io/patterns/data/saga.html
+    hash: sha256:c42eac244bf94f8db7767ba131c1715066a2dd10beb1cd6f01e5f92e19d2f0b3
+    retrieved: 2026-06-04
   - url: https://martinfowler.com/articles/patterns-of-distributed-systems/
+    hash: sha256:93092f76ea34af4d60c068180a063d9fde27ab6c7b604ba42337aeed023cab86
+    retrieved: 2026-06-04
 ---
 
 Orders in a trading system are long-lived, asynchronous, externally mutated objects — the exact shape of problem a disciplined state machine is built for. This doc covers the canonical states and transitions, how fills and partial fills land, why "unknown" is a real state you cannot wish away, and the reconciliation posture that keeps internal bookkeeping aligned with the broker of record.

package/content/knowledge/backend/backend-fintech-risk-management.md

@@ -1,13 +1,27 @@
 ---
 name: backend-fintech-risk-management
-description: Position limits, drawdown caps, circuit breakers, kill switches; pre-trade and post-trade risk checks; operational risk controls.
-topics: [backend, fintech, risk, position-limits, drawdown, circuit-breakers, kill-switch, pre-trade-checks]
+description: >-
+  Position limits, drawdown caps, circuit breakers, kill switches; pre-trade and post-trade risk checks; operational
+  risk controls.
+topics:
+  - backend
+  - fintech
+  - risk
+  - position-limits
+  - drawdown
+  - circuit-breakers
+  - kill-switch
+  - pre-trade-checks
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2026-06-04
 version-pin: null
 sources:
   - url: https://martinfowler.com/bliki/CircuitBreaker.html
+    hash: sha256:73239948ec03887430a4d139e384e94bc640fec894fb1dce53b56abe579c5da4
+    retrieved: 2026-06-04
   - url: https://microservices.io/patterns/reliability/circuit-breaker.html
+    hash: sha256:a117f72fc0d279ea99d4234ea8a8cc7bdf23d7ed59d94effc6129d613518a6fa
+    retrieved: 2026-06-04
 ---
 
 Risk management in a trading system is the set of controls that stops a bad day from becoming a catastrophic one. It lives in two places: *before* an order goes to the broker (pre-trade checks that block) and *after* fills land (post-trade monitoring that alerts, throttles, or halts). Neither half is optional, and both are exercised continuously, not just during incidents.

package/content/knowledge/backend/backend-fintech-testing.md

@@ -1,13 +1,25 @@
 ---
 name: backend-fintech-testing
 description: Deterministic backtests; financial-accuracy tests; broker sandbox testing; regulatory edge-case coverage.
-topics: [backend, fintech, testing, determinism, backtesting, sandbox, accuracy, property-based]
+topics:
+  - backend
+  - fintech
+  - testing
+  - determinism
+  - backtesting
+  - sandbox
+  - accuracy
+  - property-based
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2026-06-04
 version-pin: null
 sources:
   - url: https://docs.pact.io/
+    hash: sha256:404a36a35476bc730dc8b0bc66ecde4eb1295c63dd9c357f30d7c60aa24e960e
+    retrieved: 2026-06-04
   - url: https://martinfowler.com/articles/practical-test-pyramid.html
+    hash: sha256:d5f669995439f1c7bb7109a8f5e52044f1b7f39e92115679518d2b762ca39eff
+    retrieved: 2026-06-04
 ---
 
 Fintech tests have unusual requirements: bit-exact numeric accuracy, full determinism across runs and hosts, rich regulatory edge-case coverage, and realistic multi-session flows that span market-hours boundaries. A flakey fintech test is worse than no test — it hides the exact race conditions that cause real money to move incorrectly. This doc covers the patterns that keep backtests reproducible, numeric tests honest, broker integrations verifiable, and regulatory behavior exercised before it becomes an incident.

package/content/knowledge/backend/backend-observability.md

@@ -1,14 +1,28 @@
 ---
 name: backend-observability
 description: Structured logging, distributed tracing, RED method metrics, SLO-based alerting, and operational dashboards
-topics: [backend, observability, logging, tracing, metrics, alerting, opentelemetry, slo]
+topics:
+  - backend
+  - observability
+  - logging
+  - tracing
+  - metrics
+  - alerting
+  - opentelemetry
+  - slo
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2026-06-04
 version-pin: null
 sources:
   - url: https://opentelemetry.io/docs/
+    hash: sha256:706e97cb13d09d70eee19f203147c630bd13148cb8c5d60fd2a9f4452dbf1559
+    retrieved: 2026-06-04
   - url: https://sre.google/sre-book/service-level-objectives/
+    hash: sha256:449fb54ce65e05102fac46c797a08b86c5ab93ade2c70c63ae25e7648d687d7d
+    retrieved: 2026-06-04
   - url: https://sre.google/sre-book/monitoring-distributed-systems/
+    hash: sha256:ea5268bca492024a399730734132c7513b4412b10098a207f2e3090eeae1a6fe
+    retrieved: 2026-06-04
 ---
 
 Observability is the ability to answer arbitrary questions about a system's behavior using its outputs alone — without deploying new code. Investing in structured logging, distributed tracing, and SLO-based alerting before the first incident makes the difference between a 5-minute diagnosis and a 5-hour outage.

package/content/knowledge/backend/backend-project-structure.md

@@ -1,13 +1,24 @@
 ---
 name: backend-project-structure
-description: Canonical directory layout for backend services — routes/controllers, services, models/repositories, middleware, utils, config resolution, and dependency injection patterns
-topics: [backend, project-structure, architecture, dependency-injection, layers]
+description: >-
+  Canonical directory layout for backend services — routes/controllers, services, models/repositories, middleware,
+  utils, config resolution, and dependency injection patterns
+topics:
+  - backend
+  - project-structure
+  - architecture
+  - dependency-injection
+  - layers
 volatility: stable
-last-reviewed: null
+last-reviewed: 2026-06-04
 version-pin: null
 sources:
   - url: https://martinfowler.com/eaaCatalog/
+    hash: sha256:45b80ec0b5893f07a6d0170851f87d0904617d34f3321a0f1aab0d8807b61be7
+    retrieved: 2026-06-04
   - url: https://martinfowler.com/articles/injection.html
+    hash: sha256:a05822499fee06b676a369cc2fb0b2bdda6a589e7589382907b1ab531c26ef19
+    retrieved: 2026-06-04
 ---
 
 A well-organized backend project is readable to a new engineer in minutes. The directory layout should communicate the architecture: which layer owns which responsibility, where to add a new feature, and where to find any piece of behavior. The most common structural failure is mixing concerns — business logic in controllers, database calls in services, HTTP parsing in repositories. Enforce boundaries through structure first, tooling second.

package/content/knowledge/backend/backend-requirements.md

@@ -1,13 +1,26 @@
 ---
 name: backend-requirements
-description: API-first design principles, SLA requirements (latency p99, uptime, throughput), scalability targets, backwards compatibility commitments, and API versioning strategy
-topics: [backend, requirements, sla, api, versioning, scalability, performance]
+description: >-
+  API-first design principles, SLA requirements (latency p99, uptime, throughput), scalability targets, backwards
+  compatibility commitments, and API versioning strategy
+topics:
+  - backend
+  - requirements
+  - sla
+  - api
+  - versioning
+  - scalability
+  - performance
 volatility: stable
-last-reviewed: null
+last-reviewed: 2026-06-04
 version-pin: null
 sources:
   - url: https://spec.openapis.org/oas/latest.html
+    hash: sha256:15f12e539a3ac811c5f18950bc9cff296b43a22ad4d50b4db8d533f37ebc1d23
+    retrieved: 2026-06-04
   - url: https://sre.google/sre-book/service-level-objectives/
+    hash: sha256:449fb54ce65e05102fac46c797a08b86c5ab93ade2c70c63ae25e7648d687d7d
+    retrieved: 2026-06-04
 ---
 
 Backend requirements are the contract the service makes with its consumers — other teams, external developers, and end users. Setting explicit SLAs, versioning policies, and scalability targets before any code is written eliminates the most expensive class of late-breaking architectural changes. A backend that surprises its callers with latency spikes or breaking changes destroys trust and creates cascading toil.

package/content/knowledge/backend/backend-security.md

@@ -1,14 +1,29 @@
 ---
 name: backend-security
-description: Input validation, SQL injection prevention, rate limiting, OWASP API Security Top 10, secrets management, and dependency auditing
-topics: [backend, security, validation, sql-injection, rate-limiting, owasp, secrets]
+description: >-
+  Input validation, SQL injection prevention, rate limiting, OWASP API Security Top 10, secrets management, and
+  dependency auditing
+topics:
+  - backend
+  - security
+  - validation
+  - sql-injection
+  - rate-limiting
+  - owasp
+  - secrets
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2026-06-04
 version-pin: null
 sources:
   - url: https://owasp.org/www-project-api-security/
+    hash: sha256:ca850597dfc526453cb177306117d47a71e36b445b7c662d86ff42d777f2a035
+    retrieved: 2026-06-04
   - url: https://owasp.org/www-project-top-ten/
+    hash: sha256:aa01e44bed66cf7d8c167a39e58c0ffd131110ae4baed6beb0195c4c875af72e
+    retrieved: 2026-06-04
   - url: https://owasp.org/www-project-cheat-sheets/
+    hash: sha256:14ca69c2260d9f0de17b44c7c097fcdd3f9a23cf2bfe927cf3896ca9cbcd14fe
+    retrieved: 2026-06-04
 ---
 
 Security vulnerabilities in backend services are disproportionately expensive to fix after launch — building in input validation, injection prevention, rate limiting, and secrets hygiene from the start is always cheaper than retrofitting them under pressure after a breach.

package/content/knowledge/backend/backend-testing.md

@@ -1,14 +1,27 @@
 ---
 name: backend-testing
 description: API integration tests, contract testing, database testing patterns, mocking external services, and load testing
-topics: [backend, testing, integration-tests, contract-testing, database-testing, mocking, load-testing]
+topics:
+  - backend
+  - testing
+  - integration-tests
+  - contract-testing
+  - database-testing
+  - mocking
+  - load-testing
 volatility: stable
-last-reviewed: null
+last-reviewed: 2026-06-04
 version-pin: null
 sources:
   - url: https://docs.pact.io/
+    hash: sha256:404a36a35476bc730dc8b0bc66ecde4eb1295c63dd9c357f30d7c60aa24e960e
+    retrieved: 2026-06-04
   - url: https://martinfowler.com/articles/practical-test-pyramid.html
+    hash: sha256:d5f669995439f1c7bb7109a8f5e52044f1b7f39e92115679518d2b762ca39eff
+    retrieved: 2026-06-04
   - url: https://martinfowler.com/bliki/ContractTest.html
+    hash: sha256:0be8475d7f5e37f771ded4b200f1ee0dadbc35480fc4a5b1b2430748922e11c8
+    retrieved: 2026-06-04
 ---
 
 Backend testing strategy determines how much confidence you have before every deploy — a well-layered test suite catches regressions at the fastest possible feedback loop while still exercising the real data layer and honoring API contracts with consumers.

package/content/knowledge/backend/backend-worker-patterns.md

@@ -1,13 +1,27 @@
 ---
 name: backend-worker-patterns
-description: Background job frameworks, cron scheduling, event consumers, dead letter queues, retry strategies, and graceful shutdown for workers
-topics: [backend, workers, bullmq, celery, temporal, cron, background-jobs, dlq]
+description: >-
+  Background job frameworks, cron scheduling, event consumers, dead letter queues, retry strategies, and graceful
+  shutdown for workers
+topics:
+  - backend
+  - workers
+  - bullmq
+  - celery
+  - temporal
+  - cron
+  - background-jobs
+  - dlq
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2026-06-04
 version-pin: null
 sources:
   - url: https://microservices.io/patterns/data/transactional-outbox.html
+    hash: sha256:0311303336376acb20c3f70729a67ea9e094546798a98276567257e6631122b0
+    retrieved: 2026-06-04
   - url: https://sre.google/sre-book/handling-overload/
+    hash: sha256:8ca912a82390e7f61e8bbae7baab3a74489f5068d71dee1ff24aed99375e0373
+    retrieved: 2026-06-04
 ---
 
 Background workers offload time-consuming and deferred work from the request path, but they introduce their own failure modes — jobs that silently vanish, duplicate executions, and unclean shutdowns during deploys all require deliberate design to prevent.

package/content/skills/mmr/SKILL.md

@@ -12,6 +12,15 @@ topics:
 
 Dispatch code reviews to multiple AI model CLIs, poll for results, and collect reconciled findings with severity gating.
 
+> **Scope & related skills.** This skill ships with Scaffold for Claude Code and
+> shared-agent hosts (`.claude/skills/`, `.agents/skills/`). The MMR CLI itself can
+> install an equivalent review skill into other agent CLIs — Cursor, Codex, Gemini,
+> and Antigravity — via `mmr skill install` (see the
+> [`mmr` reference guide](../../guides/mmr/index.md)). Those per-platform skill bodies
+> live in `packages/mmr/templates/skills/` and are the source of truth for those
+> platforms; keep this file's `mmr review` guidance in sync with them when the CLI
+> surface changes.
+
 ## Quick Reference
 
 `mmr review` works for any review target — not just PRs. Pick the input mode

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zigrivers/scaffold",
-  "version": "3.33.3",
+  "version": "3.33.4",
   "description": "AI-powered software project scaffolding pipeline",
   "type": "module",
   "workspaces": [

package/skills/mmr/SKILL.md

@@ -12,6 +12,15 @@ topics:
 
 Dispatch code reviews to multiple AI model CLIs, poll for results, and collect reconciled findings with severity gating.
 
+> **Scope & related skills.** This skill ships with Scaffold for Claude Code and
+> shared-agent hosts (`.claude/skills/`, `.agents/skills/`). The MMR CLI itself can
+> install an equivalent review skill into other agent CLIs — Cursor, Codex, Gemini,
+> and Antigravity — via `mmr skill install` (see the
+> [`mmr` reference guide](../../guides/mmr/index.md)). Those per-platform skill bodies
+> live in `packages/mmr/templates/skills/` and are the source of truth for those
+> platforms; keep this file's `mmr review` guidance in sync with them when the CLI
+> surface changes.
+
 ## Quick Reference
 
 `mmr review` works for any review target — not just PRs. Pick the input mode