aw-ecc 1.4.21

package/skills/aw-brainstorm/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: aw-brainstorm
+description: Internal discovery helper that deepens pre-code exploration, compares approaches, and hands an approved direction to aw-plan without expanding the public command surface.
+trigger: Internal only. Invoked by aw-plan or aw-ship when discovery is still too fuzzy for direct planning.
+---
+
+# AW Brainstorm
+
+## Purpose
+
+`aw-brainstorm` is an internal depth skill.
+It should make the planning input sharper, not create a parallel public workflow or a second artifact system.
+
+The canonical public route for planning remains `/aw:plan`.
+
+## Hard Gate
+
+No implementation code may be written while discovery is still open.
+This skill stops at an approved direction and hands that direction to `aw-spec` through `aw-plan`.
+In other words, the public handoff is still: invoke `aw-plan`.
+
+## Discovery Loop
+
+Use this loop only when direct planning would otherwise guess:
+
+1. explore project context first:
+   - current files
+   - docs
+   - recent commits or adjacent artifacts when useful
+2. decide whether the request is actually one feature or multiple independent subsystems
+3. if the scope is too large for one spec, decompose it before detailed design work
+4. identify the unknowns, assumptions, and decision points
+5. ask at most one clarifying question at a time when a real decision is blocked
+6. propose 2-3 distinct approaches with trade-offs
+7. recommend one approach explicitly
+8. present the proposed direction in a way the user can approve or correct
+9. confirm the chosen direction or record the current best default
+10. run a quick self-review for placeholders, contradictions, ambiguity, and overscope
+11. hand the approved direction to `aw-spec` through `aw-plan`
+
+## Scope Check
+
+Before deepening the design, decide whether the request needs decomposition.
+
+If the request spans multiple independent subsystems, do not force one giant planning artifact.
+Break it into smaller spec-worthy scopes and continue with the smallest correct slice.
+If the request is too large for one spec, decompose it before moving on.
+
+## Design Expectations
+
+Discovery should be concrete enough that the next planning step does not need to rediscover the core shape of the work.
+
+Capture:
+
+- problem framing
+- purpose and success criteria
+- constraints
+- compared approaches
+- chosen approach with rationale
+- major risks
+- non-goals
+- the next planning artifact that should be written
+
+If the topic is visual and the active harness supports it, a browser-based visual companion may be offered as its own message before visual questions.
+
+## Required Output
+
+Produce a discovery summary that `aw-plan` and `aw-spec` can consume without redoing the ideation step.
+
+The summary should capture:
+
+- problem framing
+- assumptions and open questions
+- compared approaches
+- chosen approach with rationale
+- major risks
+- constraints and non-goals
+- what planning artifact should come next
+
+## Artifact Rule
+
+`aw-brainstorm` should not create a second planning file system or revive any legacy non-deterministic planning path.
+
+If it needs to persist discovery context, keep it inside:
+
+- `.aw_docs/features/<feature_slug>/state.json`
+
+or pass it directly into `aw-plan`.
+
+`aw-plan` remains responsible for canonical planning artifacts such as `prd.md`, `design.md`, `spec.md`, and `tasks.md`.
+
+## Platform Context
+
+| Domain Signal | Platform Skills to Load |
+|---|---|
+| API, controller, endpoint | `api-design`, `platform-services:development`, `platform-services:rate-limiting` |
+| Vue, component, UI | `platform-frontend:vue-development`, `platform-frontend:highrise-compliance`, `platform-design:system` |
+| Database, schema, collection | `platform-data:mongodb-patterns`, `platform-data:firestore-patterns` |
+| Auth, IAM, permissions | `platform-services:authentication-authorization` |
+| Deploy, k8s, helm | `platform-infra:kubernetes-workloads`, `platform-infra:jenkins-pipelines` |
+| Worker, queue, pub/sub | `platform-services:worker-patterns`, `platform-infra:pubsub-messaging` |
+| Multi-tenant, locationId | `platform-services:multi-tenancy` |
+
+## Anti-Patterns
+
+- jumping straight to code or implementation planning without resolving the real decision
+- batching many questions at once
+- presenting only one approach when meaningful alternatives exist
+- writing final planning artifacts directly instead of routing through `aw-plan`
+- reopening brainstorming after the direction is already clear
+- ignoring platform rules, repo context, or known constraints
+
+## Next Skill
+
+After the direction is approved, invoke `aw-plan`, which should then invoke `aw-spec`.

package/skills/aw-build/SKILL.md

@@ -0,0 +1,189 @@
+---
+name: aw-build
+description: Build approved work from `.aw_docs/features/<feature_slug>/` artifacts in thin, reversible increments with org-standard validation and handoff discipline.
+trigger: User requests implementation of approved work, or a compatible `/aw:execute` request needs to route to the canonical build stage.
+---
+
+# AW Build
+
+## Overview
+
+`aw-build` owns implementation only.
+It turns approved work into the smallest correct code, config, docs, or migration changes, continues through the full approved build scope in thin slices, and then hands off to test or review instead of self-certifying success.
+
+## When to Use
+
+- approved implementation artifacts already exist
+- the request is to code, configure, migrate, or document an approved change
+- a bug was already investigated and now needs a concrete fix
+- a legacy `/aw:execute` request arrives
+
+Do not use for vague ideation, unclear bugs, or release-only work.
+
+## Workflow
+
+1. Intake the approved inputs.
+   Load `spec.md`, `tasks.md`, and any relevant design or PRD context.
+   If the plan has a critical gap, route back to `aw-plan`.
+2. Select the smallest correct build mode.
+   Choose `code`, `infra`, `docs`, `migration`, or `config`.
+3. Resolve the execution topology before editing.
+   Default to sequential slice execution.
+   Use bounded parallel fan-out only when the approved plan marks disjoint `parallel_candidate` slices, names `parallel_group` and `parallel_write_scope`, and supplies or accepts the default `max_parallel_subagents: 3`.
+4. Slice the work before editing.
+   Use `../../references/build-increments.md` to keep changes thin, reversible, and rollback-friendly.
+   For multi-file or high-risk work, load `incremental-implementation`.
+5. Build one slice or one bounded parallel wave at a time.
+   For any slice that changes observable behavior, fixes a bug, or refactors live behavior, load `tdd-guide` and require explicit RED-GREEN-REFACTOR (RED -> GREEN -> REFACTOR).
+   For config, docs, infra, migration, or other non-behavior slices where test-first is not meaningful, record the best pre-change proof available before editing and the focused post-change validation that will prove the slice.
+   During implementation, prefer the simplest change that fits existing patterns.
+   Avoid speculative abstractions, unnecessary branching, and adjacent cleanup outside the approved slice.
+   When the working code feels heavier than necessary, load `code-simplification` before save-pointing the slice.
+   Use `../../references/testing-patterns.md` when test structure needs support.
+6. Review and simplify the completed slice before advancing.
+   Once a slice is green, run a focused chunk review before advancing.
+   Prefer the language or runtime reviewer agent when one matches the touched code (`typescript-reviewer`, `python-reviewer`, `java-reviewer`, `kotlin-reviewer`, `go-reviewer`, `rust-reviewer`, `cpp-reviewer`, or `flutter-reviewer`).
+   Otherwise use `code-reviewer`.
+   Use the `aw-review` axes for chunk review scope: correctness, readability and simplicity, architecture, security, and performance.
+   Keep this review scoped to the current slice rather than treating it as a full stage handoff.
+   Use `../../references/review-findings-severity.md` for chunk findings language.
+   For readability and maintainability concerns, load `code-simplification`.
+   Fix blocking findings inside the same slice before moving on.
+   Advisory findings may be deferred only when written down in `execution.md` and `state.json` with explicit rationale.
+   Before declaring the slice complete, check whether code can be deleted, branches reduced, names clarified, or existing patterns reused without broadening scope.
+7. Continue through the approved build scope.
+   Keep moving slice-to-slice until the approved implementation scope for this stage is complete or the next unsatisfied need is no longer build.
+   Do not stop after the first passing slice if more approved build slices remain.
+   Only pause early for an explicit blocker, a requested checkpoint, or a real approval boundary already present in the artifacts.
+8. Apply org standards during the slice.
+   Respect `.aw_rules`, relevant platform playbooks, and the resolved GHL baseline.
+   When context quality or scope focus is degrading, load `context-engineering`.
+   For frontend work, load `../../references/frontend-quality-checklist.md`.
+   For non-trivial UI work, load `frontend-ui-engineering`.
+   For interface changes, load `../../references/interface-stability.md` and `api-and-interface-design`.
+   For deprecation, removal, or migration slices, load `deprecation-and-migration`.
+9. Record evidence and boundaries.
+   Note what changed, what did not change, which slices or parallel waves are complete, which build slices still remain, and which checks were run.
+   For each completed slice, note that focused review ran and what simplification was applied or intentionally deferred.
+   When the approved tasks are grouped into phases, record phase transitions explicitly: which phase completed, which phase is now active, and what remains in later phases.
+   Use `../../references/git-save-points.md` when the work needs explicit save-point discipline.
+   For meaningful completed slices, create focused save-point commits.
+   For non-trivial commit boundaries, branch hygiene, or worktree isolation, load `git-workflow-and-versioning`.
+10. Hand off cleanly.
+   If build scope is complete, route to `aw-test` for QA proof or `aw-review` when the work needs findings, governance, or readiness decisions.
+   If the work is blocked mid-build, name the blocker, the last completed slice, and the smallest safe next action instead of stopping with a vague pause.
+
+## Completion Contract
+
+Build is complete only when one of these is true:
+
+- the approved implementation scope for the current stage is complete and written down
+- a blocker prevents the next approved build slice and that blocker is named explicitly
+
+A successful slice is a checkpoint, not an automatic terminal state.
+
+Every build handoff must make these things obvious:
+
+- what approved inputs were used
+- which phases were completed, if the approved plan used phases
+- which phase is current or next, if phased execution is still in flight
+- which slices were completed
+- whether work ran sequentially or in bounded parallel waves
+- what pre-change proof was used for each completed slice
+- which build slices remain, if any
+- which validation was run
+- which reviewer agent reviewed each completed slice
+- whether focused chunk review ran before advancing
+- what simplification was applied per completed slice
+- which findings were fixed versus explicitly deferred
+- which save-point commits were created
+- which exact next command should run next
+
+Meaningful completed build slices must create save-point commits in git-capable workspaces.
+If a slice cannot support a clean save-point commit, that is a planning problem and the slice should usually be merged with its dependent follow-up before build treats it as complete.
+Parallel build fan-out must stay within the planned `max_parallel_subagents` cap, which defaults to `3` when the plan does not justify another number.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "This is small enough to do in one big patch." | Small tasks still benefit from thin slices and explicit validation. |
+| "I'll add tests after the code is working." | If the behavior is testable, failure-first proof should lead the change. |
+| "I'll simplify after all chunks are done." | Complexity compounds across slices; simplify while the current chunk is still local and reviewable. |
+| "I'll review the whole thing at the end." | Focused chunk review catches correctness and complexity issues before they spread into later slices. |
+| "Frontend changes don't need special handling." | Responsive behavior, accessibility, and design-system compliance are part of the work. |
+| "I can just clean up adjacent code too." | Scope creep makes rollback and review harder. |
+
+## Red Flags
+
+- a slice touches unrelated files
+- a passing slice is treated as stage completion even though planned build work remains
+- tests are hand-waved instead of run or explicitly declared unavailable
+- a slice advances without a focused review after reaching green
+- complexity is knowingly deferred into later chunks without an explicit reason
+- the diff is large enough that rollback is unclear
+- interface changes are made without boundary validation
+- bugfix code appears before the failing signal is concrete
+
+## State File
+
+`state.json` should record at least:
+
+- `feature_slug`
+- `stage: "build"`
+- `mode`
+- `status`
+- written artifacts
+- inputs used
+- files changed
+- `completed_phases` when the approved plan used phases
+- `current_phase` for the active or next build phase when phase sequencing exists
+- completed slices
+- remaining slices
+- parallel execution mode and cap when parallel build fan-out was used
+- pre-change proof notes
+- validation commands
+- reviewer agents used
+- slice review notes
+- blocking findings
+- deferred findings
+- simplification notes
+- `save_point_commits`
+- blockers or concerns
+- recommended next commands
+
+## Verification
+
+Before leaving build, confirm:
+
+- [ ] the change came from approved inputs or a clearly approved direct technical request
+- [ ] the work was split into thin, reversible increments when non-trivial
+- [ ] behavior-changing slices used explicit RED -> GREEN -> REFACTOR via `tdd-guide`
+- [ ] non-behavior slices recorded pre-change proof and focused post-change validation
+- [ ] each meaningful completed slice reached green before the next slice started
+- [ ] each meaningful completed slice had a focused review with the right reviewer agent before the next slice started
+- [ ] simplification was applied inside the touched scope before save-pointing the slice
+- [ ] the approved build scope is either complete or blocked explicitly
+- [ ] relevant org standards, platform playbooks, and `.aw_rules` were applied
+- [ ] parallel execution, if used, stayed within the planned worker cap and disjoint write scopes
+- [ ] phased plans, if used, recorded phase completion plus the next phase transition
+- [ ] meaningful completed slices produced recorded save-point commits
+- [ ] `execution.md` and `state.json` are updated
+
+## Final Output Shape
+
+Always end with:
+
+- `Mode`
+- `Approved Inputs`
+- `Parallelization`
+- `Phase Progress`
+- `Completed Slices`
+- `Remaining Build Scope`
+- `Changes`
+- `Validation`
+- `Chunk Reviews`
+- `Simplification`
+- `Save Points`
+- `Blockers`
+- `Next`

package/skills/aw-build/evals/build-stage-cases.json

@@ -0,0 +1,28 @@
+{
+  "cases": [
+    {
+      "id": "backend-approved-slice",
+      "request": "Implement the approved Communities moderation API change in thin slices.",
+      "buildMode": "code",
+      "expectedFollowupStages": ["aw-test", "aw-review"],
+      "expectedArtifacts": ["execution.md", "state.json"],
+      "expectedSupportingSkills": ["platform-services:development", "incremental-implementation"]
+    },
+    {
+      "id": "frontend-ui-slice",
+      "request": "Take the approved Communities feed MFA UI change forward and update the app accordingly.",
+      "buildMode": "code",
+      "expectedFollowupStages": ["aw-test", "aw-review"],
+      "expectedArtifacts": ["execution.md", "state.json"],
+      "expectedSupportingSkills": ["platform-frontend:vue-development", "highrise-ui-governance", "frontend-ui-engineering"]
+    },
+    {
+      "id": "migration-slice",
+      "request": "Apply the approved migration slice without widening scope.",
+      "buildMode": "migration",
+      "expectedFollowupStages": ["aw-test", "aw-review"],
+      "expectedArtifacts": ["execution.md", "state.json"],
+      "expectedSupportingSkills": ["platform-data:migration-patterns", "deprecation-and-migration"]
+    }
+  ]
+}

package/skills/aw-debug/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: aw-debug
+description: Internal debugging helper that drives reproduction, root-cause isolation, confirming probes, and guarded repair.
+trigger: Internal only. Invoked by aw-investigate, aw-build, aw-test, or aw-review when failure remains uncertain.
+---
+
+# AW Debug
+
+## Overview
+
+`aw-debug` is the internal debugging playbook.
+It keeps bug work from devolving into guess-and-patch behavior.
+
+## When to Use
+
+- the failure is real but the cause is still uncertain
+- multiple fix attempts already happened
+- alerts or regressions need a concrete next probe
+
+## Workflow
+
+1. Capture a reproduction or equivalent failure signal.
+2. Define expected vs actual behavior.
+3. Identify the smallest plausible fault surface.
+4. Run the next confirming probe.
+5. Update the hypothesis based on evidence, not intuition.
+6. Only then hand back to investigation, build, test, or review.
+
+Use `../../references/debug-triage.md` for the stable checklist.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I already know the likely fix." | Likely is not confirmed. |
+| "Another patch is faster than another probe." | Repeated speculative fixes usually waste more time. |
+
+## Red Flags
+
+- third fix attempt without new evidence
+- patch size grows while root cause stays vague
+- reproduction disappears and the team starts guessing from memory
+
+## Verification
+
+- [ ] a reproduction or equivalent failure signal exists
+- [ ] expected vs actual behavior is explicit
+- [ ] the next probe or likely cause is evidence-backed
+- [ ] no speculative repair is treated as root-cause understanding

package/skills/aw-deploy/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: aw-deploy
+description: Turn reviewed work into one requested release outcome with explicit GHL provider resolution and deterministic release artifacts.
+trigger: Test and review passed and the user requests PR creation, branch handoff, or deployment.
+---
+
+# AW Deploy
+
+## Overview
+
+`aw-deploy` owns release action only.
+It should not reopen planning or implementation.
+
+## When to Use
+
+- reviewed work needs a PR
+- reviewed work should remain on a branch
+- reviewed work should go to staging or production
+
+Do not use for launch discipline or end-to-end orchestration.
+
+## Workflow
+
+1. Confirm the evidence gate.
+   The required QA and review outputs must exist.
+2. Select one release path.
+   PR, branch, staging, or production.
+3. Resolve the org-standard mechanism.
+   Use the repo archetype and resolved baseline profile to choose provider and mechanism.
+   Load `ci-cd-and-automation` for gate ordering, preview/deploy automation, and rollback-aware pipeline expectations.
+   For releases that retire or migrate legacy paths, load `deprecation-and-migration`.
+4. Execute or record the blocker.
+   Complete the selected release action end-to-end for the chosen mode.
+   External failure should still yield deterministic `release.md` evidence.
+5. Hand off to `aw-ship` when requested.
+   Use `aw-ship` for rollout safety, rollback readiness, and closeout.
+
+## Completion Contract
+
+Deploy is complete only when one of these is true:
+
+- the selected release action finished and was recorded clearly
+- the release action is blocked and the blocker is recorded clearly
+
+Every deploy handoff must make these things obvious:
+
+- which release mode was selected
+- which provider and mechanism were resolved
+- what evidence or links were produced
+- what rollback path is currently known
+- which exact next command should run next
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "Deploy can also handle launch closeout." | Release action and launch discipline are related but distinct. |
+| "I'll just guess the staging mechanism." | Unknown deployment config must fail closed. |
+
+## Red Flags
+
+- deploy runs without clear test and review evidence
+- provider or mechanism is guessed
+- deploy silently turns into release orchestration
+
+## State File
+
+`state.json` should record at least:
+
+- `feature_slug`
+- `stage: "deploy"`
+- `mode`
+- `status`
+- written artifacts
+- provider
+- resolved mechanism
+- build or release links
+- execution evidence
+- rollback path
+- blockers
+- recommended next commands
+
+## Verification
+
+- [ ] one release action was selected explicitly
+- [ ] provider and mechanism came from repo archetype and baseline resolution
+- [ ] `release.md` and `state.json` are updated
+- [ ] handoff to `aw-ship` is clear when launch discipline is still needed
+
+## Final Output Shape
+
+Always end with:
+
+- `Selected Mode`
+- `Provider`
+- `Resolved Mechanism`
+- `Build Links`
+- `Execution Evidence`
+- `Rollback Path`
+- `Outcome`
+- `Next`

package/skills/aw-deploy/evals/deploy-stage-cases.json

@@ -0,0 +1,32 @@
+{
+  "cases": [
+    {
+      "id": "pr-creation",
+      "request": "Create a PR for this reviewed work.",
+      "releasePath": "pr",
+      "expectedArtifacts": ["release.md", "state.json"],
+      "expectedSupportingSkills": ["ci-cd-and-automation"]
+    },
+    {
+      "id": "service-staging",
+      "request": "Deploy this verified Communities moderation API service to staging.",
+      "releasePath": "staging",
+      "expectedArtifacts": ["release.md", "state.json"],
+      "expectedSupportingSkills": ["platform-infra:staging-deploy", "platform-infra:deployment-strategies", "platform-infra:production-readiness"]
+    },
+    {
+      "id": "mfa-staging",
+      "request": "Deploy this verified Communities feed MFA to staging.",
+      "releasePath": "staging",
+      "expectedArtifacts": ["release.md", "state.json"],
+      "expectedSupportingSkills": ["deploy-versioned-mfa", "platform-infra:staging-deploy", "platform-infra:production-readiness"]
+    },
+    {
+      "id": "release-automation",
+      "request": "Set up the release automation, preview gates, and rollback path for this service deployment.",
+      "releasePath": "deployment-automation",
+      "expectedArtifacts": ["release.md", "state.json"],
+      "expectedSupportingSkills": ["ci-cd-and-automation"]
+    }
+  ]
+}

package/skills/aw-execute/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: aw-execute
+description: Compatibility skill for the older execute stage. Follow aw-build as the canonical implementation behavior.
+trigger: Internal compatibility only. Invoked when older docs, habits, or commands still reference aw-execute.
+---
+
+# AW Execute
+
+## Overview
+
+`aw-execute` is a compatibility layer.
+The canonical implementation stage is now `aw-build`.
+
+## When to Use
+
+- a legacy `/aw:execute` request arrives
+- an older doc or test still refers to execute semantics
+
+Do not create a separate execute-specific workflow.
+
+## Workflow
+
+1. Route to `aw-build`.
+2. Preserve the same artifact discipline:
+   - `execution.md`
+   - `state.json`
+3. Preserve the same continuation and downstream handoff:
+   - complete the current build scope or block it explicitly
+   - `aw-test`
+   - `aw-review`
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "Execute can stay different from build for now." | Dual semantics create drift and confusion. |
+
+## Red Flags
+
+- execute-specific behavior diverges from build
+- old naming is used to bypass the new stage model
+
+## Verification
+
+- [ ] the request was routed to `aw-build`
+- [ ] the current build scope was completed or blocked explicitly
+- [ ] artifact and handoff behavior stayed consistent with the canonical build stage

package/skills/aw-execute/references/mode-code.md

@@ -0,0 +1,47 @@
+# Mode: Code — TDD Execution
+
+## Iron Law
+
+> **Every [code] task follows TDD. No exceptions. No rationalizations.**
+
+## Red-Green-Refactor Cycle
+
+### 1. RED — Write the test first
+
+- Write a failing test that describes the expected behavior.
+- Run the test. It MUST fail. If it passes, the test is wrong or the behavior already exists.
+- The test defines the contract. Implementation serves the test.
+
+### 2. GREEN — Write minimal code to pass
+
+- Write the simplest implementation that makes the test pass.
+- Do not add features, optimizations, or "nice-to-haves" at this stage.
+- Run the test. It MUST pass.
+
+### 3. REFACTOR — Clean up without changing behavior
+
+- Extract helpers, rename variables, reduce duplication.
+- Run tests after every refactor step. They MUST still pass.
+- Stop refactoring when the code is clean and readable.
+
+## Rules
+
+- **Test file per source file** — `feature.service.ts` gets `feature.service.spec.ts`.
+- **Descriptive test names** — `it('should return empty array when no features exist for locationId')`.
+- **No mocking internals** — Mock boundaries (HTTP, database, external services), not internal functions.
+- **Coverage gate** — 80% minimum. Check with `npm run test:cov` or equivalent.
+- **No skipped tests** — `it.skip` and `xit` are not allowed in committed code.
+- **Platform logger** — Use `@platform-core/logger`, never `console.*`.
+- **DTO validation** — Every `@Body()` parameter has a class-validator DTO.
+- **Error handling** — Every async call has explicit error handling.
+
+## Rationalization Table
+
+| Rationalization | Why It Is Wrong |
+|---|---|
+| "I'll write tests after" | You will not. And the code will be shaped for implementation, not testability. |
+| "This is too simple to test" | Simple code breaks too. The test documents the contract. |
+| "Tests slow me down" | Tests slow you down now. Bugs slow you down forever. |
+| "I'll just test the happy path" | Errors happen on unhappy paths. Test both. |
+| "The integration test covers it" | Integration tests are slow and broad. Unit tests are fast and precise. |
+| "I know this works" | Prove it. Run the test. |

package/skills/aw-execute/references/mode-docs.md

@@ -0,0 +1,28 @@
+# Mode: Docs — Write, Review, Commit
+
+## Process
+
+### 1. Write
+
+- Write the documentation in the appropriate location.
+- Follow existing documentation style and format in the repo.
+- Include code examples where they aid understanding.
+- Keep language clear, concise, and direct.
+
+### 2. Self-Review Checklist
+
+Before committing documentation:
+
+- [ ] **Accuracy** — All technical details are correct and verified against the code.
+- [ ] **Completeness** — All public APIs, config options, and workflows are documented.
+- [ ] **Examples** — Code examples compile/run and match current API signatures.
+- [ ] **Links** — All internal links resolve. No broken references.
+- [ ] **Formatting** — Consistent heading levels, code block languages, and list styles.
+- [ ] **No stale content** — Removed or updated references to deprecated features.
+- [ ] **Audience** — Written for the target reader (developer, operator, end user).
+
+### 3. Commit
+
+- Commit documentation changes with `docs:` prefix.
+- If docs accompany code changes, include in the same PR.
+- Update the table of contents or index if one exists.