[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6J4TYGNBZG2YSSHCY8BASFB":3,"skill-same:01M6J4TYGNBZG2YSSHCY8BASFB":100},{"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":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6J4TYGNBZG2YSSHCY8BASFB","planr-sprint",null,"Refine every open backlog item against the code and the calendar, refute the picks, and select a sprint that fits capacity and the release cut. Use before a cut or sprint; not for decomposing one specification or reporting status.","openplanr\u002FOpenPlanr","openplanr","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273764861?v=4","01M6J4PHHBPM1ATKH7TXR1AZMB","OpenPlanr","01M6J4PHNQ7FWP1CC3JGNVBQ8N",6,"MIT","https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-sprint\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],"planr sprint","sprint","calendar","for","cut","release cut","backlog","refine","specification","status","use","select","open","reporting","release","code","capacity","2026-11-10 10:12:30",false,"---\nname: planr-sprint\ndescription: Refine every open backlog item against the code and the calendar, refute the picks, and select a sprint that fits capacity and the release cut. Use before a cut or sprint; not for decomposing one specification or reporting status.\nlicense: MIT\n---\n\n# OpenPlanr Sprint\n\nBacklog refinement followed by sprint selection. **Refine** reads every open\nitem in full and judges it against the default branch and the calendar.\n**Select** fits the surviving items to the stated capacity and the next release\ncut, refutes the picks with three independent lenses, and writes the sprint.\nPerform the reasoning in this session; never delegate it to a model subprocess.\nThe CLI (`openplanr sprint …`) stores what this skill decides. It is optional: when\nit is unavailable, write the same files by hand in the shapes given in\n[sprint formats](references\u002Fsprint-formats.md).\n\nUse `planr-plan` to decompose one specification, `planr-status` to report\nwithout judging, and `planr-operate` for an executive decision queue. This skill\nnever implements work and never chains into `planr-ship`.\n\n`--refine-only` runs the refine phase (steps 1 to 4 for the blocked and\nclose-or-demote buckets) and writes the refinement note without creating a\nsprint. Any run can be repeated and diffed against the previous one.\n\n## Inputs are tiers, not gates\n\nEvery input except the backlog is optional. A missing tier removes one\ncapability; it never blocks the run. Name every degraded input in `Issues`.\n\n| Input | If present | If absent |\n| --- | --- | --- |\n| Open backlog and quick tasks (`.planr\u002Fbacklog\u002F`, `.planr\u002Fquick\u002F`, open spec tasks) | The core: read, score, bucket | The only hard requirement; zero items means \"nothing to refine\" |\n| Git history and the code paths items cite | Evidence lens: stale, already fixed, premise false | Buckets rest on the items' own dates; say \"not verified against code\" |\n| Release profile (`.release\u002Fprofile.md`: cut date, cadence, freezes) | Size the In-progress bucket to the cut; the sprint gets `releaseCut` | Ask once for a horizon; default to a two-week sprint from today |\n| Capacity (engineers × working days) | Fit the list and name the overflow | Ask once; default 1 engineer × 10 days, stated in the return |\n| Previous sprint or refinement note (`.planr\u002Fsprints\u002FSPRINT-NNN\u002Frefinement.json`) | Carry `leftovers`; `openplanr sprint diff` is possible | First run, no diff |\n| Last Operate cycle | Rank its unfinished actions alongside | Skipped silently |\n| ~~project tracker or ~~source control ([connectors](references\u002Fconnectors.md)) | Update linked issues on approval, read PR state | Local files only; report the external step as not run and name the category to add |\n\n## Step 0: Frame the run\n\nBefore reading the backlog, ask through the host's structured question surface\n(Claude Code `AskUserQuestion`, the Codex equivalent), never through free text\nwhen a structured surface exists.\n\n- One call, at most three questions, each with mutually exclusive options and\n  a recommended default; the user can always answer \"Other\".\n- Ask only what the repository cannot answer: capacity and horizon when no\n  profile and no argument supplies them; a focus (one product or area, or\n  everything); what to do with items judged dead (close, demote, or list only);\n  refine only, or refine and select.\n- Never ask about facts derivable from files (the cut date in the profile, the\n  last sprint, the open item count). Never ask mid-run.\n- With `--yes` or no structured surface, take the defaults and list the ones\n  taken in `Issues`.\n\nThe only other question is the approval at the end (step 6).\n\n## Step 1: Read the calendar and capacity\n\nNext cut and freezes from `.release\u002Fprofile.md`; capacity from the framing\nquestion or argument; `leftovers` from the previous sprint's `refinement.json`;\nunfinished actions from the last Operate cycle. Record the git revision the run\njudges against (`git rev-parse --short HEAD` on the default branch).\n\n## Step 2: Read every open item in full\n\nBacklog items, quick tasks and open spec tasks: the whole file, not the title.\nFor each item record the fields in the\n[refinement contract](references\u002Frefinement-contract.md): what it claims, the\nlatest dated evidence, the code path it names and whether that path still\nexists on the default branch as described, what blocks it (partner, team\ndecision, another item, nothing), an effort class (`hours`, `day`, `days`,\n`week+`), and a score: production impact this month × tractability now.\n\nRead the code an item names before believing its claim. `git log -S`, `git\nlog -- \u003Cpath>` and the merged pull requests since the item's evidence date are\nthe cheapest refutations.\n\n## Step 3: Rank into four buckets\n\n- **In progress now**: fits capacity to the cut, in execution order, grouped\n  into PR batches by product or into sessions. Each batch carries a title and\n  an effort in days.\n- **Plan next**: real, but after the cut.\n- **Blocked**: the named blocker and the one question that unblocks it.\n- **Close or demote**: with the evidence (`file:line`, PR number or date) and\n  the target status or priority in the repository's own vocabulary.\n\nCarry the previous Operate cycle's unfinished actions explicitly. Include the\nrelease cut itself as work; when it has no artifact yet, file it with\n`openplanr quick create \"Release cut \u003Cdate>\"` so the sprint contains only artifact\nids.\n\n## Step 4: Refute the In-progress bucket\n\nBefore the bucket is shown, run three independent lenses over every pick:\n\n1. **Evidence**: still real on the default branch; premise not false; not\n   already fixed.\n2. **Capacity and sequencing**: fits the days; migrations, partner\n   dependencies, PR batching and CI cost per PR are accounted for.\n3. **User impact**: who is hit this month if it is not done, and which\n   higher-impact item was omitted for it.\n\nA pick that fails moves or drops, and the reason is kept in `refuted[]` with its\nlens. The list must fit the stated capacity; when it does not, say what was cut.\n\n## Step 5: Write the sprint, the note and the JSON, then stop\n\nWrite the three durable outputs (formats in\n[sprint formats](references\u002Fsprint-formats.md)); the chat return is a view of\nthem.\n\n```bash\nopenplanr sprint create --data sprint.json --json                  # name, releaseCut, capacityDays, startDate\nopenplanr sprint refinement SPRINT-NNN --data refinement.json --json # validates, stores the note and JSON, fills the sprint body\nopenplanr sprint diff SPRINT-MMM SPRINT-NNN                          # when a previous run exists\n```\n\n`refinement.json` must satisfy [the schema](schemas\u002Frefinement.schema.json); the\nCLI rejects an inconsistent document with `$`-rooted diagnostics. Fix the\ndocument, never the validation. With `--refine-only`, skip `sprint create` and\nrecord the refinement against the current active sprint, or write only the note\nand JSON when none exists.\n\nThen stop. Ask the approval question through the structured surface: apply the\nwrite-back, or leave the proposal as written.\n\n## Step 6: On approval, apply\n\n```bash\nopenplanr sprint apply SPRINT-NNN --dry-run          # show the status and priority changes\nopenplanr sprint apply SPRINT-NNN --yes --commit     # one commit: chore(planr): refine backlog for SPRINT-NNN\n```\n\nThen, if ~~project tracker is connected, update the issue linked to each changed\nitem through the host's connection, with the status mapping in the\n[tracker sync reference](references\u002Ftracker-connections.md). Before any remote write,\nlist every issue change: each issue to create, update, close or reopen, with its\ntitle and the status it moves to. Write only when the request explicitly asked for\nthat push or the user approves the list. Afterwards, report each item that was not\nupdated and why, and name the category and product used.\n\nWith nothing connected, the local apply is the whole step: report the tracker\nupdate as not run and give the current host's step from\n[connectors](references\u002Fconnectors.md).\n\nWhen the CLI is unavailable, apply the same status changes with the repository's\nown vocabulary and commit them with the same message.\n\nClose a finished sprint with `openplanr sprint close SPRINT-NNN`; it records the\nleftovers the next run carries.\n\n## Rules from production use\n\n- Never move an item to In progress on its own priority label; a months-old P0\n  or P1 is often dead. Evidence date beats label.\n- Never accept an item's claim of impact without reading the code path it names.\n- Items blocked on a partner or a team decision are never In progress; they get\n  the question that unblocks them.\n- The list must fit the stated capacity; if it does not, say what was cut.\n- No new migration in a hand deploy unless the sprint says so explicitly.\n- Use the repository's own status vocabulary (`openplanr update --help` lists it);\n  never introduce a second one.\n- The note and the JSON are the durable output; the chat return is a view of\n  them. That is what keeps the third run from re-arguing the first two.\n\n## Return\n\nLead with what was proposed or actually applied. Link the sprint, refinement note\nand JSON; keep full bucket rows and refuted picks in those artifacts rather than\nrepeating the backlog in chat. Summarize the selection and checks that justify it,\nand identify incomplete evidence or blocked inputs with their recovery action.\n\n- **Outcome:** `proposed` (sprint written, nothing else changed) or `applied`\n  (status changes written on approval), plus capacity used vs available in\n  engineer-days.\n- **Sprint:** the sprint id and path, and the cut it targets.\n- **Buckets:** counts for the four buckets, the selected batches in execution\n  order, and the most consequential blocked or close-or-demote decision.\n- **Refuted:** material changes to the selection, with their evidence or capacity rationale.\n- **Checks:** code\u002Fcalendar evidence and refutation lenses actually completed.\n- **Issues:** degraded inputs, items that could not be read or judged, defaults\n  taken, or `none`.\n- **Next:** the pending write-back choice or next useful action, only when needed.\n\nThe note and JSON remain complete and unchanged in shape. Omit empty chat sections;\ndifferent summary wording never causes another sprint creation or write-back.\n\n`openplanr status` shows the active sprint with its cut and progress; the dashboard\n(`planr-dashboard`) renders the sprint from the same frontmatter and checkboxes.\n\n## Reference files\n\n- [Refinement contract](references\u002Frefinement-contract.md): item record, scoring, effort classes, buckets, refuter lenses, `refinement.json` fields\n- [Sprint formats](references\u002Fsprint-formats.md): sprint artifact, refinement note, chat return, hand-written fallback\n- [Refinement schema](schemas\u002Frefinement.schema.json): the JSON Schema the CLI validates against\n","# OpenPlanr Sprint\n\nBacklog refinement followed by sprint selection. **Refine** reads every open\nitem in full and judges it against the default branch and the calendar.\n**Select** fits the surviving items to the stated capacity and the next release\ncut, refutes the picks with three independent lenses, and writes the sprint.\nPerform the reasoning in this session; never delegate it to a model subprocess.\nThe CLI (`openplanr sprint …`) stores what this skill decides. It is optional: when\nit is unavailable, write the same files by hand in the shapes given in\n[sprint formats](references\u002Fsprint-formats.md).\n\nUse `planr-plan` to decompose one specification, `planr-status` to report\nwithout judging, and `planr-operate` for an executive decision queue. This skill\nnever implements work and never chains into `planr-ship`.\n\n`--refine-only` runs the refine phase (steps 1 to 4 for the blocked and\nclose-or-demote buckets) and writes the refinement note without creating a\nsprint. Any run can be repeated and diffed against the previous one.\n\n## Inputs are tiers, not gates\n\nEvery input except the backlog is optional. A missing tier removes one\ncapability; it never blocks the run. Name every degraded input in `Issues`.\n\n| Input | If present | If absent |\n| --- | --- | --- |\n| Open backlog and quick tasks (`.planr\u002Fbacklog\u002F`, `.planr\u002Fquick\u002F`, open spec tasks) | The core: read, score, bucket | The only hard requirement; zero items means \"nothing to refine\" |\n| Git history and the code paths items cite | Evidence lens: stale, already fixed, premise false | Buckets rest on the items' own dates; say \"not verified against code\" |\n| Release profile (`.release\u002Fprofile.md`: cut date, cadence, freezes) | Size the In-progress bucket to the cut; the sprint gets `releaseCut` | Ask once for a horizon; default to a two-week sprint from today |\n| Capacity (engineers × working days) | Fit the list and name the overflow | Ask once; default 1 engineer × 10 days, stated in the return |\n| Previous sprint or refinement note (`.planr\u002Fsprints\u002FSPRINT-NNN\u002Frefinement.json`) | Carry `leftovers`; `openplanr sprint diff` is possible | First run, no diff |\n| Last Operate cycle | Rank its unfinished actions alongside | Skipped silently |\n| ~~project tracker or ~~source control ([connectors](references\u002Fconnectors.md)) | Update linked issues on approval, read PR state | Local files only; report the external step as not run and name the category to add |\n\n## Step 0: Frame the run\n\nBefore reading the backlog, ask through the host's structured question surface\n(Claude Code `AskUserQuestion`, the Codex equivalent), never through free text\nwhen a structured surface exists.\n\n- One call, at most three questions, each with mutually exclusive options and\n  a recommended default; the user can always answer \"Other\".\n- Ask only what the repository cannot answer: capacity and horizon when no\n  profile and no argument supplies them; a focus (one product or area, or\n  everything); what to do with items judged dead (close, demote, or list only);\n  refine only, or refine and select.\n- Never ask about facts derivable from files (the cut date in the profile, the\n  last sprint, the open item count). Never ask mid-run.\n- With `--yes` or no structured surface, take the defaults and list the ones\n  taken in `Issues`.\n\nThe only other question is the approval at the end (step 6).\n\n## Step 1: Read the calendar and capacity\n\nNext cut and freezes from `.release\u002Fprofile.md`; capacity from the framing\nquestion or argument; `leftovers` from the previous sprint's `refinement.json`;\nunfinished actions from the last Operate cycle. Record the git revision the run\njudges against (`git rev-parse --short HEAD` on the default branch).\n\n## Step 2: Read every open item in full\n\nBacklog items, quick tasks and open spec tasks: the whole file, not the title.\nFor each item record the fields in the\n[refinement contract](references\u002Frefinement-contract.md): what it claims, the\nlatest dated evidence, the code path it names and whether that path still\nexists on the default branch as described, what blocks it (partner, team\ndecision, another item, nothing), an effort class (`hours`, `day`, `days`,\n`week+`), and a score: production impact this month × tractability now.\n\nRead the code an item names before believing its claim. `git log -S`, `git\nlog -- \u003Cpath>` and the merged pull requests since the item's evidence date are\nthe cheapest refutations.\n\n## Step 3: Rank into four buckets\n\n- **In progress now**: fits capacity to the cut, in execution order, grouped\n  into PR batches by product or into sessions. Each batch carries a title and\n  an effort in days.\n- **Plan next**: real, but after the cut.\n- **Blocked**: the named blocker and the one question that unblocks it.\n- **Close or demote**: with the evidence (`file:line`, PR number or date) and\n  the target status or priority in the repository's own vocabulary.\n\nCarry the previous Operate cycle's unfinished actions explicitly. Include the\nrelease cut itself as work; when it has no artifact yet, file it with\n`openplanr quick create \"Release cut \u003Cdate>\"` so the sprint contains only artifact\nids.\n\n## Step 4: Refute the In-progress bucket\n\nBefore the bucket is shown, run three independent lenses over every pick:\n\n1. **Evidence**: still real on the default branch; premise not false; not\n   already fixed.\n2. **Capacity and sequencing**: fits the days; migrations, partner\n   dependencies, PR batching and CI cost per PR are accounted for.\n3. **User impact**: who is hit this month if it is not done, and which\n   higher-impact item was omitted for it.\n\nA pick that fails moves or drops, and the reason is kept in `refuted[]` with its\nlens. The list must fit the stated capacity; when it does not, say what was cut.\n\n## Step 5: Write the sprint, the note and the JSON, then stop\n\nWrite the three durable outputs (formats in\n[sprint formats](references\u002Fsprint-formats.md)); the chat return is a view of\nthem.\n\n```bash\nopenplanr sprint create --data sprint.json --json                  # name, releaseCut, capacityDays, startDate\nopenplanr sprint refinement SPRINT-NNN --data refinement.json --json # validates, stores the note and JSON, fills the sprint body\nopenplanr sprint diff SPRINT-MMM SPRINT-NNN                          # when a previous run exists\n```\n\n`refinement.json` must satisfy [the schema](schemas\u002Frefinement.schema.json); the\nCLI rejects an inconsistent document with `$`-rooted diagnostics. Fix the\ndocument, never the validation. With `--refine-only`, skip `sprint create` and\nrecord the refinement against the current active sprint, or write only the note\nand JSON when none exists.\n\nThen stop. Ask the approval question through the structured surface: apply the\nwrite-back, or leave the proposal as written.\n\n## Step 6: On approval, apply\n\n```bash\nopenplanr sprint apply SPRINT-NNN --dry-run          # show the status and priority changes\nopenplanr sprint apply SPRINT-NNN --yes --commit     # one commit: chore(planr): refine backlog for SPRINT-NNN\n```\n\nThen, if ~~project tracker is connected, update the issue linked to each changed\nitem through the host's connection, with the status mapping in the\n[tracker sync reference](references\u002Ftracker-connections.md). Before any remote write,\nlist every issue change: each issue to create, update, close or reopen, with its\ntitle and the status it moves to. Write only when the request explicitly asked for\nthat push or the user approves the list. Afterwards, report each item that was not\nupdated and why, and name the category and product used.\n\nWith nothing connected, the local apply is the whole step: report the tracker\nupdate as not run and give the current host's step from\n[connectors](references\u002Fconnectors.md).\n\nWhen the CLI is unavailable, apply the same status changes with the repository's\nown vocabulary and commit them with the same message.\n\nClose a finished sprint with `openplanr sprint close SPRINT-NNN`; it records the\nleftovers the next run carries.\n\n## Rules from production use\n\n- Never move an item to In progress on its own priority label; a months-old P0\n  or P1 is often dead. Evidence date beats label.\n- Never accept an item's claim of impact without reading the code path it names.\n- Items blocked on a partner or a team decision are never In progress; they get\n  the question that unblocks them.\n- The list must fit the stated capacity; if it does not, say what was cut.\n- No new migration in a hand deploy unless the sprint says so explicitly.\n- Use the repository's own status vocabulary (`openplanr update --help` lists it);\n  never introduce a second one.\n- The note and the JSON are the durable output; the chat return is a view of\n  them. That is what keeps the third run from re-arguing the first two.\n\n## Return\n\nLead with what was proposed or actually applied. Link the sprint, refinement note\nand JSON; keep full bucket rows and refuted picks in those artifacts rather than\nrepeating the backlog in chat. Summarize the selection and checks that justify it,\nand identify incomplete evidence or blocked inputs with their recovery action.\n\n- **Outcome:** `proposed` (sprint written, nothing else changed) or `applied`\n  (status changes written on approval), plus capacity used vs available in\n  engineer-days.\n- **Sprint:** the sprint id and path, and the cut it targets.\n- **Buckets:** counts for the four buckets, the selected batches in execution\n  order, and the most consequential blocked or close-or-demote decision.\n- **Refuted:** material changes to the selection, with their evidence or capacity rationale.\n- **Checks:** code\u002Fcalendar evidence and refutation lenses actually completed.\n- **Issues:** degraded inputs, items that could not be read or judged, defaults\n  taken, or `none`.\n- **Next:** the pending write-back choice or next useful action, only when needed.\n\nThe note and JSON remain complete and unchanged in shape. Omit empty chat sections;\ndifferent summary wording never causes another sprint creation or write-back.\n\n`openplanr status` shows the active sprint with its cut and progress; the dashboard\n(`planr-dashboard`) renders the sprint from the same frontmatter and checkboxes.\n\n## Reference files\n\n- [Refinement contract](references\u002Frefinement-contract.md): item record, scoring, effort classes, buckets, refuter lenses, `refinement.json` fields\n- [Sprint formats](references\u002Fsprint-formats.md): sprint artifact, refinement note, chat return, hand-written fallback\n- [Refinement schema](schemas\u002Frefinement.schema.json): the JSON Schema the CLI validates against\n",{"name":5,"license":15,"description":7},"main","8e3991b4f17b5619cf939a6fa06d45bca8115d98","skills\u002Fplanr-sprint",1,"https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr","https:\u002F\u002Fopenplanr.dev","https:\u002F\u002Fgithub.com\u002Fopenplanr","https:\u002F\u002Fopenplanr.dev\u002F","Close the loop from intent to delivery. The open harness around your coding agent.","2026-11-11 21:48:23",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add openplanr\u002FOpenPlanr --skill planr-sprint",{"tool":62,"command":63},"bunx","bunx skills add openplanr\u002FOpenPlanr --skill planr-sprint",{"tool":65,"command":66},"pnpm","pnpm dlx skills add openplanr\u002FOpenPlanr --skill planr-sprint","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-sprint\u002FSKILL.md",true,[70,76,80,84,88,92,96],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"agents\u002Fopenai.yaml","REFERENCE","参考文档",442,"https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-sprint\u002Fagents\u002Fopenai.yaml",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"openplanr.skill.json",1553,"https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-sprint\u002Fopenplanr.skill.json",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fconnectors.md",5264,"https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-sprint\u002Freferences\u002Fconnectors.md",{"path":85,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Frefinement-contract.md",6427,"https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-sprint\u002Freferences\u002Frefinement-contract.md",{"path":89,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fsprint-formats.md",5096,"https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-sprint\u002Freferences\u002Fsprint-formats.md",{"path":93,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Ftracker-connections.md",3278,"https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-sprint\u002Freferences\u002Ftracker-connections.md",{"path":97,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":98,"sourceHtmlUrl":99},"schemas\u002Frefinement.schema.json",5581,"https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-sprint\u002Fschemas\u002Frefinement.schema.json",[101,115,133,152,170,195],{"skillNo":102,"name":103,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":114,"publishedAt":41},"01M70XD1RYQC5160MRRCPTGA2K","design","https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Ftests\u002Frelease-train\u002Ffixtures\u002Ffigma\u002Fskills\u002Fdesign\u002FSKILL.md",[106,111],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[103],{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":41},"01M6J4V75T3VW91HJQ5ZD5SFW0","planr-sync","Audit OpenPlanr planning artifacts for graph and protocol drift. Use when statuses, references, schemas, or generated planning views may be inconsistent.","https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-sync\u002FSKILL.md",[],[122,123,27,124,125,126,127,128,129,130,34,131,132],"sync","planr sync","when","graph","protocol","audit","references","drift","artifacts","generated","planning",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":41},"01M6J4V38R89DYYA4AAN312MNZ","planr-status","Inspect project delivery or one feature's pipeline status without changing state. Use when the user asks what is done, pending, blocked, or next.","https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-status\u002FSKILL.md",[],[33,140,141,142,34,143,144,145,146,147,148,124,149,150,151],"planr status","state","done","inspect","pipeline","project","feature","next","pending","pipeline status","user","delivery",{"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":41},"01M6J4TT7X6GV9A25JHSMKEMHJ","planr-spec","Shape vague product or engineering intent into a clear, measurable Protocol-compatible specification grounded in the current repository. Use when requirements need clarification before planning or implementation.","https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-spec\u002FSKILL.md",[],[159,160,32,124,161,162,163,126,164,165,166,167,168,169,34,132],"planr spec","spec","engineering","implementation","clear","shape","repository","product","intent","vague","requirements",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":41},"01M6J4TNYE49SE8PBNNWJKK1CN","planr-ship","Implement an OpenPlanr plan, specification, task, or clearly stated request end to end in the current repository. Use when the user asks to build, implement, fix, finish, or ship local work, or to plan and implement an accepted change. Invoke before editing files for the requested change. Not for planning only, landing, release, or work handed to another coding agent.","https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-ship\u002FSKILL.md",[],[177,178,179,32,180,181,182,183,184,185,186,187,188,124,189,190,191,27,132,192,193,38,165,194],"ship","planr ship","work","files","only","local","fix","end","plan","coding agent","plan and implement","request","invoke","landing","editing","coding","finish","change",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"publishedAt":41},"01M6J4THMSWA1FC0AM76SGW3VH","planr-share","Share a status report, sprint note or release notes with the team as a chat message draft that the user approves and sends. Use when the user asks to post a planning update to chat.","https:\u002F\u002Fgithub.com\u002Fopenplanr\u002FOpenPlanr\u002Fblob\u002Fmain\u002Fskills\u002Fplanr-share\u002FSKILL.md",[],[202,203,204,205,206,25,124,207,38,208,209,210,211,212,213,34,132,214,215,216,33],"planr share","share","release notes","team","status report","update","note","report","post","with","chat","draft","as","notes","message"]