[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C44MV0QTRBA8JB8W99KCPS":3,"skill-same:01M6C44MV0QTRBA8JB8W99KCPS":60},{"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":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":45,"ownerDescription":6,"updatedAt":46,"install":47,"resources":59},"01M6C44MV0QTRBA8JB8W99KCPS","grill-initiative",null,"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.","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\u002Fgrill-initiative\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31],"grill initiative","grill","interview","strategy","kairos","code","short","title","for","answer","at","true","new","2026-11-10 10:12:30",false,"---\nname: grill-initiative\ndescription: 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.\nargument-hint: \"\u003Cinitiative or strategy short code> | \\\"\u003Ctitle of a new initiative>\\\"\"\ndisable-model-invocation: true\n---\n\n# Grill an initiative\n\nThe arguments are: `$ARGUMENTS`\n\nRun the `grilling` skill against one Kairos initiative or strategy. Read `grilling` first: it gives the interview loop, one question at a time, and that loop does not change here. This skill says which item you sharpen, which questions to ask, and where each answer goes.\n\nThe item is the record of the interview. A compaction loses the conversation, but not the item.\n\n## 1. Find or create the item\n\n- **A short code** (`PREFIX-I-NNNN` or `PREFIX-S-NNNN`): call `get_item`. If it does not find the item, tell the user and stop. Then read:\n  - each document that supports it (for example the PRD), with `get_item`;\n  - the parent strategy of an initiative;\n  - the ADRs that support it;\n  - the ADRs and the documents that impact the repository, and `related_work` on the item: [GROUND.md](..\u002F..\u002Fmeta\u002Fkairos\u002FGROUND.md). Write its \"Read: ...\" sentence before the first question.\n- **A title**: confirm the title and the board with the user. The board is `initiative_board` of the wiring (the SessionStart context, or `kairos config show`), else find it with `my_boards`. Then call `create_item` (`item_type: initiative`). Send `parent` only when the user names a parent strategy. From then on, name the initiative only by the short code in the result.\n- **No argument**: ask the user which item to grill. Do not guess.\n\nEvery answer must trace back to the parent strategy, when there is one. When an answer does not, say so.\n\n## 2. The column sets the depth\n\nRead the column from `get_item`. The default columns of an initiative board are Discovery, Design, Ready, Decompose, Active, Monitoring and Completed. A board can have different columns: use its own order. The entry column is the first one.\n\n| Column | What to grill |\n|---|---|\n| The entry column (Discovery) | The context, the goals and the non-goals. Is the problem clear enough to design? |\n| The design columns (Design) | The design, the alternatives, the plan and the tests. |\n| After the design (Ready, Decompose) | Only what the user asks to open again. Tell the user that a changed answer can make the existing tasks wrong. |\n| Active, Monitoring | Only what the user asks. The work has started. |\n| A done column (Completed) | Do not grill. Ask no design question. Offer a new initiative. |\n\nFor a strategy, the default columns are Draft, Review, Active, Monitoring and Completed. Grill in Draft and Review. In a done column, offer a new strategy.\n\n**Never call `transition_item`.** The user moves the item.\n\n## 3. Seed the questions\n\nEach branch below is a root of the design tree. Look up each fact before you ask: the code, the documents, the ADRs, other items (`search`, `get_repository`). Ask only for decisions. Expect new branches as answers come in.\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`.\n\n**An initiative**\n\n- **Context.** What is true today that makes this work necessary now? Check it against the code and the strategy. Who asks for it? Who does it change, without a request from them? What did people try before, and why did it stop?\n- **Goals and non-goals.** What can a user do after this initiative that they cannot do now? How do you see that a goal is met? If nobody can tell, it is not a goal yet.\n  What will people think is in scope that is not? Write each such thing as a non-goal. Which goal stays if the others go?\n- **Design.** What are the parts, and where are they in the code now? What is the interface to what exists: the data, the API, the owner? Walk through the main scenario, then the failure scenario, then the concurrent one. Which term in the design has two meanings?\n- **Alternatives.** What is the simplest thing that can work, and why is it not enough? For each rejected alternative: which fact or value rules it out?\n- **Plan.** Which first vertical slice proves the approach? What must be true before decomposition starts? Which other initiatives, teams or repositories does it depend on?\n- **Tests.** How does the user know that it works? How does the code know? What would be bad to ship broken? Which check needs a person, and who does it?\n\n**A strategy**\n\n- **Purpose.** Who is it for, and what changes for them?\n- **Current state.** What exists now? What works and must not break?\n- **Future state.** What is different when the strategy succeeds? What is not part of it?\n- **Success criteria.** What do you measure or see? `get_item` shows the `hypothesis` of the strategy: start from it. The kairos MCP tools do not change that field after `create_item`. Write the settled criteria under the Decisions heading, and tell the user when the `hypothesis` no longer agrees with them.\n- **Principles.** When two good options conflict, which value wins? Ask for a real tie-breaker, not a slogan.\n- **Constraints.** What is fixed: people, time, platform, compatibility, regulation? Which constraints are real, and which are assumptions?\n\nAn answer that is a separate capability is a candidate initiative. Name it as a quoted title marked \"not yet created\" (the `kairos-vocabulary` skill). Do not give it a code or \"phase 2\". Write it on the item, and do not grow the item to hold it.\n\n## 4. Write as you go\n\nWhen a decision settles, write it into the item at once, before the next question. Do not keep edits for the end.\n\n1. Call `get_item` to read the current version.\n2. Call `edit_item` on the initiative. When the initiative has a PRD and the decision is about the product, edit the PRD.\n3. Put the decision under a heading `## Decisions (\u003Cwho>, \u003Cdate>)`, for example `## Decisions (Dylan, 2026-10-02)`. Write one line for each decision. Use one heading for each session, and add to it during the session.\n\nRules for the text:\n\n- When the user reverses a decision, change its line in place, so that the text says what is true now. The history of the item keeps the old text.\n- A decision is prose. Do not number decisions (`D1`, `D2`).\n- When a term settles, it has one meaning from then on. Use only that term in the item, and do not use a synonym for it.\n- The decisions are reasoning, so write them in plain, short sentences, not in STE. An acceptance criterion or a goal that a test checks is procedural: write it in STE ([the STE reference](..\u002F..\u002F..\u002Freferences\u002Fsimplified-technical-english.md)).\n\n## 5. ADRs\n\nOffer an ADR only when the three tests of `engineering\u002Fdomain-modeling` hold. The decision is hard to reverse, surprising without context, and a real trade-off. Most decisions are lines under the Decisions heading. When the user agrees, record the ADR with `engineering\u002Fdomain-modeling\u002FADR-FORMAT.md`:\n\n- `create_item` with `parent` the initiative (a `supports` edge);\n- `link_items` with `impacts` from the ADR to each repository that it is about.\n\nThen write the short code of the ADR on its line under the Decisions heading.\n\n## 6. Close\n\nWhen no open question is left:\n\n1. Call `get_item` and read the item in full.\n2. Give a summary of the settled design in a few lines. Ask the user to confirm that you have the same understanding.\n3. Tell the user the column of the item. Do not move it.\n4. When the user confirms, offer `\u002Fkairos:decompose` to make the tasks, then `\u002Fkairos:grill-decomposition` to review the tasks as a set.\n","# Grill an initiative\n\nThe arguments are: `$ARGUMENTS`\n\nRun the `grilling` skill against one Kairos initiative or strategy. Read `grilling` first: it gives the interview loop, one question at a time, and that loop does not change here. This skill says which item you sharpen, which questions to ask, and where each answer goes.\n\nThe item is the record of the interview. A compaction loses the conversation, but not the item.\n\n## 1. Find or create the item\n\n- **A short code** (`PREFIX-I-NNNN` or `PREFIX-S-NNNN`): call `get_item`. If it does not find the item, tell the user and stop. Then read:\n  - each document that supports it (for example the PRD), with `get_item`;\n  - the parent strategy of an initiative;\n  - the ADRs that support it;\n  - the ADRs and the documents that impact the repository, and `related_work` on the item: [GROUND.md](..\u002F..\u002Fmeta\u002Fkairos\u002FGROUND.md). Write its \"Read: ...\" sentence before the first question.\n- **A title**: confirm the title and the board with the user. The board is `initiative_board` of the wiring (the SessionStart context, or `kairos config show`), else find it with `my_boards`. Then call `create_item` (`item_type: initiative`). Send `parent` only when the user names a parent strategy. From then on, name the initiative only by the short code in the result.\n- **No argument**: ask the user which item to grill. Do not guess.\n\nEvery answer must trace back to the parent strategy, when there is one. When an answer does not, say so.\n\n## 2. The column sets the depth\n\nRead the column from `get_item`. The default columns of an initiative board are Discovery, Design, Ready, Decompose, Active, Monitoring and Completed. A board can have different columns: use its own order. The entry column is the first one.\n\n| Column | What to grill |\n|---|---|\n| The entry column (Discovery) | The context, the goals and the non-goals. Is the problem clear enough to design? |\n| The design columns (Design) | The design, the alternatives, the plan and the tests. |\n| After the design (Ready, Decompose) | Only what the user asks to open again. Tell the user that a changed answer can make the existing tasks wrong. |\n| Active, Monitoring | Only what the user asks. The work has started. |\n| A done column (Completed) | Do not grill. Ask no design question. Offer a new initiative. |\n\nFor a strategy, the default columns are Draft, Review, Active, Monitoring and Completed. Grill in Draft and Review. In a done column, offer a new strategy.\n\n**Never call `transition_item`.** The user moves the item.\n\n## 3. Seed the questions\n\nEach branch below is a root of the design tree. Look up each fact before you ask: the code, the documents, the ADRs, other items (`search`, `get_repository`). Ask only for decisions. Expect new branches as answers come in.\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`.\n\n**An initiative**\n\n- **Context.** What is true today that makes this work necessary now? Check it against the code and the strategy. Who asks for it? Who does it change, without a request from them? What did people try before, and why did it stop?\n- **Goals and non-goals.** What can a user do after this initiative that they cannot do now? How do you see that a goal is met? If nobody can tell, it is not a goal yet.\n  What will people think is in scope that is not? Write each such thing as a non-goal. Which goal stays if the others go?\n- **Design.** What are the parts, and where are they in the code now? What is the interface to what exists: the data, the API, the owner? Walk through the main scenario, then the failure scenario, then the concurrent one. Which term in the design has two meanings?\n- **Alternatives.** What is the simplest thing that can work, and why is it not enough? For each rejected alternative: which fact or value rules it out?\n- **Plan.** Which first vertical slice proves the approach? What must be true before decomposition starts? Which other initiatives, teams or repositories does it depend on?\n- **Tests.** How does the user know that it works? How does the code know? What would be bad to ship broken? Which check needs a person, and who does it?\n\n**A strategy**\n\n- **Purpose.** Who is it for, and what changes for them?\n- **Current state.** What exists now? What works and must not break?\n- **Future state.** What is different when the strategy succeeds? What is not part of it?\n- **Success criteria.** What do you measure or see? `get_item` shows the `hypothesis` of the strategy: start from it. The kairos MCP tools do not change that field after `create_item`. Write the settled criteria under the Decisions heading, and tell the user when the `hypothesis` no longer agrees with them.\n- **Principles.** When two good options conflict, which value wins? Ask for a real tie-breaker, not a slogan.\n- **Constraints.** What is fixed: people, time, platform, compatibility, regulation? Which constraints are real, and which are assumptions?\n\nAn answer that is a separate capability is a candidate initiative. Name it as a quoted title marked \"not yet created\" (the `kairos-vocabulary` skill). Do not give it a code or \"phase 2\". Write it on the item, and do not grow the item to hold it.\n\n## 4. Write as you go\n\nWhen a decision settles, write it into the item at once, before the next question. Do not keep edits for the end.\n\n1. Call `get_item` to read the current version.\n2. Call `edit_item` on the initiative. When the initiative has a PRD and the decision is about the product, edit the PRD.\n3. Put the decision under a heading `## Decisions (\u003Cwho>, \u003Cdate>)`, for example `## Decisions (Dylan, 2026-10-02)`. Write one line for each decision. Use one heading for each session, and add to it during the session.\n\nRules for the text:\n\n- When the user reverses a decision, change its line in place, so that the text says what is true now. The history of the item keeps the old text.\n- A decision is prose. Do not number decisions (`D1`, `D2`).\n- When a term settles, it has one meaning from then on. Use only that term in the item, and do not use a synonym for it.\n- The decisions are reasoning, so write them in plain, short sentences, not in STE. An acceptance criterion or a goal that a test checks is procedural: write it in STE ([the STE reference](..\u002F..\u002F..\u002Freferences\u002Fsimplified-technical-english.md)).\n\n## 5. ADRs\n\nOffer an ADR only when the three tests of `engineering\u002Fdomain-modeling` hold. The decision is hard to reverse, surprising without context, and a real trade-off. Most decisions are lines under the Decisions heading. When the user agrees, record the ADR with `engineering\u002Fdomain-modeling\u002FADR-FORMAT.md`:\n\n- `create_item` with `parent` the initiative (a `supports` edge);\n- `link_items` with `impacts` from the ADR to each repository that it is about.\n\nThen write the short code of the ADR on its line under the Decisions heading.\n\n## 6. Close\n\nWhen no open question is left:\n\n1. Call `get_item` and read the item in full.\n2. Give a summary of the settled design in a few lines. Ask the user to confirm that you have the same understanding.\n3. Tell the user the column of the item. Do not move it.\n4. When the user confirms, offer `\u002Fkairos:decompose` to make the tasks, then `\u002Fkairos:grill-decomposition` to review the tasks as a set.\n",{"name":5,"description":7,"argument-hint":37,"disable-model-invocation":38},"\u003Cinitiative or strategy short code> | \"\u003Ctitle of a new initiative>\"",true,"main","904e5de249a867b635430614ce40ad9b14e5d11c","plugin\u002Fskills\u002Fworkflow\u002Fgrill-initiative",4,"https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos","https:\u002F\u002Fgithub.com\u002Fcolliery-io","https:\u002F\u002Fcolliery.io\u002F","2026-11-13 04:24:21",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":38},[49,52,55],{"tool":50,"command":51},"npx","npx skills add colliery-io\u002Fkairos --skill grill-initiative",{"tool":53,"command":54},"bunx","bunx skills add colliery-io\u002Fkairos --skill grill-initiative",{"tool":56,"command":57},"pnpm","pnpm dlx skills add colliery-io\u002Fkairos --skill grill-initiative","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fworkflow\u002Fgrill-initiative\u002FSKILL.md",[],[61,85,98,113,124,147],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":32},"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",[],[63,68,69,70,30,71,72,73,74,75,76,77,78,79,25,80,81,24,82,83,84],"todo","debt","stale","refine","delivery","escalate","restock","groom","tech","bugs","acceptance criteria","archive","board","team","acceptance","prioritize","tech debt",{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":32},"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",[],[92,23,21,93,94,95,96,97,30],"to initiative","just","prd","with","Synthesis","conversation",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":32},"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",[],[100,105,106,107,30,25,108,109,24,110,111,23,112],"max","ralph loop","task","implement","tasks","run","loop","max-iterations",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":32},"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",[],[100,120,106,105,121,122,25,109,24,110,111,23,112,123,30],"ralph initiative","blocks","sequence","open",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":32},"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",[],[81,131,132,80,133,110,134,135,136,137,138,139,72,140,141,95,142,143,144,31,30,145,146],"onboard team","onboard","write","page","dispatch","first","state","SET","safe","name","charter","wiring","gaps","repositories","local","up",{"skillNo":148,"name":108,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":32},"01M6C44QPDV3F8F6JC9B2NEDNX","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.","https:\u002F\u002Fgithub.com\u002Fcolliery-io\u002Fkairos\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fworkflow\u002Fimplement\u002FSKILL.md",[],[108,153,107,154,27,68,155,24,156,23,157,146,158,25,159],"next","when","user","use","execution","pick","work"]