[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAGMP4FSRY35QAGA84XPM4":3,"skill-same:01M6DAGMP4FSRY35QAGA84XPM4":54},{"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":27,"linkOnly":28,"markdownContent":29,"markdownBody":30,"frontMatter":31,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":35,"repositoryHtmlUrl":36,"repositoryHomepageUrl":6,"ownerHtmlUrl":37,"ownerBlogUrl":38,"ownerDescription":6,"updatedAt":39,"install":40,"resources":53},"01M6DAGMP4FSRY35QAGA84XPM4","architect-handoff",null,"Create handoff document and transfer to supervisor","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\u002Finternal\u002Ftarget\u002Fopencode\u002Fassets\u002Fskills\u002Farchitect-handoff\u002FSKILL.md",[],[19,20,21,22,23,24,25,26],"architect handoff","handoff","architect","create","create handoff","document","supervisor","transfer","2026-11-10 10:12:30",false,"---\nname: architect-handoff\ndescription: Create handoff document and transfer to supervisor\n---\n\n# Architect: Handoff to Supervisor\n\n\u003C!-- BEGIN GENERATED FROM pasture schema -->\n\u003C!-- GENERATED FROM pasture v0.0.33 artifact v1 -->\n**Command:** `pasture:architect:handoff` — Create handoff document and transfer to supervisor\n\n**-> [Full workflow in PROCESS.md](..\u002Fprotocol\u002FPROCESS.md#phase-7-handoff)** \u003C- Phase 7\n\n**[arch-handoff-link-proposal]**\n- Given: ratified PROPOSAL-N task\n- When: handing off\n- Then: author the handoff in a HANDOFF Pasture task body, linking to the ratified proposal\n- Should not: hand off without linking to ratified proposal\n\n**[arch-handoff-spawn-supervisor]**\n- Given: handoff for the IMPL_PLAN phase\n- When: spawning the supervisor\n- Then: delegate the supervisor as the implementation-plan owner (workers also on the frontier tier), then give it a self-contained assignment\n- Should not: spawn the supervisor without a self-contained assignment for the IMPL_PLAN phase\n\n**[arch-handoff-supervisor-not-idle]**\n- Given: a freshly spawned supervisor\n- When: it dispatches Explore subagents and appears idle\n- Then: let it work — an apparently-idle supervisor is usually running Explore subagents to map the codebase before decomposing slices\n- Should not: shut down or restart a supervisor that looks idle at the start of the IMPL_PLAN phase\n\n**[arch-handoff-no-impl-tasks]**\n- Given: implementation planning\n- When: handing off\n- Then: let supervisor create vertical slice tasks\n- Should not: create implementation tasks as architect\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## Writing to the User\n\nThese rules adapt ASD-STE100 Issue 9, Part 1 to chat messages. They are STE-aligned. The standard's Part 2 dictionary is not adopted, so no message can claim full compliance. This fragment covers wording: plain terms, short sentences, active voice, no invented labels, and the wording house rule, plus the pre-send check and the status template. Five skills carry these wording rules: architect-handoff, status, supervisor, user-elicit, user-uat.\n\n### The rules\n\nFormat: number, requirement, the STE rule it adapts, then a compact bad-to-good pair.\n\n**Shape**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 1 | Lead with the result, the decision, or the blocker. | 6.1, 6.2 | 'This pins both the edge and the core case per branch, so a same-count swap fails.' to 'Result: the test now fails if a real case is replaced with a filler case.' |\n| 3 | One topic per paragraph. Max 3 sentences. | 6.5, 6.6 | One 25-word sentence with four stacked ideas, to three sentences with one idea each. |\n| 4 | For 3 or more items, a flow, or a comparison, use a list, a table, or an ASCII diagram. | 4.3 | 'Adopt the first option, then the second, then both' to a three-row table: option, what happens, cost. |\n| 5 | Cut filler, self-narration, hedging, praise, and closing offers. | house | 'It is important to note that this change effectively serves to ensure the test can detect' to 'The test detects a removed case.' |\n\n**Terms**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 6 | Put every term the user did not introduce in a Terms block before first use. Max 20 words per definition. Include the code name. | 1.1, 1.6 | 'per arm' to 'Arm: one of the 5 branches of the skip gate. Code: `arm`.' |\n| 7 | Use the industry term for the concept. Do not invent a term. | 1.8, 1.10 | 'a same-count swap' to 'a replacement that keeps the test count the same'. |\n| 8 | One name per item, in the message and across the session. | 1.11, 9.4 | 'the gate', then 'the event types', then 'the IR', to 'the event types' each time. |\n| 9 | One meaning per word. Do not use one word in two senses. | 1.2, 1.3 | 'pins' for a version lock and 'pins' for a test assertion, to 'locks the version' and 'the test checks'. |\n| 10 | No internal shorthand in prose. Write the substance first, then the reference in parentheses. | 1.10, 2.2, 8.6 | 'Adopt the option code and skip the explanation' to 'Adopt the retry limit (task: Importer retry limit, round 6).' |\n| 11 | Max 3 words in a noun cluster, and no stack of hidden ideas. A hyphenated stack still hides several. Break it with 'of', 'that', or a clause. | 2.1, 1.9 | 'mutation-load-bearing core case' to 'the core case (the one case per branch that fails when the branch breaks)'. |\n| 12 | Write each abbreviation in full once, then the short form in parentheses. | 2.2, 8.3 | 'the continuous integration job, then the CI job, with no first full form' to 'the continuous integration (CI) job, then the CI job.' |\n| 13 | Use plain verbs. No slang, no noun-as-verb, no phrasal verb. | 1.7, 1.10, 9.3 | 'reddens' to 'fails'. |\n\n**Sentences**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 14 | Max 20 words for an instruction or a question. Max 25 for a description. An identifier or a quote counts as one word. The cap is necessary, not sufficient. | 5.1, 6.3, 8.6 | 'The test checks ten cases, and because each branch needs two named cases and the count is no longer enough, a replacement can pass.' to 'The test checks 10 cases. A filler case can no longer pass.' |\n| 15 | Active voice. Name the actor: the test, CI, the agent, the merge. Simple tenses only. | 3.2, 3.6 | 'The gate will be rebased on the types.' to 'The agent rebases the gate on the event types.' |\n| 16 | One instruction per sentence. Imperative. Condition first. | 5.2, 5.3, 5.4 | 'All three at once, then check.' to 'If the types change, rebase the gate. Then run the tests.' |\n| 17 | Full sentences keep articles and verbs. Fragments only in lists, tables, and labels. | 4.2, 4.3, 4.5 | 'Defer the timeout, keep the retry limit fix' to 'Keep the retry limit. Defer the timeout change. The correctness review is round 3 and the test-quality review is round 2.' |\n| 18 | No semicolons. No em-dashes. Use a period or a list. | 8.1 + house | 'per arm, so a swap fails' with an em-dash, to 'per arm. That is 10 checks, so a swap fails.' |\n| 19 | Show the logic with because, so, but, if, then. | 4.4 | '10 predicates. A same-count swap fails.' to 'The test checks 10 cases, so a replacement that keeps the count cannot pass.' |\n\n**Exempt material**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 20 | Backtick each identifier. Max 2 per sentence. Give a plain gloss on first use. | 8.6 + house | Four bare references in one line, to one task, one design decision, and two reviews, each written in substance first. |\n| 21 | Quote user text, code, paths, and logs exactly. Explain them outside the quote. | 8.6 | A quote silently edited, to the blockquote verbatim with a plain reading on the next line. |\n\n**Risk**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 25 | Mark an irreversible action with WARNING or CAUTION, then the condition, then the result. | 7.1, 7.2, 7.3 | 'Removing the core case will fail the suite.' to 'CAUTION: if you remove the core case, the test passes and a broken branch ships.' |\n\n### Wording house rule\n\nNo self-praise is the wording house rule.\n\n| Rule | Requirement |\n|---|---|\n| No self-praise | No self-congratulation. State the next step in one line instead. |\n\n### Template: status update\n\n~~~markdown\n**Status:** \u003Cthe result or the state, max 25 words>.\n\n**Done**\n- \u003Cartifact or outcome, past tense, actor named> (`\u003Cpath>`, pull request #N, or task title).\n\n**Next**\n- \u003Cwhat happens next, and who does it>.\n\n**Needs you** (omit if empty)\n- \u003Cthe decision>, needed for \u003Cwhat it unblocks>.\n\n**Risk** (omit if empty)\n- WARNING or CAUTION: \u003Ccondition>. \u003Cresult>.\n\n**Terms** (new terms only)\n- **\u003Cterm>**: \u003Cmax 20 words>.\n~~~\n\nBudget: 120 words. Every Done item names an artefact. Do not restate the plan. One status per message, not one per thought.\n\n### Exempt material\n\nTwo material classes are exempt from the word and sentence caps: quoted text and code blocks. A third is allowed as technical nouns. Everything else obeys the caps.\n\n- **Quoted user text.** Verbatim in a blockquote. Never rewrite it into the house style. Put the plain reading after the quote.\n- **Code, logs, diffs, test output.** Exempt. Explain them in prose around the block.\n- **Industry terms of art.** Fixture, golden test, mutation testing, schema migration, fail-safe default, backfill, and closed enum are allowed as technical nouns. Define one in Terms if the user did not use it first.\n\nTwo more rows are relaxations, not exemptions. **Spelling** keeps one spelling per message and does not enforce American spelling. **Identifiers** are not exempt from a gloss, as rule 20 says.\n\nThe caps stay live for everything else. Rule 3 sets paragraph length, rule 14 sets the word caps, and rule 17 sets where a fragment is allowed; none of those three is an exemption.\n\n### Pre-send check\n\nRun this list on every user-facing message. A clean pass is not a gate.\n\n1. Does sentence one give the result, the decision, or the blocker?\n2. Does every term the reader did not introduce appear in Terms before first use?\n3. Search the draft for a token that matches `[A-Z]{1,3}-?[0-9]`, for a section sign (`§`), and for a five- or six-character token that matches `[A-Za-z0-9]{5,6}` and contains both a letter and a digit. Is each one defined, or replaced by its substance?\n4. Does one item have two names, or one word have two senses?\n5. Any sentence over 20 words (instruction or question) or 25 (description)?\n6. Any noun cluster over 3 words? Any slang verb, noun-as-verb, or phrasal verb?\n7. Any semicolon or em-dash?\n8. Any passive verb with no actor?\n9. Does an irreversible action carry WARNING or CAUTION?\n10. Delete one sentence. If nothing is lost, keep it deleted.\n\n## Question and Option Design\n\nThis fragment covers question and option design: grounding before asking, one decision, option shape, recommendation placement, the present template, and the weak-tool degrade. Wording rules, the STE-aligned claim, the status template, and the pre-send check are in Writing to the User. Four skills carry these question rules: architect-handoff, supervisor, user-elicit, user-uat. The status skill asks no question, so it does not carry this fragment. Ask through the `request_user_decision` operation, never by launching a subagent. That launch is `delegate_assignment`, a different operation. The role-tool binding in `internal\u002Fruntime\u002Fprofiles.go` lowers `request_user_decision` to the harness question tool and lowers `delegate_assignment` to the subagent tool.\n\n### The rules\n\nFormat: number, requirement, the STE rule it adapts, then a compact bad-to-good pair.\n\n**Grounding**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 2 | Ground before you ask. Show what the thing is, where it lives, and one example. Never put the only explanation in the options. | 6.1, 4.4 | 'Which order: the types to the gate in parallel, or the gate first?' to 'Three parts share one type. The gate reads it. The fixtures copy it. Code: `ir.Event`.' |\n\n**Questions and options**\n\nRules 22, 23 and 24 are house rules. The house-rule table names them by number. Do not attach an STE number to a house rule.\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 22 | One question, one decision. Say what the answer changes. | house | 'Which order do you want, and are the labels clear?' to 'Which part merges first? The answer sets the order for the next 3 days.' |\n| 23 | Each option is self-contained: a label of max 6 words, what happens, and the cost. Use only Terms words. | house | 'Both' to 'Both limits. The import stops at the first limit it reaches. Cost: one more setting to test.' |\n| 24 | Put the recommendation outside the options, with one reason. You may also mark the label '(recommended)'. | house | An option labelled 'recommended' with no reason, to 'Recommendation: merge the event types first, because a later change costs rework in two places.' |\n\n### House rules for questions, options and recommendations\n\nASD-STE100 has no rule for questions, options, recommendations, or the turn split around a question tool. Rules 2, 22, 23 and 24 already carry grounding before asking, one decision per question, option design and recommendation placement. Four rows in this table are pointers to those rules. Question shape and Text-before-question turn add only what those rules do not. No self-praise is a wording rule; it is in Writing to the User. Never cite an STE number for a house rule.\n\n| Rule | Requirement |\n|---|---|\n| Question shape | A short header, max 4 words. |\n| Option design | Extends rule 23. Do not restate it. |\n| Recommendation placement | Extends rule 24. Do not restate it. |\n| Grounding before asking | Extends rule 2. Do not restate it. |\n| One decision per question | Extends rule 22. Do not restate it. |\n| Text-before-question turn | Send the grounding as text and end the turn. Ask through the `request_user_decision` operation in the next turn, because a question tool can hide prose sent in the same turn. |\n\n### Template: present a component, then ask\n\nSend the block below as text only, then end the turn. In the next turn, ask through the `request_user_decision` operation with the same options. The split is the Text-before-question turn house rule.\n\n~~~~markdown\n## \u003CPart name>: \u003Cwhat it does for the user, max 10 words>\n\n**Decision needed:** \u003Cone sentence>. The answer changes \u003Cwhat>.\n\n**Terms**\n- **\u003Cterm>**: \u003Cmax 20 words>. Code: `\u003Cidentifier>`.\n- **\u003Cterm>**: \u003Cmax 20 words>.\n\n**What it is**\n\u003Cmax 3 sentences. Name the actor. One fact per sentence.>\n\n**Definition**\n~~~\u003Clang>\n\u003Cthe smallest type, interface, schema, or command shape that shows the choice>\n~~~\n\n**Example**\n~~~\n\u003Cone realistic before and after, or input and output>\n~~~\n\n**Diagram**\n~~~\n\u003CASCII, plain labels, no em-dash>\n~~~\n\n**Options**\n\n| Option | What happens | Cost |\n|---|---|---|\n| \u003Clabel, max 6 words> | \u003Cone sentence> | \u003Cone sentence> |\n| \u003Clabel> | \u003Cone sentence> | \u003Cone sentence> |\n\n**Recommendation:** \u003Coption>, because \u003Cone reason>.\n~~~~\n\nThen, in the next turn:\n\n~~~\n`request_user_decision`: '\u003Cquestion, max 20 words>'\noptions: the same labels, with the 'what happens' and 'cost' text repeated in each description, because the picker can hide the table.\n~~~\n\nOne component per call. Use multi-select only when the options combine. Always add one open-ended feedback question.\n\n### Degrade when the question tool is weak\n\nSome hosts expose a weak question tool: it takes one question per call, it has no multi-select, or its picker hides option descriptions. Degrade in this order:\n\n1. Ask one question.\n2. Phrase the options as a single-select choice.\n3. State the assumption you will use if the answer is unavailable.\n\nPut the assumption in the text turn that grounds the question, not inside the options. An assumption never satisfies a user gate: a gated phase waits for the user's answer. The question still asks for one decision, and the recommendation names the cost of the assumption.\n\n### Pre-send check for a question\n\nRun this list before you send a question. It tests the question rules in this fragment. The wording pre-send check is in Writing to the User.\n\n1. Before a question: did the reader already see what the thing is, its definition, and one example, in an earlier turn or an earlier block?\n2. Can the reader choose from the options alone, with no other document? Is the recommendation outside the options?\n\n## When to Use\n\nPlan ratified and user has approved proceeding with implementation.\n\n## Handoff Template\n\nUse the required handoff fields in [architect](..\u002Farchitect\u002FSKILL.md). That skill renders the list from the handoff registry; this template renders from the same registry.\n\nStorage: the handoff is authored directly in the **HANDOFF Pasture task body** (no filesystem path; the task body IS the handoff).\n\n```markdown\n# Handoff: Architect → Supervisor\n\n## Supervisor Startup\n1. Call `skill(\u002Fpasture:supervisor)` to load your role instructions\n2. Spawn ephemeral Explore subagents with the task tool when codebase exploration is needed\n3. Read each reference under References with the command beside it, before you plan\n4. Every vertical slice MUST have leaf tasks — any number, named after the real work units\n\n## References\n- Request: \"${REQUEST_ID_URI}\" — read with `\"${EPOCH_REC}\" show \"${REQUEST_ID_URI}\"`\n- URD: \"${URD_ID_URI}\" — read with `\"${EPOCH_REC}\" show \"${URD_ID_URI}\"`\n- Proposal: \"${RATIFIED_PROPOSAL_ID_URI}\" — read with `\"${EPOCH_REC}\" show \"${RATIFIED_PROPOSAL_ID_URI}\"`\n- Ratified Plan: \"${RATIFIED_PLAN_ID_URI}\" — read with `\"${EPOCH_REC}\" show \"${RATIFIED_PLAN_ID_URI}\"`\n\n## Context\n\u003Ccontext>\n\n## Key Decisions\n\u003Ckey-decisions>\n\n## Open Items\n\u003Copen-items>\n\n## Acceptance Criteria\n\u003Cacceptance-criteria>\n```\n\n\n## Steps\n\n1. Create the HANDOFF Pasture task — its body IS the handoff document (use the template above):\n   ```bash\n   HANDOFF_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"HANDOFF: Architect → Supervisor for REQUEST\" --phase handoff --priority 2 \\\n     --body=\"---\nreferences:\n  request: \"${REQUEST_ID_URI}\"\n  urd: \"${URD_ID_URI}\"\n  proposal: \"${RATIFIED_PROPOSAL_ID_URI}\"\n  ratified_plan: \"${RATIFIED_PLAN_ID_URI}\"\n---\n# Handoff: Architect → Supervisor\n\u003Cfull handoff body per the template above>\")\n   \"${EPOCH_REC}\" label \"$HANDOFF_ID_URI\" pasture:p7-plan:s7-handoff\n\n   ```\n\n2. Delegate the supervisor with the task operation (the IMPL_PLAN phase runs under the supervisor):\n   ```\n   delegate the implementation-plan owner, then give it the self-contained assignment below\n   ```\n\n3. Monitor supervisor progress:\n   ```bash\n   # Check pasture status\n   \"${EPOCH_REC}\" query --status=in_progress\n   ```\n\n   A supervisor that looks idle right after spawn is usually running Explore subagents — do **not** shut it down pre-emptively.\n\n## Example Prompt\n\n**CRITICAL:** The send_assignment_message assignment MUST instruct the supervisor to invoke `\u002Fpasture:supervisor` as its first action. Without this, the supervisor agent starts without its role instructions and skips leaf task creation, ephemeral exploration, and other critical procedures.\n\n```\nStart by calling `skill(\u002Fpasture:supervisor)` to load your role instructions.\n\nImplement the ratified plan for \u003Cfeature name>.\n\n## Context\n- REQUEST: \"${REQUEST_ID_URI}\"\n- URD: \"${URD_ID_URI}\" (read with `\"${EPOCH_REC}\" show \"${URD_ID_URI}\"` for user requirements)\n- RATIFIED PROPOSAL: \"${RATIFIED_PROPOSAL_ID_URI}\"\n- HANDOFF: \"${HANDOFF_ID_URI}\" (the handoff body — read with `\"${EPOCH_REC}\" show \"${HANDOFF_ID_URI}\"`)\n\n## Summary\n\u003C1-2 sentence summary of what needs to be implemented>\n\n## Key Files\n\u003Clist main files to be created\u002Fmodified from the ratified plan>\n\n## Acceptance Criteria\n\u003CGiven\u002FWhen\u002FThen criteria from the ratified plan>\n\n## Reminders\n1. Call `skill(\u002Fpasture:supervisor)` FIRST — do not proceed without loading your role\n2. Spawn ephemeral Explore subagents with the task tool when codebase exploration is needed\n3. Every vertical slice MUST have leaf tasks — any number, named after the real work units (the L1\u002FL2\u002FL3 triple is only illustrative); a slice without leaf tasks is undecomposed\n4. Read the ratified plan with `\"${EPOCH_REC}\" show \"${RATIFIED_PROPOSAL_ID_URI}\"` and the URD with `\"${EPOCH_REC}\" show \"${URD_ID_URI}\"`\n```\n\nDeliver this assignment to the supervisor when you delegate it:\n\n```\nsend_assignment_message({\n  to: \"supervisor\",\n  message: `Start by calling skill(\u002Fpasture:supervisor) to load your role instructions.\n\nImplement the ratified plan for User Authentication.\n\n## Context\n- REQUEST: ${REQUEST_ID_URI}\n- URD: \"${URD_ID_URI}\"\n- RATIFIED PROPOSAL: \"${RATIFIED_PROPOSAL_ID_URI}\"\n- HANDOFF: \"${HANDOFF_ID_URI}\" (read with \"${EPOCH_REC}\" show \"${HANDOFF_ID_URI}\")\n\n## Summary\nAdd JWT-based authentication with login\u002Flogout endpoints and middleware.\n\n## Key Files\n- pkg\u002Fauth\u002Fjwt.go\n- pkg\u002Fauth\u002Fmiddleware.go\n- cmd\u002Fapi\u002Fauth.go\n\n## Acceptance Criteria\nGiven a valid JWT token when accessing protected routes then allow access\nGiven an expired token when accessing protected routes then return 401\n\n## Reminders\n1. Call skill(\u002Fpasture:supervisor) FIRST\n2. Spawn ephemeral Explore subagents with the task tool when codebase exploration is needed\n3. Every slice MUST have leaf tasks (any number; L1\u002FL2\u002FL3 is only illustrative)\n4. Read ratified plan: \"${EPOCH_REC}\" show \"${RATIFIED_PROPOSAL_ID_URI}\" and URD: \"${EPOCH_REC}\" show \"${URD_ID_URI}\"`,\n  summary: \"IMPL_PLAN assignment with Pasture context\"\n})\n```\n\n## Delegation Notes\n\n- Delegate the supervisor (and the workers it will coordinate) as **T1 frontier** assignments — the IMPL_PLAN phase benefits from the frontier tier for decomposition and review.\n- A delegated assignment has **zero prior context**: every assignment MUST be self-contained (call `skill(\u002Fpasture:supervisor)`, the Pasture task IDs, and `\"${EPOCH_REC}\" show` commands to fetch full requirements).\n- Do not spawn the supervisor for the IMPL_PLAN phase except through this handoff.\n\n## IMPORTANT\n\n- **DO NOT** skip the handoff and spawn the supervisor for the IMPL_PLAN phase — delegate it with the task operation\n- **DO NOT** create implementation tasks yourself - the supervisor creates vertical slice tasks\n- **DO NOT** implement the plan yourself - your role is handoff and monitoring\n- **DO NOT** shut down a supervisor that appears idle right after spawn — it is usually running Explore subagents\n- The supervisor reads the ratified plan and determines vertical slice structure\n- Architect monitors for blockers or escalations\n\n## Follow-up Lifecycle (h1 Reuse)\n\nThis handoff (h1: Architect → Supervisor) also occurs after FOLLOWUP_PROPOSAL is ratified. In follow-up context:\n\n- **Storage:** the follow-up handoff is authored in its own HANDOFF Pasture task body (no filesystem path)\n- **References:** keep `urd: \"${URD_ID_URI}\"` and add `followup_urd: \"${FOLLOWUP_URD_ID_URI}\"`, then read each with `\"${EPOCH_REC}\" show`\n- **Context:** Summary of FOLLOWUP_PROPOSAL ratification and the user-DEFER'd UAT items the follow-up addresses\n- **Next step:** Supervisor creates the follow-up plan and the follow-up slices for that scope\n\u003C!-- END GENERATED FROM pasture schema -->\n","# Architect: Handoff to Supervisor\n\n\u003C!-- BEGIN GENERATED FROM pasture schema -->\n\u003C!-- GENERATED FROM pasture v0.0.33 artifact v1 -->\n**Command:** `pasture:architect:handoff` — Create handoff document and transfer to supervisor\n\n**-> [Full workflow in PROCESS.md](..\u002Fprotocol\u002FPROCESS.md#phase-7-handoff)** \u003C- Phase 7\n\n**[arch-handoff-link-proposal]**\n- Given: ratified PROPOSAL-N task\n- When: handing off\n- Then: author the handoff in a HANDOFF Pasture task body, linking to the ratified proposal\n- Should not: hand off without linking to ratified proposal\n\n**[arch-handoff-spawn-supervisor]**\n- Given: handoff for the IMPL_PLAN phase\n- When: spawning the supervisor\n- Then: delegate the supervisor as the implementation-plan owner (workers also on the frontier tier), then give it a self-contained assignment\n- Should not: spawn the supervisor without a self-contained assignment for the IMPL_PLAN phase\n\n**[arch-handoff-supervisor-not-idle]**\n- Given: a freshly spawned supervisor\n- When: it dispatches Explore subagents and appears idle\n- Then: let it work — an apparently-idle supervisor is usually running Explore subagents to map the codebase before decomposing slices\n- Should not: shut down or restart a supervisor that looks idle at the start of the IMPL_PLAN phase\n\n**[arch-handoff-no-impl-tasks]**\n- Given: implementation planning\n- When: handing off\n- Then: let supervisor create vertical slice tasks\n- Should not: create implementation tasks as architect\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## Writing to the User\n\nThese rules adapt ASD-STE100 Issue 9, Part 1 to chat messages. They are STE-aligned. The standard's Part 2 dictionary is not adopted, so no message can claim full compliance. This fragment covers wording: plain terms, short sentences, active voice, no invented labels, and the wording house rule, plus the pre-send check and the status template. Five skills carry these wording rules: architect-handoff, status, supervisor, user-elicit, user-uat.\n\n### The rules\n\nFormat: number, requirement, the STE rule it adapts, then a compact bad-to-good pair.\n\n**Shape**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 1 | Lead with the result, the decision, or the blocker. | 6.1, 6.2 | 'This pins both the edge and the core case per branch, so a same-count swap fails.' to 'Result: the test now fails if a real case is replaced with a filler case.' |\n| 3 | One topic per paragraph. Max 3 sentences. | 6.5, 6.6 | One 25-word sentence with four stacked ideas, to three sentences with one idea each. |\n| 4 | For 3 or more items, a flow, or a comparison, use a list, a table, or an ASCII diagram. | 4.3 | 'Adopt the first option, then the second, then both' to a three-row table: option, what happens, cost. |\n| 5 | Cut filler, self-narration, hedging, praise, and closing offers. | house | 'It is important to note that this change effectively serves to ensure the test can detect' to 'The test detects a removed case.' |\n\n**Terms**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 6 | Put every term the user did not introduce in a Terms block before first use. Max 20 words per definition. Include the code name. | 1.1, 1.6 | 'per arm' to 'Arm: one of the 5 branches of the skip gate. Code: `arm`.' |\n| 7 | Use the industry term for the concept. Do not invent a term. | 1.8, 1.10 | 'a same-count swap' to 'a replacement that keeps the test count the same'. |\n| 8 | One name per item, in the message and across the session. | 1.11, 9.4 | 'the gate', then 'the event types', then 'the IR', to 'the event types' each time. |\n| 9 | One meaning per word. Do not use one word in two senses. | 1.2, 1.3 | 'pins' for a version lock and 'pins' for a test assertion, to 'locks the version' and 'the test checks'. |\n| 10 | No internal shorthand in prose. Write the substance first, then the reference in parentheses. | 1.10, 2.2, 8.6 | 'Adopt the option code and skip the explanation' to 'Adopt the retry limit (task: Importer retry limit, round 6).' |\n| 11 | Max 3 words in a noun cluster, and no stack of hidden ideas. A hyphenated stack still hides several. Break it with 'of', 'that', or a clause. | 2.1, 1.9 | 'mutation-load-bearing core case' to 'the core case (the one case per branch that fails when the branch breaks)'. |\n| 12 | Write each abbreviation in full once, then the short form in parentheses. | 2.2, 8.3 | 'the continuous integration job, then the CI job, with no first full form' to 'the continuous integration (CI) job, then the CI job.' |\n| 13 | Use plain verbs. No slang, no noun-as-verb, no phrasal verb. | 1.7, 1.10, 9.3 | 'reddens' to 'fails'. |\n\n**Sentences**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 14 | Max 20 words for an instruction or a question. Max 25 for a description. An identifier or a quote counts as one word. The cap is necessary, not sufficient. | 5.1, 6.3, 8.6 | 'The test checks ten cases, and because each branch needs two named cases and the count is no longer enough, a replacement can pass.' to 'The test checks 10 cases. A filler case can no longer pass.' |\n| 15 | Active voice. Name the actor: the test, CI, the agent, the merge. Simple tenses only. | 3.2, 3.6 | 'The gate will be rebased on the types.' to 'The agent rebases the gate on the event types.' |\n| 16 | One instruction per sentence. Imperative. Condition first. | 5.2, 5.3, 5.4 | 'All three at once, then check.' to 'If the types change, rebase the gate. Then run the tests.' |\n| 17 | Full sentences keep articles and verbs. Fragments only in lists, tables, and labels. | 4.2, 4.3, 4.5 | 'Defer the timeout, keep the retry limit fix' to 'Keep the retry limit. Defer the timeout change. The correctness review is round 3 and the test-quality review is round 2.' |\n| 18 | No semicolons. No em-dashes. Use a period or a list. | 8.1 + house | 'per arm, so a swap fails' with an em-dash, to 'per arm. That is 10 checks, so a swap fails.' |\n| 19 | Show the logic with because, so, but, if, then. | 4.4 | '10 predicates. A same-count swap fails.' to 'The test checks 10 cases, so a replacement that keeps the count cannot pass.' |\n\n**Exempt material**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 20 | Backtick each identifier. Max 2 per sentence. Give a plain gloss on first use. | 8.6 + house | Four bare references in one line, to one task, one design decision, and two reviews, each written in substance first. |\n| 21 | Quote user text, code, paths, and logs exactly. Explain them outside the quote. | 8.6 | A quote silently edited, to the blockquote verbatim with a plain reading on the next line. |\n\n**Risk**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 25 | Mark an irreversible action with WARNING or CAUTION, then the condition, then the result. | 7.1, 7.2, 7.3 | 'Removing the core case will fail the suite.' to 'CAUTION: if you remove the core case, the test passes and a broken branch ships.' |\n\n### Wording house rule\n\nNo self-praise is the wording house rule.\n\n| Rule | Requirement |\n|---|---|\n| No self-praise | No self-congratulation. State the next step in one line instead. |\n\n### Template: status update\n\n~~~markdown\n**Status:** \u003Cthe result or the state, max 25 words>.\n\n**Done**\n- \u003Cartifact or outcome, past tense, actor named> (`\u003Cpath>`, pull request #N, or task title).\n\n**Next**\n- \u003Cwhat happens next, and who does it>.\n\n**Needs you** (omit if empty)\n- \u003Cthe decision>, needed for \u003Cwhat it unblocks>.\n\n**Risk** (omit if empty)\n- WARNING or CAUTION: \u003Ccondition>. \u003Cresult>.\n\n**Terms** (new terms only)\n- **\u003Cterm>**: \u003Cmax 20 words>.\n~~~\n\nBudget: 120 words. Every Done item names an artefact. Do not restate the plan. One status per message, not one per thought.\n\n### Exempt material\n\nTwo material classes are exempt from the word and sentence caps: quoted text and code blocks. A third is allowed as technical nouns. Everything else obeys the caps.\n\n- **Quoted user text.** Verbatim in a blockquote. Never rewrite it into the house style. Put the plain reading after the quote.\n- **Code, logs, diffs, test output.** Exempt. Explain them in prose around the block.\n- **Industry terms of art.** Fixture, golden test, mutation testing, schema migration, fail-safe default, backfill, and closed enum are allowed as technical nouns. Define one in Terms if the user did not use it first.\n\nTwo more rows are relaxations, not exemptions. **Spelling** keeps one spelling per message and does not enforce American spelling. **Identifiers** are not exempt from a gloss, as rule 20 says.\n\nThe caps stay live for everything else. Rule 3 sets paragraph length, rule 14 sets the word caps, and rule 17 sets where a fragment is allowed; none of those three is an exemption.\n\n### Pre-send check\n\nRun this list on every user-facing message. A clean pass is not a gate.\n\n1. Does sentence one give the result, the decision, or the blocker?\n2. Does every term the reader did not introduce appear in Terms before first use?\n3. Search the draft for a token that matches `[A-Z]{1,3}-?[0-9]`, for a section sign (`§`), and for a five- or six-character token that matches `[A-Za-z0-9]{5,6}` and contains both a letter and a digit. Is each one defined, or replaced by its substance?\n4. Does one item have two names, or one word have two senses?\n5. Any sentence over 20 words (instruction or question) or 25 (description)?\n6. Any noun cluster over 3 words? Any slang verb, noun-as-verb, or phrasal verb?\n7. Any semicolon or em-dash?\n8. Any passive verb with no actor?\n9. Does an irreversible action carry WARNING or CAUTION?\n10. Delete one sentence. If nothing is lost, keep it deleted.\n\n## Question and Option Design\n\nThis fragment covers question and option design: grounding before asking, one decision, option shape, recommendation placement, the present template, and the weak-tool degrade. Wording rules, the STE-aligned claim, the status template, and the pre-send check are in Writing to the User. Four skills carry these question rules: architect-handoff, supervisor, user-elicit, user-uat. The status skill asks no question, so it does not carry this fragment. Ask through the `request_user_decision` operation, never by launching a subagent. That launch is `delegate_assignment`, a different operation. The role-tool binding in `internal\u002Fruntime\u002Fprofiles.go` lowers `request_user_decision` to the harness question tool and lowers `delegate_assignment` to the subagent tool.\n\n### The rules\n\nFormat: number, requirement, the STE rule it adapts, then a compact bad-to-good pair.\n\n**Grounding**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 2 | Ground before you ask. Show what the thing is, where it lives, and one example. Never put the only explanation in the options. | 6.1, 4.4 | 'Which order: the types to the gate in parallel, or the gate first?' to 'Three parts share one type. The gate reads it. The fixtures copy it. Code: `ir.Event`.' |\n\n**Questions and options**\n\nRules 22, 23 and 24 are house rules. The house-rule table names them by number. Do not attach an STE number to a house rule.\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 22 | One question, one decision. Say what the answer changes. | house | 'Which order do you want, and are the labels clear?' to 'Which part merges first? The answer sets the order for the next 3 days.' |\n| 23 | Each option is self-contained: a label of max 6 words, what happens, and the cost. Use only Terms words. | house | 'Both' to 'Both limits. The import stops at the first limit it reaches. Cost: one more setting to test.' |\n| 24 | Put the recommendation outside the options, with one reason. You may also mark the label '(recommended)'. | house | An option labelled 'recommended' with no reason, to 'Recommendation: merge the event types first, because a later change costs rework in two places.' |\n\n### House rules for questions, options and recommendations\n\nASD-STE100 has no rule for questions, options, recommendations, or the turn split around a question tool. Rules 2, 22, 23 and 24 already carry grounding before asking, one decision per question, option design and recommendation placement. Four rows in this table are pointers to those rules. Question shape and Text-before-question turn add only what those rules do not. No self-praise is a wording rule; it is in Writing to the User. Never cite an STE number for a house rule.\n\n| Rule | Requirement |\n|---|---|\n| Question shape | A short header, max 4 words. |\n| Option design | Extends rule 23. Do not restate it. |\n| Recommendation placement | Extends rule 24. Do not restate it. |\n| Grounding before asking | Extends rule 2. Do not restate it. |\n| One decision per question | Extends rule 22. Do not restate it. |\n| Text-before-question turn | Send the grounding as text and end the turn. Ask through the `request_user_decision` operation in the next turn, because a question tool can hide prose sent in the same turn. |\n\n### Template: present a component, then ask\n\nSend the block below as text only, then end the turn. In the next turn, ask through the `request_user_decision` operation with the same options. The split is the Text-before-question turn house rule.\n\n~~~~markdown\n## \u003CPart name>: \u003Cwhat it does for the user, max 10 words>\n\n**Decision needed:** \u003Cone sentence>. The answer changes \u003Cwhat>.\n\n**Terms**\n- **\u003Cterm>**: \u003Cmax 20 words>. Code: `\u003Cidentifier>`.\n- **\u003Cterm>**: \u003Cmax 20 words>.\n\n**What it is**\n\u003Cmax 3 sentences. Name the actor. One fact per sentence.>\n\n**Definition**\n~~~\u003Clang>\n\u003Cthe smallest type, interface, schema, or command shape that shows the choice>\n~~~\n\n**Example**\n~~~\n\u003Cone realistic before and after, or input and output>\n~~~\n\n**Diagram**\n~~~\n\u003CASCII, plain labels, no em-dash>\n~~~\n\n**Options**\n\n| Option | What happens | Cost |\n|---|---|---|\n| \u003Clabel, max 6 words> | \u003Cone sentence> | \u003Cone sentence> |\n| \u003Clabel> | \u003Cone sentence> | \u003Cone sentence> |\n\n**Recommendation:** \u003Coption>, because \u003Cone reason>.\n~~~~\n\nThen, in the next turn:\n\n~~~\n`request_user_decision`: '\u003Cquestion, max 20 words>'\noptions: the same labels, with the 'what happens' and 'cost' text repeated in each description, because the picker can hide the table.\n~~~\n\nOne component per call. Use multi-select only when the options combine. Always add one open-ended feedback question.\n\n### Degrade when the question tool is weak\n\nSome hosts expose a weak question tool: it takes one question per call, it has no multi-select, or its picker hides option descriptions. Degrade in this order:\n\n1. Ask one question.\n2. Phrase the options as a single-select choice.\n3. State the assumption you will use if the answer is unavailable.\n\nPut the assumption in the text turn that grounds the question, not inside the options. An assumption never satisfies a user gate: a gated phase waits for the user's answer. The question still asks for one decision, and the recommendation names the cost of the assumption.\n\n### Pre-send check for a question\n\nRun this list before you send a question. It tests the question rules in this fragment. The wording pre-send check is in Writing to the User.\n\n1. Before a question: did the reader already see what the thing is, its definition, and one example, in an earlier turn or an earlier block?\n2. Can the reader choose from the options alone, with no other document? Is the recommendation outside the options?\n\n## When to Use\n\nPlan ratified and user has approved proceeding with implementation.\n\n## Handoff Template\n\nUse the required handoff fields in [architect](..\u002Farchitect\u002FSKILL.md). That skill renders the list from the handoff registry; this template renders from the same registry.\n\nStorage: the handoff is authored directly in the **HANDOFF Pasture task body** (no filesystem path; the task body IS the handoff).\n\n```markdown\n# Handoff: Architect → Supervisor\n\n## Supervisor Startup\n1. Call `skill(\u002Fpasture:supervisor)` to load your role instructions\n2. Spawn ephemeral Explore subagents with the task tool when codebase exploration is needed\n3. Read each reference under References with the command beside it, before you plan\n4. Every vertical slice MUST have leaf tasks — any number, named after the real work units\n\n## References\n- Request: \"${REQUEST_ID_URI}\" — read with `\"${EPOCH_REC}\" show \"${REQUEST_ID_URI}\"`\n- URD: \"${URD_ID_URI}\" — read with `\"${EPOCH_REC}\" show \"${URD_ID_URI}\"`\n- Proposal: \"${RATIFIED_PROPOSAL_ID_URI}\" — read with `\"${EPOCH_REC}\" show \"${RATIFIED_PROPOSAL_ID_URI}\"`\n- Ratified Plan: \"${RATIFIED_PLAN_ID_URI}\" — read with `\"${EPOCH_REC}\" show \"${RATIFIED_PLAN_ID_URI}\"`\n\n## Context\n\u003Ccontext>\n\n## Key Decisions\n\u003Ckey-decisions>\n\n## Open Items\n\u003Copen-items>\n\n## Acceptance Criteria\n\u003Cacceptance-criteria>\n```\n\n\n## Steps\n\n1. Create the HANDOFF Pasture task — its body IS the handoff document (use the template above):\n   ```bash\n   HANDOFF_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"HANDOFF: Architect → Supervisor for REQUEST\" --phase handoff --priority 2 \\\n     --body=\"---\nreferences:\n  request: \"${REQUEST_ID_URI}\"\n  urd: \"${URD_ID_URI}\"\n  proposal: \"${RATIFIED_PROPOSAL_ID_URI}\"\n  ratified_plan: \"${RATIFIED_PLAN_ID_URI}\"\n---\n# Handoff: Architect → Supervisor\n\u003Cfull handoff body per the template above>\")\n   \"${EPOCH_REC}\" label \"$HANDOFF_ID_URI\" pasture:p7-plan:s7-handoff\n\n   ```\n\n2. Delegate the supervisor with the task operation (the IMPL_PLAN phase runs under the supervisor):\n   ```\n   delegate the implementation-plan owner, then give it the self-contained assignment below\n   ```\n\n3. Monitor supervisor progress:\n   ```bash\n   # Check pasture status\n   \"${EPOCH_REC}\" query --status=in_progress\n   ```\n\n   A supervisor that looks idle right after spawn is usually running Explore subagents — do **not** shut it down pre-emptively.\n\n## Example Prompt\n\n**CRITICAL:** The send_assignment_message assignment MUST instruct the supervisor to invoke `\u002Fpasture:supervisor` as its first action. Without this, the supervisor agent starts without its role instructions and skips leaf task creation, ephemeral exploration, and other critical procedures.\n\n```\nStart by calling `skill(\u002Fpasture:supervisor)` to load your role instructions.\n\nImplement the ratified plan for \u003Cfeature name>.\n\n## Context\n- REQUEST: \"${REQUEST_ID_URI}\"\n- URD: \"${URD_ID_URI}\" (read with `\"${EPOCH_REC}\" show \"${URD_ID_URI}\"` for user requirements)\n- RATIFIED PROPOSAL: \"${RATIFIED_PROPOSAL_ID_URI}\"\n- HANDOFF: \"${HANDOFF_ID_URI}\" (the handoff body — read with `\"${EPOCH_REC}\" show \"${HANDOFF_ID_URI}\"`)\n\n## Summary\n\u003C1-2 sentence summary of what needs to be implemented>\n\n## Key Files\n\u003Clist main files to be created\u002Fmodified from the ratified plan>\n\n## Acceptance Criteria\n\u003CGiven\u002FWhen\u002FThen criteria from the ratified plan>\n\n## Reminders\n1. Call `skill(\u002Fpasture:supervisor)` FIRST — do not proceed without loading your role\n2. Spawn ephemeral Explore subagents with the task tool when codebase exploration is needed\n3. Every vertical slice MUST have leaf tasks — any number, named after the real work units (the L1\u002FL2\u002FL3 triple is only illustrative); a slice without leaf tasks is undecomposed\n4. Read the ratified plan with `\"${EPOCH_REC}\" show \"${RATIFIED_PROPOSAL_ID_URI}\"` and the URD with `\"${EPOCH_REC}\" show \"${URD_ID_URI}\"`\n```\n\nDeliver this assignment to the supervisor when you delegate it:\n\n```\nsend_assignment_message({\n  to: \"supervisor\",\n  message: `Start by calling skill(\u002Fpasture:supervisor) to load your role instructions.\n\nImplement the ratified plan for User Authentication.\n\n## Context\n- REQUEST: ${REQUEST_ID_URI}\n- URD: \"${URD_ID_URI}\"\n- RATIFIED PROPOSAL: \"${RATIFIED_PROPOSAL_ID_URI}\"\n- HANDOFF: \"${HANDOFF_ID_URI}\" (read with \"${EPOCH_REC}\" show \"${HANDOFF_ID_URI}\")\n\n## Summary\nAdd JWT-based authentication with login\u002Flogout endpoints and middleware.\n\n## Key Files\n- pkg\u002Fauth\u002Fjwt.go\n- pkg\u002Fauth\u002Fmiddleware.go\n- cmd\u002Fapi\u002Fauth.go\n\n## Acceptance Criteria\nGiven a valid JWT token when accessing protected routes then allow access\nGiven an expired token when accessing protected routes then return 401\n\n## Reminders\n1. Call skill(\u002Fpasture:supervisor) FIRST\n2. Spawn ephemeral Explore subagents with the task tool when codebase exploration is needed\n3. Every slice MUST have leaf tasks (any number; L1\u002FL2\u002FL3 is only illustrative)\n4. Read ratified plan: \"${EPOCH_REC}\" show \"${RATIFIED_PROPOSAL_ID_URI}\" and URD: \"${EPOCH_REC}\" show \"${URD_ID_URI}\"`,\n  summary: \"IMPL_PLAN assignment with Pasture context\"\n})\n```\n\n## Delegation Notes\n\n- Delegate the supervisor (and the workers it will coordinate) as **T1 frontier** assignments — the IMPL_PLAN phase benefits from the frontier tier for decomposition and review.\n- A delegated assignment has **zero prior context**: every assignment MUST be self-contained (call `skill(\u002Fpasture:supervisor)`, the Pasture task IDs, and `\"${EPOCH_REC}\" show` commands to fetch full requirements).\n- Do not spawn the supervisor for the IMPL_PLAN phase except through this handoff.\n\n## IMPORTANT\n\n- **DO NOT** skip the handoff and spawn the supervisor for the IMPL_PLAN phase — delegate it with the task operation\n- **DO NOT** create implementation tasks yourself - the supervisor creates vertical slice tasks\n- **DO NOT** implement the plan yourself - your role is handoff and monitoring\n- **DO NOT** shut down a supervisor that appears idle right after spawn — it is usually running Explore subagents\n- The supervisor reads the ratified plan and determines vertical slice structure\n- Architect monitors for blockers or escalations\n\n## Follow-up Lifecycle (h1 Reuse)\n\nThis handoff (h1: Architect → Supervisor) also occurs after FOLLOWUP_PROPOSAL is ratified. In follow-up context:\n\n- **Storage:** the follow-up handoff is authored in its own HANDOFF Pasture task body (no filesystem path)\n- **References:** keep `urd: \"${URD_ID_URI}\"` and add `followup_urd: \"${FOLLOWUP_URD_ID_URI}\"`, then read each with `\"${EPOCH_REC}\" show`\n- **Context:** Summary of FOLLOWUP_PROPOSAL ratification and the user-DEFER'd UAT items the follow-up addresses\n- **Next step:** Supervisor creates the follow-up plan and the follow-up slices for that scope\n\u003C!-- END GENERATED FROM pasture schema -->\n",{"name":5,"description":7},"main","5813de22110ddc609b465a982b4811646ff72d18","internal\u002Ftarget\u002Fopencode\u002Fassets\u002Fskills\u002Farchitect-handoff",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":41,"prompt":51,"zipAvailable":52},[42,45,48],{"tool":43,"command":44},"npx","npx skills add dayvidpham\u002Fpasture --skill architect-handoff",{"tool":46,"command":47},"bunx","bunx skills add dayvidpham\u002Fpasture --skill architect-handoff",{"tool":49,"command":50},"pnpm","pnpm dlx skills add dayvidpham\u002Fpasture --skill architect-handoff","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Finternal\u002Ftarget\u002Fopencode\u002Fassets\u002Fskills\u002Farchitect-handoff\u002FSKILL.md",true,[],[55,63,79,89,101,111],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":27},"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",[],[57,62],"fixture skill",{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":27},"01M6DAP48A4K365N83NBG0GFVC","worker","Vertical slice implementer (full production code path)","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker\u002FSKILL.md",[],[65,70,71,72,73,74,75,76,77,78],"implementer","code","implement","Production","full","complete","vertical slice","slice","path",{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":27},"01M6DAP18QJM7P7N31TYGNJBCP","worker-implement","Implement assigned vertical slice following TDD layers","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-implement\u002FSKILL.md",[],[86,65,72,76,87,77,88],"worker implement","layers","tdd",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":27},"01M6DANYHC7P63RFEN26F70MC2","worker-complete","Signal slice completion after quality gates pass","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-complete\u002FSKILL.md",[],[65,96,75,97,77,98,99,100],"worker complete","signal","gates","quality","quality gates",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":27},"01M6DANWZ31TRP4NN4T1BFYKSR","worker-blocked","Report a blocker to supervisor via Pasture","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-blocked\u002FSKILL.md",[],[108,65,109,110,25],"worker blocked","via","report",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":122,"publishedAt":27},"01M6DANSVDBXBFH93B6EX3H2QK","user-uat","User Acceptance Testing with demonstrative examples","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fuser-uat\u002FSKILL.md",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[123,124,125,126,127,128,129,130,131],"uat","user uat","user","acceptance testing","with","user acceptance testing","examples","acceptance","testing"]