[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C44QPDV3F8F6JC9B2NEDNX":3,"skill-same:01M6C44QPDV3F8F6JC9B2NEDNX":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":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":6,"ownerHtmlUrl":43,"ownerBlogUrl":44,"ownerDescription":6,"updatedAt":45,"install":46,"resources":59},"01M6C44QPDV3F8F6JC9B2NEDNX","implement",null,"Implement one Kairos task from Todo to Completed. Use when the user names a task or short code to implement, asks to pick up the next todo item, or when groomed work is handed off for execution.","colliery-io\u002Fkairos","colliery-io","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F167646339?v=4","01M6C4368BHZH1AYSJ3SX124ET","Colliery","01M6C436CSYPJ80ZNK1SA2Q7Z3",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fworkflow\u002Fimplement\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32],"work","short","pick","up","execution","kairos","use","code","user","todo","next","for","when","task","2026-11-10 10:12:30",false,"---\nname: implement\ndescription: Implement one Kairos task from Todo to Completed. Use when the user names a task or short code to implement, asks to pick up the next todo item, or when groomed work is handed off for execution.\n---\n\n# Implement\n\nExecute one Kairos task from Todo to Completed.\n\n## Pick up\n\nYour **queue** is the board of your team, filtered by the repository of this checkout. The SessionStart context gives both: `team_board` and `repository` (the wiring of `kairos config show`, COLLIERY-A-0023). Given a short code, `get_item` it. Given nothing, `board_items` with `board=\u003Cteam_board>`, `repository=\u003Cthis repo>`, `column=Todo` and `details: true` → the highest-priority item with no unresolved `blocks` edge; state the pick and why before starting. With `details`, each card shows its priority, the date of its last change and its claim, so you need no `get_item` for each card. `list_metadata_definitions` gives the order of the priority values. (No `repository` wired? Fall back to `my_boards` → the delivery board → `board_items` unfiltered, and suggest `\u002Fkairos:bootstrap`.)\n\n**Read each part of the board before you pick.** `board_items` gives 200 items at most in one result. When the result is a part of the board, its first lines say so and give the `offset` of the next part. Call `board_items` again with that `offset` until you have each part. Then make the decision. To read one column only, send `column` (`column=Todo`).\n\n**Stay in your repository.** `get_item` prints the link of the task: `repository: \u003Cslug> (owner: \u003Cteam>)`. The owner can be a different team; that is normal. You need a clone of that repository. It is this checkout or the clone of this worktree. In a board folder, the session context lists the clones. `get_repository \u003Cslug>` gives the full name to compare with the origin remote. If no clone has that origin, stop: say which repository holds the code, and pick a different task. A task with no repository that needs code in this checkout: link it with `set_repository` (`short_code`, `repository`), then continue.\n\n**The work of other teams in this repository is not in your queue.** Find it with `search` (`filter.repository`), or in the commits. Read it; the team of its board does it.\n\n**A task on the wrong board is moved, not recreated.** When a ticket is on this board but is really another team's work, `move_item` it to their delivery board (`to_board`) — recreating it there throws away its history, its edges and its author. You need `manage_tasks` on both boards; if the tool refuses, name the board it belongs on and ask the lead. The task keeps its repository: the move does not look at it.\n\nAnything procedural you write while implementing — a how-to or reference page, an error message, CLI help text — follows Simplified Technical English: [The Simplified Technical English reference](..\u002F..\u002F..\u002Freferences\u002Fsimplified-technical-english.md) (KAIROS-S-0009). It does **not** apply to your commit message, your code comments, or the reasoning you record on the item; those exist to explain why, and STE cannot. `angreal docs ste` checks the mechanical rules where the project has that task, and `angreal docs ste --code` checks the texts of errors in the code.\n\nThe task must be workable: acceptance criteria present and independently verifiable, blockers resolved. When it isn't, stop, note the gap on the item, and tell the lead it needs `\u002Fkairos:triage` — surface the gap rather than quietly filling it yourself.\n\n`transition_item` to **Active** before the first change. The move gives the task your **claim**: the board and `get_item` show that you (or your agent) work on it. If `get_item` shows a claim of a different person, the task is theirs: ask before you start, and do not take it over. A change to a task with the claim of a different person succeeds. The answer then ends with a `Warning:` line that names the person. Stop, do \"Abort\", and tell the lead.\n\n**Read your notifications.** While you have unread notifications, each answer of a Kairos tool ends with a block `## Your notifications (N unread)`: the 5 newest. With more than 5, the heading says `5+ unread`, and the block ends with `More: call get_events`. A notification tells you of a claim handed off to you, a blocker of your claimed task that is done or archived, a task that you created that someone cancelled, a mention of your user name, or a P0 bug on the board of your team. `get_events` lists them with their ids. Act on each one that changes your work (a cleared blocker can make a task workable; a P0 bug can come before your pick), tell the lead about the others, then `mark_events_read` (`ids`, or `all: true` with `up_to`: the newest id that you read, as `get_events` gives it). Your agent key keeps its own read state: your read does not clear the bell of the person. Do not mark a notification read before you have read it.\n\nTo give the task to a different person, `hand_off_item` (`to`: a user id, an email, a user name, or `me`). `list_members` gives the user names: send `board` for the people who can move the task. To mention a person in a note, write `@\u003Cuser name>`. `whoami` gives your own user name. To stop work on a task and leave it in Active for anyone, `release_item`. To take a free task in Active, `claim_item` (KAIROS-T-0528): a task that a different person holds is refused with the name of the holder. The claim ends by itself when the task leaves Active.\n\n## Open the work\n\nDo the work in a worktree of the clone, not in the clone. Other sessions use the same clone. Do these steps after the claim:\n\n1. Find the clone. In a checkout, it is this checkout, or the clone of this worktree (`git rev-parse --git-common-dir`). In a board folder, find it in the list of clones of the session context.\n2. Find the default branch. `get_repository` gives it, else `git -C \u003Cclone> symbolic-ref --short refs\u002Fremotes\u002Forigin\u002FHEAD`.\n3. Get the latest commits: `git -C \u003Cclone> fetch origin \u003Cdefault>`.\n4. Make the worktree next to the clone. The folder and the branch use the short code in lower case:\n   `git -C \u003Cclone> worktree add ..\u002Fwt-\u003Ccode> -b \u003Ccode> origin\u002F\u003Cdefault>`\n   For KAIROS-T-0522 that is the folder `..\u002Fwt-kairos-t-0522` and the branch `kairos-t-0522`. When the worktree of the task is there already, use it.\n5. Do the repository check on the worktree. `git -C \u003Cworktree> remote get-url origin` must give the repository of the task. If it does not, remove the worktree and stop.\n6. Open the code index of the worktree: `fetch_index` with `root=\u003Cworktree>`.\n7. Write the branch: `set_state` with `branch=\u003Ccode>` and the next step.\n\nThe worktree needs no Kairos file. The `[[project]]` of `config.toml` matches the `origin` remote, so the worktree has the wiring of its clone: `kairos config show` in the worktree gives it. Each later step runs in the worktree. Use `git -C \u003Cworktree>` and absolute paths. Do not use `cd` in commands that run in parallel, because they share one shell.\n\n## Ground\n\nBefore the plan, read the record: [GROUND.md](..\u002F..\u002Fmeta\u002Fkairos\u002FGROUND.md). The ADRs and the documents of this repository (`get_repository \u003Cslug>`: the items that impact it, and the ADRs of the owner team; `team_pages \u003Cteam>`: the tree of the team), the documents of the parent initiative, and `related_work` on the task. Write the sentence it gives (\"Read: ... Nothing read contradicts this plan.\" or \"Step N contradicts ...\") on the task and in your reply, before the first change.\n\n## Check the names\n\nList each symbol, file, crate and dependency that the task text names. Check each one with the code tools (`symbol`, `code_search`, `path`) before the plan relies on it. A name that is not in the code gets one note on the task, \"Stale: `resolve_many` (KAIROS-T-0579) is not in the code\", and the plan does not use it. A blocker that the task names: `get_item` it. Is it open, and does its scope block this task? When it does not, say so on the task.\n\nAn assertion that you make without evidence, in a note or in a reply, carries the marker \"not checked\". Repair it when you check it. The closing note of the task lists what stays \"not checked\".\n\n## Work\n\nThe task item is your **working memory**. Every few significant steps, `append_note` findings, decisions, dead ends ruled out, and plan changes onto it (one call: no version, no anchor text; the note gets an id, and `get_item` shows it after the content under a heading with the date and your name) — the item must let any session, or another agent, resume cold after this conversation's context is gone. Reference commits, files, and other items by hash, path, or short code rather than restating them. End each note with a `Next step:` line: after a context compaction, the plugin gives you that line again for each Active task.\n\nThe task also has a **live state**, separate from the notes: one current line that `get_item`, `board_items` and the card show. Write it with `set_state` (`branch`, `commit`, `pushed`, `pr_url`, `next_step`) after each commit, after each push, after a PR opens, and before any stop or hand-off. The write is a patch (KAIROS-A-0029): a field that you do not send keeps its value, and `null` clears it. A note records what happened; the state says where the work is now.\n\nCode index first. Find code with the tools of the `kairos-code` MCP server before you read a file. `code_search` finds what the code does; `symbol` finds one name. `callers` and `references` find its uses; `path` finds how one symbol reaches another. Then read only the files that they name. grep is for literal text only: a log line, a config key, an error message. After you change code, run `kairos index update`. `module_map` gives the map of the modules; `callees` gives the calls of one symbol. When you start an Agent subagent, put this paragraph and the path of the worktree in its prompt.\n\nWhen you split the task, or add a task for work that you find, link the tasks with `blocks` when one must wait for the other. Give no edge to tasks that can go in parallel. Say the order in each task.\n\n**What remains lives on the items.** The remaining work is the open tasks of the initiative and their `blocks` edges, not a list you rewrite from memory each turn. When asked what is left: `get_item` the initiative, then `search` with `traverse: {from: \u003Cinitiative>, relationships: [parent, blocks], direction: both, depth: 2}`, and present the open tasks in the order of their edges. A new step goes on the record before you answer: a task with its `blocks` edge, or a note on the task when it is small. A deliverable of the active task is never \"out of scope\" in a reply: it is done, split into a task with a reason and an edge, or left on the task as open.\n\nUse the `tdd` skill at the seams that the task names, or that the lead agrees. Run the repo's fast checks — formatter, typecheck, single test files — as you go; the full suite once at the end.\n\n## The completion gate\n\nThe task transitions Active → Completed **only** when all of these hold, with output recorded on the item:\n\n1. **Gates clean** where the repo has them: formatter check, linter with warnings denied, full test suite green (in a Rust\u002Fangreal repo: `cargo fmt --check`, `cargo clippy -- -D warnings`, `angreal test unit && angreal test integration`; otherwise the repo's equivalents).\n2. **Every acceptance criterion demonstrated, not asserted**: for each criterion, `append_note` the command you ran and the observed output onto the item as evidence.\n3. **New behavior carries new tests.**\n\nThe closing note lists what stays \"not checked\" (a manual check, a live run, a claim without evidence).\n\nBefore Completed, ask: did this work decide anything an ADR or the spec should hold? A behaviour change, a rule, a boundary. The test for an ADR: would a reader of the code get it wrong without it? That includes a choice against a library default, a rejected option that will come back, and a decision of the user. Skip routine bug fixes. Yes: record it with the \"Record this decision\" path of the `domain-modeling` skill (an ADR with `parent` this task, `impacts` the repository), and write its short code in the closing note. Then cite the ADR in the code that you changed: a comment or a test names the short code and does not copy the reasoning. A change of a part of an existing ADR `amends` it; a replacement of all of it `supersedes` it. No: say so in the closing note (\"No decision to record.\"). A decision in a note or in local memory only is lost to the next session.\n\nThen review the diff (the `kairos:code-review` skill; the built-in `\u002Fcode-review` posts nothing to the task). Commit in the worktree, on the branch of the task (`git -C \u003Cworktree> commit`). Do \"Push and open the PR\", then \"Close the work\", then `transition_item` to **Completed**. When the work needs a change from a DIFFERENT team (an API to add, a client to update), send a request to that team. The recipe is [CROSS-TEAM-FILING.md](CROSS-TEAM-FILING.md): `create_item` (`board: \u003Cthe delivery board of that team>`, `parent: \u003Cthis task's initiative>`), then `link_items blocks` from the request to this task.\n\n## Push and open the PR\n\nThis is the push policy (KAIROS-A-0046). You push the branch of the task and open a draft PR. Then you stop. The user merges.\n\n1. Push the branch of the task: `git -C \u003Cworktree> push -u origin \u003Ccode>`. The git guard lets this push through.\n2. Open a draft PR: `gh pr create --draft --base \u003Cdefault> --head \u003Ccode>`. Run it in the worktree. The body links the task.\n3. Write the PR on the task: `set_state` with each field. Send `branch`, `commit`, `pushed: true`, `pr_url` and `next_step`.\n4. Stop at the PR. Do not merge, release, tag or deploy.\n\nDo not push the default branch. Do not use `--force`, `--delete` or a `+` refspec. The guard asks the user for each other push. When the guard asks, tell the user why you push.\n\n## Close the work\n\nDo this step at Completed. When the branch is pushed and the PR is open, remove the worktree:\n\n`git -C \u003Cclone> worktree remove ..\u002Fwt-\u003Ccode>`\n\nKeep the branch, because the PR uses it. Do not use `--force`. When the command refuses, the worktree has changes that are not committed: keep it. Also keep the worktree when the branch is not pushed or no PR is open. When this session runs in the worktree, keep it and tell the user to remove it after the session. Write the path of a kept worktree and the reason in the closing note.\n\n## Abort\n\nDo these steps when you stop a task before Completed. Examples: the user cancels the work, `\u002Fkairos:cancel-ralph` stops the loop, or a different person has the claim. Do not leave a task with no record. A task that waits on a decision or another team goes to Blocked first (the next section).\n\n1. Look for changes that are not committed: `git -C \u003Cworktree> status --porcelain`.\n2. When the output is empty, remove the worktree: `git -C \u003Cclone> worktree remove ..\u002Fwt-\u003Ccode>`. Keep the branch.\n3. When the output is not empty, keep the worktree. Do not use `--force`.\n4. `append_note` on the task. Write what is done and what is not done. Write the path of a kept worktree and the reason. End with a `Next step:` line.\n5. `set_state` with each field: `branch`, the last `commit`, `pushed` (true or false), `pr_url`, and `next_step`.\n6. When the task is in Active and you hold the claim, `release_item` the task. The task stays in Active, free for the next person. Do not release the claim of a different person.\n\nThen tell the lead the short code, the state and the worktree.\n\n## Blocked\n\nWhen the task stalls on something outside your reach — a decision, access, another team — `link_items` (`blocks`) from the blocking thing to the task, `transition_item` to Blocked, and `append_note` a note naming exactly what's needed and from whom, on the task **and** on its parent initiative so the blocker surfaces at the Initiative Board Review. Then stop rather than guess.\n","# Implement\n\nExecute one Kairos task from Todo to Completed.\n\n## Pick up\n\nYour **queue** is the board of your team, filtered by the repository of this checkout. The SessionStart context gives both: `team_board` and `repository` (the wiring of `kairos config show`, COLLIERY-A-0023). Given a short code, `get_item` it. Given nothing, `board_items` with `board=\u003Cteam_board>`, `repository=\u003Cthis repo>`, `column=Todo` and `details: true` → the highest-priority item with no unresolved `blocks` edge; state the pick and why before starting. With `details`, each card shows its priority, the date of its last change and its claim, so you need no `get_item` for each card. `list_metadata_definitions` gives the order of the priority values. (No `repository` wired? Fall back to `my_boards` → the delivery board → `board_items` unfiltered, and suggest `\u002Fkairos:bootstrap`.)\n\n**Read each part of the board before you pick.** `board_items` gives 200 items at most in one result. When the result is a part of the board, its first lines say so and give the `offset` of the next part. Call `board_items` again with that `offset` until you have each part. Then make the decision. To read one column only, send `column` (`column=Todo`).\n\n**Stay in your repository.** `get_item` prints the link of the task: `repository: \u003Cslug> (owner: \u003Cteam>)`. The owner can be a different team; that is normal. You need a clone of that repository. It is this checkout or the clone of this worktree. In a board folder, the session context lists the clones. `get_repository \u003Cslug>` gives the full name to compare with the origin remote. If no clone has that origin, stop: say which repository holds the code, and pick a different task. A task with no repository that needs code in this checkout: link it with `set_repository` (`short_code`, `repository`), then continue.\n\n**The work of other teams in this repository is not in your queue.** Find it with `search` (`filter.repository`), or in the commits. Read it; the team of its board does it.\n\n**A task on the wrong board is moved, not recreated.** When a ticket is on this board but is really another team's work, `move_item` it to their delivery board (`to_board`) — recreating it there throws away its history, its edges and its author. You need `manage_tasks` on both boards; if the tool refuses, name the board it belongs on and ask the lead. The task keeps its repository: the move does not look at it.\n\nAnything procedural you write while implementing — a how-to or reference page, an error message, CLI help text — follows Simplified Technical English: [The Simplified Technical English reference](..\u002F..\u002F..\u002Freferences\u002Fsimplified-technical-english.md) (KAIROS-S-0009). It does **not** apply to your commit message, your code comments, or the reasoning you record on the item; those exist to explain why, and STE cannot. `angreal docs ste` checks the mechanical rules where the project has that task, and `angreal docs ste --code` checks the texts of errors in the code.\n\nThe task must be workable: acceptance criteria present and independently verifiable, blockers resolved. When it isn't, stop, note the gap on the item, and tell the lead it needs `\u002Fkairos:triage` — surface the gap rather than quietly filling it yourself.\n\n`transition_item` to **Active** before the first change. The move gives the task your **claim**: the board and `get_item` show that you (or your agent) work on it. If `get_item` shows a claim of a different person, the task is theirs: ask before you start, and do not take it over. A change to a task with the claim of a different person succeeds. The answer then ends with a `Warning:` line that names the person. Stop, do \"Abort\", and tell the lead.\n\n**Read your notifications.** While you have unread notifications, each answer of a Kairos tool ends with a block `## Your notifications (N unread)`: the 5 newest. With more than 5, the heading says `5+ unread`, and the block ends with `More: call get_events`. A notification tells you of a claim handed off to you, a blocker of your claimed task that is done or archived, a task that you created that someone cancelled, a mention of your user name, or a P0 bug on the board of your team. `get_events` lists them with their ids. Act on each one that changes your work (a cleared blocker can make a task workable; a P0 bug can come before your pick), tell the lead about the others, then `mark_events_read` (`ids`, or `all: true` with `up_to`: the newest id that you read, as `get_events` gives it). Your agent key keeps its own read state: your read does not clear the bell of the person. Do not mark a notification read before you have read it.\n\nTo give the task to a different person, `hand_off_item` (`to`: a user id, an email, a user name, or `me`). `list_members` gives the user names: send `board` for the people who can move the task. To mention a person in a note, write `@\u003Cuser name>`. `whoami` gives your own user name. To stop work on a task and leave it in Active for anyone, `release_item`. To take a free task in Active, `claim_item` (KAIROS-T-0528): a task that a different person holds is refused with the name of the holder. The claim ends by itself when the task leaves Active.\n\n## Open the work\n\nDo the work in a worktree of the clone, not in the clone. Other sessions use the same clone. Do these steps after the claim:\n\n1. Find the clone. In a checkout, it is this checkout, or the clone of this worktree (`git rev-parse --git-common-dir`). In a board folder, find it in the list of clones of the session context.\n2. Find the default branch. `get_repository` gives it, else `git -C \u003Cclone> symbolic-ref --short refs\u002Fremotes\u002Forigin\u002FHEAD`.\n3. Get the latest commits: `git -C \u003Cclone> fetch origin \u003Cdefault>`.\n4. Make the worktree next to the clone. The folder and the branch use the short code in lower case:\n   `git -C \u003Cclone> worktree add ..\u002Fwt-\u003Ccode> -b \u003Ccode> origin\u002F\u003Cdefault>`\n   For KAIROS-T-0522 that is the folder `..\u002Fwt-kairos-t-0522` and the branch `kairos-t-0522`. When the worktree of the task is there already, use it.\n5. Do the repository check on the worktree. `git -C \u003Cworktree> remote get-url origin` must give the repository of the task. If it does not, remove the worktree and stop.\n6. Open the code index of the worktree: `fetch_index` with `root=\u003Cworktree>`.\n7. Write the branch: `set_state` with `branch=\u003Ccode>` and the next step.\n\nThe worktree needs no Kairos file. The `[[project]]` of `config.toml` matches the `origin` remote, so the worktree has the wiring of its clone: `kairos config show` in the worktree gives it. Each later step runs in the worktree. Use `git -C \u003Cworktree>` and absolute paths. Do not use `cd` in commands that run in parallel, because they share one shell.\n\n## Ground\n\nBefore the plan, read the record: [GROUND.md](..\u002F..\u002Fmeta\u002Fkairos\u002FGROUND.md). The ADRs and the documents of this repository (`get_repository \u003Cslug>`: the items that impact it, and the ADRs of the owner team; `team_pages \u003Cteam>`: the tree of the team), the documents of the parent initiative, and `related_work` on the task. Write the sentence it gives (\"Read: ... Nothing read contradicts this plan.\" or \"Step N contradicts ...\") on the task and in your reply, before the first change.\n\n## Check the names\n\nList each symbol, file, crate and dependency that the task text names. Check each one with the code tools (`symbol`, `code_search`, `path`) before the plan relies on it. A name that is not in the code gets one note on the task, \"Stale: `resolve_many` (KAIROS-T-0579) is not in the code\", and the plan does not use it. A blocker that the task names: `get_item` it. Is it open, and does its scope block this task? When it does not, say so on the task.\n\nAn assertion that you make without evidence, in a note or in a reply, carries the marker \"not checked\". Repair it when you check it. The closing note of the task lists what stays \"not checked\".\n\n## Work\n\nThe task item is your **working memory**. Every few significant steps, `append_note` findings, decisions, dead ends ruled out, and plan changes onto it (one call: no version, no anchor text; the note gets an id, and `get_item` shows it after the content under a heading with the date and your name) — the item must let any session, or another agent, resume cold after this conversation's context is gone. Reference commits, files, and other items by hash, path, or short code rather than restating them. End each note with a `Next step:` line: after a context compaction, the plugin gives you that line again for each Active task.\n\nThe task also has a **live state**, separate from the notes: one current line that `get_item`, `board_items` and the card show. Write it with `set_state` (`branch`, `commit`, `pushed`, `pr_url`, `next_step`) after each commit, after each push, after a PR opens, and before any stop or hand-off. The write is a patch (KAIROS-A-0029): a field that you do not send keeps its value, and `null` clears it. A note records what happened; the state says where the work is now.\n\nCode index first. Find code with the tools of the `kairos-code` MCP server before you read a file. `code_search` finds what the code does; `symbol` finds one name. `callers` and `references` find its uses; `path` finds how one symbol reaches another. Then read only the files that they name. grep is for literal text only: a log line, a config key, an error message. After you change code, run `kairos index update`. `module_map` gives the map of the modules; `callees` gives the calls of one symbol. When you start an Agent subagent, put this paragraph and the path of the worktree in its prompt.\n\nWhen you split the task, or add a task for work that you find, link the tasks with `blocks` when one must wait for the other. Give no edge to tasks that can go in parallel. Say the order in each task.\n\n**What remains lives on the items.** The remaining work is the open tasks of the initiative and their `blocks` edges, not a list you rewrite from memory each turn. When asked what is left: `get_item` the initiative, then `search` with `traverse: {from: \u003Cinitiative>, relationships: [parent, blocks], direction: both, depth: 2}`, and present the open tasks in the order of their edges. A new step goes on the record before you answer: a task with its `blocks` edge, or a note on the task when it is small. A deliverable of the active task is never \"out of scope\" in a reply: it is done, split into a task with a reason and an edge, or left on the task as open.\n\nUse the `tdd` skill at the seams that the task names, or that the lead agrees. Run the repo's fast checks — formatter, typecheck, single test files — as you go; the full suite once at the end.\n\n## The completion gate\n\nThe task transitions Active → Completed **only** when all of these hold, with output recorded on the item:\n\n1. **Gates clean** where the repo has them: formatter check, linter with warnings denied, full test suite green (in a Rust\u002Fangreal repo: `cargo fmt --check`, `cargo clippy -- -D warnings`, `angreal test unit && angreal test integration`; otherwise the repo's equivalents).\n2. **Every acceptance criterion demonstrated, not asserted**: for each criterion, `append_note` the command you ran and the observed output onto the item as evidence.\n3. **New behavior carries new tests.**\n\nThe closing note lists what stays \"not checked\" (a manual check, a live run, a claim without evidence).\n\nBefore Completed, ask: did this work decide anything an ADR or the spec should hold? A behaviour change, a rule, a boundary. The test for an ADR: would a reader of the code get it wrong without it? That includes a choice against a library default, a rejected option that will come back, and a decision of the user. Skip routine bug fixes. Yes: record it with the \"Record this decision\" path of the `domain-modeling` skill (an ADR with `parent` this task, `impacts` the repository), and write its short code in the closing note. Then cite the ADR in the code that you changed: a comment or a test names the short code and does not copy the reasoning. A change of a part of an existing ADR `amends` it; a replacement of all of it `supersedes` it. No: say so in the closing note (\"No decision to record.\"). A decision in a note or in local memory only is lost to the next session.\n\nThen review the diff (the `kairos:code-review` skill; the built-in `\u002Fcode-review` posts nothing to the task). Commit in the worktree, on the branch of the task (`git -C \u003Cworktree> commit`). Do \"Push and open the PR\", then \"Close the work\", then `transition_item` to **Completed**. When the work needs a change from a DIFFERENT team (an API to add, a client to update), send a request to that team. The recipe is [CROSS-TEAM-FILING.md](CROSS-TEAM-FILING.md): `create_item` (`board: \u003Cthe delivery board of that team>`, `parent: \u003Cthis task's initiative>`), then `link_items blocks` from the request to this task.\n\n## Push and open the PR\n\nThis is the push policy (KAIROS-A-0046). You push the branch of the task and open a draft PR. Then you stop. The user merges.\n\n1. Push the branch of the task: `git -C \u003Cworktree> push -u origin \u003Ccode>`. The git guard lets this push through.\n2. Open a draft PR: `gh pr create --draft --base \u003Cdefault> --head \u003Ccode>`. Run it in the worktree. The body links the task.\n3. Write the PR on the task: `set_state` with each field. Send `branch`, `commit`, `pushed: true`, `pr_url` and `next_step`.\n4. Stop at the PR. Do not merge, release, tag or deploy.\n\nDo not push the default branch. Do not use `--force`, `--delete` or a `+` refspec. The guard asks the user for each other push. When the guard asks, tell the user why you push.\n\n## Close the work\n\nDo this step at Completed. When the branch is pushed and the PR is open, remove the worktree:\n\n`git -C \u003Cclone> worktree remove ..\u002Fwt-\u003Ccode>`\n\nKeep the branch, because the PR uses it. Do not use `--force`. When the command refuses, the worktree has changes that are not committed: keep it. Also keep the worktree when the branch is not pushed or no PR is open. When this session runs in the worktree, keep it and tell the user to remove it after the session. Write the path of a kept worktree and the reason in the closing note.\n\n## Abort\n\nDo these steps when you stop a task before Completed. Examples: the user cancels the work, `\u002Fkairos:cancel-ralph` stops the loop, or a different person has the claim. Do not leave a task with no record. A task that waits on a decision or another team goes to Blocked first (the next section).\n\n1. Look for changes that are not committed: `git -C \u003Cworktree> status --porcelain`.\n2. When the output is empty, remove the worktree: `git -C \u003Cclone> worktree remove ..\u002Fwt-\u003Ccode>`. Keep the branch.\n3. When the output is not empty, keep the worktree. Do not use `--force`.\n4. `append_note` on the task. Write what is done and what is not done. Write the path of a kept worktree and the reason. End with a `Next step:` line.\n5. `set_state` with each field: `branch`, the last `commit`, `pushed` (true or false), `pr_url`, and `next_step`.\n6. When the task is in Active and you hold the claim, `release_item` the task. The task stays in Active, free for the next person. Do not release the claim of a different person.\n\nThen tell the lead the short code, the state and the worktree.\n\n## Blocked\n\nWhen the task stalls on something outside your reach — a decision, access, another team — `link_items` (`blocks`) from the blocking thing to the task, `transition_item` to Blocked, and `append_note` a note naming exactly what's needed and from whom, on the task **and** on its parent initiative so the blocker surfaces at the Initiative Board Review. Then stop rather than guess.\n",{"name":5,"description":7},"main","904e5de249a867b635430614ce40ad9b14e5d11c","plugin\u002Fskills\u002Fworkflow\u002Fimplement",4,"https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos","https:\u002F\u002Fgithub.com\u002Fcolliery-io","https:\u002F\u002Fcolliery.io\u002F","2026-11-10 20:52:44",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add colliery-io\u002Fkairos --skill implement",{"tool":52,"command":53},"bunx","bunx skills add colliery-io\u002Fkairos --skill implement",{"tool":55,"command":56},"pnpm","pnpm dlx skills add colliery-io\u002Fkairos --skill implement","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fworkflow\u002Fimplement\u002FSKILL.md",true,[60],{"path":61,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":64,"sourceHtmlUrl":65},"CROSS-TEAM-FILING.md","REFERENCE","参考文档",2163,"https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fworkflow\u002Fimplement\u002FCROSS-TEAM-FILING.md",[67,91,105,118,129,152],{"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":73,"publishedAt":33},"01M6C4534Y6DB5N1V03Q5N9HVG","triage","Groom the delivery board — refine acceptance criteria, prioritize bugs, weigh tech debt, archive stale items, restock Todo, escalate cross-team blockers.","https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fworkflow\u002Ftriage\u002FSKILL.md",[],[69,74,75,76,77,78,79,80,81,82,83,84,28,85,20,86,87,26,88,89,90],"delivery","refine","true","stale","debt","team","tech","bugs","acceptance criteria","restock","escalate","archive","board","groom","acceptance","prioritize","tech debt",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":33},"01M6C450QYKWYHEA0VHZCM5XEW","to-initiative","Turn the current conversation into a Kairos initiative with an attached PRD — no interview, just synthesis of what's already been discussed.","https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fworkflow\u002Fto-initiative\u002FSKILL.md",[],[98,99,24,100,101,102,76,103,104],"to initiative","just","interview","prd","Synthesis","conversation","with",{"skillNo":106,"name":107,"nameZh":6,"description":108,"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":33},"01M6C44YQG7CESHVHC6Z0TADZC","ralph","Run Kairos tasks one by one in a Ralph loop, through the steps of \u002Fkairos:implement.","https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fworkflow\u002Fralph\u002FSKILL.md",[],[107,20,112,32,76,113,5,114,26,115,116,24,117],"ralph loop","max","tasks","run","loop","max-iterations",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":33},"01M6C44WW9QWDTG173VFRA7E1Y","ralph-initiative","Run the open tasks of a Kairos initiative in a Ralph loop, in the sequence of their blocks edges.","https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fworkflow\u002Fralph-initiative\u002FSKILL.md",[],[125,107,126,127,76,128,113,20,114,26,115,116,24,117,112],"ralph initiative","sequence","open","blocks",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":33},"01M6C44SW6JFF3946GAV7CKJYH","onboard-team","Take a new or half-set-up delivery team to a working state with the person — its team, members, board, repositories, team page and charter, dispatch, and local wiring. Reads first, lists the gaps, asks before each write; safe to run again.","https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fworkflow\u002Fonboard-team\u002FSKILL.md",[],[79,136,137,22,138,86,139,115,140,141,142,143,144,145,74,146,147,104,148,149,150,151,76],"onboard team","onboard","safe","write","page","dispatch","first","state","SET","local","name","charter","wiring","gaps","repositories","new",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":33},"01M6C44MV0QTRBA8JB8W99KCPS","grill-initiative","A relentless interview that sharpens a Kairos initiative (or a strategy) and writes each settled answer into the item at once. Pass an initiative or strategy short code, or a title for a new initiative.","https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fworkflow\u002Fgrill-initiative\u002FSKILL.md",[],[159,160,151,76,161,162,30,163,20,26,24,164,100],"grill initiative","grill","at","answer","title","strategy"]