[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PS7Y0VNMYTK7P277JN8WE2":3,"skill-same:01M6PS7Y0VNMYTK7P277JN8WE2":84},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6PS7Y0VNMYTK7P277JN8WE2","tracker",null,"Work the issue tracker – `publish` projects a PRD and its plan into a parent issue and one child issue per story, `triage` labels and routes incoming items toward implementation or a human decision, and `setup` writes the Issue Tracker document. Trigger on 'publish this plan to the tracker', 'triage the backlog', 'set up the issue tracker'.","IT-HUSET\u002Fandthen","IT-HUSET","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F10847803?v=4","01M6DR5QJD7MVM4R3DWCCCTHZ5","01M6DR5QQ0JFQAYZ39SYY8BA28",4,"MIT","https:\u002F\u002Fgithub.com\u002FIT-HUSET\u002Fandthen\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Ftracker\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[5,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"number","json","run","human","child","plan","work","publish","dry","query","document","auto","labels","decision","up","trigger","backlog","projects","SET","2026-11-10 10:12:30",false,"---\ndescription: Work the issue tracker – `publish` projects a PRD and its plan into a parent issue and one child issue per story, `triage` labels and routes incoming items toward implementation or a human decision, and `setup` writes the Issue Tracker document. Trigger on 'publish this plan to the tracker', 'triage the backlog', 'set up the issue tracker'.\nargument-hint: \"[--auto] (publish \u003Cplan.json | prd.md> [--dry-run] | triage [issue number(s) or tracker query] | setup)\"\n---\n\n# Tracker\n\nWork the project's issue tracker through its `Issue Tracker` document, one verb per run.\n\n## Input\n\n`$ARGUMENTS` opens with the verb, and `ARGUMENTS` is the rest minus flags. With no verb there, take the one the request's words name.\n\n| Verb | `ARGUMENTS` | Read |\n|---|---|---|\n| **publish** | a `plan.json`, or a `prd.md` alone | § 2a below |\n| **triage** | issue number(s) or a tracker query; empty triages the untriaged backlog | [`triage.md`](references\u002Ftriage.md), [`agent-brief.md`](references\u002Fagent-brief.md) |\n| **setup** | none | § 2c below |\n\n- `--auto` makes the run unattended: read [`unattended-runs.md`](..\u002F..\u002Freferences\u002Funattended-runs.md) and follow it.\n\n## Rules\n\n- Print each recommended skill invocation as a complete, paste-ready line in the host's syntax, including its target path or request and required arguments.\n\n- **Executable config.** The `Issue Tracker` document is security-critical, because its table values run as commands. Each value is a single direct command invocation (an executable, fixed arguments, `\u003Cplaceholders>`) with no pipes, shell operators, command substitution, or piping to an interpreter. Review changes to it as code.\n- **Complete mapping first.** Before a verb's first tracker call, reads included, stop on any operation it needs that the Operation Table leaves unmapped, so a multi-issue write never strands partial state.\n- **Durability rule.** What you write into a tracker body or comment outlives the branch that prompted it. Name interfaces (types, signatures, commands) and behavior, never file paths, line numbers, commits, or code snippets. A snippet that itself encodes a settled decision (schema, state machine, type) may be inlined, trimmed to the decision-carrying part.\n- **Argv-safe.** Every title, body, and issue number is data: pass the title, the body file, and the issue number as distinct argv elements (or structured MCP fields), never as interpolated shell source. On GitHub, `fetch issue` maps the issue number to `gh issue view \u003CN> --json title,body,labels,state,comments`, `create issue` maps them to `gh issue create --title` and `--body-file`, `edit body` maps the issue number and the body file to `gh issue edit --body-file`, and `comment` maps them to `gh issue comment \u003CN> --body-file`. An operation-table backend keeps the same argument boundary, and a mapping that only offers a shell template is unresolved executable config: stop before the first external call.\n\n## Workflow\n\n### 1. Tracker resolution\n\nBefore `publish` or `triage` runs any tracker operation, resolve the `Issue Tracker` document (**Project Document Index**; default `docs\u002FISSUE-TRACKER.md`) by its `Backend:` line:\n\n- `GitHub` takes the built-in `gh` flows.\n- `none` declares no tracker: end on one line saying so, naming the `Backend:` line.\n- Another backend substitutes every operation from its **Operation Table**. A value naming an MCP tool is invoked the same way.\n- An unparseable `Backend:` line takes `setup`.\n- An absent document takes the `gh` default where the repository has a GitHub remote, and `setup` where it has none, since there is nothing to read.\n\nTaking `setup` means offering it, and an unattended run stops as step 2c says. On acceptance, run it, then resolve against the document it wrote.\n\n**Gate**: the backend is known and every operation the verb needs is mapped.\n\n### 2a. Publish\n\nThe bundle is agent truth, and the tracker is its human projection. `publish` never writes `plan.json`, and sync is one way: a PM reprioritizing in the tracker is a re-plan.\n\n**Operations used**: `fetch issue`, `list issues`, `create issue`, `edit body`.\n\n#### The issues\n\nEach body you write is projected from one hidden line down. On the parent the line is `\u003C!-- andthen-projection \u003Csource> -->`, where `\u003Csource>` is the repo path of the PRD, else of the `plan.json`, kept as identity only. On a child it is `\u003C!-- andthen-projection \u003Cid> \u003Csource> -->`, led by its story's id so the parent's line never matches it. Keep the text above the line, such as a source issue's original request, and put the line below the text of an issue that has none.\n\n- **The parent** is titled by the PRD's heading, else `Plan: \u003Cplan directory name>`. Below the line goes the PRD, each file path it cites replaced by what the file is, then a `## Stories` checklist with one `- [ ] \u003Cid> \u003Cref> – \u003Cname>` per story, `\u003Cref>` the child's `#\u003Cnumber>`, or its key (`ENG-123`) on a tracker whose issue ids are keys, checked once the story is `done` or `skipped`. A plan without a PRD writes only the checklist. A `prd.md` alone writes only the PRD and keeps the checklist already there.\n- **A child** per story is titled `\u003Cplan directory name> \u003Cid> - \u003Cname>`, because story ids restart in every plan. Below the line go the story's scope, then its FIS's Intent, Expected Outcomes, and Acceptance Scenarios without their Proof lines, then `Blocked by:` its dependencies' issues, and once the story is done `Verified:` with its `verified.summary`.\n- **A closed issue is the shipped record**, so never edit one. A found issue keeps its title, because `publish` has no retitle operation.\n- **The checklist never loses a finished story or a link.** A story it checks stays checked, because another branch's copy of `plan.json` finished it; while this copy has not, leave that story's child as it is. An entry for a story the plan no longer has stays too, and the preview and Output name its open child to close. A re-plan numbers new stories after the highest old ID, so an old entry never names a new story.\n\n#### Find them\n\nThe parent is the first open issue among the issue the PRD's header names, a tracker item the plan's `sourceRefs` cite, and the issue `list issues` finds with the line as the body-search phrase. With none open, create the parent, and when a candidate was closed, link it in the text above the line. A child is the issue the parent's checklist links for its story, else the open issue `list issues` finds with its line, because a run that stopped before the checklist write left it unlinked. Two open candidates at one step, for the parent or a child, stop the run, naming both.\n\nOn GitHub, `list issues` for a line is `gh issue list --state all --json number,state,body --search` with one argument, `\"\u003Cline text>\" in:body`: the text inside the comment markers, quoted as one phrase, because unquoted its words match unrelated issues. Only a hit whose body holds the exact line counts.\n\n#### Preview and send\n\nCompare each composed body with the issue's text below its line. Show each issue to create and what each update changes, and ask once before the first write, because an update replaces an edit made in the tracker since the last publish. An edit worth keeping goes into its source first: `prd.md` through the `andthen:clarify` skill, or the story's FIS. When the skill that invoked this run already showed this preview and got a yes, as the `andthen:ship` skill does, that answer is the ask.\n\n`--dry-run` prints the preview and stops before any write. An unattended run skips the ask.\n\nWrite each body as a UTF-8 file under `.agent_temp\u002Ftracker-bodies\u002F` and send it as the body file. Create the missing issues, parent first and stories in plan order, and add each child to the parent's checklist as soon as it exists. Then edit each body still missing an issue reference it names, and send the other updates.\n\n**Gate**: every issue created, updated, or found unchanged, or the user's no; under `--dry-run`, the preview printed.\n\n### 2b. Triage\n\nFollow `triage.md`.\n\n### 2c. Setup\n\nAsk which backend the tracker uses, for any backend but GitHub the command each operation maps to, and whether a feature's requirements record lives in the repo or the tracker. An unattended run writes nothing and stops on `BLOCKED:` naming `setup` and the `Backend:` line to set.\n\n- **An existing document** is edited in place, with no template loaded: set its `Backend:` and `Record:` lines and the operations the answer maps.\n- **A new document** is seeded by a subagent – the installed `worker` role agent when available, else a generic inherited one – that invokes the `andthen:init` skill with `seed Issue Tracker`, the chosen backend, and the record's home, which keeps the templates out of this run's context.\n\n**Gate**: the document carries a parseable `Backend:` line and every operation the chosen backend needs.\n\n## Output\n\n`publish` reports each issue it created, updated, found unchanged, or left closed, by number or key, naming the open child of a dropped story for the user to close, and in an unattended run what each update replaced.\n","# Tracker\n\nWork the project's issue tracker through its `Issue Tracker` document, one verb per run.\n\n## Input\n\n`$ARGUMENTS` opens with the verb, and `ARGUMENTS` is the rest minus flags. With no verb there, take the one the request's words name.\n\n| Verb | `ARGUMENTS` | Read |\n|---|---|---|\n| **publish** | a `plan.json`, or a `prd.md` alone | § 2a below |\n| **triage** | issue number(s) or a tracker query; empty triages the untriaged backlog | [`triage.md`](references\u002Ftriage.md), [`agent-brief.md`](references\u002Fagent-brief.md) |\n| **setup** | none | § 2c below |\n\n- `--auto` makes the run unattended: read [`unattended-runs.md`](..\u002F..\u002Freferences\u002Funattended-runs.md) and follow it.\n\n## Rules\n\n- Print each recommended skill invocation as a complete, paste-ready line in the host's syntax, including its target path or request and required arguments.\n\n- **Executable config.** The `Issue Tracker` document is security-critical, because its table values run as commands. Each value is a single direct command invocation (an executable, fixed arguments, `\u003Cplaceholders>`) with no pipes, shell operators, command substitution, or piping to an interpreter. Review changes to it as code.\n- **Complete mapping first.** Before a verb's first tracker call, reads included, stop on any operation it needs that the Operation Table leaves unmapped, so a multi-issue write never strands partial state.\n- **Durability rule.** What you write into a tracker body or comment outlives the branch that prompted it. Name interfaces (types, signatures, commands) and behavior, never file paths, line numbers, commits, or code snippets. A snippet that itself encodes a settled decision (schema, state machine, type) may be inlined, trimmed to the decision-carrying part.\n- **Argv-safe.** Every title, body, and issue number is data: pass the title, the body file, and the issue number as distinct argv elements (or structured MCP fields), never as interpolated shell source. On GitHub, `fetch issue` maps the issue number to `gh issue view \u003CN> --json title,body,labels,state,comments`, `create issue` maps them to `gh issue create --title` and `--body-file`, `edit body` maps the issue number and the body file to `gh issue edit --body-file`, and `comment` maps them to `gh issue comment \u003CN> --body-file`. An operation-table backend keeps the same argument boundary, and a mapping that only offers a shell template is unresolved executable config: stop before the first external call.\n\n## Workflow\n\n### 1. Tracker resolution\n\nBefore `publish` or `triage` runs any tracker operation, resolve the `Issue Tracker` document (**Project Document Index**; default `docs\u002FISSUE-TRACKER.md`) by its `Backend:` line:\n\n- `GitHub` takes the built-in `gh` flows.\n- `none` declares no tracker: end on one line saying so, naming the `Backend:` line.\n- Another backend substitutes every operation from its **Operation Table**. A value naming an MCP tool is invoked the same way.\n- An unparseable `Backend:` line takes `setup`.\n- An absent document takes the `gh` default where the repository has a GitHub remote, and `setup` where it has none, since there is nothing to read.\n\nTaking `setup` means offering it, and an unattended run stops as step 2c says. On acceptance, run it, then resolve against the document it wrote.\n\n**Gate**: the backend is known and every operation the verb needs is mapped.\n\n### 2a. Publish\n\nThe bundle is agent truth, and the tracker is its human projection. `publish` never writes `plan.json`, and sync is one way: a PM reprioritizing in the tracker is a re-plan.\n\n**Operations used**: `fetch issue`, `list issues`, `create issue`, `edit body`.\n\n#### The issues\n\nEach body you write is projected from one hidden line down. On the parent the line is `\u003C!-- andthen-projection \u003Csource> -->`, where `\u003Csource>` is the repo path of the PRD, else of the `plan.json`, kept as identity only. On a child it is `\u003C!-- andthen-projection \u003Cid> \u003Csource> -->`, led by its story's id so the parent's line never matches it. Keep the text above the line, such as a source issue's original request, and put the line below the text of an issue that has none.\n\n- **The parent** is titled by the PRD's heading, else `Plan: \u003Cplan directory name>`. Below the line goes the PRD, each file path it cites replaced by what the file is, then a `## Stories` checklist with one `- [ ] \u003Cid> \u003Cref> – \u003Cname>` per story, `\u003Cref>` the child's `#\u003Cnumber>`, or its key (`ENG-123`) on a tracker whose issue ids are keys, checked once the story is `done` or `skipped`. A plan without a PRD writes only the checklist. A `prd.md` alone writes only the PRD and keeps the checklist already there.\n- **A child** per story is titled `\u003Cplan directory name> \u003Cid> - \u003Cname>`, because story ids restart in every plan. Below the line go the story's scope, then its FIS's Intent, Expected Outcomes, and Acceptance Scenarios without their Proof lines, then `Blocked by:` its dependencies' issues, and once the story is done `Verified:` with its `verified.summary`.\n- **A closed issue is the shipped record**, so never edit one. A found issue keeps its title, because `publish` has no retitle operation.\n- **The checklist never loses a finished story or a link.** A story it checks stays checked, because another branch's copy of `plan.json` finished it; while this copy has not, leave that story's child as it is. An entry for a story the plan no longer has stays too, and the preview and Output name its open child to close. A re-plan numbers new stories after the highest old ID, so an old entry never names a new story.\n\n#### Find them\n\nThe parent is the first open issue among the issue the PRD's header names, a tracker item the plan's `sourceRefs` cite, and the issue `list issues` finds with the line as the body-search phrase. With none open, create the parent, and when a candidate was closed, link it in the text above the line. A child is the issue the parent's checklist links for its story, else the open issue `list issues` finds with its line, because a run that stopped before the checklist write left it unlinked. Two open candidates at one step, for the parent or a child, stop the run, naming both.\n\nOn GitHub, `list issues` for a line is `gh issue list --state all --json number,state,body --search` with one argument, `\"\u003Cline text>\" in:body`: the text inside the comment markers, quoted as one phrase, because unquoted its words match unrelated issues. Only a hit whose body holds the exact line counts.\n\n#### Preview and send\n\nCompare each composed body with the issue's text below its line. Show each issue to create and what each update changes, and ask once before the first write, because an update replaces an edit made in the tracker since the last publish. An edit worth keeping goes into its source first: `prd.md` through the `andthen:clarify` skill, or the story's FIS. When the skill that invoked this run already showed this preview and got a yes, as the `andthen:ship` skill does, that answer is the ask.\n\n`--dry-run` prints the preview and stops before any write. An unattended run skips the ask.\n\nWrite each body as a UTF-8 file under `.agent_temp\u002Ftracker-bodies\u002F` and send it as the body file. Create the missing issues, parent first and stories in plan order, and add each child to the parent's checklist as soon as it exists. Then edit each body still missing an issue reference it names, and send the other updates.\n\n**Gate**: every issue created, updated, or found unchanged, or the user's no; under `--dry-run`, the preview printed.\n\n### 2b. Triage\n\nFollow `triage.md`.\n\n### 2c. Setup\n\nAsk which backend the tracker uses, for any backend but GitHub the command each operation maps to, and whether a feature's requirements record lives in the repo or the tracker. An unattended run writes nothing and stops on `BLOCKED:` naming `setup` and the `Backend:` line to set.\n\n- **An existing document** is edited in place, with no template loaded: set its `Backend:` and `Record:` lines and the operations the answer maps.\n- **A new document** is seeded by a subagent – the installed `worker` role agent when available, else a generic inherited one – that invokes the `andthen:init` skill with `seed Issue Tracker`, the chosen backend, and the record's home, which keeps the templates out of this run's context.\n\n**Gate**: the document carries a parseable `Backend:` line and every operation the chosen backend needs.\n\n## Output\n\n`publish` reports each issue it created, updated, found unchanged, or left closed, by number or key, naming the open child of a dropped story for the user to close, and in an unattended run what each update replaced.\n",{"description":7,"argument-hint":47},"[--auto] (publish \u003Cplan.json | prd.md> [--dry-run] | triage [issue number(s) or tracker query] | setup)","main","902d8d8d11e7349e3156fa117b248e28e0e273e5","plugin\u002Fskills\u002Ftracker",2,"https:\u002F\u002Fgithub.com\u002FIT-HUSET\u002Fandthen","https:\u002F\u002Fgithub.com\u002FIT-HUSET","https:\u002F\u002Fit-huset.se\u002F","2026-11-11 02:57:38",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add IT-HUSET\u002Fandthen --skill tracker",{"tool":62,"command":63},"bunx","bunx skills add IT-HUSET\u002Fandthen --skill tracker",{"tool":65,"command":66},"pnpm","pnpm dlx skills add IT-HUSET\u002Fandthen --skill tracker","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FIT-HUSET\u002Fandthen\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Ftracker\u002FSKILL.md",true,[70,76,80],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"agents\u002Fopenai.yaml","REFERENCE","参考文档",477,"https:\u002F\u002Fgithub.com\u002FIT-HUSET\u002Fandthen\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Ftracker\u002Fagents\u002Fopenai.yaml",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fagent-brief.md",1033,"https:\u002F\u002Fgithub.com\u002FIT-HUSET\u002Fandthen\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Ftracker\u002Freferences\u002Fagent-brief.md",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Ftriage.md",6714,"https:\u002F\u002Fgithub.com\u002FIT-HUSET\u002Fandthen\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Ftracker\u002Freferences\u002Ftriage.md",[]]