[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CY5X095CWCNFJWGBJQP6VC":3,"skill-same:01M6CY5X095CWCNFJWGBJQP6VC":69},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":13,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M6CY5X095CWCNFJWGBJQP6VC","document-review",null,"Review workflow artifacts such as brainstorms, plans, architecture docs, tickets, and compounded learnings with artifact-aware lenses, including headless workflow invocation","The-Rabak\u002Fcompound-engineering-plugin","The-Rabak","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F44833742?v=4","01M6CY211HB58Y8JNWWEV9FGN1","01M6CY2165MYWKS66VN01X82EB",1,"MIT","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fportable\u002Fcompound-engineering\u002Fskills\u002Fdocument-review\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35],"review","document","document review","docs","codex","workflow","architecture","artifacts","gpt","openrouter","kimi","learnings","artifact","2026-11-10 10:12:30",false,"---\nname: document-review\ndescription: >-\n  Review workflow artifacts such as brainstorms, plans, architecture docs, tickets, and compounded\n  learnings with artifact-aware lenses, including headless workflow invocation\nmodel: claude-sonnet-5\nplatforms:\n  codex:\n    model: gpt-5.5\n  copilot:\n    model: gpt-5.3-codex\n  opencode:\n    model: openrouter\u002Fmoonshotai\u002Fkimi-k2.6\n\n---\n\n# Document Review\n\nImprove workflow documents through structured, artifact-aware review.\n\nThis skill supports both:\n\n- **interactive refinement** -- the user wants a review pass and can answer questions\n- **headless refinement** -- another workflow invokes review non-interactively and needs a concise result\n\n## Step 1: Get and classify the artifact\n\nIf a document path is provided, read it first and infer the artifact type from path and content.\n\n**Dual-read by artifact extension.** Brainstorm, plan, and architecture artifacts may each be legacy `.md` or the `.html`-artifact output (brainstorm since T03, plan since the html-artifacts pilot, architecture since T04). Detect which reader applies from the artifact's own file extension before reading its content: **`.md`** -- parse frontmatter and sections as today (legacy path, unchanged). **`.html`** -- load `commands\u002Fworkflows\u002Freferences\u002Fhtml-artifacts\u002Fisland-extraction-helper.md`, quote its first non-empty line, and read the artifact's `#artifact-data` JSON island for that kind's fixed-core facts instead of frontmatter\u002Fsections. If extraction fails for any reason, stop immediately and report the artifact path and the exact failure per the helper's fail-loud branch -- do not proceed on partial data, scrape the rendered HTML, or fall back to a `.md` mirror (none exists for an `.html` artifact). Ticket-index, ticket, and solution artifacts stay `.md`-only.\n\nIf no document is specified, ask which artifact to review or look for the most recent relevant file in:\n\n- `docs\u002Fbrainstorms\u002F` (`.md` or `.html`)\n- `docs\u002Fplans\u002F` (`.md` or `.html`)\n- `docs\u002Farchitecture\u002F` (`.md` or `.html`)\n- `docs\u002Ftickets\u002F`\n- `docs\u002Fsolutions\u002F`\n\nClassify the artifact as one of:\n\n- **brainstorm**\n- **plan**\n- **architecture**\n- **ticket-index**\n- **ticket**\n- **solution**\n- **generic-doc** (only if it clearly does not fit the above)\n\nIf the caller already specified the review mode, trust it unless the file clearly contradicts it.\n\n## Step 2: Load the minimum linked context\n\nDo not review an artifact in isolation when its contract depends on linked docs.\n\nLoad only the minimum linked artifacts needed to judge handoff integrity:\n\n- **brainstorm** -> constitution when present\n- **plan** -> `brainstorm_ref`, constitution, and `architecture_ref` if already recorded\n- **architecture** -> parent plan and relevant brainstorm context\n- **ticket-index** -> parent plan + architecture artifact\n- **ticket** -> parent ticket index + plan + architecture artifact\n- **solution** -> nearby related solution docs or referenced execution\u002Fsession artifacts when present\n\nIf a required linked artifact is missing, note that as a review finding instead of inventing the missing context.\n\n## Step 3: Choose the review lenses\n\nAlways review for these baseline lenses:\n\n- **Clarity** -- vague language, hidden assumptions, or ambiguous ownership\n- **Decision honesty** -- real decisions made, real open questions named\n- **Specificity** -- enough detail for the next workflow step, not bloated filler\n- **YAGNI \u002F simplicity** -- no speculative work disguised as readiness\n\nThen apply artifact-specific lenses.\n\n### Brainstorm review\n\n- **WHY fidelity** -- problem narrative, user story, and success criteria align\n- **Stakeholder clarity** -- who is affected and why is actually clear\n- **Ambiguity pressure-test** -- important unknowns are surfaced before planning\n\n### Plan review\n\n- **Handoff integrity** -- brainstorm, constitution, source docs, and architecture refs align\n- **Execution-shape honesty** -- slices\u002Ftracks\u002Fbatches match the real work\n- **TDD & evidence contract** -- test expectations and exceptions are explicit\n- **Scope discipline** -- plan stays implementable without fake AI-shaped batching\n\n### Architecture review\n\n- **Feature-home honesty** -- ownership is explicit and believable\n- **Shared\u002Fglobal boundary honesty** -- truly shared concerns are separated from feature-local work\n- **Deletion test \u002F seam quality** -- abstractions are justified, not decorative\n- **Downstream usefulness** -- `\u002Fdeepen-plan`, `\u002Fworkflows:work`, and `\u002Fworkflows:review` can actually use this artifact\n\n### Ticket-index review\n\n- **Dependency ordering** -- batch order and blockers are believable\n- **Parallel safety** -- file overlap and shared mutable state are accounted for\n- **Resume quality** -- index acts as an execution cursor, not a directory listing\n- **WHY tracing** -- ticket set still points back to the parent intent\n\n### Ticket review\n\n- **Ticket-local sufficiency** -- enough context to execute without copying the whole plan\n- **Scope fence honesty** -- non-goals and boundaries are explicit\n- **Evidence commands** -- proof paths are concrete\n- **Parent-link integrity** -- ticket points to the right index\u002Fplan\u002Farchitecture artifacts\n\n### Solution review\n\n- **Institutional reuse** -- this teaches something future work can actually reuse\n- **Root cause and prevention quality** -- not just \"what we changed,\" but why\n- **Searchability** -- title\u002Fcategory\u002Fstructure make future lookup realistic\n- **Noise control** -- keep the learning crisp instead of turning it into a diary\n\n## Step 4: Identify findings\n\nKeep findings short and actionable. Use these buckets:\n\n1. **Blocking gaps** -- artifact is not ready for the next step\n2. **Important improvements** -- not blocking, but meaningfully improves handoff quality\n3. **Minor fixes** -- clarity, wording, formatting, or duplication cleanup\n\nAlso identify one **critical improvement** if a single change would most improve the artifact.\n\n## Step 5: Make changes\n\n1. **Auto-fix minor issues** inline\n2. **Make safe structural edits** when the intended meaning is already clear\n3. **Ask approval before changing meaning** when running interactively\n4. **In headless mode, do not invent missing decisions** -- leave concise findings instead\n\nKeep edits in the same file. Do not create parallel review docs, checklists, or metadata-only artifacts.\n\n### Simplification Guidance\n\nSimplification is purposeful removal of unnecessary complexity, not shortening for its own sake.\n\n**Simplify when:**\n- Content serves hypothetical future needs, not current ones\n- Sections repeat information already covered elsewhere\n- Detail exceeds what's needed to take the next step\n- Abstractions or structure add overhead without clarity\n\n**Don't simplify:**\n- Constraints or edge cases that affect implementation\n- Rationale that explains why alternatives were rejected\n- Open questions that need resolution\n\n## Step 6: Return the right output shape\n\n### Interactive mode\n\nAfter changes are complete, ask:\n\n1. **Refine again** - Another review pass\n2. **Review complete** - Document is ready\n\n### Iteration Guidance\n\nAfter 2 refinement passes, recommend completion—diminishing returns are likely. But if the user wants to continue, allow it.\n\nReturn control to the caller (workflow or user) after selection.\n\n### Headless mode\n\nIf this skill was invoked by another workflow for a non-interactive pass, do **not** ask follow-up questions unless a blocking ambiguity truly prevents review.\n\nReturn a concise summary:\n\n```markdown\n## Document Review\n\n- **Artifact type:** ...\n- **Critical improvement:** ...\n- **Edits made:** ...\n- **Remaining blockers or open questions:** ...\n```\n\n## What NOT to Do\n\n- Do not rewrite the entire artifact unless the existing structure is unusable\n- Do not add new requirements the user or parent artifacts did not establish\n- Do not over-engineer or add shadow process\n- Do not create separate review files or metadata-only artifacts\n","# Document Review\n\nImprove workflow documents through structured, artifact-aware review.\n\nThis skill supports both:\n\n- **interactive refinement** -- the user wants a review pass and can answer questions\n- **headless refinement** -- another workflow invokes review non-interactively and needs a concise result\n\n## Step 1: Get and classify the artifact\n\nIf a document path is provided, read it first and infer the artifact type from path and content.\n\n**Dual-read by artifact extension.** Brainstorm, plan, and architecture artifacts may each be legacy `.md` or the `.html`-artifact output (brainstorm since T03, plan since the html-artifacts pilot, architecture since T04). Detect which reader applies from the artifact's own file extension before reading its content: **`.md`** -- parse frontmatter and sections as today (legacy path, unchanged). **`.html`** -- load `commands\u002Fworkflows\u002Freferences\u002Fhtml-artifacts\u002Fisland-extraction-helper.md`, quote its first non-empty line, and read the artifact's `#artifact-data` JSON island for that kind's fixed-core facts instead of frontmatter\u002Fsections. If extraction fails for any reason, stop immediately and report the artifact path and the exact failure per the helper's fail-loud branch -- do not proceed on partial data, scrape the rendered HTML, or fall back to a `.md` mirror (none exists for an `.html` artifact). Ticket-index, ticket, and solution artifacts stay `.md`-only.\n\nIf no document is specified, ask which artifact to review or look for the most recent relevant file in:\n\n- `docs\u002Fbrainstorms\u002F` (`.md` or `.html`)\n- `docs\u002Fplans\u002F` (`.md` or `.html`)\n- `docs\u002Farchitecture\u002F` (`.md` or `.html`)\n- `docs\u002Ftickets\u002F`\n- `docs\u002Fsolutions\u002F`\n\nClassify the artifact as one of:\n\n- **brainstorm**\n- **plan**\n- **architecture**\n- **ticket-index**\n- **ticket**\n- **solution**\n- **generic-doc** (only if it clearly does not fit the above)\n\nIf the caller already specified the review mode, trust it unless the file clearly contradicts it.\n\n## Step 2: Load the minimum linked context\n\nDo not review an artifact in isolation when its contract depends on linked docs.\n\nLoad only the minimum linked artifacts needed to judge handoff integrity:\n\n- **brainstorm** -> constitution when present\n- **plan** -> `brainstorm_ref`, constitution, and `architecture_ref` if already recorded\n- **architecture** -> parent plan and relevant brainstorm context\n- **ticket-index** -> parent plan + architecture artifact\n- **ticket** -> parent ticket index + plan + architecture artifact\n- **solution** -> nearby related solution docs or referenced execution\u002Fsession artifacts when present\n\nIf a required linked artifact is missing, note that as a review finding instead of inventing the missing context.\n\n## Step 3: Choose the review lenses\n\nAlways review for these baseline lenses:\n\n- **Clarity** -- vague language, hidden assumptions, or ambiguous ownership\n- **Decision honesty** -- real decisions made, real open questions named\n- **Specificity** -- enough detail for the next workflow step, not bloated filler\n- **YAGNI \u002F simplicity** -- no speculative work disguised as readiness\n\nThen apply artifact-specific lenses.\n\n### Brainstorm review\n\n- **WHY fidelity** -- problem narrative, user story, and success criteria align\n- **Stakeholder clarity** -- who is affected and why is actually clear\n- **Ambiguity pressure-test** -- important unknowns are surfaced before planning\n\n### Plan review\n\n- **Handoff integrity** -- brainstorm, constitution, source docs, and architecture refs align\n- **Execution-shape honesty** -- slices\u002Ftracks\u002Fbatches match the real work\n- **TDD & evidence contract** -- test expectations and exceptions are explicit\n- **Scope discipline** -- plan stays implementable without fake AI-shaped batching\n\n### Architecture review\n\n- **Feature-home honesty** -- ownership is explicit and believable\n- **Shared\u002Fglobal boundary honesty** -- truly shared concerns are separated from feature-local work\n- **Deletion test \u002F seam quality** -- abstractions are justified, not decorative\n- **Downstream usefulness** -- `\u002Fdeepen-plan`, `\u002Fworkflows:work`, and `\u002Fworkflows:review` can actually use this artifact\n\n### Ticket-index review\n\n- **Dependency ordering** -- batch order and blockers are believable\n- **Parallel safety** -- file overlap and shared mutable state are accounted for\n- **Resume quality** -- index acts as an execution cursor, not a directory listing\n- **WHY tracing** -- ticket set still points back to the parent intent\n\n### Ticket review\n\n- **Ticket-local sufficiency** -- enough context to execute without copying the whole plan\n- **Scope fence honesty** -- non-goals and boundaries are explicit\n- **Evidence commands** -- proof paths are concrete\n- **Parent-link integrity** -- ticket points to the right index\u002Fplan\u002Farchitecture artifacts\n\n### Solution review\n\n- **Institutional reuse** -- this teaches something future work can actually reuse\n- **Root cause and prevention quality** -- not just \"what we changed,\" but why\n- **Searchability** -- title\u002Fcategory\u002Fstructure make future lookup realistic\n- **Noise control** -- keep the learning crisp instead of turning it into a diary\n\n## Step 4: Identify findings\n\nKeep findings short and actionable. Use these buckets:\n\n1. **Blocking gaps** -- artifact is not ready for the next step\n2. **Important improvements** -- not blocking, but meaningfully improves handoff quality\n3. **Minor fixes** -- clarity, wording, formatting, or duplication cleanup\n\nAlso identify one **critical improvement** if a single change would most improve the artifact.\n\n## Step 5: Make changes\n\n1. **Auto-fix minor issues** inline\n2. **Make safe structural edits** when the intended meaning is already clear\n3. **Ask approval before changing meaning** when running interactively\n4. **In headless mode, do not invent missing decisions** -- leave concise findings instead\n\nKeep edits in the same file. Do not create parallel review docs, checklists, or metadata-only artifacts.\n\n### Simplification Guidance\n\nSimplification is purposeful removal of unnecessary complexity, not shortening for its own sake.\n\n**Simplify when:**\n- Content serves hypothetical future needs, not current ones\n- Sections repeat information already covered elsewhere\n- Detail exceeds what's needed to take the next step\n- Abstractions or structure add overhead without clarity\n\n**Don't simplify:**\n- Constraints or edge cases that affect implementation\n- Rationale that explains why alternatives were rejected\n- Open questions that need resolution\n\n## Step 6: Return the right output shape\n\n### Interactive mode\n\nAfter changes are complete, ask:\n\n1. **Refine again** - Another review pass\n2. **Review complete** - Document is ready\n\n### Iteration Guidance\n\nAfter 2 refinement passes, recommend completion—diminishing returns are likely. But if the user wants to continue, allow it.\n\nReturn control to the caller (workflow or user) after selection.\n\n### Headless mode\n\nIf this skill was invoked by another workflow for a non-interactive pass, do **not** ask follow-up questions unless a blocking ambiguity truly prevents review.\n\nReturn a concise summary:\n\n```markdown\n## Document Review\n\n- **Artifact type:** ...\n- **Critical improvement:** ...\n- **Edits made:** ...\n- **Remaining blockers or open questions:** ...\n```\n\n## What NOT to Do\n\n- Do not rewrite the entire artifact unless the existing structure is unusable\n- Do not add new requirements the user or parent artifacts did not establish\n- Do not over-engineer or add shadow process\n- Do not create separate review files or metadata-only artifacts\n",{"name":5,"model":41,"platforms":42,"description":7},"claude-sonnet-5",{"codex":43,"copilot":45,"opencode":47},{"model":44},"gpt-5.5",{"model":46},"gpt-5.3-codex",{"model":48},"openrouter\u002Fmoonshotai\u002Fkimi-k2.6","main","4c70ff7e10e692dfcc6d7877a6e57dd08df94d9b","portable\u002Fcompound-engineering\u002Fskills\u002Fdocument-review","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin","https:\u002F\u002Fgithub.com\u002FThe-Rabak","2026-07-28 15:25:35",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add The-Rabak\u002Fcompound-engineering-plugin --skill document-review",{"tool":61,"command":62},"bunx","bunx skills add The-Rabak\u002Fcompound-engineering-plugin --skill document-review",{"tool":64,"command":65},"pnpm","pnpm dlx skills add The-Rabak\u002Fcompound-engineering-plugin --skill document-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fportable\u002Fcompound-engineering\u002Fskills\u002Fdocument-review\u002FSKILL.md",true,[],[70,84,93,103,111,118],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":79,"publishedAt":36},"01M6CY858Z5RCC30TKAVBDJ6SZ","skill-one","Shared reusable skill.","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-portable-plugin\u002Fskills\u002Fskill-one\u002FSKILL.md",[76],{"categoryNo":77,"categoryName":78,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[80,81,82,83,31],"skill one","shared","reusable","haiku",{"skillNo":85,"name":72,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":90,"publishedAt":36},"01M6CY843KQG3FQF6259420CCD","Sample skill","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fskill-one\u002FSKILL.md",[89],{"categoryNo":77,"categoryName":78,"taxonomyType":20,"taxonomyTypeDesc":21},[80,91,92],"sample","sample skill",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":100,"publishedAt":36},"01M6CY82607GGPWR5H25SY74H2","disabled-skill","A skill with model invocation disabled","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fdisabled-skill\u002FSKILL.md",[99],{"categoryNo":77,"categoryName":78,"taxonomyType":20,"taxonomyTypeDesc":21},[101,102],"disabled skill","model",{"skillNo":104,"name":105,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":36},"01M6CY80RWMK81T97A2Q5KAFAF","default-skill","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fskills\u002Fdefault-skill\u002FSKILL.md",[],[109,110],"default skill","default",{"skillNo":112,"name":113,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":36},"01M6CY7ZK2PMV75ES90W6YYD4S","custom-skill","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fcustom-skills\u002Fcustom-skill\u002FSKILL.md",[],[117],"custom skill",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":125,"publishedAt":36},"01M6CY7V6C7HFCNJEVNFT1X00T","workflow-next-step","This skill should be used at the end of core compound-engineering workflows to inspect completed artifacts, show the workflow progress checklist, and give the exact next-session command with inputs.","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fportable\u002Fcompound-engineering\u002Fskills\u002Fworkflow-next-step\u002FSKILL.md",[124],{"categoryNo":77,"categoryName":78,"taxonomyType":20,"taxonomyTypeDesc":21},[28,126,127,128,129,130,131,132,133,30,134,135],"next","workflow next step","compound","show","checklist","session","command","engineering","core","workflows"]