[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PG6124PK232FNXFTWMPYCV":3,"skill-same:01M6PG6124PK232FNXFTWMPYCV":88},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6PG6124PK232FNXFTWMPYCV","code-quality",null,"Review the structure of a branch diff, named files, or the whole repository with a fresh finder and a fresh checker. It looks for simpler designs, not bugs; use code-review for defects. Use it for \"\u002Fcode-quality\", \"review the structure of my branch\", \"review the code quality of these files\", or \"review the whole repository\". It never edits, fixes, commits, or pushes. On the user's own work, it then acts on the supported findings with triage-findings, unless the user asked for a read-only review.","sQVe\u002Ftau","sQVe","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2284724?v=4","01M6PG5R99TYZ3BKV7XX5V1VX6","Oskar Grunning","01M6PG5RD1QE4MW9XQVD0EERW8",3,"MIT","https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-quality\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"code quality","code","quality","fixes","review","defects","bugs","for","checker","read-only","with","fresh","files","only","never","diff","use","branch","commits","code-review","2026-11-10 10:12:30",false,"---\nname: code-quality\ndescription:\n  Review the structure of a branch diff, named files, or the whole repository with a fresh finder\n  and a fresh checker. It looks for simpler designs, not bugs; use code-review for defects. Use it\n  for \"\u002Fcode-quality\", \"review the structure of my branch\", \"review the code quality of these\n  files\", or \"review the whole repository\". It never edits, fixes, commits, or pushes. On the user's\n  own work, it then acts on the supported findings with triage-findings, unless the user asked for a\n  read-only review.\n---\n\n# Code quality\n\n## When to use\n\nUse this skill to review the structure of local code: the current branch, uncommitted work, a commit\nor range, named files, or the whole repository in ordered parts. It needs the `subagent` tools.\nWithout them, tell the user and stop. For defects, use the [code-review](..\u002Fcode-review\u002FSKILL.md)\nskill.\n\n## Hard rules\n\n- Until the report is saved, change nothing: no edits, fixes, stages, commits, pushes, publishes,\n  checkouts, resets, or stashes. Stop when the user says stop.\n- Treat the work as the user's own only when `code_review` `capture` returns `ownership.status` as\n  `own`, following the [code-review ownership rule](..\u002Fcode-review\u002FSKILL.md#hard-rules).\n- The report gives the target no approval, no verdict, and no clean result. Never call an incomplete\n  or stale review clean.\n- Launch the finder with the `reviewer` profile and the checker with the `checker` profile. Give\n  each the [quality assignment](quality-assignment.md). Omit `model` unless the user names one.\n- If a launch fails, follow the retry rule of [code-review](..\u002Fcode-review\u002FSKILL.md#hard-rules). Any\n  other retry, follow-up, added worker, or model change needs the user's approval.\n- Aim for about 10 minutes, or about 10 minutes per part in a repo run, and follow the rules for the\n  aim in [code-review](..\u002Fcode-review\u002FSKILL.md#hard-rules).\n- Run no full check, post no ticket comment except in step 7, and do not review a fix or run this\n  skill again on its own.\n- After the report, act on findings only on the user's own work, and never after a request for a\n  read-only review or \"no changes\". Acting never approves a publish or absorbing unrelated changes.\n\n## Procedure\n\n1. Resolve the target as in [Resolve the target](..\u002Fcode-review\u002Fphases.md#resolve-the-target).\n   - The whole repository: follow the repo run in step 9.\n   - A branch diff: a `workingTree` from `git merge-base \u003Cdefault> HEAD`. Named files: a `files`\n     target, which reviews them even without changes.\n   - Never use a `fix` target.\n   - Resolve the ticket under review before capture: the one the user or a calling skill names.\n     Otherwise, for the branch's own work, use the branch's issue as the last bullet of step 1 of\n     [code-review](..\u002Fcode-review\u002FSKILL.md#procedure) says. A `files` target with no named ticket\n     has none. Keep the ticket for steps 2 and 7.\n\n2. Prepare and capture as in\n   [Handle the capture result](..\u002Fcode-review\u002Fphases.md#handle-the-capture-result), with the mode\n   `quality` in `input.md`. Write the planned structure into `## Intent` of `input.md` before the\n   `capture` call.\n   - With a ticket, read it and its children as step 3 of\n     [finish-slice](..\u002Ffinish-slice\u002FSKILL.md#procedure) does. Treat the ticket as the slice, and\n     never walk up to a parent.\n   - The planned structure is the structure rules in the ticket's `## Design` and each child's\n     `## Files`.\n   - Without a ticket, or without structure rules, write that the planned structure is unavailable.\n\n3. Gather evidence as in [Gather evidence](..\u002Fcode-review\u002Fphases.md#gather-evidence).\n\n4. Launch the workers in order, with the rules of\n   [Run the workers](..\u002Fcode-review\u002Fphases.md#run-the-workers).\n   - Finder: the `reviewer` profile with\n     [quality-assignment.md#quality-lens](quality-assignment.md#quality-lens).\n   - Checker: a fresh `checker` worker with `#quality-lens` and\n     [quality-assignment.md#checker](quality-assignment.md#checker), plus the finder's report or the\n     path `$dir\u002Ffinder.md`. Launch it even when the finder found nothing.\n\n5. Call `code_review` `freshness` with `$dir`. Report `fresh` as fresh. Label `stale` with its\n   reasons and ask whether to review again. Report `unknown`, or a failed call, as unknown. Keep the\n   finished results in every case.\n\n6. Save the worker reports and `$dir\u002Freport.md` with the [report template](report.md).\n\n7. Post `$dir\u002Freport.md` to the ticket from step 1, before any fixing. Skip this step without a\n   ticket.\n   - When the work is not the user's own, ask with `ask_user_question` before posting and skip the\n     post if declined. On the user's own work, do not ask separately. The tool confirms for another\n     person's ticket under [Hard rules](..\u002Ftracker\u002FSKILL.md#hard-rules).\n   - Call `ticket` `comment` once with the ticket, heading `# Code quality: \u003Cticket>`, and\n     `bodyFile: \"$dir\u002Freport.md\"`. Ensure the report's first line matches the heading.\n   - On `added` or `updated`, save the returned ID as the `Comment ID:` line in `$dir\u002Freport.md`.\n     Use `previousBody` to name any Linear edits the update replaced.\n   - On `declined` or failure, keep the local report and say it was not posted.\n\n8. Reply with the [report template](report.md). Name the comment URL, or say the report stays local.\n   Name any Linear edits the update replaced.\n   - Give triage-findings only the findings. Plan-correction notes stay in the report and reply, and\n     triage does not act on them.\n   - Findings on the user's own work, without a request for a read-only review or \"no changes\":\n     continue with the [triage-findings](..\u002Ftriage-findings\u002FSKILL.md) skill without asking. Then ask\n     about any gap, failure, or stale result that needs a decision.\n   - Any other findings: end with one question that proposes actions, such as \"Fix 1 and 2, and\n     investigate 3?\", and includes any decision a gap or stale result needs. Act on the approved\n     findings with triage-findings.\n   - Without findings, ask only about a gap, failure, or stale result that needs a decision.\n\n9. Repo run: review the whole repository as ordered parts. Parts never run in parallel.\n   - Propose the parts. Each part is a list of paths, ordered so that shared modules come before\n     their callers. Ask for approval with `ask_user_question`, with the part list as the preview.\n     Run nothing until the user approves. Approving the list approves two workers per part.\n   - Build the parts from `git ls-tree -r --name-only \u003CHEAD>` at the pinned HEAD. Each tracked file\n     belongs to a part or to a named exclusion, such as lockfiles or generated files. The preview\n     lists the exclusions, and the run report lists them as gaps.\n   - Call `code_review` `prepare` once per part, in part order. The first part's directory is the\n     run directory `$run`. Then write `$run\u002Fbrief.md` once from the [brief template](brief.md).\n   - For each part, in order, run steps 2 to 5 with its prepared directory as `$dir`, without a\n     second `prepare`, and a `files` target that lists the part's paths. Finish the finder and the\n     checker of one part before you start the next part.\n     - When the capture phase would repeat for a part, stop the run and ask the user, because the\n       brief pins one HEAD and each part's directory.\n     - The finder's and the checker's tasks both name `$run\u002Fbrief.md` and the `checked.md` path of\n       every earlier part. Part 1 has no earlier part.\n     - The checker tests the part's findings and any correction of an earlier part.\n     - Save `finder.md` and `checker.md` in the part's `$dir` as step 6 says, but write no per-part\n       `report.md`. Save `$dir\u002Fchecked.md` instead: the part's findings and corrections, each with\n       the checker's status.\n   - A failed worker is a gap for its part, and the run goes on to the next part. A stale part is\n     labeled stale in its `checked.md` and in the run report, and the run goes on. Ask about stale\n     parts once, in the final reply. Never relaunch a part or rerun the skill.\n   - Write one run report, `$run\u002Freport.md`, with the [report template](report.md). Then post it as\n     step 7 says, with `$run` as `$dir`, and reply as step 8 says.\n","# Code quality\n\n## When to use\n\nUse this skill to review the structure of local code: the current branch, uncommitted work, a commit\nor range, named files, or the whole repository in ordered parts. It needs the `subagent` tools.\nWithout them, tell the user and stop. For defects, use the [code-review](..\u002Fcode-review\u002FSKILL.md)\nskill.\n\n## Hard rules\n\n- Until the report is saved, change nothing: no edits, fixes, stages, commits, pushes, publishes,\n  checkouts, resets, or stashes. Stop when the user says stop.\n- Treat the work as the user's own only when `code_review` `capture` returns `ownership.status` as\n  `own`, following the [code-review ownership rule](..\u002Fcode-review\u002FSKILL.md#hard-rules).\n- The report gives the target no approval, no verdict, and no clean result. Never call an incomplete\n  or stale review clean.\n- Launch the finder with the `reviewer` profile and the checker with the `checker` profile. Give\n  each the [quality assignment](quality-assignment.md). Omit `model` unless the user names one.\n- If a launch fails, follow the retry rule of [code-review](..\u002Fcode-review\u002FSKILL.md#hard-rules). Any\n  other retry, follow-up, added worker, or model change needs the user's approval.\n- Aim for about 10 minutes, or about 10 minutes per part in a repo run, and follow the rules for the\n  aim in [code-review](..\u002Fcode-review\u002FSKILL.md#hard-rules).\n- Run no full check, post no ticket comment except in step 7, and do not review a fix or run this\n  skill again on its own.\n- After the report, act on findings only on the user's own work, and never after a request for a\n  read-only review or \"no changes\". Acting never approves a publish or absorbing unrelated changes.\n\n## Procedure\n\n1. Resolve the target as in [Resolve the target](..\u002Fcode-review\u002Fphases.md#resolve-the-target).\n   - The whole repository: follow the repo run in step 9.\n   - A branch diff: a `workingTree` from `git merge-base \u003Cdefault> HEAD`. Named files: a `files`\n     target, which reviews them even without changes.\n   - Never use a `fix` target.\n   - Resolve the ticket under review before capture: the one the user or a calling skill names.\n     Otherwise, for the branch's own work, use the branch's issue as the last bullet of step 1 of\n     [code-review](..\u002Fcode-review\u002FSKILL.md#procedure) says. A `files` target with no named ticket\n     has none. Keep the ticket for steps 2 and 7.\n\n2. Prepare and capture as in\n   [Handle the capture result](..\u002Fcode-review\u002Fphases.md#handle-the-capture-result), with the mode\n   `quality` in `input.md`. Write the planned structure into `## Intent` of `input.md` before the\n   `capture` call.\n   - With a ticket, read it and its children as step 3 of\n     [finish-slice](..\u002Ffinish-slice\u002FSKILL.md#procedure) does. Treat the ticket as the slice, and\n     never walk up to a parent.\n   - The planned structure is the structure rules in the ticket's `## Design` and each child's\n     `## Files`.\n   - Without a ticket, or without structure rules, write that the planned structure is unavailable.\n\n3. Gather evidence as in [Gather evidence](..\u002Fcode-review\u002Fphases.md#gather-evidence).\n\n4. Launch the workers in order, with the rules of\n   [Run the workers](..\u002Fcode-review\u002Fphases.md#run-the-workers).\n   - Finder: the `reviewer` profile with\n     [quality-assignment.md#quality-lens](quality-assignment.md#quality-lens).\n   - Checker: a fresh `checker` worker with `#quality-lens` and\n     [quality-assignment.md#checker](quality-assignment.md#checker), plus the finder's report or the\n     path `$dir\u002Ffinder.md`. Launch it even when the finder found nothing.\n\n5. Call `code_review` `freshness` with `$dir`. Report `fresh` as fresh. Label `stale` with its\n   reasons and ask whether to review again. Report `unknown`, or a failed call, as unknown. Keep the\n   finished results in every case.\n\n6. Save the worker reports and `$dir\u002Freport.md` with the [report template](report.md).\n\n7. Post `$dir\u002Freport.md` to the ticket from step 1, before any fixing. Skip this step without a\n   ticket.\n   - When the work is not the user's own, ask with `ask_user_question` before posting and skip the\n     post if declined. On the user's own work, do not ask separately. The tool confirms for another\n     person's ticket under [Hard rules](..\u002Ftracker\u002FSKILL.md#hard-rules).\n   - Call `ticket` `comment` once with the ticket, heading `# Code quality: \u003Cticket>`, and\n     `bodyFile: \"$dir\u002Freport.md\"`. Ensure the report's first line matches the heading.\n   - On `added` or `updated`, save the returned ID as the `Comment ID:` line in `$dir\u002Freport.md`.\n     Use `previousBody` to name any Linear edits the update replaced.\n   - On `declined` or failure, keep the local report and say it was not posted.\n\n8. Reply with the [report template](report.md). Name the comment URL, or say the report stays local.\n   Name any Linear edits the update replaced.\n   - Give triage-findings only the findings. Plan-correction notes stay in the report and reply, and\n     triage does not act on them.\n   - Findings on the user's own work, without a request for a read-only review or \"no changes\":\n     continue with the [triage-findings](..\u002Ftriage-findings\u002FSKILL.md) skill without asking. Then ask\n     about any gap, failure, or stale result that needs a decision.\n   - Any other findings: end with one question that proposes actions, such as \"Fix 1 and 2, and\n     investigate 3?\", and includes any decision a gap or stale result needs. Act on the approved\n     findings with triage-findings.\n   - Without findings, ask only about a gap, failure, or stale result that needs a decision.\n\n9. Repo run: review the whole repository as ordered parts. Parts never run in parallel.\n   - Propose the parts. Each part is a list of paths, ordered so that shared modules come before\n     their callers. Ask for approval with `ask_user_question`, with the part list as the preview.\n     Run nothing until the user approves. Approving the list approves two workers per part.\n   - Build the parts from `git ls-tree -r --name-only \u003CHEAD>` at the pinned HEAD. Each tracked file\n     belongs to a part or to a named exclusion, such as lockfiles or generated files. The preview\n     lists the exclusions, and the run report lists them as gaps.\n   - Call `code_review` `prepare` once per part, in part order. The first part's directory is the\n     run directory `$run`. Then write `$run\u002Fbrief.md` once from the [brief template](brief.md).\n   - For each part, in order, run steps 2 to 5 with its prepared directory as `$dir`, without a\n     second `prepare`, and a `files` target that lists the part's paths. Finish the finder and the\n     checker of one part before you start the next part.\n     - When the capture phase would repeat for a part, stop the run and ask the user, because the\n       brief pins one HEAD and each part's directory.\n     - The finder's and the checker's tasks both name `$run\u002Fbrief.md` and the `checked.md` path of\n       every earlier part. Part 1 has no earlier part.\n     - The checker tests the part's findings and any correction of an earlier part.\n     - Save `finder.md` and `checker.md` in the part's `$dir` as step 6 says, but write no per-part\n       `report.md`. Save `$dir\u002Fchecked.md` instead: the part's findings and corrections, each with\n       the checker's status.\n   - A failed worker is a gap for its part, and the run goes on to the next part. A stale part is\n     labeled stale in its `checked.md` and in the run report, and the run goes on. Ask about stale\n     parts once, in the final reply. Never relaunch a part or rerun the skill.\n   - Write one run report, `$run\u002Freport.md`, with the [report template](report.md). Then post it as\n     step 7 says, with `$run` as `$dir`, and reply as step 8 says.\n",{"name":5,"description":7},"main","94c73f87b3dc74c74d42405a593111283ef692b2","src\u002Fskills\u002Fcode-quality",0,"https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau","https:\u002F\u002Fgithub.com\u002FsQVe","2026-11-13 03:55:48",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add sQVe\u002Ftau --skill code-quality",{"tool":62,"command":63},"bunx","bunx skills add sQVe\u002Ftau --skill code-quality",{"tool":65,"command":66},"pnpm","pnpm dlx skills add sQVe\u002Ftau --skill code-quality","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-quality\u002FSKILL.md",true,[70,76,80,84],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"brief.md","REFERENCE","参考文档",549,"https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-quality\u002Fbrief.md",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"quality-assignment.md",5073,"https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-quality\u002Fquality-assignment.md",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"report.md",2860,"https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-quality\u002Freport.md",{"path":85,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":86,"sourceHtmlUrl":87},"structure-criteria.md",8121,"https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-quality\u002Fstructure-criteria.md",[89,112,129,147,169,189],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":44},"01M6PG8VMDC9G899WQR5Y6P837","worktree","Create or open a Git worktree for a ticket or task with Grove and open it as a herdr-app space. Use it when asked to create, add, start, or open a worktree, optionally followed by a handover.","https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fworktree\u002FSKILL.md",[],[91,96,34,97,98,99,100,101,31,102,103,104,105,106,40,107,108,109,110,111],"handover","app","create","as","git worktree","herdr","ticket","git","grove","open","start","it","add","task","space","when",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":44},"01M6PG8RSA5XKX4FVSZ5K8GZC4","update-branch","Rebase the current branch onto its base, resolve conflicts, and update the PR when asked. Use it for \"rebase onto main\", \"fix conflicts\", \"the PR has conflicts\", or when a rebase or merge stops on a conflict.","https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fupdate-branch\u002FSKILL.md",[],[41,119,120,121,122,123,31,124,125,126,49,40,127,128,107,111],"update","update branch","conflicts","conflict","pr","merge","fix","base","resolve conflicts","rebase",{"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":44},"01M6PG8KQYQKE4JW4ZPC113F7M","triage-findings","Verify review findings or comments the user asked you to act on, fix the supported ones in scope, and report each one as Fixed, Not worth changing, Incorrect, or Blocked. Use it for \"triage these findings\", \"fix these review comments\", or \"act on the findings I approved\". `code-review`, `pr`, and `start-slice` also start it after a review of the user's own work.","https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Ftriage-findings\u002FSKILL.md",[],[136,137,99,123,138,31,139,140,125,40,141,142,25,43,28,143,144,145,106,146],"triage findings","triage","scope","slice","review findings","you","comments","work","verify","report","act",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":44},"01M6PG8E9VEDNC1CVNMFRBFYFD","tracker","Write Linear tickets by Tau's rules. Pick the type and template, route it, search for duplicates, and use checked tools for ticket writes and the two allowed status changes. Use it for \"file a bug\", \"create a ticket\", or \"add a follow-up ticket\". It does not split designs or start slices.","https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Ftracker\u002FSKILL.md",[],[149,154,155,31,156,157,102,158,40,159,160,161,162,163,164,98,165,166,167,168],"tau","duplicates","search","pick","up","Rules","split","file","linear ticket","type","route","changes","template","run","tickets",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":44},"01M6PG8AJTFMSX8T44VN9WWDS7","tdd","Change behavior test-first with Tau's run_tests tool, then verify the affected tests and a mutation check. Use it when changing behavior. Covers the cycle and survivor handling, not test design.","https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Ftdd\u002FSKILL.md",[],[171,176,154,34,177,178,179,180,144,167,181,182,183,184,185,186,40,187,188,107,111],"test-first","test","change","first","affected","cycle","behavior","tool","tests","design","mutation","test design","survivor",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":200,"publishedAt":44},"01M6PG84S06028WY2HY53RZ1XA","start-slice","Start one slice of a planned design. Creates its branch and its agent tickets in Linear, then delegates the work. Picks the next slice from order, dependencies, and merge state, and reports the branch, base, and agent tickets it created. Use it for \"start the next slice\", \"start ENG-123\", or \"begin this ticket as a slice\". It does not split a design into slices.","https:\u002F\u002Fgithub.com\u002FsQVe\u002Ftau\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fstart-slice\u002FSKILL.md",[195],{"categoryNo":196,"categoryName":197,"taxonomyType":198,"taxonomyTypeDesc":199},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[139,201,106,202,203,99,41,143,204,205,31,124,168,206,102,126,185,40,160,107],"start slice","reports","state","next","delegates","dependencies"]