[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FNMC8SP8JTDZ2AKBPRECYP":3,"skill-same:01M6FNMC8SP8JTDZ2AKBPRECYP":76},{"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":31,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6FNMC8SP8JTDZ2AKBPRECYP","investigate",null,"Root cause analysis skill — diagnose bugs systematically before fixing. Iron Law: no fix without a confirmed hypothesis. Uses scope lock, 3-strike escalation, and structured debug reports.","shenxingy\u002FClade","shenxingy","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F89829751?v=4","01M6CQXHTV3WQZJMG0JXD93MEK","Xingyu (Alex) Shen","01M6CQXHYCTGPJ5HD8Z7MD4Q5P",10,"MIT","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Finvestigate\u002FSKILL.md",[18,23,28],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务",[5,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"debug","diagnose","root cause analysis","escalation","hypothesis","analysis","fix","strike","reports","structured","scope","root","lock","bugs","root cause","2026-11-10 10:12:30",false,"---\nname: investigate\ndescription: \"Root cause analysis skill — diagnose bugs systematically before fixing. Iron Law: no fix without a confirmed hypothesis. Uses scope lock, 3-strike escalation, and structured debug reports.\"\n---\n\n# Clade for Codex\n\nThis workflow runs **directly in Codex**. Do not launch the `claude` CLI or\ndelegate the workflow to Clade's MCP bridge.\n\nCodex compatibility rules:\n\n- Plugin skills are namespaced. Invoke this workflow explicitly as\n  `$clade:investigate`; a bare `$name` does not select the installed Clade plugin.\n- Read the nearest `AGENTS.md` files for repository instructions. If a project\n  has only `CLAUDE.md`, treat it as legacy project guidance and read it too.\n- Store new Clade working state under `.clade\u002F` (or `~\u002F.clade\u002F` for personal\n  state). Existing legacy Claude state may be read for migration, but do not\n  create new vendor-specific state.\n- A `\u002Fskill-name` reference means the corresponding Codex\n  `$clade:skill-name` plugin skill, or the same workflow invoked naturally when\n  explicit skill invocation is not available.\n- Use Codex web, file, shell, image, and subagent capabilities when the source\n  workflow names a vendor-specific tool. If a capability is unavailable, use\n  the documented fallback instead of spawning another agent CLI.\n- Paths such as `\u003Cplugin-root>\u002F...` are relative to the installed Clade plugin\n  containing this `SKILL.md`; resolve that root before invoking a helper.\n\n## Canonical Clade workflow\n\nYou are the Investigate skill. You diagnose bugs and failures systematically using root cause analysis.\n\n## Iron Law\n\n**No fix without a confirmed root cause hypothesis.**\n\nFixing symptoms wastes time and creates new bugs. Understand why something is broken before touching the code.\n\n---\n\n## Phase 1: Collect Symptoms\n\nRe-ground on context before diving in:\n```bash\ngit branch --show-current\ngit log --oneline -10\n```\n\nGather what's known:\n- What exactly is failing? (error message, stack trace, unexpected behavior)\n- Is it reproducible? On every run or intermittent?\n- When did it start? Check recent commits:\n  ```bash\n  git log --oneline -20 -- \u003Caffected-files>\n  ```\n- What changed recently that could have introduced this?\n\nIf the symptom description is vague, ask the user ONE specific question before continuing (not a list — one question at a time):\n\n> **Re-ground:** [project + branch + task]\n> **Question:** [single concrete question]\n> **Why:** I need this to narrow down where to look.\n\n---\n\n## Phase 2: Code Path Tracing\n\nRead the relevant code. Don't guess — trace the actual execution path:\n\n1. Identify the entry point (route, function call, script invocation)\n2. Use Grep to find where the error originates\n3. Read the files in the call chain — follow imports, not assumptions\n4. Check recent changes to the affected files:\n   ```bash\n   git log --oneline -20 -- \u003Cfile>\n   git show HEAD~1 -- \u003Cfile>   # what changed in last commit?\n   ```\n\n**Output a root cause hypothesis** at this point — a specific, testable claim:\n```\nRoot cause hypothesis: \u003Cfile>:\u003Cline> — \u003Cwhat is wrong and why>\nExample: \"auth.py:142 — token expiry check uses UTC naive datetime but DB stores UTC+8, causes\n         valid tokens to appear expired during 00:00–08:00 window\"\n```\n\n---\n\n## Phase 3: Scope Lock\n\nOnce you have a hypothesis, identify the minimum scope needed to fix it:\n```bash\necho \"\u003Caffected-directory>\u002F\" > .clade\u002Ffreeze-dir.txt\n```\n\nThis is a commitment: all edits should stay within this scope. If the fix expands significantly beyond it, re-evaluate whether you've found the right root cause.\n\n---\n\n## Phase 4: Hypothesis Testing\n\n**Before writing any fix**, verify the hypothesis with evidence:\n\n- Add a temporary log\u002Fassertion to confirm the exact failure point\n- Run the failing scenario\n- Does the log confirm your hypothesis?\n\n**3-strike rule:** If your hypothesis is wrong, form a new one. After 3 failed hypotheses, stop and ask:\n\n> **Context:** [project + branch + what was tried]\n> **RECOMMENDATION:** Option A — add instrumentation and let it fail naturally in the next real occurrence, because shotgun debugging without data is counterproductive.\n>\n> A. Add observability (log + metric) and wait for next occurrence  `Completeness: 8\u002F10`  (human: ~15min \u002F Codex: ~20min)\n> B. Escalate to a more senior debugger \u002F fresh pair of eyes        `Completeness: 7\u002F10`  (human: ~30min \u002F Codex: N\u002FA)\n> C. Continue investigating with a different approach                `Completeness: 5\u002F10`  (human: ~1h \u002F Codex: ~45min)\n\n---\n\n## Phase 5: Known Pattern Analysis\n\nCheck if this matches a known failure pattern:\n\n| Pattern | Signals |\n|---|---|\n| Race condition | Works in isolation, fails under load or with concurrent ops |\n| Null propagation | `NoneType`, `undefined`, `null pointer` errors deep in call chain |\n| State corruption | Correct on first run, wrong after repeated use \u002F restart |\n| Integration failure | Works in unit tests, fails with real dependencies |\n| Config drift | Works on one machine\u002Fenv, fails on another |\n| Stale cache | Old data persists after state change |\n| Off-by-one | Fencepost errors, wrong range boundaries |\n| Timezone\u002Fencoding | Works locally, fails with different locale\u002FTZ |\n\nIf the pattern is recognized, reference it explicitly in your hypothesis.\n\n---\n\n## Phase 6: Implement Fix\n\nFix the **root cause**, not the symptom.\n\nRules:\n- **Minimal diff** — touch only what's necessary to fix the root cause\n- **No refactoring** — if you see unrelated issues, note them but don't fix them now\n- **Write the regression test first** — a test that fails WITHOUT the fix and passes WITH it\n- Remove any temporary debugging logs\n\n**Blast radius gate:** If the fix requires changes to more than 5 files, stop and ask:\n\n> **Context:** [project + branch]\n> **This fix touches N files — broader than expected.**\n> **RECOMMENDATION:** Option A — confirm this is the right root cause before proceeding, because wide blast radius often signals we're fixing the wrong layer.\n>\n> A. Confirm root cause + proceed with full fix   `Completeness: 9\u002F10`  (human: ~10min \u002F Codex: ~30min)\n> B. Find a narrower fix at a higher layer         `Completeness: 7\u002F10`  (human: ~20min \u002F Codex: ~20min)\n> C. Split into two commits: fix + refactor        `Completeness: 8\u002F10`  (human: ~15min \u002F Codex: ~25min)\n\n---\n\n## Phase 6b: Root Cause Is in a Dependency\n\nIf tracing landed in a third-party package (not this codebase), the Iron Law still applies — and a recording law joins it: **a dependency bug handled silently is a bug planted for the next person.**\n\n1. **Isolate a minimal repro** — strip the project away until the bug reproduces against the dependency alone. Save it as `.clade\u002Frepro\u002F\u003Cdep>-\u003Cissue>.py` (or as an xfail\u002Fskipped test in `tests\u002F` referencing the upstream issue).\n2. **Search the upstream tracker** — `gh search issues --repo \u003Cupstream> \"\u003Csymptom>\"` or web search. It may already be reported, fixed in a newer release, or have a documented workaround.\n3. **Resolve in strict preference order:**\n   - **a. Upstream patch PR** — fix it at the source; link the PR in your commit body\n   - **b. Pin the version + linked issue** — pin to the last good version, add a TODO.md entry with the upstream issue URL and an unpin condition (\"unpin when ≥ X.Y.Z ships the fix\")\n   - **c. Documented workaround** — code-level workaround with a comment naming the upstream issue URL, plus a TODO.md entry\n4. **Never silent.** Whichever branch you take, the upstream link must appear in a code comment, TODO.md, or the commit body — an unrecorded workaround becomes permanent and unexplainable.\n5. **Never monkey-patch the installed copy** — edits inside `.venv\u002F` or `node_modules\u002F` evaporate on the next install.\n\n---\n\n## Phase 7: Verify & Report\n\nRun the full test suite after fixing:\n```bash\n# Run project tests\n# (check AGENTS.md for the test command)\n```\n\nThen output the structured debug report:\n\n```\nDEBUG REPORT\n════════════════════════════════════════\nSymptom:          [what the user observed]\nRoot cause:       [specific file:line — what was wrong and why]\nFix:              [file:line — what was changed]\nEvidence:         [test output or log showing the fix works]\nRegression test:  [file:line of new test]\nRelated:          [any TODOS.md items or related issues discovered]\n════════════════════════════════════════\n```\n\n---\n\n## Completion Status\n\nEnd every run with one of:\n- ✅ **DONE** — root cause found, fix applied, regression test written, report output\n- ⚠ **DONE_WITH_CONCERNS** — fix applied but hypothesis confidence is medium; monitor in production\n- ❌ **BLOCKED** — cannot reproduce or hypothesis exhausted; details written to `.clade\u002Fblockers.md`\n- ❓ **NEEDS_CONTEXT** — not enough information to proceed; specific question asked\n\n**3-strike rule:** After 3 failed hypotheses, always switch to BLOCKED — don't keep guessing.\n\n---\n\n## What NOT to do\n\n- Fix before forming a hypothesis\n- Change multiple things at once to \"see what works\"\n- Skip the regression test\n- Leave debugging logs in the code\n- Treat a passing test as proof — verify the specific failure scenario\n\n---\n\n## Deep-Dive Mode (optional)\n\nFor complex bugs requiring multi-file execution tracing, spawn the `debug-specialist` subagent:\n\n```\nUse a Codex subagent when available with subagent_type=\"debug-specialist\":\n  \"Trace the root cause of: [symptom]. Entry point: [file:function]. Known context: [what you've already found]\"\n```\n\nThe subagent reads code and forms hypotheses but cannot modify files. Merge its root cause finding into your Phase 6 fix.\n\n---\n\n## Error Handling\n\n| Scenario | Action |\n|----------|--------|\n| Cannot reproduce the bug | Ask user for exact reproduction steps (ONE specific question). Do not guess. |\n| Symptom is too vague (\"it's slow\", \"it crashes sometimes\") | Ask for a concrete example: specific error message, specific input, specific timing |\n| Files implicated are very large (>2000 lines) | Use Grep to locate the specific section before reading; use offset\u002Flimit on Read |\n| Bug is in a dependency (not this codebase) | Go to Phase 6b: minimal repro → upstream patch > pin-with-linked-issue > documented workaround. Never patch the installed copy in-place. |\n| Hypothesis requires runtime data not visible in code | Suggest specific logging\u002Fassertion to add. Output as NEEDS_CONTEXT with exact location and what to log. |\n| 3 hypotheses exhausted, still no root cause | Output BLOCKED — write to `.clade\u002Fblockers.md` with what was tried and what's needed |\n\n## Delivery completion\n\nIf this workflow changes files or external state:\n\n- Inspect the real final state before responding, including `git status` for a\n  repository task.\n- Never report `DONE` while task-owned changes are uncommitted. Use or continue\n  `$clade:delivery` and create a repository-compliant checkpoint or preserve\n  the work when committing is unavailable.\n- When the user request or trusted repository policy makes publication,\n  deployment, or live verification part of the task, do not silently downgrade\n  the result to local-only work.\n- If a required delivery transition lacks authority, credentials, a destination,\n  or reachable external state, report `BLOCKED` or `NEEDS_CONTEXT` rather than\n  appending a \"not committed\u002Fpushed\u002Fdeployed\" caveat after `DONE`.\n","# Clade for Codex\n\nThis workflow runs **directly in Codex**. Do not launch the `claude` CLI or\ndelegate the workflow to Clade's MCP bridge.\n\nCodex compatibility rules:\n\n- Plugin skills are namespaced. Invoke this workflow explicitly as\n  `$clade:investigate`; a bare `$name` does not select the installed Clade plugin.\n- Read the nearest `AGENTS.md` files for repository instructions. If a project\n  has only `CLAUDE.md`, treat it as legacy project guidance and read it too.\n- Store new Clade working state under `.clade\u002F` (or `~\u002F.clade\u002F` for personal\n  state). Existing legacy Claude state may be read for migration, but do not\n  create new vendor-specific state.\n- A `\u002Fskill-name` reference means the corresponding Codex\n  `$clade:skill-name` plugin skill, or the same workflow invoked naturally when\n  explicit skill invocation is not available.\n- Use Codex web, file, shell, image, and subagent capabilities when the source\n  workflow names a vendor-specific tool. If a capability is unavailable, use\n  the documented fallback instead of spawning another agent CLI.\n- Paths such as `\u003Cplugin-root>\u002F...` are relative to the installed Clade plugin\n  containing this `SKILL.md`; resolve that root before invoking a helper.\n\n## Canonical Clade workflow\n\nYou are the Investigate skill. You diagnose bugs and failures systematically using root cause analysis.\n\n## Iron Law\n\n**No fix without a confirmed root cause hypothesis.**\n\nFixing symptoms wastes time and creates new bugs. Understand why something is broken before touching the code.\n\n---\n\n## Phase 1: Collect Symptoms\n\nRe-ground on context before diving in:\n```bash\ngit branch --show-current\ngit log --oneline -10\n```\n\nGather what's known:\n- What exactly is failing? (error message, stack trace, unexpected behavior)\n- Is it reproducible? On every run or intermittent?\n- When did it start? Check recent commits:\n  ```bash\n  git log --oneline -20 -- \u003Caffected-files>\n  ```\n- What changed recently that could have introduced this?\n\nIf the symptom description is vague, ask the user ONE specific question before continuing (not a list — one question at a time):\n\n> **Re-ground:** [project + branch + task]\n> **Question:** [single concrete question]\n> **Why:** I need this to narrow down where to look.\n\n---\n\n## Phase 2: Code Path Tracing\n\nRead the relevant code. Don't guess — trace the actual execution path:\n\n1. Identify the entry point (route, function call, script invocation)\n2. Use Grep to find where the error originates\n3. Read the files in the call chain — follow imports, not assumptions\n4. Check recent changes to the affected files:\n   ```bash\n   git log --oneline -20 -- \u003Cfile>\n   git show HEAD~1 -- \u003Cfile>   # what changed in last commit?\n   ```\n\n**Output a root cause hypothesis** at this point — a specific, testable claim:\n```\nRoot cause hypothesis: \u003Cfile>:\u003Cline> — \u003Cwhat is wrong and why>\nExample: \"auth.py:142 — token expiry check uses UTC naive datetime but DB stores UTC+8, causes\n         valid tokens to appear expired during 00:00–08:00 window\"\n```\n\n---\n\n## Phase 3: Scope Lock\n\nOnce you have a hypothesis, identify the minimum scope needed to fix it:\n```bash\necho \"\u003Caffected-directory>\u002F\" > .clade\u002Ffreeze-dir.txt\n```\n\nThis is a commitment: all edits should stay within this scope. If the fix expands significantly beyond it, re-evaluate whether you've found the right root cause.\n\n---\n\n## Phase 4: Hypothesis Testing\n\n**Before writing any fix**, verify the hypothesis with evidence:\n\n- Add a temporary log\u002Fassertion to confirm the exact failure point\n- Run the failing scenario\n- Does the log confirm your hypothesis?\n\n**3-strike rule:** If your hypothesis is wrong, form a new one. After 3 failed hypotheses, stop and ask:\n\n> **Context:** [project + branch + what was tried]\n> **RECOMMENDATION:** Option A — add instrumentation and let it fail naturally in the next real occurrence, because shotgun debugging without data is counterproductive.\n>\n> A. Add observability (log + metric) and wait for next occurrence  `Completeness: 8\u002F10`  (human: ~15min \u002F Codex: ~20min)\n> B. Escalate to a more senior debugger \u002F fresh pair of eyes        `Completeness: 7\u002F10`  (human: ~30min \u002F Codex: N\u002FA)\n> C. Continue investigating with a different approach                `Completeness: 5\u002F10`  (human: ~1h \u002F Codex: ~45min)\n\n---\n\n## Phase 5: Known Pattern Analysis\n\nCheck if this matches a known failure pattern:\n\n| Pattern | Signals |\n|---|---|\n| Race condition | Works in isolation, fails under load or with concurrent ops |\n| Null propagation | `NoneType`, `undefined`, `null pointer` errors deep in call chain |\n| State corruption | Correct on first run, wrong after repeated use \u002F restart |\n| Integration failure | Works in unit tests, fails with real dependencies |\n| Config drift | Works on one machine\u002Fenv, fails on another |\n| Stale cache | Old data persists after state change |\n| Off-by-one | Fencepost errors, wrong range boundaries |\n| Timezone\u002Fencoding | Works locally, fails with different locale\u002FTZ |\n\nIf the pattern is recognized, reference it explicitly in your hypothesis.\n\n---\n\n## Phase 6: Implement Fix\n\nFix the **root cause**, not the symptom.\n\nRules:\n- **Minimal diff** — touch only what's necessary to fix the root cause\n- **No refactoring** — if you see unrelated issues, note them but don't fix them now\n- **Write the regression test first** — a test that fails WITHOUT the fix and passes WITH it\n- Remove any temporary debugging logs\n\n**Blast radius gate:** If the fix requires changes to more than 5 files, stop and ask:\n\n> **Context:** [project + branch]\n> **This fix touches N files — broader than expected.**\n> **RECOMMENDATION:** Option A — confirm this is the right root cause before proceeding, because wide blast radius often signals we're fixing the wrong layer.\n>\n> A. Confirm root cause + proceed with full fix   `Completeness: 9\u002F10`  (human: ~10min \u002F Codex: ~30min)\n> B. Find a narrower fix at a higher layer         `Completeness: 7\u002F10`  (human: ~20min \u002F Codex: ~20min)\n> C. Split into two commits: fix + refactor        `Completeness: 8\u002F10`  (human: ~15min \u002F Codex: ~25min)\n\n---\n\n## Phase 6b: Root Cause Is in a Dependency\n\nIf tracing landed in a third-party package (not this codebase), the Iron Law still applies — and a recording law joins it: **a dependency bug handled silently is a bug planted for the next person.**\n\n1. **Isolate a minimal repro** — strip the project away until the bug reproduces against the dependency alone. Save it as `.clade\u002Frepro\u002F\u003Cdep>-\u003Cissue>.py` (or as an xfail\u002Fskipped test in `tests\u002F` referencing the upstream issue).\n2. **Search the upstream tracker** — `gh search issues --repo \u003Cupstream> \"\u003Csymptom>\"` or web search. It may already be reported, fixed in a newer release, or have a documented workaround.\n3. **Resolve in strict preference order:**\n   - **a. Upstream patch PR** — fix it at the source; link the PR in your commit body\n   - **b. Pin the version + linked issue** — pin to the last good version, add a TODO.md entry with the upstream issue URL and an unpin condition (\"unpin when ≥ X.Y.Z ships the fix\")\n   - **c. Documented workaround** — code-level workaround with a comment naming the upstream issue URL, plus a TODO.md entry\n4. **Never silent.** Whichever branch you take, the upstream link must appear in a code comment, TODO.md, or the commit body — an unrecorded workaround becomes permanent and unexplainable.\n5. **Never monkey-patch the installed copy** — edits inside `.venv\u002F` or `node_modules\u002F` evaporate on the next install.\n\n---\n\n## Phase 7: Verify & Report\n\nRun the full test suite after fixing:\n```bash\n# Run project tests\n# (check AGENTS.md for the test command)\n```\n\nThen output the structured debug report:\n\n```\nDEBUG REPORT\n════════════════════════════════════════\nSymptom:          [what the user observed]\nRoot cause:       [specific file:line — what was wrong and why]\nFix:              [file:line — what was changed]\nEvidence:         [test output or log showing the fix works]\nRegression test:  [file:line of new test]\nRelated:          [any TODOS.md items or related issues discovered]\n════════════════════════════════════════\n```\n\n---\n\n## Completion Status\n\nEnd every run with one of:\n- ✅ **DONE** — root cause found, fix applied, regression test written, report output\n- ⚠ **DONE_WITH_CONCERNS** — fix applied but hypothesis confidence is medium; monitor in production\n- ❌ **BLOCKED** — cannot reproduce or hypothesis exhausted; details written to `.clade\u002Fblockers.md`\n- ❓ **NEEDS_CONTEXT** — not enough information to proceed; specific question asked\n\n**3-strike rule:** After 3 failed hypotheses, always switch to BLOCKED — don't keep guessing.\n\n---\n\n## What NOT to do\n\n- Fix before forming a hypothesis\n- Change multiple things at once to \"see what works\"\n- Skip the regression test\n- Leave debugging logs in the code\n- Treat a passing test as proof — verify the specific failure scenario\n\n---\n\n## Deep-Dive Mode (optional)\n\nFor complex bugs requiring multi-file execution tracing, spawn the `debug-specialist` subagent:\n\n```\nUse a Codex subagent when available with subagent_type=\"debug-specialist\":\n  \"Trace the root cause of: [symptom]. Entry point: [file:function]. Known context: [what you've already found]\"\n```\n\nThe subagent reads code and forms hypotheses but cannot modify files. Merge its root cause finding into your Phase 6 fix.\n\n---\n\n## Error Handling\n\n| Scenario | Action |\n|----------|--------|\n| Cannot reproduce the bug | Ask user for exact reproduction steps (ONE specific question). Do not guess. |\n| Symptom is too vague (\"it's slow\", \"it crashes sometimes\") | Ask for a concrete example: specific error message, specific input, specific timing |\n| Files implicated are very large (>2000 lines) | Use Grep to locate the specific section before reading; use offset\u002Flimit on Read |\n| Bug is in a dependency (not this codebase) | Go to Phase 6b: minimal repro → upstream patch > pin-with-linked-issue > documented workaround. Never patch the installed copy in-place. |\n| Hypothesis requires runtime data not visible in code | Suggest specific logging\u002Fassertion to add. Output as NEEDS_CONTEXT with exact location and what to log. |\n| 3 hypotheses exhausted, still no root cause | Output BLOCKED — write to `.clade\u002Fblockers.md` with what was tried and what's needed |\n\n## Delivery completion\n\nIf this workflow changes files or external state:\n\n- Inspect the real final state before responding, including `git status` for a\n  repository task.\n- Never report `DONE` while task-owned changes are uncommitted. Use or continue\n  `$clade:delivery` and create a repository-compliant checkpoint or preserve\n  the work when committing is unavailable.\n- When the user request or trusted repository policy makes publication,\n  deployment, or live verification part of the task, do not silently downgrade\n  the result to local-only work.\n- If a required delivery transition lacks authority, credentials, a destination,\n  or reachable external state, report `BLOCKED` or `NEEDS_CONTEXT` rather than\n  appending a \"not committed\u002Fpushed\u002Fdeployed\" caveat after `DONE`.\n",{"name":5,"description":7},"main","bb20646cb013d2f52f854743fcee83dcc5ccfbd9","plugins\u002Fclade\u002Fskills\u002Finvestigate",6,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade","https:\u002F\u002Falexshen.dev\u002Fen\u002Fblog\u002Fclade","https:\u002F\u002Fgithub.com\u002Fshenxingy","https:\u002F\u002Falexshen.dev\u002F","Founding Engineer @ Scam AI | ECE @ Duke University | Data Science @ Duke Kunshan University","2026-11-13 19:38:31",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add shenxingy\u002FClade --skill investigate",{"tool":68,"command":69},"bunx","bunx skills add shenxingy\u002FClade --skill investigate",{"tool":71,"command":72},"pnpm","pnpm dlx skills add shenxingy\u002FClade --skill investigate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Finvestigate\u002FSKILL.md",true,[],[77,96,125,146,172,189],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":84,"publishedAt":47},"01M6FNPBA3494GF2W7V4MMAKG3","worktree","Create or inspect runtime-adaptive isolated Git workspaces with explicit ownership and delivery routing","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fworktree\u002FSKILL.md",[83],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[79,85,86,87,88,89,90,91,92,93,94,95],"adaptive","inspect","with","ownership","delivery routing","runtime","delivery","workspaces","git","routing","create",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":104,"publishedAt":47},"01M6FNP75BY8CS006EWGN29FM0","web-search","Route online research and URL reading to native tools or TinyFish MCP\u002FAPI; prepare targeted requests, handle progress and failures, and check returned evidence. Applies to web search, fetching, and bulk collection; excludes repository\u002Ffile search.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fweb-search\u002FSKILL.md",[102,103],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124],"web search","search","web","repository","file","research","MCP","requests","collection","reading","URL","native","bulk","progress","file search","route","tinyfish","evidence","check","api",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"publishedAt":47},"01M6FNP2616DRTZRSZJQM3HPHY","verify","Verify project behavior anchors — compilation, tests, and interaction checks after autonomous runs. NOT the Codex built-in \u002Fverify (which runs the app to observe a single change working) — this one walks the AGENTS.md \"Features (Behavior Anchors)\" list.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fverify\u002FSKILL.md",[131],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[127,133,134,135,136,137,138,139,140,141,142,143,144,145],"app","single","features","which","interaction","tests","project","observe","autonomous","behavior","list","change","codex",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":153,"publishedAt":47},"01M6FNNX95R9H29BNERFY15704","tasks","Coordinate dependency-aware project tasks across independent Codex, Codex, Kimi and human sessions using Beads. Use for shared plans, claiming work, task handoffs, acceptance and agent monitoring snapshots.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Ftasks\u002FSKILL.md",[152],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[148,154,155,156,139,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,145],"for","plans","work","shared","across","human","task","coordinate","kimi","snapshots","agent monitoring","dependency","use","using beads","beads","monitoring","acceptance","sessions",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":179,"publishedAt":47},"01M6FNNTAD1BCZX5Q9TC55MZCH","sync","End-of-session documentation sync — updates TODO.md and PROGRESS.md only (run \u002Fcommit after to commit everything)","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fsync\u002FSKILL.md",[178],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[174,180,181,182,183,184,185,186,118,187,188],"session","run","documentation","commit","only","documentation sync","updates","end","todo",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":196,"publishedAt":47},"01M6FNNPTR5H23MD3849E66WYA","status","Show a provider-neutral, freshness-aware snapshot of active Agent work, Git delivery, execution identity, and usage limits. Use for “what's going on right now”, what is running, progress updates, active runtime\u002Fprovider\u002Fmodel, or stuck-work checks.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fstatus\u002FSKILL.md",[195],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[191,90,197,198,154,186,199,200,118,201,91,202,203,166,204,156,205,206,93,207],"running","limits","usage","now","active","show","provider","snapshot","model","execution","identity"]