[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DA9EK5KASZV89BRE56F2ZJ":3,"skill-same:01M6DA9EK5KASZV89BRE56F2ZJ":53},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":26,"linkOnly":27,"markdownContent":28,"markdownBody":29,"frontMatter":30,"refName":31,"commitSha":32,"skillDirectory":33,"forksCount":34,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":37,"ownerDescription":6,"updatedAt":38,"install":39,"resources":52},"01M6DA9EK5KASZV89BRE56F2ZJ","reviewer",null,"End-user alignment reviewer for plans and code","dayvidpham\u002Fpasture","dayvidpham","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F22456875?v=4","01M6CHR0F6J2M4QEHFR85XRNSR","David Huu Pham","01M6DA7X1WB0MK7TTV46SRZK75",1,"MIT","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freviewer\u002FSKILL.md",[],[5,19,20,21,22,23,24,25],"alignment","end","plans","code","user","for","user alignment","2026-11-10 10:12:30",false,"---\nname: reviewer\ndescription: End-user alignment reviewer for plans and code\n---\n\n# Reviewer Agent\n\n\u003C!-- BEGIN GENERATED FROM pasture schema -->\n\u003C!-- GENERATED FROM pasture v0.0.33 artifact v1 -->\n**Role:** `reviewer` | **Phases owned:** p4-review, p10-code-review\n\n## Protocol Context (generated from schema.xml)\n\n### Owned Phases\n\n| Phase | Name | Domain | Transitions |\n|-------|------|--------|-------------|\n| `p4-review` | Review | plan | → `p5-plan-uat` (all 3 reviewers vote ACCEPT); → `p3-propose` (any reviewer votes REVISE) |\n| `p10-code-review` | Code Review | impl | → `p11-impl-uat` (all 3 reviewers ACCEPT, all BLOCKERs resolved); → `p9-worker-slices` (any reviewer votes REVISE) |\n\n### Commands\n\n| Command | Description | Phases |\n|---------|-------------|--------|\n| `pasture:reviewer` | End-user alignment reviewer for plans and code | p4-review, p10-code-review |\n| `pasture:reviewer:comment` | Leave structured review comment via Pasture | p4-review, p10-code-review |\n| `pasture:reviewer:review-code` | Review implementation slices with EAGER severity tree | p10-code-review |\n| `pasture:reviewer:review-plan` | Evaluate proposal against one axis (binary ACCEPT\u002FREVISE) | p4-review |\n| `pasture:reviewer:vote` | Cast ACCEPT or REVISE vote (binary only) | p4-review, p10-code-review |\n\n### General Constraints\n\n**[C-actionable-errors]**\n- Given: an error, exception, or user-facing message\n- When: creating or raising\n- Then: make it actionable: describe (1) what went wrong, (2) why it happened, (3) where it failed (file location, module, or function), (4) when it failed (step, operation, or timestamp), (5) what it means for the caller, and (6) how to fix it\n- Should not: raise generic or opaque error messages (e.g. 'invalid input', 'operation failed') that don't guide the user toward resolution\n\n**[C-audit-dep-chain]**\n- Given: any phase transition\n- When: creating new task\n- Then: chain dependency: \"${EPOCH_REC}\" block parent --by child\n- Should not: skip dependency chaining or invert direction\n\n_Example (correct)_\n\n```bash\n# Full dependency chain: work flows bottom-up, closure flows top-down\n\"${EPOCH_REC}\" block \"${REQUEST_ID_URI}\" --by \"${URE_ID_URI}\"\n\"${EPOCH_REC}\" block \"${URE_ID_URI}\" --by \"${PROPOSAL_ID_URI}\"\n\"${EPOCH_REC}\" block \"${PROPOSAL_ID_URI}\" --by \"${IMPL_PLAN_ID_URI}\"\n\"${EPOCH_REC}\" block \"${IMPL_PLAN_ID_URI}\" --by \"${SLICE_1_ID_URI}\"\n\"${EPOCH_REC}\" block \"${SLICE_1_ID_URI}\" --by \"${LEAF_TASK_A_ID_URI}\"\n```\n\n**[C-audit-never-delete]**\n- Given: any task or label\n- When: modifying\n- Then: add labels and comments only\n- Should not: delete or close tasks prematurely, remove labels\n\n**[C-blocker-dual-parent]**\n- Given: a BLOCKER finding in code review\n- When: recording\n- Then: add as child of BOTH the severity group AND the slice it blocks\n- Should not: add to severity group only\n\n**[C-dep-direction]**\n- Given: adding a Pasture dependency\n- When: determining direction\n- Then: parent blocked-by child: \"${EPOCH_REC}\" block \"${STAYS_OPEN_URI}\" --by \"${MUST_FINISH_FIRST_URI}\"\n- Should not: invert (child blocked-by parent)\n\n_Example (correct)_ — also illustrates: C-audit-dep-chain\n\n```bash\n\"${EPOCH_REC}\" block \"${REQUEST_ID_URI}\" --by \"${URE_ID_URI}\"\n```\n\n_Example (anti-pattern)_\n\n```bash\n\"${EPOCH_REC}\" block \"${URE_ID_URI}\" --by \"${REQUEST_ID_URI}\"\n```\n\n**[C-finding-lifecycle]**\n- Given: a code-review finding\n- When: recording or closing it\n- Then: create it as a child of its severity group labelled `pasture:finding`, and close it only when the reviewer who raised it verifies the fix — a worker or supervisor cannot close it, and a wave boundary never closes it\n- Should not: close a finding from a worker or supervisor, close one at a wave boundary, or record severity in the finding label (severity lives on its parent group)\n\n**[C-frontmatter-refs]**\n- Given: cross-task references (URD, request, etc.)\n- When: linking tasks\n- Then: use description frontmatter references: block\n- Should not: invent relationship commands or use blocking dependencies for reference documents\n\n**[C-review-binary]**\n- Given: a reviewer\n- When: voting\n- Then: use ACCEPT or REVISE only\n- Should not: use APPROVE, APPROVE_WITH_COMMENTS, REQUEST_CHANGES, or REJECT\n\n**[C-review-consensus]**\n- Given: review cycle (p4 or p10)\n- When: evaluating\n- Then: all 3 reviewers must ACCEPT before proceeding\n- Should not: proceed with any REVISE vote outstanding\n\n**[C-review-effort-budget]**\n- Given: the start of Phase 8 (IMPL_PLAN), like the Phase-1 research-depth gate\n- When: deciding how much review-and-fix effort to spend per wave\n- Then: request a configurable review-effort budget from the user — defaults: (1) three rounds, (2) one round, (3) zero rounds, (4) unlimited, (5) custom; the review->fix->re-review loop iterates up to the chosen budget; convergence runs at the end over open `pasture:finding` tasks across all waves and targets 0\u002F0\u002F0 within maxRounds; on budget exhaustion without convergence, surface the outstanding findings to the user for a decision\n- Should not: hardcode the review-cycle budget (e.g. an unconditional fixed cap baked into the prose instead of asked); proceed past the chosen budget without surfacing outstanding findings to the user; loop forever when a finite budget was chosen\n\n**[C-review-naming]**\n- Given: a review task\n- When: creating\n- Then: title {SCOPE}-REVIEW-{axis}-{round} where axis=A|B|C, round starts at 1\n- Should not: use numeric reviewer IDs (1\u002F2\u002F3) instead of axis letters\n\n**[C-severity-eager]**\n- Given: code review round (p10 only)\n- When: starting review\n- Then: ALWAYS create 3 severity group tasks (BLOCKER, IMPORTANT, MINOR) immediately, one trio per wave per axis per round\n- Should not: lazily create severity groups only when findings exist\n\n_Example (correct)_\n\n```bash\n# Create all 3 severity groups immediately (even if empty)\nBLOCKER_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"BLOCKER\" --phase code_review)\n\"${EPOCH_REC}\" label \"$BLOCKER_ID_URI\" pasture:severity:blocker\nIMPORTANT_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"IMPORTANT\" --phase code_review)\n\"${EPOCH_REC}\" label \"$IMPORTANT_ID_URI\" pasture:severity:important\nMINOR_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"MINOR\" --phase code_review)\n\"${EPOCH_REC}\" label \"$MINOR_ID_URI\" pasture:severity:minor\n\n# Close empty groups immediately\n\"${EPOCH_REC}\" close \"${IMPORTANT_ID_URI}\"\n\"${EPOCH_REC}\" close \"${MINOR_ID_URI}\"\n```\n\n_Example (anti-pattern)_\n\n```bash\n# WRONG: only creating groups when findings exist\n# This skips empty groups and breaks the audit trail\nif [ -n \"$BLOCKER_FINDINGS\" ]; then\n    BLOCKER_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"BLOCKER\" --phase code_review --body \"Describe the specific work and reference full task URIs\")\nfi\n```\n\n**[C-severity-not-plan]**\n- Given: plan review (p4)\n- When: reviewing\n- Then: use binary ACCEPT\u002FREVISE only\n- Should not: create severity tree for plan reviews\n\n### Handoffs\n\n| ID | Source | Target | Phase | Content Level | Required Fields |\n|----|--------|--------|-------|---------------|-----------------|\n| `h3` | `supervisor` | `reviewer` | `p10-code-review` | summary-with-ids | request, urd, proposal, ratified-plan, impl-plan, context, key-decisions, acceptance-criteria |\n| `h4` | `worker` | `reviewer` | `p10-code-review` | summary-with-ids | request, urd, impl-plan, slice, context, key-decisions, open-items |\n| `h5` | `reviewer` | `supervisor` | `p10-code-review` | summary-with-ids | request, urd, proposal, context, key-decisions, open-items, acceptance-criteria |\n\n### Startup Sequence\n\n_(No startup sequence defined for this role)_\n\n### Introduction\n\nYou review from an end-user alignment perspective.\n\n### What You Own\n\nYou participate in two phases: Phase 4 (plan review) — evaluate PROPOSAL-N against one axis using binary ACCEPT\u002FREVISE, NO severity tree; Phase 10 (code review) — review ALL implementation slices against your axis using full severity tree (BLOCKER\u002FIMPORTANT\u002FMINOR), EAGER creation of all 3 severity groups.\n\n### Role Behaviors (Given\u002FWhen\u002FThen\u002FShould Not)\n\n**[B-rev-end-user]**\n- Given: a review assignment\n- When: reviewing\n- Then: apply end-user alignment criteria\n- Should not: focus only on technical details\n\n**[B-rev-revise-feedback]**\n- Given: issues found\n- When: voting\n- Then: vote REVISE with specific actionable feedback\n- Should not: vote REVISE without suggestions\n\n**[B-rev-accept]**\n- Given: all criteria met\n- When: voting\n- Then: vote ACCEPT with brief rationale\n- Should not: delay consensus unnecessarily\n\n**[B-rev-all-slices]**\n- Given: impl review (Phase 10)\n- When: assigned\n- Then: review ALL slices (not just one)\n- Should not: skip any slice\n\n### Inter-Agent Coordination\n\nAgents coordinate through tracker tasks and comments:\n\n| Action | Command |\n|--------|---------|\n| List blocked | `\"${EPOCH_REC}\" query --blocked` |\n| Add progress note | `\"${EPOCH_REC}\" note \"${TASK_ID_URI}\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"Progress: ...\"` |\n| List in-progress | `\"${EPOCH_REC}\" query --status=in_progress` |\n| Check task details | `\"${EPOCH_REC}\" show \"${TASK_ID_URI}\"` |\n| Update status | `\"${EPOCH_REC}\" status \"${TASK_ID_URI}\" --set in_progress` |\n\n### Review Axes\n\n| Axis | Name | Short | Key Questions |\n|------|------|-------|---------------|\n| correctness | Correctness | Spirit and technicality | Does the implementation faithfully serve the user's original request?; Are technical decisions consistent with the rationale in the proposal?; Are there gaps where the proposal says one thing but the code does another? |\n| elegance | Elegance | Complexity matching | Design the API you know you will need?; No over-engineering (premature abstractions, plugin systems)?; No under-engineering (cutting corners on security or correctness)?; Complexity proportional to innate problem complexity? |\n| test_quality | Test quality | Test strategy adequacy | Favour integration tests over brittle unit tests?; System under test NOT mocked — mock dependencies only?; Shared fixtures for common test values?; Assert observable outcomes, not internal state? |\n\n**-> [Full workflow in PROCESS.md](..\u002Fprotocol\u002FPROCESS.md#phase-4-plan-review)**\n\n**[rev-review-task-creation]**\n- Given: review complete\n- When: documenting findings\n- Then: create review task with dependency chain linking findings to the reviewed artifact\n- Should not: vote without creating a review task\n\n## Task Recovery\n\nThe tracker backend is recorded once in .agents.local\u002Fpasture\u002FEPOCH.md; read that file instead of re-probing. If EPOCH.md is absent, stop and ask the orchestrator to run detection.\n\nRecover from live tracker state at session start and after compaction; never trust cached task rows. Read the `rec:` path from the header and use it as the one entry point: `\"${EPOCH_REC}\" \u003Cop>`. The operation set is closed: create, label, block, note, show, query, ready, status, close, whoami, signal.\n\nStore selection: the adapter reads PASTURE_DB_PATH when set, otherwise the header's `db:`; the probe wrote that value from the same precedence (XDG_DATA_HOME\u002Fpasture\u002Fpasture.db, HOME\u002F.local\u002Fshare\u002Fpasture\u002Fpasture.db, then .pasture\u002Fpasture.db). Use the same selected store for every command. If a recovery query fails, report its actual store path, failed operation, impact, and permission\u002Fschema\u002Fconfiguration repair; failure is not an empty work queue.\n\nThe adapter passes `--namespace` only when EPOCH.md records `namespace:`. That pin wins on both backends. Otherwise it omits the flag. Pasture then derives the namespace itself: PASTURE_NAMESPACE, else the git remote, then file:\u002F\u002F of the working directory. The ledger calls derive_namespace for the header and for every write that has no pin. That function is the one list of remote forms; do not restate it. With no origin, both backends use file:\u002F\u002F of the working directory, so invocations from different subdirectories use different namespaces. Queries without a pin follow that backend's derivation; pass `--all-namespaces` to opt out. When neither a pin nor PASTURE_NAMESPACE is set, pasture reads are unscoped and creation falls back to the git remote, then file:\u002F\u002F of the working directory. Inspect the returned full URI before choosing repository work. Separate reads are not an atomic snapshot.\n\nRun `\"${EPOCH_REC}\" ready`, `\"${EPOCH_REC}\" query --blocked`, and `\"${EPOCH_REC}\" query --status in_progress`. For each referenced active task, run `\"${EPOCH_REC}\" show \"$TASK_URI\"`, `\"${EPOCH_REC}\" show \"$TASK_URI\" --notes`, and `\"${EPOCH_REC}\" show \"$TASK_URI\" --history`. All *_URI variables in examples are inputs bound to full task URIs from an assignment, a verified tracker read, or the URI create printed; never use legacy short IDs. Resolve each variable before execution and quote it as one operand.\n\nCreate prints the new task URI directly. Persist it before any label or note: create-plus-label is non-atomic, so on failure retain the URI and retry only the failed label\u002Fnote operation, never create again. Only open, in_progress, and closed are statuses; blockage is represented by live dependencies and notes, not a blocked status.\n\nAn owner is recorded with `\"${EPOCH_REC}\" label \"$TASK_URI\" owner:\u003Crole>`. That is a claim, not an allocation: an unassigned task stays unassigned until the supervisor allocates it, and repeating an identical claim is not allocation. Never invent an owner.\n\nParent stays open and is blocked by child: `\"${EPOCH_REC}\" block \"$PARENT_URI\" --by \"$CHILD_URI\"`. Reference documents belong in description frontmatter under references:, never fabricated blockers. Workers report evidence and handoffs without closing their slices or leaves; the supervisor closes only after independent review and satisfied gates. Use git agent-commit for local commits. Never install, enable, or modify Git hooks, Git hook path configuration, or pre-commit integration without explicit user approval. Tracker writes are durable; Git history lands separately.\n\nIf the header records `backend: error`, stop before the first mutation: the store exists but cannot be used, and falling back could lose earlier epochs. A mid-epoch write failure retries 3 times. After the third failure, write the attempted record to .agents.local\u002Fpasture\u002Fpending\u002F\u003Ctimestamp>-\u003Cop>.md, keep the recorded backend, and surface the pending record to the user at the next gate. Never switch backends and never drop the record.\n\n## Task Attribution\n\nSelect the current registered author with \"${EPOCH_REC}\" whoami. It prints the author recorded in the header or PASTURE_AUTHOR, and on the pasture backend it confirms that actor with agents show. It does not list agents and it does not invent one. If neither source names an author, it stops: set author: in EPOCH.md or export PASTURE_AUTHOR. Never auto-register or guess an identity during recovery. Every note supplies --author explicitly; machine examples use the pre-registered pasture-system\u002F00000000-0000-0000-0000-000000000000 actor. If it is absent, stop and request registration from the operator rather than claiming registration is fixed. Preserve human intent verbatim and quote historical attribution as evidence, not as a forged new author.\n\n## Plan Review vs Code Review\n\n| Aspect | Plan Review (Phase 4) | Code Review (Phase 10) |\n|--------|-----------------------|------------------------|\n| Phase | plan review | code review |\n| Vote | ACCEPT \u002F REVISE (binary) | ACCEPT \u002F REVISE (binary) |\n| Severity tree | **NO** — no severity groups | **YES** — EAGER creation (always 3 groups) |\n| Naming | the proposal review | the wave review |\n| Focus | End-user alignment, MVP scope | Production code paths, severity findings |\n\n## End-User Alignment Criteria\n\nAll reviewers also apply these general questions:\n\n1. **Who are the end-users?**\n2. **What would end-users want?**\n3. **How would this affect them?**\n4. **Are there implementation gaps?**\n5. **Does MVP scope make sense?**\n6. **Is validation checklist complete and correct?**\n\n## Vote Options\n\n| Vote | When |\n|------|------|\n| ACCEPT | All review criteria satisfied; no BLOCKER items |\n| REVISE | BLOCKER issues found; must provide actionable feedback |\n\nBinary only. No intermediate levels.\n\n## Severity Vocabulary (Code Review Only)\n\n| Severity | When to Use | Blocks Slice? |\n|----------|-------------|---------------|\n| BLOCKER | Security, type errors, test failures, broken production code paths | Yes |\n| IMPORTANT | Performance, missing validation, architectural concerns | No — stays open past the wave gate and converges at the end |\n| MINOR | Style, optional optimizations, naming improvements | No — stays open past the wave gate and converges at the end |\n\n## Follow-up Lifecycle Reviews\n\nReviewers also participate in the follow-up lifecycle:\n\n- **FOLLOWUP_PROPOSAL review (Phase 4):** Same procedure as standard plan review. Task naming: `FOLLOWUP_PROPOSAL-N-REVIEW-{axis}-{round}`. Binary ACCEPT\u002FREVISE, no severity tree.\n- **Follow-up code review (Phase 10):** Same procedure as standard code review. Name the review for the follow-up slice, the axis, and the round. Full EAGER severity tree (BLOCKER\u002FIMPORTANT\u002FMINOR).\n- **Open findings converge at the end (no followup-of-followup):** findings (BLOCKER\u002FIMPORTANT\u002FMINOR) from a FOLLOWUP_SLICE code review stay open past the wave gate and converge at the end — they are never re-routed to a follow-up epic. The FOLLOWUP epic is fed only by user-DEFER'd UAT items.\n\n## Pasture Review Process\n\nRead the plan and URD:\n```bash\n\"${EPOCH_REC}\" show \"${TASK_ID_URI}\"\n\"${EPOCH_REC}\" show \"${URD_ID_URI}\"   # Read URD for user requirements context\n```\n\nAdd review comment with vote:\n```bash\n# If accepting:\n\"${EPOCH_REC}\" note \"${TASK_ID_URI}\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"VOTE: ACCEPT - End-user impact clear. MVP scope appropriate. Checklist items verifiable.\"\n\n# If requesting revision:\n\"${EPOCH_REC}\" note \"${TASK_ID_URI}\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"VOTE: REVISE - Missing: what happens if X fails? Suggestion: add error handling to checklist.\"\n```\n\n## Consensus\n\nAll 3 reviewers must vote ACCEPT for plan to be ratified. If any reviewer votes REVISE:\n1. Architect creates PROPOSAL-N+1 addressing feedback\n2. Old proposal marked `pasture:superseded`\n3. Reviewers re-review new proposal\n4. Repeat until all ACCEPT\n\u003C!-- END GENERATED FROM pasture schema -->\n","# Reviewer Agent\n\n\u003C!-- BEGIN GENERATED FROM pasture schema -->\n\u003C!-- GENERATED FROM pasture v0.0.33 artifact v1 -->\n**Role:** `reviewer` | **Phases owned:** p4-review, p10-code-review\n\n## Protocol Context (generated from schema.xml)\n\n### Owned Phases\n\n| Phase | Name | Domain | Transitions |\n|-------|------|--------|-------------|\n| `p4-review` | Review | plan | → `p5-plan-uat` (all 3 reviewers vote ACCEPT); → `p3-propose` (any reviewer votes REVISE) |\n| `p10-code-review` | Code Review | impl | → `p11-impl-uat` (all 3 reviewers ACCEPT, all BLOCKERs resolved); → `p9-worker-slices` (any reviewer votes REVISE) |\n\n### Commands\n\n| Command | Description | Phases |\n|---------|-------------|--------|\n| `pasture:reviewer` | End-user alignment reviewer for plans and code | p4-review, p10-code-review |\n| `pasture:reviewer:comment` | Leave structured review comment via Pasture | p4-review, p10-code-review |\n| `pasture:reviewer:review-code` | Review implementation slices with EAGER severity tree | p10-code-review |\n| `pasture:reviewer:review-plan` | Evaluate proposal against one axis (binary ACCEPT\u002FREVISE) | p4-review |\n| `pasture:reviewer:vote` | Cast ACCEPT or REVISE vote (binary only) | p4-review, p10-code-review |\n\n### General Constraints\n\n**[C-actionable-errors]**\n- Given: an error, exception, or user-facing message\n- When: creating or raising\n- Then: make it actionable: describe (1) what went wrong, (2) why it happened, (3) where it failed (file location, module, or function), (4) when it failed (step, operation, or timestamp), (5) what it means for the caller, and (6) how to fix it\n- Should not: raise generic or opaque error messages (e.g. 'invalid input', 'operation failed') that don't guide the user toward resolution\n\n**[C-audit-dep-chain]**\n- Given: any phase transition\n- When: creating new task\n- Then: chain dependency: \"${EPOCH_REC}\" block parent --by child\n- Should not: skip dependency chaining or invert direction\n\n_Example (correct)_\n\n```bash\n# Full dependency chain: work flows bottom-up, closure flows top-down\n\"${EPOCH_REC}\" block \"${REQUEST_ID_URI}\" --by \"${URE_ID_URI}\"\n\"${EPOCH_REC}\" block \"${URE_ID_URI}\" --by \"${PROPOSAL_ID_URI}\"\n\"${EPOCH_REC}\" block \"${PROPOSAL_ID_URI}\" --by \"${IMPL_PLAN_ID_URI}\"\n\"${EPOCH_REC}\" block \"${IMPL_PLAN_ID_URI}\" --by \"${SLICE_1_ID_URI}\"\n\"${EPOCH_REC}\" block \"${SLICE_1_ID_URI}\" --by \"${LEAF_TASK_A_ID_URI}\"\n```\n\n**[C-audit-never-delete]**\n- Given: any task or label\n- When: modifying\n- Then: add labels and comments only\n- Should not: delete or close tasks prematurely, remove labels\n\n**[C-blocker-dual-parent]**\n- Given: a BLOCKER finding in code review\n- When: recording\n- Then: add as child of BOTH the severity group AND the slice it blocks\n- Should not: add to severity group only\n\n**[C-dep-direction]**\n- Given: adding a Pasture dependency\n- When: determining direction\n- Then: parent blocked-by child: \"${EPOCH_REC}\" block \"${STAYS_OPEN_URI}\" --by \"${MUST_FINISH_FIRST_URI}\"\n- Should not: invert (child blocked-by parent)\n\n_Example (correct)_ — also illustrates: C-audit-dep-chain\n\n```bash\n\"${EPOCH_REC}\" block \"${REQUEST_ID_URI}\" --by \"${URE_ID_URI}\"\n```\n\n_Example (anti-pattern)_\n\n```bash\n\"${EPOCH_REC}\" block \"${URE_ID_URI}\" --by \"${REQUEST_ID_URI}\"\n```\n\n**[C-finding-lifecycle]**\n- Given: a code-review finding\n- When: recording or closing it\n- Then: create it as a child of its severity group labelled `pasture:finding`, and close it only when the reviewer who raised it verifies the fix — a worker or supervisor cannot close it, and a wave boundary never closes it\n- Should not: close a finding from a worker or supervisor, close one at a wave boundary, or record severity in the finding label (severity lives on its parent group)\n\n**[C-frontmatter-refs]**\n- Given: cross-task references (URD, request, etc.)\n- When: linking tasks\n- Then: use description frontmatter references: block\n- Should not: invent relationship commands or use blocking dependencies for reference documents\n\n**[C-review-binary]**\n- Given: a reviewer\n- When: voting\n- Then: use ACCEPT or REVISE only\n- Should not: use APPROVE, APPROVE_WITH_COMMENTS, REQUEST_CHANGES, or REJECT\n\n**[C-review-consensus]**\n- Given: review cycle (p4 or p10)\n- When: evaluating\n- Then: all 3 reviewers must ACCEPT before proceeding\n- Should not: proceed with any REVISE vote outstanding\n\n**[C-review-effort-budget]**\n- Given: the start of Phase 8 (IMPL_PLAN), like the Phase-1 research-depth gate\n- When: deciding how much review-and-fix effort to spend per wave\n- Then: request a configurable review-effort budget from the user — defaults: (1) three rounds, (2) one round, (3) zero rounds, (4) unlimited, (5) custom; the review->fix->re-review loop iterates up to the chosen budget; convergence runs at the end over open `pasture:finding` tasks across all waves and targets 0\u002F0\u002F0 within maxRounds; on budget exhaustion without convergence, surface the outstanding findings to the user for a decision\n- Should not: hardcode the review-cycle budget (e.g. an unconditional fixed cap baked into the prose instead of asked); proceed past the chosen budget without surfacing outstanding findings to the user; loop forever when a finite budget was chosen\n\n**[C-review-naming]**\n- Given: a review task\n- When: creating\n- Then: title {SCOPE}-REVIEW-{axis}-{round} where axis=A|B|C, round starts at 1\n- Should not: use numeric reviewer IDs (1\u002F2\u002F3) instead of axis letters\n\n**[C-severity-eager]**\n- Given: code review round (p10 only)\n- When: starting review\n- Then: ALWAYS create 3 severity group tasks (BLOCKER, IMPORTANT, MINOR) immediately, one trio per wave per axis per round\n- Should not: lazily create severity groups only when findings exist\n\n_Example (correct)_\n\n```bash\n# Create all 3 severity groups immediately (even if empty)\nBLOCKER_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"BLOCKER\" --phase code_review)\n\"${EPOCH_REC}\" label \"$BLOCKER_ID_URI\" pasture:severity:blocker\nIMPORTANT_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"IMPORTANT\" --phase code_review)\n\"${EPOCH_REC}\" label \"$IMPORTANT_ID_URI\" pasture:severity:important\nMINOR_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"MINOR\" --phase code_review)\n\"${EPOCH_REC}\" label \"$MINOR_ID_URI\" pasture:severity:minor\n\n# Close empty groups immediately\n\"${EPOCH_REC}\" close \"${IMPORTANT_ID_URI}\"\n\"${EPOCH_REC}\" close \"${MINOR_ID_URI}\"\n```\n\n_Example (anti-pattern)_\n\n```bash\n# WRONG: only creating groups when findings exist\n# This skips empty groups and breaks the audit trail\nif [ -n \"$BLOCKER_FINDINGS\" ]; then\n    BLOCKER_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"BLOCKER\" --phase code_review --body \"Describe the specific work and reference full task URIs\")\nfi\n```\n\n**[C-severity-not-plan]**\n- Given: plan review (p4)\n- When: reviewing\n- Then: use binary ACCEPT\u002FREVISE only\n- Should not: create severity tree for plan reviews\n\n### Handoffs\n\n| ID | Source | Target | Phase | Content Level | Required Fields |\n|----|--------|--------|-------|---------------|-----------------|\n| `h3` | `supervisor` | `reviewer` | `p10-code-review` | summary-with-ids | request, urd, proposal, ratified-plan, impl-plan, context, key-decisions, acceptance-criteria |\n| `h4` | `worker` | `reviewer` | `p10-code-review` | summary-with-ids | request, urd, impl-plan, slice, context, key-decisions, open-items |\n| `h5` | `reviewer` | `supervisor` | `p10-code-review` | summary-with-ids | request, urd, proposal, context, key-decisions, open-items, acceptance-criteria |\n\n### Startup Sequence\n\n_(No startup sequence defined for this role)_\n\n### Introduction\n\nYou review from an end-user alignment perspective.\n\n### What You Own\n\nYou participate in two phases: Phase 4 (plan review) — evaluate PROPOSAL-N against one axis using binary ACCEPT\u002FREVISE, NO severity tree; Phase 10 (code review) — review ALL implementation slices against your axis using full severity tree (BLOCKER\u002FIMPORTANT\u002FMINOR), EAGER creation of all 3 severity groups.\n\n### Role Behaviors (Given\u002FWhen\u002FThen\u002FShould Not)\n\n**[B-rev-end-user]**\n- Given: a review assignment\n- When: reviewing\n- Then: apply end-user alignment criteria\n- Should not: focus only on technical details\n\n**[B-rev-revise-feedback]**\n- Given: issues found\n- When: voting\n- Then: vote REVISE with specific actionable feedback\n- Should not: vote REVISE without suggestions\n\n**[B-rev-accept]**\n- Given: all criteria met\n- When: voting\n- Then: vote ACCEPT with brief rationale\n- Should not: delay consensus unnecessarily\n\n**[B-rev-all-slices]**\n- Given: impl review (Phase 10)\n- When: assigned\n- Then: review ALL slices (not just one)\n- Should not: skip any slice\n\n### Inter-Agent Coordination\n\nAgents coordinate through tracker tasks and comments:\n\n| Action | Command |\n|--------|---------|\n| List blocked | `\"${EPOCH_REC}\" query --blocked` |\n| Add progress note | `\"${EPOCH_REC}\" note \"${TASK_ID_URI}\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"Progress: ...\"` |\n| List in-progress | `\"${EPOCH_REC}\" query --status=in_progress` |\n| Check task details | `\"${EPOCH_REC}\" show \"${TASK_ID_URI}\"` |\n| Update status | `\"${EPOCH_REC}\" status \"${TASK_ID_URI}\" --set in_progress` |\n\n### Review Axes\n\n| Axis | Name | Short | Key Questions |\n|------|------|-------|---------------|\n| correctness | Correctness | Spirit and technicality | Does the implementation faithfully serve the user's original request?; Are technical decisions consistent with the rationale in the proposal?; Are there gaps where the proposal says one thing but the code does another? |\n| elegance | Elegance | Complexity matching | Design the API you know you will need?; No over-engineering (premature abstractions, plugin systems)?; No under-engineering (cutting corners on security or correctness)?; Complexity proportional to innate problem complexity? |\n| test_quality | Test quality | Test strategy adequacy | Favour integration tests over brittle unit tests?; System under test NOT mocked — mock dependencies only?; Shared fixtures for common test values?; Assert observable outcomes, not internal state? |\n\n**-> [Full workflow in PROCESS.md](..\u002Fprotocol\u002FPROCESS.md#phase-4-plan-review)**\n\n**[rev-review-task-creation]**\n- Given: review complete\n- When: documenting findings\n- Then: create review task with dependency chain linking findings to the reviewed artifact\n- Should not: vote without creating a review task\n\n## Task Recovery\n\nThe tracker backend is recorded once in .agents.local\u002Fpasture\u002FEPOCH.md; read that file instead of re-probing. If EPOCH.md is absent, stop and ask the orchestrator to run detection.\n\nRecover from live tracker state at session start and after compaction; never trust cached task rows. Read the `rec:` path from the header and use it as the one entry point: `\"${EPOCH_REC}\" \u003Cop>`. The operation set is closed: create, label, block, note, show, query, ready, status, close, whoami, signal.\n\nStore selection: the adapter reads PASTURE_DB_PATH when set, otherwise the header's `db:`; the probe wrote that value from the same precedence (XDG_DATA_HOME\u002Fpasture\u002Fpasture.db, HOME\u002F.local\u002Fshare\u002Fpasture\u002Fpasture.db, then .pasture\u002Fpasture.db). Use the same selected store for every command. If a recovery query fails, report its actual store path, failed operation, impact, and permission\u002Fschema\u002Fconfiguration repair; failure is not an empty work queue.\n\nThe adapter passes `--namespace` only when EPOCH.md records `namespace:`. That pin wins on both backends. Otherwise it omits the flag. Pasture then derives the namespace itself: PASTURE_NAMESPACE, else the git remote, then file:\u002F\u002F of the working directory. The ledger calls derive_namespace for the header and for every write that has no pin. That function is the one list of remote forms; do not restate it. With no origin, both backends use file:\u002F\u002F of the working directory, so invocations from different subdirectories use different namespaces. Queries without a pin follow that backend's derivation; pass `--all-namespaces` to opt out. When neither a pin nor PASTURE_NAMESPACE is set, pasture reads are unscoped and creation falls back to the git remote, then file:\u002F\u002F of the working directory. Inspect the returned full URI before choosing repository work. Separate reads are not an atomic snapshot.\n\nRun `\"${EPOCH_REC}\" ready`, `\"${EPOCH_REC}\" query --blocked`, and `\"${EPOCH_REC}\" query --status in_progress`. For each referenced active task, run `\"${EPOCH_REC}\" show \"$TASK_URI\"`, `\"${EPOCH_REC}\" show \"$TASK_URI\" --notes`, and `\"${EPOCH_REC}\" show \"$TASK_URI\" --history`. All *_URI variables in examples are inputs bound to full task URIs from an assignment, a verified tracker read, or the URI create printed; never use legacy short IDs. Resolve each variable before execution and quote it as one operand.\n\nCreate prints the new task URI directly. Persist it before any label or note: create-plus-label is non-atomic, so on failure retain the URI and retry only the failed label\u002Fnote operation, never create again. Only open, in_progress, and closed are statuses; blockage is represented by live dependencies and notes, not a blocked status.\n\nAn owner is recorded with `\"${EPOCH_REC}\" label \"$TASK_URI\" owner:\u003Crole>`. That is a claim, not an allocation: an unassigned task stays unassigned until the supervisor allocates it, and repeating an identical claim is not allocation. Never invent an owner.\n\nParent stays open and is blocked by child: `\"${EPOCH_REC}\" block \"$PARENT_URI\" --by \"$CHILD_URI\"`. Reference documents belong in description frontmatter under references:, never fabricated blockers. Workers report evidence and handoffs without closing their slices or leaves; the supervisor closes only after independent review and satisfied gates. Use git agent-commit for local commits. Never install, enable, or modify Git hooks, Git hook path configuration, or pre-commit integration without explicit user approval. Tracker writes are durable; Git history lands separately.\n\nIf the header records `backend: error`, stop before the first mutation: the store exists but cannot be used, and falling back could lose earlier epochs. A mid-epoch write failure retries 3 times. After the third failure, write the attempted record to .agents.local\u002Fpasture\u002Fpending\u002F\u003Ctimestamp>-\u003Cop>.md, keep the recorded backend, and surface the pending record to the user at the next gate. Never switch backends and never drop the record.\n\n## Task Attribution\n\nSelect the current registered author with \"${EPOCH_REC}\" whoami. It prints the author recorded in the header or PASTURE_AUTHOR, and on the pasture backend it confirms that actor with agents show. It does not list agents and it does not invent one. If neither source names an author, it stops: set author: in EPOCH.md or export PASTURE_AUTHOR. Never auto-register or guess an identity during recovery. Every note supplies --author explicitly; machine examples use the pre-registered pasture-system\u002F00000000-0000-0000-0000-000000000000 actor. If it is absent, stop and request registration from the operator rather than claiming registration is fixed. Preserve human intent verbatim and quote historical attribution as evidence, not as a forged new author.\n\n## Plan Review vs Code Review\n\n| Aspect | Plan Review (Phase 4) | Code Review (Phase 10) |\n|--------|-----------------------|------------------------|\n| Phase | plan review | code review |\n| Vote | ACCEPT \u002F REVISE (binary) | ACCEPT \u002F REVISE (binary) |\n| Severity tree | **NO** — no severity groups | **YES** — EAGER creation (always 3 groups) |\n| Naming | the proposal review | the wave review |\n| Focus | End-user alignment, MVP scope | Production code paths, severity findings |\n\n## End-User Alignment Criteria\n\nAll reviewers also apply these general questions:\n\n1. **Who are the end-users?**\n2. **What would end-users want?**\n3. **How would this affect them?**\n4. **Are there implementation gaps?**\n5. **Does MVP scope make sense?**\n6. **Is validation checklist complete and correct?**\n\n## Vote Options\n\n| Vote | When |\n|------|------|\n| ACCEPT | All review criteria satisfied; no BLOCKER items |\n| REVISE | BLOCKER issues found; must provide actionable feedback |\n\nBinary only. No intermediate levels.\n\n## Severity Vocabulary (Code Review Only)\n\n| Severity | When to Use | Blocks Slice? |\n|----------|-------------|---------------|\n| BLOCKER | Security, type errors, test failures, broken production code paths | Yes |\n| IMPORTANT | Performance, missing validation, architectural concerns | No — stays open past the wave gate and converges at the end |\n| MINOR | Style, optional optimizations, naming improvements | No — stays open past the wave gate and converges at the end |\n\n## Follow-up Lifecycle Reviews\n\nReviewers also participate in the follow-up lifecycle:\n\n- **FOLLOWUP_PROPOSAL review (Phase 4):** Same procedure as standard plan review. Task naming: `FOLLOWUP_PROPOSAL-N-REVIEW-{axis}-{round}`. Binary ACCEPT\u002FREVISE, no severity tree.\n- **Follow-up code review (Phase 10):** Same procedure as standard code review. Name the review for the follow-up slice, the axis, and the round. Full EAGER severity tree (BLOCKER\u002FIMPORTANT\u002FMINOR).\n- **Open findings converge at the end (no followup-of-followup):** findings (BLOCKER\u002FIMPORTANT\u002FMINOR) from a FOLLOWUP_SLICE code review stay open past the wave gate and converge at the end — they are never re-routed to a follow-up epic. The FOLLOWUP epic is fed only by user-DEFER'd UAT items.\n\n## Pasture Review Process\n\nRead the plan and URD:\n```bash\n\"${EPOCH_REC}\" show \"${TASK_ID_URI}\"\n\"${EPOCH_REC}\" show \"${URD_ID_URI}\"   # Read URD for user requirements context\n```\n\nAdd review comment with vote:\n```bash\n# If accepting:\n\"${EPOCH_REC}\" note \"${TASK_ID_URI}\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"VOTE: ACCEPT - End-user impact clear. MVP scope appropriate. Checklist items verifiable.\"\n\n# If requesting revision:\n\"${EPOCH_REC}\" note \"${TASK_ID_URI}\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"VOTE: REVISE - Missing: what happens if X fails? Suggestion: add error handling to checklist.\"\n```\n\n## Consensus\n\nAll 3 reviewers must vote ACCEPT for plan to be ratified. If any reviewer votes REVISE:\n1. Architect creates PROPOSAL-N+1 addressing feedback\n2. Old proposal marked `pasture:superseded`\n3. Reviewers re-review new proposal\n4. Repeat until all ACCEPT\n\u003C!-- END GENERATED FROM pasture schema -->\n",{"name":5,"description":7},"main","5813de22110ddc609b465a982b4811646ff72d18",".agents\u002Fskills\u002Freviewer",0,"https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture","https:\u002F\u002Fgithub.com\u002Fdayvidpham","dhpham.com","2026-11-11 16:48:48",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add dayvidpham\u002Fpasture --skill reviewer",{"tool":45,"command":46},"bunx","bunx skills add dayvidpham\u002Fpasture --skill reviewer",{"tool":48,"command":49},"pnpm","pnpm dlx skills add dayvidpham\u002Fpasture --skill reviewer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freviewer\u002FSKILL.md",true,[],[54,62,77,87,99,110],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":26},"01M6DAP7307B3JVZX5DSNAE08Y","fixture","Isolated fixture skill","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Ftestdata\u002Finstall\u002Fglobal\u002Fclaude-code\u002Fnative-marketplace\u002Ffixture-plugin\u002Fskills\u002Ffixture\u002FSKILL.md",[],[56,61],"fixture skill",{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":26},"01M6DAP48A4K365N83NBG0GFVC","worker","Vertical slice implementer (full production code path)","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker\u002FSKILL.md",[],[64,69,22,70,71,72,73,74,75,76],"implementer","implement","Production","full","complete","vertical slice","slice","path",{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":26},"01M6DAP18QJM7P7N31TYGNJBCP","worker-implement","Implement assigned vertical slice following TDD layers","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-implement\u002FSKILL.md",[],[84,64,70,74,85,75,86],"worker implement","layers","tdd",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":26},"01M6DANYHC7P63RFEN26F70MC2","worker-complete","Signal slice completion after quality gates pass","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-complete\u002FSKILL.md",[],[64,94,73,95,75,96,97,98],"worker complete","signal","gates","quality","quality gates",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":26},"01M6DANWZ31TRP4NN4T1BFYKSR","worker-blocked","Report a blocker to supervisor via Pasture","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-blocked\u002FSKILL.md",[],[106,64,107,108,109],"worker blocked","via","report","supervisor",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":121,"publishedAt":26},"01M6DANSVDBXBFH93B6EX3H2QK","user-uat","User Acceptance Testing with demonstrative examples","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fuser-uat\u002FSKILL.md",[116],{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[122,123,23,124,125,126,127,128,129],"uat","user uat","acceptance testing","with","user acceptance testing","examples","acceptance","testing"]