@zigrivers/scaffold 3.33.3 → 3.33.5

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.10

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/knowledge/browser-extension/browser-extension-architecture.md

@@ -1,13 +1,25 @@
 ---
 name: browser-extension-architecture
-description: Component isolation across content scripts, background service workers, and popup pages; message passing patterns; and state synchronization strategies
-topics: [browser-extension, architecture, message-passing, state-synchronization, service-worker, content-scripts]
+description: >-
+  Component isolation across content scripts, background service workers, and popup pages; message passing patterns; and
+  state synchronization strategies
+topics:
+  - browser-extension
+  - architecture
+  - message-passing
+  - state-synchronization
+  - service-worker
+  - content-scripts
 volatility: evolving
-last-reviewed: null
-version-pin: 'Manifest V3'
+last-reviewed: 2026-06-05
+version-pin: Manifest V3
 sources:
   - url: https://developer.chrome.com/docs/extensions/mv3/architecture-overview
+    hash: sha256:138a4d2e5659d81c90bdf5914adef0d119793f3e665aeea5183863b06f469d12
+    retrieved: 2026-06-05
   - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Anatomy_of_a_WebExtension
+    hash: sha256:25478eeaaec350aa31f533f52c1c34042cd13a133bd5add6d23f567265ce862b
+    retrieved: 2026-06-05
 ---
 
 Browser extension architecture is fundamentally different from web app architecture because the application is split across multiple isolated execution environments that cannot share memory directly. Content scripts run inside host pages but in an isolated JavaScript world. Service workers run in a separate context that is terminated and re-created between events. Popup pages are ephemeral — they exist only while the popup is open. These constraints drive every architectural decision: communication is via message passing, state must be externalized to `chrome.storage`, and every component must tolerate being initialized from scratch at any time.

package/content/knowledge/browser-extension/browser-extension-content-scripts.md

@@ -1,13 +1,25 @@
 ---
 name: browser-extension-content-scripts
-description: DOM manipulation from content scripts, isolated worlds, CSS injection, and communicating with the host page via postMessage
-topics: [browser-extension, content-scripts, dom-manipulation, isolated-worlds, css-injection, postmessage]
+description: >-
+  DOM manipulation from content scripts, isolated worlds, CSS injection, and communicating with the host page via
+  postMessage
+topics:
+  - browser-extension
+  - content-scripts
+  - dom-manipulation
+  - isolated-worlds
+  - css-injection
+  - postmessage
 volatility: fast-moving
-last-reviewed: null
-version-pin: 'Manifest V3'
+last-reviewed: 2026-06-05
+version-pin: Manifest V3
 sources:
   - url: https://developer.chrome.com/docs/extensions/develop/concepts/content-scripts
+    hash: sha256:21d93ef79a4d62b9593ff5f7c28e095031baace9884dbc1128b18ea26194cec2
+    retrieved: 2026-06-05
   - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts
+    hash: sha256:6089f52945b1b44a6c9361351c91f0304634dc429bb822fa83c4e7ff109a37c2
+    retrieved: 2026-06-05
 ---
 
 Content scripts are the extension's interface with the web page. They run inside the page's DOM but in an isolated JavaScript world — they see the same HTML and can manipulate the same elements, but they cannot access the page's JavaScript variables or prototype chain without explicitly crossing the world boundary. Understanding this isolation is essential for writing content scripts that are both functional and secure.

package/content/knowledge/browser-extension/browser-extension-conventions.md

@@ -1,13 +1,23 @@
 ---
 name: browser-extension-conventions
 description: Naming conventions for manifests, message action types, file organization, and i18n structure in browser extensions
-topics: [browser-extension, conventions, naming, i18n, file-organization, messaging]
+topics:
+  - browser-extension
+  - conventions
+  - naming
+  - i18n
+  - file-organization
+  - messaging
 volatility: evolving
-last-reviewed: null
-version-pin: 'Manifest V3'
+last-reviewed: 2026-06-05
+version-pin: Manifest V3
 sources:
   - url: https://developer.chrome.com/docs/extensions/reference/manifest
+    hash: sha256:873da4e4724c4352c91929415bcb9e7b98b79f7773e26bf4387ad0137ae69753
+    retrieved: 2026-06-05
   - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Internationalization
+    hash: sha256:55fd96d3c9e92a0d13221f3485b9c7b82192a2fb95fa96586bfd2c091240ba04
+    retrieved: 2026-06-05
 ---
 
 Browser extensions accumulate technical debt faster than typical web apps because they span multiple execution contexts — content scripts, service workers, popup pages, options pages — each with distinct constraints. Consistent naming conventions and file organization make cross-context code navigable and reduce the cognitive overhead of working across these boundaries. Establish conventions before writing code.

package/content/knowledge/browser-extension/browser-extension-cross-browser.md

@@ -1,13 +1,26 @@
 ---
 name: browser-extension-cross-browser
-description: Using webextension-polyfill for API compatibility, manifest differences between Chrome and Firefox, browser-specific APIs, and managing a multi-browser build matrix
-topics: [browser-extension, cross-browser, firefox, chrome, webextension-polyfill, compatibility, build-matrix]
+description: >-
+  Using webextension-polyfill for API compatibility, manifest differences between Chrome and Firefox, browser-specific
+  APIs, and managing a multi-browser build matrix
+topics:
+  - browser-extension
+  - cross-browser
+  - firefox
+  - chrome
+  - webextension-polyfill
+  - compatibility
+  - build-matrix
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2026-06-05
 version-pin: null
 sources:
   - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs
+    hash: sha256:4b0a8d2d7f7db598b7c1b745e49b32e5408a7ca6a58a99450aea1e3bd01fde60
+    retrieved: 2026-06-05
   - url: https://developer.chrome.com/docs/extensions/develop/migrate
+    hash: sha256:63ca45e8137178af34a42b750639120fe28502a27a59c476cfc77fb778f14b14
+    retrieved: 2026-06-05
 ---
 
 Browser extensions that target both Chrome and Firefox share most of their codebase, but the differences between the two platforms are significant enough to require explicit management. API namespaces differ, manifest syntax diverges in subtle ways, and some APIs exist only in Chrome or only in Firefox. A systematic cross-browser strategy prevents the "works in Chrome, broken in Firefox" class of bugs.

package/content/knowledge/browser-extension/browser-extension-dev-environment.md

@@ -1,13 +1,26 @@
 ---
 name: browser-extension-dev-environment
-description: Build tooling with Webpack/Vite, hot reload via web-ext and crx-hotreload, and browser launch configuration for extension development
-topics: [browser-extension, dev-environment, vite, webpack, hot-reload, web-ext, build]
+description: >-
+  Build tooling with Webpack/Vite, hot reload via web-ext and crx-hotreload, and browser launch configuration for
+  extension development
+topics:
+  - browser-extension
+  - dev-environment
+  - vite
+  - webpack
+  - hot-reload
+  - web-ext
+  - build
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2026-06-05
 version-pin: null
 sources:
   - url: https://developer.chrome.com/docs/extensions/get-started/tutorial/hello-world
+    hash: sha256:dc673d9b594c057cf68896851b5c211552f4b7f3876c22a568c95348b0155075
+    retrieved: 2026-06-05
   - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Your_first_WebExtension
+    hash: sha256:0f4e414a029b2c3f6e6c1ba5709dd88822fc61cddde1ac58af60f3dffad8d53d
+    retrieved: 2026-06-05
 ---
 
 Browser extension development requires a different local setup than web app development. There is no dev server to navigate to — the extension must be loaded into a real browser instance, and changes require either a manual reload or a dedicated hot-reload tool. Getting this setup right at the start of the project eliminates the most friction-heavy part of the development loop.

package/content/knowledge/browser-extension/browser-extension-manifest.md

@@ -1,13 +1,26 @@
 ---
 name: browser-extension-manifest
-description: Manifest V3 schema, permissions declarations, host_permissions, content_scripts configuration, and background service_worker setup
-topics: [browser-extension, manifest, manifest-v3, permissions, content-scripts, service-worker, host-permissions]
+description: >-
+  Manifest V3 schema, permissions declarations, host_permissions, content_scripts configuration, and background
+  service_worker setup
+topics:
+  - browser-extension
+  - manifest
+  - manifest-v3
+  - permissions
+  - content-scripts
+  - service-worker
+  - host-permissions
 volatility: fast-moving
-last-reviewed: null
-version-pin: 'Manifest V3'
+last-reviewed: 2026-06-05
+version-pin: Manifest V3
 sources:
   - url: https://developer.chrome.com/docs/extensions/reference/manifest
+    hash: sha256:0bbe598d0affd4b9431dabcde7a0410f81e95b38092d6b258bf796135c438ab6
+    retrieved: 2026-06-05
   - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json
+    hash: sha256:cea8bb2558b2918998720b80649d5e9551491afec633fede6d338f913b55a5bc
+    retrieved: 2026-06-05
 ---
 
 The `manifest.json` is the contract between your extension and the browser. Every capability your extension uses must be declared here before it can be used. Manifest V3 (MV3) is the current standard, having replaced Manifest V2 (MV2) in Chrome. Understanding the MV3 schema in depth prevents runtime errors, store rejections, and security review failures.

package/content/knowledge/browser-extension/browser-extension-project-structure.md

@@ -1,13 +1,24 @@
 ---
 name: browser-extension-project-structure
-description: Directory layout for browser extensions covering src/popup, src/content, src/background, src/options, public/icons, and _locales
-topics: [browser-extension, project-structure, file-organization, build, icons]
+description: >-
+  Directory layout for browser extensions covering src/popup, src/content, src/background, src/options, public/icons,
+  and _locales
+topics:
+  - browser-extension
+  - project-structure
+  - file-organization
+  - build
+  - icons
 volatility: evolving
-last-reviewed: null
-version-pin: 'Manifest V3'
+last-reviewed: 2026-06-05
+version-pin: Manifest V3
 sources:
   - url: https://developer.chrome.com/docs/extensions/develop
+    hash: sha256:fc24f69c0d484d9806c95229ddf1c29a1fd9a03cc81ccc9f837548725171a5ef
+    retrieved: 2026-06-05
   - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Anatomy_of_a_WebExtension
+    hash: sha256:25478eeaaec350aa31f533f52c1c34042cd13a133bd5add6d23f567265ce862b
+    retrieved: 2026-06-05
 ---
 
 Browser extension project structure must account for multiple compilation targets (one bundle per execution context), static assets that bypass the build pipeline, and locale files consumed by the WebExtensions runtime. A well-organized project structure makes build configuration straightforward, keeps context-specific code isolated, and prevents accidentally importing browser APIs that are unavailable in a given context.

package/content/knowledge/browser-extension/browser-extension-requirements.md

@@ -1,13 +1,25 @@
 ---
 name: browser-extension-requirements
-description: User permissions model, store policies (Chrome Web Store, AMO), accessibility requirements, and performance budgets for browser extensions
-topics: [browser-extension, requirements, permissions, store-policies, accessibility, performance]
+description: >-
+  User permissions model, store policies (Chrome Web Store, AMO), accessibility requirements, and performance budgets
+  for browser extensions
+topics:
+  - browser-extension
+  - requirements
+  - permissions
+  - store-policies
+  - accessibility
+  - performance
 volatility: evolving
-last-reviewed: null
-version-pin: 'Manifest V3'
+last-reviewed: 2026-06-05
+version-pin: Manifest V3
 sources:
   - url: https://developer.chrome.com/docs/webstore/program-policies
+    hash: sha256:b920f88cdb7ee59c5e91d45357680c06a781db04bdfc72aa242e3dde71862838
+    retrieved: 2026-06-05
   - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/AMO/Policy
+    hash: sha256:9791bbdf9ed9ecd0f0b6b8478bda286ab4fce4c7544a0100186b5fa28988daa1
+    retrieved: 2026-06-05
 ---
 
 Browser extension requirements differ fundamentally from web app requirements because the extension operates inside a user's browser with elevated trust and broad access to browsing data. Every permission requested must be justified, every store policy must be understood before writing code, and performance budgets must be set early because extensions run on every page a user visits — regressions directly degrade the entire browsing experience.

package/content/knowledge/browser-extension/browser-extension-security.md

@@ -1,14 +1,29 @@
 ---
 name: browser-extension-security
-description: Content Security Policy for extensions, prohibitions on eval and inline scripts, host permissions principle of least privilege, and XSS prevention in extension UIs
-topics: [browser-extension, security, csp, xss, permissions, least-privilege, eval]
+description: >-
+  Content Security Policy for extensions, prohibitions on eval and inline scripts, host permissions principle of least
+  privilege, and XSS prevention in extension UIs
+topics:
+  - browser-extension
+  - security
+  - csp
+  - xss
+  - permissions
+  - least-privilege
+  - eval
 volatility: evolving
-last-reviewed: null
-version-pin: 'Manifest V3'
+last-reviewed: 2026-06-05
+version-pin: Manifest V3
 sources:
   - url: https://developer.chrome.com/docs/extensions/reference/manifest/content-security-policy
+    hash: sha256:e4c7c42933e4e917edd5cf2b5aa3e3d6a13f07ebdfad927d4bda567f6c8c175f
+    retrieved: 2026-06-05
   - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy
+    hash: sha256:d06e2e28a6173edd2dfd58b02f2d5c5e0665a76da98dea2b4f9a8f07c2ecfb4d
+    retrieved: 2026-06-05
   - url: https://owasp.org/www-community/attacks/xss/
+    hash: sha256:e2d634a57647ee73a8aced85e0950560020e44324931468de07e36d1bba49c1d
+    retrieved: 2026-06-05
 ---
 
 Browser extensions run with elevated browser privileges compared to ordinary web pages. A compromised extension can read browsing history, intercept network requests, steal cookies, and inject content into any page it has permission to access. Security is not optional — it is a first-class requirement enforced by the browser, the store review process, and the trust of every user who installs the extension.

package/content/knowledge/browser-extension/browser-extension-service-workers.md

@@ -1,13 +1,26 @@
 ---
 name: browser-extension-service-workers
-description: Extension service worker lifecycle (install/activate), event-driven programming model, alarms API for recurring tasks, and persistent state via chrome.storage
-topics: [browser-extension, service-worker, lifecycle, alarms, chrome-storage, event-driven, background]
+description: >-
+  Extension service worker lifecycle (install/activate), event-driven programming model, alarms API for recurring tasks,
+  and persistent state via chrome.storage
+topics:
+  - browser-extension
+  - service-worker
+  - lifecycle
+  - alarms
+  - chrome-storage
+  - event-driven
+  - background
 volatility: fast-moving
-last-reviewed: null
-version-pin: 'Manifest V3'
+last-reviewed: 2026-06-05
+version-pin: Manifest V3
 sources:
   - url: https://developer.chrome.com/docs/extensions/develop/concepts/service-workers
+    hash: sha256:088fdeebf41909724c31ae64f779d25853ce91dab3d30d48fe6876beb697984a
+    retrieved: 2026-06-05
   - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Background_scripts
+    hash: sha256:74c09f9ce0e40ed769c4c1128493ee5749df7b9d5359b7a815c6dfbd18069aff
+    retrieved: 2026-06-05
 ---
 
 The Manifest V3 background service worker is the most architecturally disruptive change from MV2. The persistent background page that could hold state indefinitely is gone. Service workers are event-driven and ephemeral — Chrome terminates them when idle and restarts them when events arrive. Every design decision for background logic must account for this constraint.

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.5",
   "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