[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70PPVS3CW9RYWGZ4KSNV7MV":3,"skill-same:01M70PPVS3CW9RYWGZ4KSNV7MV":66},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":6,"updatedAt":51,"install":52,"resources":65},"01M70PPVS3CW9RYWGZ4KSNV7MV","afk-implement",null,"Run an unattended (\"AFK\") implementation session as the supervisor — scope small progressive iterations, push feature branches, open pull requests, drive review waves to clean, and never merge. Use when the user says they are going AFK or to bed, asks for overnight autonomous implementation, says \"don't block on me\", \"open PRs but don't merge\", \"progressive adoption\", or \"stack changes\".","dayvidpham\u002Faura-plugins","dayvidpham","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F22456875?v=4","01M6CHR0F6J2M4QEHFR85XRNSR","David Huu Pham","01M6CHR0KQJ4DK5KSZ9TRTP7DW",2,"MIT","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fafk-implement\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"implement","afk implement","pull","but","overnight","unattended","merge","run","me","stack","pull requests","review","when","autonomous","open","branches","clean","scope","never","bed","2026-11-10 10:12:30",false,"---\nname: afk-implement\ndescription: Run an unattended (\"AFK\") implementation session as the supervisor — scope small progressive iterations, push feature branches, open pull requests, drive review waves to clean, and never merge. Use when the user says they are going AFK or to bed, asks for overnight autonomous implementation, says \"don't block on me\", \"open PRs but don't merge\", \"progressive adoption\", or \"stack changes\".\n---\n\n# AFK implement\n\nYou are the supervisor for an unattended session. The human is away and will\nreview later. Turn the approved direction into a small stack of review-ready\npull requests, with evidence, then **stop**.\n\nSuccess is: every scoped iteration has an open PR, the final review wave is\nclean, and the morning handoff says what to merge in which order. Success is\n**not** \"CI is green\", \"I found more work\", or \"I merged it\". Do not merge. Do\nnot expand scope. Do not keep going after clean.\n\n## Load first\n\n- `supervisor` — role and phase ownership.\n- `impl-review`, `reviewer`, `reviewer-review-code` — review waves and severity.\n- `pasture-usage` — tracker store, namespace, author, gotchas.\n- Repo `AGENTS.md` \u002F `CLAUDE.md`, `Makefile`, CI config, and the default branch.\n- Live tracker state for the repository namespace.\n\nIf a generated protocol skill conflicts with this file, this file wins on the\nAFK gate (no live human UAT, no merge) and loses on safety, tracker, commit, and\nworktree rules.\n\n## Invocation contract\n\nMap the user's words to these defaults, and state the mapping in the handoff.\n\n| The user says | Default |\n|---|---|\n| \"act as the supervisor\" | Own the implementation and review loop; spawn workers\u002Freviewers instead of doing every part serially when parallel work is safe. |\n| \"use `\u003Cmodel>` for all subagents\" | Resolve the exact `provider\u002Fmodel` ID with the harness before spawning (in OpenCode, the models tool). Pass it as `model` on every subagent call. If the invocation names a variant\u002Feffort, pass that too. |\n| \"scope smaller; minimal code; YAGNI\" | One smallest end-to-end change per iteration. No speculative flags, config, abstractions, or refactors. No drive-by edits. |\n| \"progressive adoption\" | Each iteration must be independently reviewable and revertable. Prefer several small PRs over one large one. |\n| \"once one iteration is done, proceed to the next and stack changes on top\" | Finish iteration 1 through a clean review wave, then start iteration 2 on top of it only when it depends on it; otherwise branch from the default branch. |\n| \"open PRs... don't merge\" | Push the branch and open a ready PR. Never merge, never self-approve on the human's behalf, never push to the default branch. |\n| \"stop when the PRs are open and we end on a clean review wave\" | The exit criteria below, not an open-ended backlog burn. |\n| \"handle architecture and design questions sensibly\" | Decide from the repo and the user's stated goal; record the decision and rationale. Do not ask. |\n| \"don't block on raising things to me\" | Continue past anything reversible. Only the hard stops below end or pause the run. |\n| \"I'll review in the morning\" | Write a handoff that is readable in five minutes, with merge order and risks. |\n\nResolve model IDs rather than echoing them. For example,\n`deepseek\u002Fdeepseek-v4.1-flash-1017` as named by a user is the model whose\nharness ID is `deepseek\u002Fdeepseek-flash` (DeepSeek V4.1 Flash 1017). If no exact\nID resolves, use the nearest same-family ID and record the substitution in the\nhandoff. Never silently downgrade.\n\n## Non-negotiables\n\n- **No merges.** Not with green CI, not with clean review, not \"just this one\".\n  The human merges in the morning.\n- **No pushes to the default\u002Fprotected branch.** Feature branches only.\n- **No shared-history rewrites.** `--force-with-lease` is allowed only on your\n  own feature branch, and only when rebasing a stack onto its updated base.\n- **No destructive commands** (`rm -rf`, history rewrites, branch deletion,\n  data deletion). No Git hook installs or `core.hooksPath` changes.\n- **Preserve the user's work.** Do not clean, stash, or reset a dirty primary\n  checkout. Work in a worktree.\n- **No fake reviews.** Reviewers must be independent subagents. Never write\n  their comments or votes yourself, and never claim consensus you did not get.\n- **Never claim an unrun gate passed.** Report what ran, on which tree.\n\n## Iteration loop\n\nWork one iteration at a time. Each iteration ships a PR before the next begins.\n\n0. **Recover.** Check live tracker state, `git status`, local branches ahead of\n   the base, existing worktrees, and open PRs. If the user said \"work on this\",\n   the work may already exist locally: inventory it instead of restarting.\n1. **Choose the next iteration.** Follow the user's named scope first. Otherwise\n   prefer, in order: a failing test or reproduction, a correctness bug, the\n   smallest missing piece of the approved feature, then cleanup that unblocks\n   the feature. Do not invent new product scope.\n2. **Plan in one paragraph.** Change, files, test, acceptance case, risk,\n   base branch. If it does not fit in a paragraph, it is too big — split it.\n3. **Worktree.** Use the repository's naming and isolation convention\n   (`\u003Crepo>-\u003Cissue#>--\u003Ctype>--\u003Cwords>`, branch = directory name). Never work in\n   the primary checkout.\n4. **Implement.** Reproduce or write the failing test first when practical, then\n   the smallest production change that satisfies it. Keep the diff inside the\n   iteration's boundary.\n5. **Verify.** Run the repository's declared gates for the touched surface, then\n   the full gate if cheap. Go repos: `make fmt`, `make lint`, `make test-race`,\n   `make build` (or the documented equivalents). Record exact commands and\n   outcomes.\n6. **Commit.** Atomic commit with `git agent-commit -m \"\u003Cconventional>\"`. Stage\n   only files this iteration owns. Reference the acceptance case in the body.\n7. **Push and open the PR.** Ready (not draft) so CI runs. Fill the PR shape\n   below.\n8. **Review wave.** Spawn three independent reviewers in parallel with the\n   resolved model. Fix blockers and importants, re-review. Repeat up to three\n   cycles.\n9. **Record evidence.** Comment the commit, PR URL, gate results, and review\n   rounds on the iteration's tracker task. Then, and only then, start the next\n   iteration.\n\n### Resuming existing work\n\nWhen feature branches already exist: map each branch\u002Fworktree to an iteration,\nrun gates on each, push, and open the missing PRs. Preserve unfinished work and\noriginal failure evidence. Do not rebase someone else's branch or delete a\nworktree you did not create; ask is not available, so leave it alone and note it.\n\n## PR shape\n\n- Title: conventional commit style, scoped to the change.\n- Body, in this order:\n  1. **What \u002F why** — one paragraph.\n  2. **Scope boundary** — what this PR deliberately does *not* do.\n  3. **Acceptance** — the Given\u002FWhen\u002FThen case, or the observed before\u002Fafter.\n  4. **Verification** — exact commands and results, including CI status.\n  5. **Stack** — `1 of 3`, base branch, and merge order, or `standalone`.\n  6. **Decisions** — choice, rationale, alternatives, reversibility.\n  7. **Known gaps** — residual findings, flaky tests, unverified paths.\n- If blocked, mark the PR draft and put the blocker and the exact next action in\n  the body. Do not leave a broken PR presented as ready.\n- Never merge or close the PR. Leave review state and merge order for the human.\n\n## Stacking\n\n- Branch from the previous iteration only when the change depends on it.\n  Otherwise branch from the default branch to keep each PR independently\n  adoptable.\n- Name the base branch in the PR body and in the handoff. Merge order is\n  bottom-up.\n- When the base moves, rebase only your own branches and push with\n  `--force-with-lease`. Re-run gates after every rebase.\n- Prefer not stacking. If two iterations touch the same files, they are probably\n  one iteration.\n\n## Review wave\n\nSpawn three reviewers in parallel, each with the same inputs but a distinct\naxis:\n\n| Axis | Ask |\n|---|---|\n| A — Correctness | Does the diff do what the PR claims, without breaking existing behavior? Edge cases, error paths, data loss, concurrency. |\n| B — Tests | Do tests exercise the production path (not a test-only export)? Do they cover failure cases and the acceptance case? Would they catch a regression? Are they flaky? |\n| C — Elegance \u002F YAGNI | Is the complexity proportional? Any speculative abstraction, unused flag, duplicated logic, or scope creep? Is there a materially smaller change? |\n\nGive each reviewer: the PR URL, `base...head` diff, acceptance case, repo gate\ncommands, and the scope boundary. Require findings as\n`severity (blocker|important|minor) — file:line — problem — concrete fix`, and a\nbinary vote: `ACCEPT` or `REVISE`.\n\nA **clean wave** is all three `ACCEPT` with zero blocker and zero important\nfindings. Minor findings are fixed if trivial, otherwise recorded as follow-up.\n\n- Fix blockers and importants in the same branch, commit atomically, push, and\n  re-run the wave. Max three cycles per PR.\n- If a blocker survives three cycles, mark the PR draft, write the exact blocker\n  and attempted fixes, and move to independent work. Do not merge.\n- After the final iteration, run one **cross-stack** wave over all open PRs (or\n  the cumulative diff): conflicting assumptions, duplicated helpers, merge-order\n  breakage. This is the wave that must end clean before you stop.\n- Reviewers are ephemeral. If the harness cannot spawn them, stop and report —\n  do not substitute self-review and call it clean.\n\n## Decisions\n\nPrecedence, highest first:\n\n1. The user's explicit request and the repo's documented invariants.\n2. Existing repo conventions (naming, error style, test patterns, gates).\n3. The smallest, most reversible option.\n4. A prototype behind no public API.\n\nFor every non-obvious choice, record in the PR body: the decision, why, the\nalternatives considered, and how to reverse it. If two options are plausible and\nreversible, pick the smaller one and keep moving. Do not stop to ask.\n\nReasonable autonomy includes: naming, file placement, test shape, helper\nextraction, error wording, choosing between equivalent libraries already in the\nrepo, and splitting or merging iterations.\n\n## Hard stops\n\nStop the current line of work, leave a clear note, and continue only with\nindependent iterations when one of these is true:\n\n- Credentials, permissions, a paid resource, or a secret is required.\n- The action is irreversible or destructive: rewriting shared history, deleting\n  data or branches, installing\u002Faltering Git hooks, force-pushing a shared branch.\n- It reaches production: deploy, release, publish, tag, or migrate live data.\n- Product intent is genuinely ambiguous and both options change user-facing\n  behavior irreversibly.\n- The change is security-sensitive and there is no safe default.\n\nNot hard stops: failing tests, flaky tests, CI infrastructure outages, merge\nconflicts inside your own stack, missing documentation, an unavailable model\n(fall back and record), or an unpleasant design tradeoff.\n\n## Verification and evidence\n\n- Discover gates from `AGENTS.md` \u002F `CLAUDE.md` \u002F `Makefile` \u002F CI. Run the\n  narrow gate while iterating, the full gate before calling a PR ready.\n- Docs-only changes still run docs\u002Flink\u002Ffrontmatter checks.\n- If CI cannot run, say so explicitly and report local results instead. Never\n  claim green from a job that did not execute.\n- Keep the tree quiescent while verifying. Record the commit SHA the results\n  apply to.\n\n## Tracking\n\n- One tracker task per iteration, linked to the parent scope. Labels and\n  comments are additive; never delete audit history.\n- Comment: branch, commit SHA, PR URL, gate results, review rounds and votes.\n- Workers report evidence and never close their own tasks. Close only after the\n  clean wave, and only for work you supervised and verified.\n- If the tracker is unavailable, report the store path, failed operation, and\n  repair needed, then continue with Git and PR evidence. A broken query is not\n  proof of no work.\n\n## Morning handoff\n\nWrite `.agents.local\u002Fafk-\u003CYYYY-MM-DD>.md` (or the repo's existing handoff\ndirectory) and repeat the essentials in the final message:\n\n1. **State** — why the run stopped, what is ready, what is not.\n2. **PR table** — link, one-line summary, base, stack position, CI, review\n   wave result, recommended merge order.\n3. **Decisions** — choice and rationale for each non-obvious call.\n4. **Risks** — residual findings, unverified paths, flaky or skipped gates.\n5. **Scope boundary** — what you deliberately did not do.\n6. **First three checks** — the fastest way for the human to validate the work.\n\nNo \"done\" or \"shipped\" language for unmerged work. Say \"open, review clean,\nawaiting merge\".\n\n## Exit criteria\n\nStop the session when all of these are true:\n\n- Every scoped iteration has an open PR, or is explicitly marked draft with a\n  hard-stop reason.\n- The final cross-stack review wave is clean: three `ACCEPT`, zero blockers,\n  zero importants — or the three-cycle budget is exhausted and the residual\n  findings are recorded.\n- The morning handoff is written and names the merge order.\n- No merge occurred, the default branch is untouched, and no unrelated work was\n  modified.\n\nThen stop and report. Do not start new scope, do not \"while I'm here\" anything,\nand do not wait or poll for the human.\n\n## Anti-patterns\n\n- Merging because CI is green, or because the user seemed to want speed.\n- One giant PR that cannot be adopted progressively.\n- Silencing, skipping, or deleting a failing test to reach green.\n- Refactoring adjacent code because it was \"right there\".\n- Asking the user a question mid-run and idling; or worse, blocking forever.\n- Calling a wave clean without independent reviewers or without reading their\n  findings.\n- Expanding the backlog instead of stopping at the approved scope.\n- Leaving a red or draft PR described as ready in the handoff.\n","# AFK implement\n\nYou are the supervisor for an unattended session. The human is away and will\nreview later. Turn the approved direction into a small stack of review-ready\npull requests, with evidence, then **stop**.\n\nSuccess is: every scoped iteration has an open PR, the final review wave is\nclean, and the morning handoff says what to merge in which order. Success is\n**not** \"CI is green\", \"I found more work\", or \"I merged it\". Do not merge. Do\nnot expand scope. Do not keep going after clean.\n\n## Load first\n\n- `supervisor` — role and phase ownership.\n- `impl-review`, `reviewer`, `reviewer-review-code` — review waves and severity.\n- `pasture-usage` — tracker store, namespace, author, gotchas.\n- Repo `AGENTS.md` \u002F `CLAUDE.md`, `Makefile`, CI config, and the default branch.\n- Live tracker state for the repository namespace.\n\nIf a generated protocol skill conflicts with this file, this file wins on the\nAFK gate (no live human UAT, no merge) and loses on safety, tracker, commit, and\nworktree rules.\n\n## Invocation contract\n\nMap the user's words to these defaults, and state the mapping in the handoff.\n\n| The user says | Default |\n|---|---|\n| \"act as the supervisor\" | Own the implementation and review loop; spawn workers\u002Freviewers instead of doing every part serially when parallel work is safe. |\n| \"use `\u003Cmodel>` for all subagents\" | Resolve the exact `provider\u002Fmodel` ID with the harness before spawning (in OpenCode, the models tool). Pass it as `model` on every subagent call. If the invocation names a variant\u002Feffort, pass that too. |\n| \"scope smaller; minimal code; YAGNI\" | One smallest end-to-end change per iteration. No speculative flags, config, abstractions, or refactors. No drive-by edits. |\n| \"progressive adoption\" | Each iteration must be independently reviewable and revertable. Prefer several small PRs over one large one. |\n| \"once one iteration is done, proceed to the next and stack changes on top\" | Finish iteration 1 through a clean review wave, then start iteration 2 on top of it only when it depends on it; otherwise branch from the default branch. |\n| \"open PRs... don't merge\" | Push the branch and open a ready PR. Never merge, never self-approve on the human's behalf, never push to the default branch. |\n| \"stop when the PRs are open and we end on a clean review wave\" | The exit criteria below, not an open-ended backlog burn. |\n| \"handle architecture and design questions sensibly\" | Decide from the repo and the user's stated goal; record the decision and rationale. Do not ask. |\n| \"don't block on raising things to me\" | Continue past anything reversible. Only the hard stops below end or pause the run. |\n| \"I'll review in the morning\" | Write a handoff that is readable in five minutes, with merge order and risks. |\n\nResolve model IDs rather than echoing them. For example,\n`deepseek\u002Fdeepseek-v4.1-flash-1017` as named by a user is the model whose\nharness ID is `deepseek\u002Fdeepseek-flash` (DeepSeek V4.1 Flash 1017). If no exact\nID resolves, use the nearest same-family ID and record the substitution in the\nhandoff. Never silently downgrade.\n\n## Non-negotiables\n\n- **No merges.** Not with green CI, not with clean review, not \"just this one\".\n  The human merges in the morning.\n- **No pushes to the default\u002Fprotected branch.** Feature branches only.\n- **No shared-history rewrites.** `--force-with-lease` is allowed only on your\n  own feature branch, and only when rebasing a stack onto its updated base.\n- **No destructive commands** (`rm -rf`, history rewrites, branch deletion,\n  data deletion). No Git hook installs or `core.hooksPath` changes.\n- **Preserve the user's work.** Do not clean, stash, or reset a dirty primary\n  checkout. Work in a worktree.\n- **No fake reviews.** Reviewers must be independent subagents. Never write\n  their comments or votes yourself, and never claim consensus you did not get.\n- **Never claim an unrun gate passed.** Report what ran, on which tree.\n\n## Iteration loop\n\nWork one iteration at a time. Each iteration ships a PR before the next begins.\n\n0. **Recover.** Check live tracker state, `git status`, local branches ahead of\n   the base, existing worktrees, and open PRs. If the user said \"work on this\",\n   the work may already exist locally: inventory it instead of restarting.\n1. **Choose the next iteration.** Follow the user's named scope first. Otherwise\n   prefer, in order: a failing test or reproduction, a correctness bug, the\n   smallest missing piece of the approved feature, then cleanup that unblocks\n   the feature. Do not invent new product scope.\n2. **Plan in one paragraph.** Change, files, test, acceptance case, risk,\n   base branch. If it does not fit in a paragraph, it is too big — split it.\n3. **Worktree.** Use the repository's naming and isolation convention\n   (`\u003Crepo>-\u003Cissue#>--\u003Ctype>--\u003Cwords>`, branch = directory name). Never work in\n   the primary checkout.\n4. **Implement.** Reproduce or write the failing test first when practical, then\n   the smallest production change that satisfies it. Keep the diff inside the\n   iteration's boundary.\n5. **Verify.** Run the repository's declared gates for the touched surface, then\n   the full gate if cheap. Go repos: `make fmt`, `make lint`, `make test-race`,\n   `make build` (or the documented equivalents). Record exact commands and\n   outcomes.\n6. **Commit.** Atomic commit with `git agent-commit -m \"\u003Cconventional>\"`. Stage\n   only files this iteration owns. Reference the acceptance case in the body.\n7. **Push and open the PR.** Ready (not draft) so CI runs. Fill the PR shape\n   below.\n8. **Review wave.** Spawn three independent reviewers in parallel with the\n   resolved model. Fix blockers and importants, re-review. Repeat up to three\n   cycles.\n9. **Record evidence.** Comment the commit, PR URL, gate results, and review\n   rounds on the iteration's tracker task. Then, and only then, start the next\n   iteration.\n\n### Resuming existing work\n\nWhen feature branches already exist: map each branch\u002Fworktree to an iteration,\nrun gates on each, push, and open the missing PRs. Preserve unfinished work and\noriginal failure evidence. Do not rebase someone else's branch or delete a\nworktree you did not create; ask is not available, so leave it alone and note it.\n\n## PR shape\n\n- Title: conventional commit style, scoped to the change.\n- Body, in this order:\n  1. **What \u002F why** — one paragraph.\n  2. **Scope boundary** — what this PR deliberately does *not* do.\n  3. **Acceptance** — the Given\u002FWhen\u002FThen case, or the observed before\u002Fafter.\n  4. **Verification** — exact commands and results, including CI status.\n  5. **Stack** — `1 of 3`, base branch, and merge order, or `standalone`.\n  6. **Decisions** — choice, rationale, alternatives, reversibility.\n  7. **Known gaps** — residual findings, flaky tests, unverified paths.\n- If blocked, mark the PR draft and put the blocker and the exact next action in\n  the body. Do not leave a broken PR presented as ready.\n- Never merge or close the PR. Leave review state and merge order for the human.\n\n## Stacking\n\n- Branch from the previous iteration only when the change depends on it.\n  Otherwise branch from the default branch to keep each PR independently\n  adoptable.\n- Name the base branch in the PR body and in the handoff. Merge order is\n  bottom-up.\n- When the base moves, rebase only your own branches and push with\n  `--force-with-lease`. Re-run gates after every rebase.\n- Prefer not stacking. If two iterations touch the same files, they are probably\n  one iteration.\n\n## Review wave\n\nSpawn three reviewers in parallel, each with the same inputs but a distinct\naxis:\n\n| Axis | Ask |\n|---|---|\n| A — Correctness | Does the diff do what the PR claims, without breaking existing behavior? Edge cases, error paths, data loss, concurrency. |\n| B — Tests | Do tests exercise the production path (not a test-only export)? Do they cover failure cases and the acceptance case? Would they catch a regression? Are they flaky? |\n| C — Elegance \u002F YAGNI | Is the complexity proportional? Any speculative abstraction, unused flag, duplicated logic, or scope creep? Is there a materially smaller change? |\n\nGive each reviewer: the PR URL, `base...head` diff, acceptance case, repo gate\ncommands, and the scope boundary. Require findings as\n`severity (blocker|important|minor) — file:line — problem — concrete fix`, and a\nbinary vote: `ACCEPT` or `REVISE`.\n\nA **clean wave** is all three `ACCEPT` with zero blocker and zero important\nfindings. Minor findings are fixed if trivial, otherwise recorded as follow-up.\n\n- Fix blockers and importants in the same branch, commit atomically, push, and\n  re-run the wave. Max three cycles per PR.\n- If a blocker survives three cycles, mark the PR draft, write the exact blocker\n  and attempted fixes, and move to independent work. Do not merge.\n- After the final iteration, run one **cross-stack** wave over all open PRs (or\n  the cumulative diff): conflicting assumptions, duplicated helpers, merge-order\n  breakage. This is the wave that must end clean before you stop.\n- Reviewers are ephemeral. If the harness cannot spawn them, stop and report —\n  do not substitute self-review and call it clean.\n\n## Decisions\n\nPrecedence, highest first:\n\n1. The user's explicit request and the repo's documented invariants.\n2. Existing repo conventions (naming, error style, test patterns, gates).\n3. The smallest, most reversible option.\n4. A prototype behind no public API.\n\nFor every non-obvious choice, record in the PR body: the decision, why, the\nalternatives considered, and how to reverse it. If two options are plausible and\nreversible, pick the smaller one and keep moving. Do not stop to ask.\n\nReasonable autonomy includes: naming, file placement, test shape, helper\nextraction, error wording, choosing between equivalent libraries already in the\nrepo, and splitting or merging iterations.\n\n## Hard stops\n\nStop the current line of work, leave a clear note, and continue only with\nindependent iterations when one of these is true:\n\n- Credentials, permissions, a paid resource, or a secret is required.\n- The action is irreversible or destructive: rewriting shared history, deleting\n  data or branches, installing\u002Faltering Git hooks, force-pushing a shared branch.\n- It reaches production: deploy, release, publish, tag, or migrate live data.\n- Product intent is genuinely ambiguous and both options change user-facing\n  behavior irreversibly.\n- The change is security-sensitive and there is no safe default.\n\nNot hard stops: failing tests, flaky tests, CI infrastructure outages, merge\nconflicts inside your own stack, missing documentation, an unavailable model\n(fall back and record), or an unpleasant design tradeoff.\n\n## Verification and evidence\n\n- Discover gates from `AGENTS.md` \u002F `CLAUDE.md` \u002F `Makefile` \u002F CI. Run the\n  narrow gate while iterating, the full gate before calling a PR ready.\n- Docs-only changes still run docs\u002Flink\u002Ffrontmatter checks.\n- If CI cannot run, say so explicitly and report local results instead. Never\n  claim green from a job that did not execute.\n- Keep the tree quiescent while verifying. Record the commit SHA the results\n  apply to.\n\n## Tracking\n\n- One tracker task per iteration, linked to the parent scope. Labels and\n  comments are additive; never delete audit history.\n- Comment: branch, commit SHA, PR URL, gate results, review rounds and votes.\n- Workers report evidence and never close their own tasks. Close only after the\n  clean wave, and only for work you supervised and verified.\n- If the tracker is unavailable, report the store path, failed operation, and\n  repair needed, then continue with Git and PR evidence. A broken query is not\n  proof of no work.\n\n## Morning handoff\n\nWrite `.agents.local\u002Fafk-\u003CYYYY-MM-DD>.md` (or the repo's existing handoff\ndirectory) and repeat the essentials in the final message:\n\n1. **State** — why the run stopped, what is ready, what is not.\n2. **PR table** — link, one-line summary, base, stack position, CI, review\n   wave result, recommended merge order.\n3. **Decisions** — choice and rationale for each non-obvious call.\n4. **Risks** — residual findings, unverified paths, flaky or skipped gates.\n5. **Scope boundary** — what you deliberately did not do.\n6. **First three checks** — the fastest way for the human to validate the work.\n\nNo \"done\" or \"shipped\" language for unmerged work. Say \"open, review clean,\nawaiting merge\".\n\n## Exit criteria\n\nStop the session when all of these are true:\n\n- Every scoped iteration has an open PR, or is explicitly marked draft with a\n  hard-stop reason.\n- The final cross-stack review wave is clean: three `ACCEPT`, zero blockers,\n  zero importants — or the three-cycle budget is exhausted and the residual\n  findings are recorded.\n- The morning handoff is written and names the merge order.\n- No merge occurred, the default branch is untouched, and no unrelated work was\n  modified.\n\nThen stop and report. Do not start new scope, do not \"while I'm here\" anything,\nand do not wait or poll for the human.\n\n## Anti-patterns\n\n- Merging because CI is green, or because the user seemed to want speed.\n- One giant PR that cannot be adopted progressively.\n- Silencing, skipping, or deleting a failing test to reach green.\n- Refactoring adjacent code because it was \"right there\".\n- Asking the user a question mid-run and idling; or worse, blocking forever.\n- Calling a wave clean without independent reviewers or without reading their\n  findings.\n- Expanding the backlog instead of stopping at the approved scope.\n- Leaving a red or draft PR described as ready in the handoff.\n",{"name":5,"description":7},"main","f8d88df79f7c7d9471370408cee6b79640357b23",".claude\u002Fskills\u002Fafk-implement",0,"https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins","https:\u002F\u002Fgithub.com\u002Fdayvidpham","dhpham.com","2026-11-11 16:48:56",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add dayvidpham\u002Faura-plugins --skill afk-implement",{"tool":58,"command":59},"bunx","bunx skills add dayvidpham\u002Faura-plugins --skill afk-implement",{"tool":61,"command":62},"pnpm","pnpm dlx skills add dayvidpham\u002Faura-plugins --skill afk-implement","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fafk-implement\u002FSKILL.md",true,[],[67,96,101,107,112,117],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":78,"publishedAt":39},"01M6CHSCKDTSV05385SJ05XWW6","protocol","Aura protocol reference documentation — 12-phase workflow, agent roles, constraints, and coding standards. Read when you need to understand the full workflow or look up conventions.","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fskills\u002Fprotocol\u002FSKILL.md",[73],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[69,79,31,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95],"understand","phase","aura","workflow","documentation","you","coding standards","constraints","conventions","coding","roles","read","up","look","standards","reference","full",{"skillNo":97,"name":69,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":39},"01M6CHSBJDVKGWAJWQCNQ22F9F","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002Fskills\u002Fprotocol\u002FSKILL.md",[],[69],{"skillNo":102,"name":103,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":39},"01M6CHSAJY85M0W8NEAN4PRF82","example","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002Fskills\u002Fexample\u002FSKILL.md",[],[103],{"skillNo":108,"name":103,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":39},"01M6CHS9KQJYCWR1C9F2GJDZYX","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002F.opencode\u002Fskill\u002Fexample\u002FSKILL.md",[],[103],{"skillNo":113,"name":103,"nameZh":6,"description":6,"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":116,"publishedAt":39},"01M6CHS8MSW2SDQ5Y05A3GZES4","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002F.agents\u002Fskills\u002Fexample\u002FSKILL.md",[],[103],{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":39},"01M6CHS52TKPKC7WV8ZG9YDDAZ","write-go-tests","Use when adding or extending Go tests in strike-cli — *_test.go, table-driven cases, fixtures, httptest, tool Ask helpers, TUI harnesses, coverage gaps. Do not use for running tests only (use test-and-validate).","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwrite-go-tests\u002FSKILL.md",[],[124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,31,147],"go","tests","write go tests","write","cli","use","test","validate","coverage gaps","running tests","tool","table","ask","tui","coverage","extending","only","strike","do","fixtures","harnesses","for","gaps","running"]