[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7DFAS5993CF7FS5S483DKQ6":3,"skill-same:01M7DFAS5993CF7FS5S483DKQ6":51},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M7DFAS5993CF7FS5S483DKQ6","task-review",null,"Review an existing task, issue, ticket, story, bug report or epic for missing context, unsupported assumptions, unverifiable criteria and scope. Use when asked to assess or refine work-item text before implementation; use task-specification to write a new item and change-review to review code.","andersonmrodrigues\u002Fpaved","andersonmrodrigues","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F13907380?v=4","01M7DEV3FP2VMQZ3FP2FP1TK1C","Anderson Rodrigues","01M7DEV3GC2QAQBW4FMNT98H48",1,"MIT","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Fplugins\u002Fpaved\u002Fskills\u002Ftask-review\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: task-review\ndescription: >-\n  Review an existing task, issue, ticket, story, bug report or epic for missing context, unsupported assumptions, unverifiable criteria and scope. Use when asked to assess or refine work-item text before implementation; use task-specification to write a new item and change-review to review code.\n---\n\n\u003C!-- Generated by Paved plugin paved@2.29.0 from core.product.task-review@0.4.1; edit Paved Core instead. -->\n# Task review\n\n## When to use\n\nWhen a task already written by anyone must be judged ready or improved before someone\nimplements it. To write a task from a request use `task-specification`. To review code\nthat implements a task use `change-review`.\n\n## Required context\n\nNone is required. Read the same context `task-specification` reads (product, domain,\nfeature map, architecture, rules, verification profile), because the review judges the\ntask against what the repository says.\n\n## Preconditions\n\n- The task text is available: pasted by the user, or read through a tracker integration\n  when the user gives a link or identifier and the agent has one. Otherwise ask for the\n  text.\n- The task concerns this repository. If its code lives elsewhere, review only its form\n  and say the repository could not be checked.\n\n## Procedure\n\n1. **Read the task** whole, including comments or subtasks the user supplied, and state\n   its intent in one sentence. Everything below is judged against that intent.\n2. **Check the form** against the template and the per-section bar of the\n   `task-specification` skill, in its directory next to this one\n   (`..\u002Ftask-specification\u002Freferences\u002Ftask-template.md` and\n   `..\u002Ftask-specification\u002Freferences\u002Ftask-quality.md`). Use the template that file's\n   precedence selects, so a repository with its own issue template is judged by it:\n   sections present, type consistent with the content, criteria observable and one per\n   line, steps to reproduce for a bug, and the ready-to-implement bar.\n3. **Check it against the repository.** With `core.repository.structure` and\n   `core.repository.files`, confirm that each path, component, endpoint, screen or\n   configuration the task names exists or is marked as new. Look for premises the code\n   contradicts, other consumers of the affected area the task ignores, rules or\n   boundaries the described change would break, and a pattern to follow it should name.\n4. **Check the size** with the split criteria. A task that fails them gets the vertical\n   slices `task-specification` would propose.\n5. **Classify** each candidate. A *blocking* finding stops someone from implementing the\n   task as written: a missing expected result or criteria, a criterion no one could\n   verify, a premise the code contradicts, a change a project rule forbids, a missing\n   reproduction for a bug, or a size that needs splitting. Any other candidate is a\n   *note*. Discard candidates that are preferences, or that depend on facts you cannot\n   point at in the task or the repository.\n6. **Validate** each blocking finding before recording it: re-open the file or rule it\n   cites and confirm the problem exists as stated. Drop what fails. Each finding names\n   its source: the task section, the path or the rule.\n7. **Decide the verdict**: `ready` (no blocking finding), `needs changes` or\n   `needs split`.\n8. **Rewrite** the task in the template, fixing every finding the repository or the task\n   itself can settle, or propose the split tasks. Keep the author's intent and wording\n   where they were fine; never add a fact the task, the user or the repository does not\n   support. A finding only a human can settle becomes an open question in the rewritten\n   task, or, when the repository shows a few plausible answers, a short set of options\n   for the user to choose from.\n9. **Present it in the preview.** Put the verdict, the findings, what changed and the\n   rewritten task in one Markdown file under `.paved\u002Fgenerated\u002Ftasks\u002F`; for a split, use\n   a folder with the review as its first file and one file per proposed task. Open it\n   with `paved preview start \u003Cfile-or-folder> --json` and reply in the chat with the\n   URL, the verdict and the count of blocking findings only. Run the preview loop from\n   the workflow instructions, applying each comment and resolving it with a reply,\n   until the user says the review is finished. Fall back to the chat only when the user\n   asks for it or the preview fails to start, and say which.\n10. **Apply** only after an explicit yes in the chat to the exact text; the preview\n    approves nothing. If a tracker integration is available, then update the task's\n    description. Never close, move, reassign or delete the task.\n\n## Tools\n\n`core.repository.structure` and `core.repository.files` for step 3. A tracker\nintegration, when the agent has one, reads the task in the preconditions and updates it\nin step 10 only after the user confirms.\n\n## Rules\n\n`core.quality.unknowns-stay-unknown`: a gap the repository cannot fill is an open\nquestion, never a guessed answer in the rewrite. `core.architecture.follow-existing-patterns`\ndecides which sibling the rewritten technical context points at.\n\n## Verification\n\nNone is required of the review. The rewritten task states how each criterion would be\nverified.\n\n## Evidence\n\nA review artifact: the verdict, blocking findings with their source, notes listed\napart, and what was checked in the repository.\n\n## Completion criteria\n\n- The verdict is one of `ready`, `needs changes` or `needs split`.\n- Every blocking finding names its source and was validated against it.\n- The rewrite or the split tasks meet the quality bar and keep the author's intent.\n- Open questions only a human can settle are listed, not answered by guess.\n- The review was presented in the preview, or the reason it was not is stated.\n- The tracker was changed only after the user confirmed the exact text.\n\n## Failure modes\n\n| Failure | Signal | Response |\n|---|---|---|\n| Rubber stamp | `ready` for a task with vague criteria | Apply the verifiable criteria bar line by line |\n| Pedantry | Findings are about wording while criteria are unverifiable | Revisit steps 2 and 3 first |\n| False contradiction | A finding says something is missing, but it lives in another repository | Say the repository could not confirm it; ask |\n| Silent rewrite | The corrected task changes scope without a finding explaining why | Add the finding or restore the author's scope |\n| Invented fix | The rewrite fills a gap with a plausible answer no source supports | Make it an open question or offer options |\n| Review dumped in the chat | The findings and rewrite were printed instead of previewed | Write them to the file, open the preview, reply with the URL |\n| Unconfirmed write | The tracker changed before the user saw the text | Stop; always show and ask first |\n| Template conflict | The project addendum and the template disagree | Follow the addendum |\n\n## References\n\n- `examples\u002Ftask-review.md`: a weak task, its findings and its rewrite.\n\n\n## Paved integration\n\nUse the project-local Paved contract as the source of truth. Discover state with `node \"\u003Cplugin root>\u002Fscripts\u002Fpaved.mjs\" status --json`, load only relevant `.paved\u002Fproject\u002F` context, and invoke verification with `node \"\u003Cplugin root>\u002Fscripts\u002Fpaved.mjs\" verify --json`. `\u003Cplugin root>` is the installed Paved plugin directory, two directories above this SKILL.md. Always run the launcher from the repository being worked on, never from the plugin directory. Do not edit generated integration files or bypass Paved lifecycle and ownership checks.\n","\u003C!-- Generated by Paved plugin paved@2.29.0 from core.product.task-review@0.4.1; edit Paved Core instead. -->\n# Task review\n\n## When to use\n\nWhen a task already written by anyone must be judged ready or improved before someone\nimplements it. To write a task from a request use `task-specification`. To review code\nthat implements a task use `change-review`.\n\n## Required context\n\nNone is required. Read the same context `task-specification` reads (product, domain,\nfeature map, architecture, rules, verification profile), because the review judges the\ntask against what the repository says.\n\n## Preconditions\n\n- The task text is available: pasted by the user, or read through a tracker integration\n  when the user gives a link or identifier and the agent has one. Otherwise ask for the\n  text.\n- The task concerns this repository. If its code lives elsewhere, review only its form\n  and say the repository could not be checked.\n\n## Procedure\n\n1. **Read the task** whole, including comments or subtasks the user supplied, and state\n   its intent in one sentence. Everything below is judged against that intent.\n2. **Check the form** against the template and the per-section bar of the\n   `task-specification` skill, in its directory next to this one\n   (`..\u002Ftask-specification\u002Freferences\u002Ftask-template.md` and\n   `..\u002Ftask-specification\u002Freferences\u002Ftask-quality.md`). Use the template that file's\n   precedence selects, so a repository with its own issue template is judged by it:\n   sections present, type consistent with the content, criteria observable and one per\n   line, steps to reproduce for a bug, and the ready-to-implement bar.\n3. **Check it against the repository.** With `core.repository.structure` and\n   `core.repository.files`, confirm that each path, component, endpoint, screen or\n   configuration the task names exists or is marked as new. Look for premises the code\n   contradicts, other consumers of the affected area the task ignores, rules or\n   boundaries the described change would break, and a pattern to follow it should name.\n4. **Check the size** with the split criteria. A task that fails them gets the vertical\n   slices `task-specification` would propose.\n5. **Classify** each candidate. A *blocking* finding stops someone from implementing the\n   task as written: a missing expected result or criteria, a criterion no one could\n   verify, a premise the code contradicts, a change a project rule forbids, a missing\n   reproduction for a bug, or a size that needs splitting. Any other candidate is a\n   *note*. Discard candidates that are preferences, or that depend on facts you cannot\n   point at in the task or the repository.\n6. **Validate** each blocking finding before recording it: re-open the file or rule it\n   cites and confirm the problem exists as stated. Drop what fails. Each finding names\n   its source: the task section, the path or the rule.\n7. **Decide the verdict**: `ready` (no blocking finding), `needs changes` or\n   `needs split`.\n8. **Rewrite** the task in the template, fixing every finding the repository or the task\n   itself can settle, or propose the split tasks. Keep the author's intent and wording\n   where they were fine; never add a fact the task, the user or the repository does not\n   support. A finding only a human can settle becomes an open question in the rewritten\n   task, or, when the repository shows a few plausible answers, a short set of options\n   for the user to choose from.\n9. **Present it in the preview.** Put the verdict, the findings, what changed and the\n   rewritten task in one Markdown file under `.paved\u002Fgenerated\u002Ftasks\u002F`; for a split, use\n   a folder with the review as its first file and one file per proposed task. Open it\n   with `paved preview start \u003Cfile-or-folder> --json` and reply in the chat with the\n   URL, the verdict and the count of blocking findings only. Run the preview loop from\n   the workflow instructions, applying each comment and resolving it with a reply,\n   until the user says the review is finished. Fall back to the chat only when the user\n   asks for it or the preview fails to start, and say which.\n10. **Apply** only after an explicit yes in the chat to the exact text; the preview\n    approves nothing. If a tracker integration is available, then update the task's\n    description. Never close, move, reassign or delete the task.\n\n## Tools\n\n`core.repository.structure` and `core.repository.files` for step 3. A tracker\nintegration, when the agent has one, reads the task in the preconditions and updates it\nin step 10 only after the user confirms.\n\n## Rules\n\n`core.quality.unknowns-stay-unknown`: a gap the repository cannot fill is an open\nquestion, never a guessed answer in the rewrite. `core.architecture.follow-existing-patterns`\ndecides which sibling the rewritten technical context points at.\n\n## Verification\n\nNone is required of the review. The rewritten task states how each criterion would be\nverified.\n\n## Evidence\n\nA review artifact: the verdict, blocking findings with their source, notes listed\napart, and what was checked in the repository.\n\n## Completion criteria\n\n- The verdict is one of `ready`, `needs changes` or `needs split`.\n- Every blocking finding names its source and was validated against it.\n- The rewrite or the split tasks meet the quality bar and keep the author's intent.\n- Open questions only a human can settle are listed, not answered by guess.\n- The review was presented in the preview, or the reason it was not is stated.\n- The tracker was changed only after the user confirmed the exact text.\n\n## Failure modes\n\n| Failure | Signal | Response |\n|---|---|---|\n| Rubber stamp | `ready` for a task with vague criteria | Apply the verifiable criteria bar line by line |\n| Pedantry | Findings are about wording while criteria are unverifiable | Revisit steps 2 and 3 first |\n| False contradiction | A finding says something is missing, but it lives in another repository | Say the repository could not confirm it; ask |\n| Silent rewrite | The corrected task changes scope without a finding explaining why | Add the finding or restore the author's scope |\n| Invented fix | The rewrite fills a gap with a plausible answer no source supports | Make it an open question or offer options |\n| Review dumped in the chat | The findings and rewrite were printed instead of previewed | Write them to the file, open the preview, reply with the URL |\n| Unconfirmed write | The tracker changed before the user saw the text | Stop; always show and ask first |\n| Template conflict | The project addendum and the template disagree | Follow the addendum |\n\n## References\n\n- `examples\u002Ftask-review.md`: a weak task, its findings and its rewrite.\n\n\n## Paved integration\n\nUse the project-local Paved contract as the source of truth. Discover state with `node \"\u003Cplugin root>\u002Fscripts\u002Fpaved.mjs\" status --json`, load only relevant `.paved\u002Fproject\u002F` context, and invoke verification with `node \"\u003Cplugin root>\u002Fscripts\u002Fpaved.mjs\" verify --json`. `\u003Cplugin root>` is the installed Paved plugin directory, two directories above this SKILL.md. Always run the launcher from the repository being worked on, never from the plugin directory. Do not edit generated integration files or bypass Paved lifecycle and ownership checks.\n",{"name":5,"description":7},"main","1cd80f05aff924ea609012e864fa5c22c16c7d2d","plugins\u002Fpaved\u002Fskills\u002Ftask-review",0,"https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues","2026-11-14 20:09:28",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add andersonmrodrigues\u002Fpaved --skill task-review",{"tool":37,"command":38},"bunx","bunx skills add andersonmrodrigues\u002Fpaved --skill task-review",{"tool":40,"command":41},"pnpm","pnpm dlx skills add andersonmrodrigues\u002Fpaved --skill task-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Fplugins\u002Fpaved\u002Fskills\u002Ftask-review\u002FSKILL.md",true,[45],{"path":46,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":49,"sourceHtmlUrl":50},"examples\u002Ftask-review.md","REFERENCE","参考文档",2662,"https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Fplugins\u002Fpaved\u002Fskills\u002Ftask-review\u002Fexamples\u002Ftask-review.md",[52,59,65,71,77,83],{"skillNo":53,"name":54,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":19},"01M7DFBWJT4T1MPBHTWT19PBEK","sample-skill","Does a sample task. Use when a sample is needed.","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fvalid\u002Fsample-skill\u002FSKILL.md",[],[],{"skillNo":60,"name":61,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":19},"01M7DFBS6WTK30PBSW4ZS0NPWT","unexplained-contract","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Finvalid\u002Funexplained-contract\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":19},"01M7DFBPJGG170V9WTMFWY73R4","shell-block","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Finvalid\u002Fshell-block\u002FSKILL.md",[],[],{"skillNo":72,"name":73,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M7DFBMZYR20JPTXNE5A8EFG6","project-identifier","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Finvalid\u002Fproject-identifier\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M7DFBJ8J533DAKA3FTF54SX3","oversized","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Finvalid\u002Foversized\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M7DFBFAD0RYCRHTZ2JW4RX7E","no-activation","Does a sample task.","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Finvalid\u002Fno-activation\u002FSKILL.md",[],[]]