[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6J7300TDEFYBVM5JAASH74D":3,"skill-same:01M6J7300TDEFYBVM5JAASH74D":59},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":42,"ownerDescription":43,"updatedAt":44,"install":45,"resources":58},"01M6J7300TDEFYBVM5JAASH74D","mach6-implement",null,"Implement a plan from a PR, or fix review findings \u002F CI failures. Usage: mach6-implement 42 [finding-numbers] or mach6-implement 42 ci","aebrer\u002Fdreb","aebrer","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F16313135?v=4","01M6J72TA43F9MBRZJE5W6B8DR","Drew Brereton","01M6J72TEDDHRA5AT4X9TR64AD",34,"MIT","https:\u002F\u002Fgithub.com\u002Faebrer\u002Fdreb\u002Fblob\u002Fmaster\u002Fpackages\u002Fcoding-agent\u002Fskills\u002Fmach6-implement\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29],"implement","mach6 implement","review","pr","ci","plan","fix","fix review","review findings","usage","number","2026-11-10 10:12:30",false,"---\nname: mach6-implement\ndescription: \"Implement a plan from a PR, or fix review findings \u002F CI failures. Usage: mach6-implement 42 [finding-numbers] or mach6-implement 42 ci\"\nargument-hint: \"\u003Cpr-number> [finding-numbers | ci]\"\n---\n\n# mach6-implement — Implement Plans, Fix Findings, or Fix CI\n\n**User input:** $ARGUMENTS\n\nThis skill has two modes:\n- **Implement mode** (just a PR number): reads the plan comment and implements it\n- **Fix mode** (with finding numbers or `ci`): fixes specific review findings or CI failures\n\n## Global Rules\n\n1. **GitHub as shared memory** — Plans, reviews, and assessments are on the PR as comments with HTML markers.\n2. **No `#N` in comment bodies** — Use \"finding 3\", \"item 3\" etc. instead.\n3. **Safe git** — Never use `git add -A` or `git add .`. Stage files by name. Never stage secrets.\n4. **Task tracking** — Use the `tasks_update` tool to show progress.\n5. **Non-interactive `gh`** — Set `GH_PAGER=cat` and `GH_EDITOR=cat` before all `gh` commands to prevent interactive prompts from hanging the agent. Use `--body-file` instead of inline `--body` for all `gh pr comment`, `gh pr create`, and `gh issue create` calls to avoid shell interpretation of backticks. Write each body to a **unique per-invocation temp file** via `mktemp` (e.g. `GH_BODY=\"$(mktemp \u002Ftmp\u002Fgh-comment.$$.XXXXXXXX)\"`) — never a fixed path like `\u002Ftmp\u002Fgh-comment.md`, which concurrent mach6 sessions on the same machine would clobber, cross-posting one session's body to another's PR\u002Fissue.\n\n## Parent ownership and the formal-review checkpoint\n\nThese rules apply in both implement and fix modes, even if you never load the `mach6-push` or `mach6-review` skills:\n\n- **The parent model owns implementation reasoning.** You decide the design, decomposition, exact changes, constraints, and verification strategy. Do not use a subagent as a substitute for thinking through the implementation.\n- **Direct implementation is generally acceptable.** The parent may implement any deliverable or fix directly; this is not limited to trivial work.\n- **Delegate execution, not unresolved design.** `feature-dev` is optional and is most useful for high-volume, repetitive, mechanically scoped grunt work after you have settled the rules—for example, applying a content-dependent transformation across dozens of files. Ordinary reading and writing alone is not a reason to delegate.\n- **Every delegated task must be clear, detailed, and specific.** Give the agent the intended changes, exact relevant files, existing patterns to follow, decision rules, constraints, required tests, and expected verification. Resolve ambiguity yourself before delegation; never hand off a vague deliverable and ask the agent to design it.\n- **Focused checks remain allowed.** You may launch a focused, one-off reviewer or checker subagent for a narrow correctness question or second opinion. Do not turn that into the formal mach6 multi-agent review\u002Fassessment workflow or an autonomous review-fix-review loop.\n- **Save work before formal review.** A successful implementation is not yet durable shared work. Committing, pushing, and posting a GitHub progress comment creates the accountability and recovery boundary, reducing the risk that unsupervised review cycles repeatedly rewrite or destroy work before it is saved.\n- **Only the user starts formal `mach6-review`.** After implementation and direct verification, do not invoke `mach6-review` and do not begin a review cycle. Use `suggest_next` to offer `\u002Fskill:mach6-push`, then stop. After the push is complete, the user decides whether to explicitly invoke review.\n\n## Step 1: Parse input\n\nExtract:\n- **PR number** (required)\n- **Finding numbers** to fix (optional — e.g., `1,2,3`)\n- **`ci`** flag (optional — fix CI failures instead of review findings)\n\nIf only a PR number is given → **implement mode**.\nIf finding numbers or `ci` → **fix mode**.\n\n## Step 2: Checkout\n\n```bash\ngh pr checkout \u003Cpr-number>\ngit pull\n```\n\n---\n\n## Implement Mode (PR number only)\n\n### Step 3i: Read the plan and full PR context\n\nRead ALL PR comments and the PR body to get complete context:\n```bash\ngh pr view \u003Cpr-number> --json title,body,comments\n```\n\nFind the plan comment (contains `\u003C!-- mach6-plan -->` marker) from the comments. If no plan comment exists, tell the user and suggest running `\u002Fskill:mach6-plan` first.\n\nAlso read any progress updates, prior review findings, assessments, and discussion — all of this context informs implementation.\n\n### Step 4i: Set up task tracking\n\nCreate tasks based on the plan's deliverables\u002Ffeatures. Example:\n```\ntasks_update([\n  { id: \"read\", title: \"Read plan and codebase\", status: \"in_progress\" },\n  { id: \"feature-1\", title: \"Implement feature 1\", status: \"pending\" },\n  { id: \"feature-2\", title: \"Implement feature 2\", status: \"pending\" },\n  { id: \"test\", title: \"Add\u002Fupdate tests\", status: \"pending\" },\n  { id: \"verify\", title: \"Build and verify\", status: \"pending\" }\n])\n```\n\n### Step 5i: Read the codebase\n\nRead all files mentioned in the plan. Understand the existing code before making changes.\n\n### Step 6i: Implement\n\nFor each deliverable, first decide the implementation yourself: map it to the approved plan, inspect the relevant code, settle the design and decision rules, identify exact files and patterns, and define the required tests and verification.\n\nImplement directly unless delegation has a concrete context-preservation benefit. Direct parent implementation is generally acceptable regardless of plan size. Use the pre-existing `feature-dev` agent only for execution that is sufficiently high-volume, repetitive, and mechanically specified to justify delegation; do not delegate merely because a task involves reading and writing code.\n\nWhen delegating, provide a complete execution plan containing:\n- The authorized deliverable and why it is in scope\n- Exact files or a precisely bounded file set\n- Specific changes and content-dependent decision rules\n- Existing code patterns and constraints to preserve\n- Required tests, linting, and validation commands\n- Expected observable result and completion criteria\n- Relevant plan and PR discussion context\n\nA `feature-dev` agent should be able to execute without inventing design decisions. If direction is ambiguous, the parent must resolve it before delegation. Do not override the agent's model unless there is a specific reason.\n\n**Test coverage is part of the deliverable, not an afterthought.** Implement all planned tests with the behavior they cover. If the target package lacks test infrastructure, add it.\n\n**Parallelism:** Parallelize only independent, mechanically specified tasks that do not overlap files or depend on unresolved work. Otherwise implement directly or sequence the work.\n\nUpdate task tracking as each deliverable completes.\n\n### Step 7i: Verify\n\nAfter all `feature-dev` agents complete:\n- Run the project's test suite\n- Run any linting\u002Fformatting tools\n- Build the project if applicable\n- Verify each deliverable from the plan is addressed\n- If any agent reported issues or partial completion, address the gaps\n\nStop at the accountability checkpoint. Do **not** invoke `mach6-review` or begin a formal review cycle. Explain that the implementation must be committed, pushed, and recorded before the user decides whether to review. Use `suggest_next` to offer `\u002Fskill:mach6-push`, then end the turn.\n\n---\n\n## Fix Mode (finding numbers or `ci`)\n\n### Step 3f: Set up task tracking\n\n```\ntasks_update([\n  { id: \"gather\", title: \"Gather findings to fix\", status: \"in_progress\" },\n  { id: \"fix\", title: \"Implement fixes\", status: \"pending\" },\n  { id: \"verify\", title: \"Verify fixes\", status: \"pending\" }\n])\n```\n\n### Step 4f: Gather context\n\n#### If `ci` was specified:\n\nUse `watch_github_ci` with `pr: \"\u003Cpr-number>\"` so the tool blocks until the pull request's checks pass or fail. Do not use `wait`, sleep, or repeated polling commands for CI.\n\nIf checks fail, use the returned check output to identify the failed run, then inspect it:\n\n```bash\ngh run view \u003Crun-id> --log-failed\n```\n\nRead the failed CI logs and identify issues. Extract test failures, stack traces, error messages. If all checks pass, report this and stop.\n\n#### If finding numbers were specified:\n\nRead ALL PR comments to get full context:\n```bash\ngh pr view \u003Cpr-number> --json title,body,comments\n```\n\nFind the review (`\u003C!-- mach6-review -->`) and assessment (`\u003C!-- mach6-assessment -->`) comments, then extract the specific findings to fix. Prior progress comments and discussion may also provide useful context.\n\n#### If no finding numbers and not `ci`:\n\nRead ALL PR comments, find review\u002Fassessment comments, present the merge blockers from the latest assessment comment, and ask which to fix.\n\n### Step 5f: Batch sizing\n\n- **Simple fixes** (typos, naming, imports): ~10 per batch\n- **Moderate fixes** (logic changes, refactors): ~6 per batch\n- **Complex fixes** (architecture, new features): ~3 per batch\n\nIf more than batch size, fix first batch and tell user to re-run.\n\n### Step 6f: Implement fixes\n\nFor each authorized finding, the parent must verify the assessment against the current code, decide the exact fix, identify affected files and patterns, and define the regression tests and validation before editing or delegating.\n\nImplement fixes directly by default. Use the pre-existing `feature-dev` agent only when a fix has high-volume, repetitive, mechanically settled execution that benefits from context isolation. Direct parent implementation is acceptable for simple and complex fixes alike.\n\nWhen delegating, provide:\n- The finding and its factual and scope reasoning\n- Exact files and code locations, or a precisely bounded file set\n- The complete fix design and content-dependent decision rules\n- Existing patterns and constraints to preserve\n- Required regression tests and validation commands\n- Expected result and completion criteria\n\nDo not ask `feature-dev` to determine the design. Resolve ambiguity before delegation, and do not override its model unless there is a specific reason.\n\n**Parallelism:** Parallelize only independent, mechanically specified fixes that do not overlap files. Otherwise implement directly or sequence them.\n\nDefer only review-surfaced items that are factually valid but outside the authoritative PR scope. User-approved requirements are in scope. Update task tracking per finding.\n\n### Step 7f: Verify\n\nAfter all `feature-dev` agents complete:\n- Run tests and linting\n- Verify each fix addresses its finding\n- If any agent reported issues, address the gaps\n\nStop at the accountability checkpoint. Do **not** invoke `mach6-review` or begin a formal re-review cycle. Explain that the fixes must be committed, pushed, and recorded before the user decides whether to re-review. Use `suggest_next` to offer `\u002Fskill:mach6-push`, then end the turn.\n","# mach6-implement — Implement Plans, Fix Findings, or Fix CI\n\n**User input:** $ARGUMENTS\n\nThis skill has two modes:\n- **Implement mode** (just a PR number): reads the plan comment and implements it\n- **Fix mode** (with finding numbers or `ci`): fixes specific review findings or CI failures\n\n## Global Rules\n\n1. **GitHub as shared memory** — Plans, reviews, and assessments are on the PR as comments with HTML markers.\n2. **No `#N` in comment bodies** — Use \"finding 3\", \"item 3\" etc. instead.\n3. **Safe git** — Never use `git add -A` or `git add .`. Stage files by name. Never stage secrets.\n4. **Task tracking** — Use the `tasks_update` tool to show progress.\n5. **Non-interactive `gh`** — Set `GH_PAGER=cat` and `GH_EDITOR=cat` before all `gh` commands to prevent interactive prompts from hanging the agent. Use `--body-file` instead of inline `--body` for all `gh pr comment`, `gh pr create`, and `gh issue create` calls to avoid shell interpretation of backticks. Write each body to a **unique per-invocation temp file** via `mktemp` (e.g. `GH_BODY=\"$(mktemp \u002Ftmp\u002Fgh-comment.$$.XXXXXXXX)\"`) — never a fixed path like `\u002Ftmp\u002Fgh-comment.md`, which concurrent mach6 sessions on the same machine would clobber, cross-posting one session's body to another's PR\u002Fissue.\n\n## Parent ownership and the formal-review checkpoint\n\nThese rules apply in both implement and fix modes, even if you never load the `mach6-push` or `mach6-review` skills:\n\n- **The parent model owns implementation reasoning.** You decide the design, decomposition, exact changes, constraints, and verification strategy. Do not use a subagent as a substitute for thinking through the implementation.\n- **Direct implementation is generally acceptable.** The parent may implement any deliverable or fix directly; this is not limited to trivial work.\n- **Delegate execution, not unresolved design.** `feature-dev` is optional and is most useful for high-volume, repetitive, mechanically scoped grunt work after you have settled the rules—for example, applying a content-dependent transformation across dozens of files. Ordinary reading and writing alone is not a reason to delegate.\n- **Every delegated task must be clear, detailed, and specific.** Give the agent the intended changes, exact relevant files, existing patterns to follow, decision rules, constraints, required tests, and expected verification. Resolve ambiguity yourself before delegation; never hand off a vague deliverable and ask the agent to design it.\n- **Focused checks remain allowed.** You may launch a focused, one-off reviewer or checker subagent for a narrow correctness question or second opinion. Do not turn that into the formal mach6 multi-agent review\u002Fassessment workflow or an autonomous review-fix-review loop.\n- **Save work before formal review.** A successful implementation is not yet durable shared work. Committing, pushing, and posting a GitHub progress comment creates the accountability and recovery boundary, reducing the risk that unsupervised review cycles repeatedly rewrite or destroy work before it is saved.\n- **Only the user starts formal `mach6-review`.** After implementation and direct verification, do not invoke `mach6-review` and do not begin a review cycle. Use `suggest_next` to offer `\u002Fskill:mach6-push`, then stop. After the push is complete, the user decides whether to explicitly invoke review.\n\n## Step 1: Parse input\n\nExtract:\n- **PR number** (required)\n- **Finding numbers** to fix (optional — e.g., `1,2,3`)\n- **`ci`** flag (optional — fix CI failures instead of review findings)\n\nIf only a PR number is given → **implement mode**.\nIf finding numbers or `ci` → **fix mode**.\n\n## Step 2: Checkout\n\n```bash\ngh pr checkout \u003Cpr-number>\ngit pull\n```\n\n---\n\n## Implement Mode (PR number only)\n\n### Step 3i: Read the plan and full PR context\n\nRead ALL PR comments and the PR body to get complete context:\n```bash\ngh pr view \u003Cpr-number> --json title,body,comments\n```\n\nFind the plan comment (contains `\u003C!-- mach6-plan -->` marker) from the comments. If no plan comment exists, tell the user and suggest running `\u002Fskill:mach6-plan` first.\n\nAlso read any progress updates, prior review findings, assessments, and discussion — all of this context informs implementation.\n\n### Step 4i: Set up task tracking\n\nCreate tasks based on the plan's deliverables\u002Ffeatures. Example:\n```\ntasks_update([\n  { id: \"read\", title: \"Read plan and codebase\", status: \"in_progress\" },\n  { id: \"feature-1\", title: \"Implement feature 1\", status: \"pending\" },\n  { id: \"feature-2\", title: \"Implement feature 2\", status: \"pending\" },\n  { id: \"test\", title: \"Add\u002Fupdate tests\", status: \"pending\" },\n  { id: \"verify\", title: \"Build and verify\", status: \"pending\" }\n])\n```\n\n### Step 5i: Read the codebase\n\nRead all files mentioned in the plan. Understand the existing code before making changes.\n\n### Step 6i: Implement\n\nFor each deliverable, first decide the implementation yourself: map it to the approved plan, inspect the relevant code, settle the design and decision rules, identify exact files and patterns, and define the required tests and verification.\n\nImplement directly unless delegation has a concrete context-preservation benefit. Direct parent implementation is generally acceptable regardless of plan size. Use the pre-existing `feature-dev` agent only for execution that is sufficiently high-volume, repetitive, and mechanically specified to justify delegation; do not delegate merely because a task involves reading and writing code.\n\nWhen delegating, provide a complete execution plan containing:\n- The authorized deliverable and why it is in scope\n- Exact files or a precisely bounded file set\n- Specific changes and content-dependent decision rules\n- Existing code patterns and constraints to preserve\n- Required tests, linting, and validation commands\n- Expected observable result and completion criteria\n- Relevant plan and PR discussion context\n\nA `feature-dev` agent should be able to execute without inventing design decisions. If direction is ambiguous, the parent must resolve it before delegation. Do not override the agent's model unless there is a specific reason.\n\n**Test coverage is part of the deliverable, not an afterthought.** Implement all planned tests with the behavior they cover. If the target package lacks test infrastructure, add it.\n\n**Parallelism:** Parallelize only independent, mechanically specified tasks that do not overlap files or depend on unresolved work. Otherwise implement directly or sequence the work.\n\nUpdate task tracking as each deliverable completes.\n\n### Step 7i: Verify\n\nAfter all `feature-dev` agents complete:\n- Run the project's test suite\n- Run any linting\u002Fformatting tools\n- Build the project if applicable\n- Verify each deliverable from the plan is addressed\n- If any agent reported issues or partial completion, address the gaps\n\nStop at the accountability checkpoint. Do **not** invoke `mach6-review` or begin a formal review cycle. Explain that the implementation must be committed, pushed, and recorded before the user decides whether to review. Use `suggest_next` to offer `\u002Fskill:mach6-push`, then end the turn.\n\n---\n\n## Fix Mode (finding numbers or `ci`)\n\n### Step 3f: Set up task tracking\n\n```\ntasks_update([\n  { id: \"gather\", title: \"Gather findings to fix\", status: \"in_progress\" },\n  { id: \"fix\", title: \"Implement fixes\", status: \"pending\" },\n  { id: \"verify\", title: \"Verify fixes\", status: \"pending\" }\n])\n```\n\n### Step 4f: Gather context\n\n#### If `ci` was specified:\n\nUse `watch_github_ci` with `pr: \"\u003Cpr-number>\"` so the tool blocks until the pull request's checks pass or fail. Do not use `wait`, sleep, or repeated polling commands for CI.\n\nIf checks fail, use the returned check output to identify the failed run, then inspect it:\n\n```bash\ngh run view \u003Crun-id> --log-failed\n```\n\nRead the failed CI logs and identify issues. Extract test failures, stack traces, error messages. If all checks pass, report this and stop.\n\n#### If finding numbers were specified:\n\nRead ALL PR comments to get full context:\n```bash\ngh pr view \u003Cpr-number> --json title,body,comments\n```\n\nFind the review (`\u003C!-- mach6-review -->`) and assessment (`\u003C!-- mach6-assessment -->`) comments, then extract the specific findings to fix. Prior progress comments and discussion may also provide useful context.\n\n#### If no finding numbers and not `ci`:\n\nRead ALL PR comments, find review\u002Fassessment comments, present the merge blockers from the latest assessment comment, and ask which to fix.\n\n### Step 5f: Batch sizing\n\n- **Simple fixes** (typos, naming, imports): ~10 per batch\n- **Moderate fixes** (logic changes, refactors): ~6 per batch\n- **Complex fixes** (architecture, new features): ~3 per batch\n\nIf more than batch size, fix first batch and tell user to re-run.\n\n### Step 6f: Implement fixes\n\nFor each authorized finding, the parent must verify the assessment against the current code, decide the exact fix, identify affected files and patterns, and define the regression tests and validation before editing or delegating.\n\nImplement fixes directly by default. Use the pre-existing `feature-dev` agent only when a fix has high-volume, repetitive, mechanically settled execution that benefits from context isolation. Direct parent implementation is acceptable for simple and complex fixes alike.\n\nWhen delegating, provide:\n- The finding and its factual and scope reasoning\n- Exact files and code locations, or a precisely bounded file set\n- The complete fix design and content-dependent decision rules\n- Existing patterns and constraints to preserve\n- Required regression tests and validation commands\n- Expected result and completion criteria\n\nDo not ask `feature-dev` to determine the design. Resolve ambiguity before delegation, and do not override its model unless there is a specific reason.\n\n**Parallelism:** Parallelize only independent, mechanically specified fixes that do not overlap files. Otherwise implement directly or sequence them.\n\nDefer only review-surfaced items that are factually valid but outside the authoritative PR scope. User-approved requirements are in scope. Update task tracking per finding.\n\n### Step 7f: Verify\n\nAfter all `feature-dev` agents complete:\n- Run tests and linting\n- Verify each fix addresses its finding\n- If any agent reported issues, address the gaps\n\nStop at the accountability checkpoint. Do **not** invoke `mach6-review` or begin a formal re-review cycle. Explain that the fixes must be committed, pushed, and recorded before the user decides whether to re-review. Use `suggest_next` to offer `\u002Fskill:mach6-push`, then end the turn.\n",{"name":5,"description":7,"argument-hint":35},"\u003Cpr-number> [finding-numbers | ci]","master","c9f9063dab2d32cd49fc2b250075b578f25431b9","packages\u002Fcoding-agent\u002Fskills\u002Fmach6-implement",11,"https:\u002F\u002Fgithub.com\u002Faebrer\u002Fdreb","https:\u002F\u002Fgithub.com\u002Faebrer","https:\u002F\u002Fentropist.ca","Currently working on:\r\n- DEEP YELLOW: a turn based backrooms game in godot game engine\r\n- dreb: agentic coding harness\r\n- Professionally: AI in drug-discovery","2026-11-11 05:00:12",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add aebrer\u002Fdreb --skill mach6-implement",{"tool":51,"command":52},"bunx","bunx skills add aebrer\u002Fdreb --skill mach6-implement",{"tool":54,"command":55},"pnpm","pnpm dlx skills add aebrer\u002Fdreb --skill mach6-implement","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Faebrer\u002Fdreb\u002Fblob\u002Fmaster\u002Fpackages\u002Fcoding-agent\u002Fskills\u002Fmach6-implement\u002FSKILL.md",true,[],[60,87,102,114,127,138],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":30},"01M6J75F1VDHCGAEC4CRENR3BZ","search","Semantic codebase search — use for exploring code, finding implementations, and answering questions about any project. Searches using natural language queries, identifier names, or file paths. Returns ranked results using embedding-based similarity, BM25 keyword matching, symbol matching, import graph analysis, and git recency. Best for exploring a large code or text corpus when you don't know the exact keywords; use grep when you know the exact text.","https:\u002F\u002Fgithub.com\u002Faebrer\u002Fdreb\u002Fblob\u002Fmaster\u002Fpackages\u002Fsemantic-search\u002Fskills\u002Fsearch\u002FSKILL.md",[],[62,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86],"when","queries","natural language","project","matching","bm25","import graph","similarity","import","embedding","about","questions","you","for","use","results","text","analysis","file","code",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":98,"publishedAt":30},"01M6J75DJ172W73T7GX993YR25","valid-skill","A valid skill for testing purposes.","https:\u002F\u002Fgithub.com\u002Faebrer\u002Fdreb\u002Fblob\u002Fmaster\u002Fpackages\u002Fcoding-agent\u002Ftest\u002Ffixtures\u002Fskills\u002Fvalid-skill\u002FSKILL.md",[93],{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[99,100,80,101],"valid","valid skill","testing",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":30},"01M6J75A2GVQ5QHPMSF9Z355GC","unknown-field","A skill with an unknown frontmatter field.","https:\u002F\u002Fgithub.com\u002Faebrer\u002Fdreb\u002Fblob\u002Fmaster\u002Fpackages\u002Fcoding-agent\u002Ftest\u002Ffixtures\u002Fskills\u002Funknown-field\u002FSKILL.md",[],[109,110,111,112,113],"unknown","unknown field","frontmatter","with","unknown frontmatter field",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":123,"publishedAt":30},"01M6J758HV5H5BWXH28AVMH3HA","substitution-test","A skill for testing content substitution.","https:\u002F\u002Fgithub.com\u002Faebrer\u002Fdreb\u002Fblob\u002Fmaster\u002Fpackages\u002Fcoding-agent\u002Ftest\u002Ffixtures\u002Fskills\u002Fsubstitution-test\u002FSKILL.md",[120],{"categoryNo":121,"categoryName":122,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000008","测试与质量",[124,125,80,126,101],"substitution test","test","content",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":30},"01M6J757BHN1NZPYEZNANVYW5Q","nested-child","Nested skill should be ignored.","https:\u002F\u002Fgithub.com\u002Faebrer\u002Fdreb\u002Fblob\u002Fmaster\u002Fpackages\u002Fcoding-agent\u002Ftest\u002Ffixtures\u002Fskills\u002Froot-skill-preferred\u002Fnested-child\u002FSKILL.md",[],[134,135,136,137],"child","nested","nested child","ignored",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":145,"publishedAt":30},"01M6J754D441E7R785DG009DSG","root-skill-preferred","Root skill should win.","https:\u002F\u002Fgithub.com\u002Faebrer\u002Fdreb\u002Fblob\u002Fmaster\u002Fpackages\u002Fcoding-agent\u002Ftest\u002Ffixtures\u002Fskills\u002Froot-skill-preferred\u002FSKILL.md",[144],{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},[146,147,148],"root skill preferred","root skill","root"]