[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FNM85B64ZAXAQ7HA6QPVKC":3,"skill-same:01M6FNM85B64ZAXAQ7HA6QPVKC":68},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6FNM85B64ZAXAQ7HA6QPVKC","incident",null,"Incident response mode — diagnose a production issue, write a postmortem, add follow-up tasks to TODO.md. Use when user says \"\u002Fincident [description]\".","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\u002Fincident\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"incident response","diagnose","tasks","Production","postmortem","write","user","use","up","issue","todo","add","follow-up","mode","when","2026-11-10 10:12:30",false,"---\nname: incident\ndescription: \"Incident response mode — diagnose a production issue, write a postmortem, add follow-up tasks to TODO.md. Use when user says \\\"\u002Fincident [description]\\\".\"\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:incident`; 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\n# \u002Fincident Skill: Structured Incident Logging\n\n## Overview\nThis skill helps you systematically capture incidents, analyze their root causes, and extract lessons learned to prevent future recurrence.\n\n## Workflow\n\n### Step 1: Gather Incident Details\nIf the user provided a description with `\u002Fincident \u003Cdescription>`, use that. Otherwise, ask the user:\n- **What went wrong?** (the symptom, the failure, what the user observed)\n- **What was the context?** (what was being done, what changed, what was the state)\n- **What was the impact?** (did it affect production, other users, how long did it last)\n\n### Step 2: Perform Root Cause Analysis\nOnce you have the details, conduct a structured RCA:\n- **Immediate cause**: What directly caused the failure? (e.g., missing validation, race condition, config not deployed)\n- **Root cause**: Why was the immediate cause present? (e.g., code not tested, config drift, async task not awaited)\n- **Category**: Classify the root cause into one of these categories:\n  - `settings-disconnect`: Config defined but not wired, loaded, or called\n  - `edge-case`: Untested input, OS-specific behavior, empty\u002Fnull\u002Ffirst-run state\n  - `async-race`: TOCTOU (time-of-check-time-of-use), stale closures, missing locks, zombie processes\n  - `security`: Unsanitized input, leaked secrets, missing auth\u002Fvalidation\n  - `deploy-gap`: Source differs from deployed, config not reloaded, code defined but not called at runtime\n\n### Step 3: Write Incident Entry\nCreate or update `.clade\u002Fincidents.md` with a new entry:\n\n```markdown\n## Incident — {date: YYYY-MM-DD}\n**What:** {1-2 sentence symptom - what went wrong}\n**Context:** {1-2 sentences - what was being done, what changed}\n**Root cause:** {1-2 sentences - why did it happen, which category}\n**Fix applied:** {how was it resolved, if immediate fix exists}\n**Prevention:** {what should prevent this next time - concrete steps, not vague}\n```\n\nExample:\n```markdown\n## Incident — 2026-02-26\n**What:** API endpoint returned 500 on startup, database connection string missing from error response.\n**Context:** Deploying to production with new secrets management; assumed .env would be loaded from system but it wasn't.\n**Root cause:** Secrets loading hook defined in config but never called during server startup. [deploy-gap]\n**Fix applied:** Added explicit `await loadSecrets()` call in server init before database connect.\n**Prevention:** Add startup checklist: (1) required envvars defined, (2) all config-loading hooks executed, (3) test startup on fresh container.\n```\n\n### Agent-caused incidents: extra fields\n\nIf the failure came from an agent run (unattended loop, dispatched worker,\ncron session) rather than a human-driven edit, the standard entry is not\nenough — agent incidents carry *delegated authority*, so the postmortem must\nreconstruct what the agent was allowed to do, not just what it did. Add:\n\n**Agent:** {which run\u002Fworker\u002Fsession, with its log or evidence-bundle path}\n**Authority scope:** {permissions granted vs. the ones actually exercised}\n**Tool-call trace:** {replayable record — session transcript, hook log, or evidence bundle}\n**Blast radius:** {compute\u002FAPI spend and external side effects (messages sent, pushes, deploys), not just code damage}\n**Facts vs. hypotheses:** {what the trace proves vs. what is inferred — mark each}\n\nAn agent-incident postmortem that names no trace is UNVERIFIED by\nconstruction: an agent's own summary of its run is a claim, not evidence.\n\n### Step 4: Extract Corrective Rule (Optional)\nIf the incident reveals a pattern worth remembering, offer to append a rule to `corrections\u002Frules.md`:\n\nFormat:\n```\n- [YYYY-MM-DD] {domain} ({root-cause-category}): {do this} instead of {not this}\n```\n\nExample:\n```\n- [2026-02-26] deploy (deploy-gap): Call `loadSecrets()` explicitly in server init — not rely on framework autoload\n```\n\nAsk the user if they want to add the rule. If yes, append it to the file. If no, skip.\n\n### Step 5: Confirm and Close\nOnce the incident entry is written, print:\n\n```\n✓ Incident logged to .clade\u002Fincidents.md — [link to timestamp]\n```\n\nIf a rule was added:\n```\n✓ Corrective rule added to corrections\u002Frules.md\n```\n\n---\n\n## Implementation Notes\n\n- **Keep it concise**: Incident entries should be scannable — one incident per date.\n- **Date format**: Use YYYY-MM-DD (e.g., 2026-02-27).\n- **Prevention is key**: The \"Prevention\" section is the most valuable part — it should be concrete and actionable, not vague.\n- **Root cause category** is required for rule extraction — it helps organize lessons by type.\n- **If .clade\u002Fincidents.md doesn't exist**, create it with a header: `# Incident Log\\n\\n`.\n- **If corrections\u002Frules.md doesn't exist**, create it with a header: `# Correction Rules\\n\\n`.\n\n---\n\n## User Interaction Model\n\n1. User runs `\u002Fincident` with optional description: `\u002Fincident \"API timeout during batch job\"`\n2. If no description, ask for what\u002Fcontext\u002Fimpact\n3. Conduct RCA together (ask clarifying questions if needed)\n4. Write the incident entry to `.clade\u002Fincidents.md`\n5. **Append the prevention work to `TODO.md`.** The entry's Prevention field is\n   already the follow-up task; a postmortem whose prevention lives only in an\n   incidents file is a postmortem nobody acts on. One checkbox per preventable\n   cause, each naming the file or gate that would have caught it. Say so if\n   there is genuinely nothing to prevent — that is a finding, not an omission.\n6. Offer to extract a rule — get user confirmation before appending\n7. Confirm logging is complete, and name the TODO items you added\n\n\n---\n\n## Completion Status\n\n- ✅ **DONE** — task completed successfully\n- ⚠ **DONE_WITH_CONCERNS** — completed but with caveats to note\n- ❌ **BLOCKED** — cannot proceed; write details to `.clade\u002Fblockers.md`\n- ❓ **NEEDS_CONTEXT** — missing information; use AskUserQuestion\n\n**3-strike rule:** If the same approach fails 3 times, switch to BLOCKED — do not retry indefinitely.\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:incident`; 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\n# \u002Fincident Skill: Structured Incident Logging\n\n## Overview\nThis skill helps you systematically capture incidents, analyze their root causes, and extract lessons learned to prevent future recurrence.\n\n## Workflow\n\n### Step 1: Gather Incident Details\nIf the user provided a description with `\u002Fincident \u003Cdescription>`, use that. Otherwise, ask the user:\n- **What went wrong?** (the symptom, the failure, what the user observed)\n- **What was the context?** (what was being done, what changed, what was the state)\n- **What was the impact?** (did it affect production, other users, how long did it last)\n\n### Step 2: Perform Root Cause Analysis\nOnce you have the details, conduct a structured RCA:\n- **Immediate cause**: What directly caused the failure? (e.g., missing validation, race condition, config not deployed)\n- **Root cause**: Why was the immediate cause present? (e.g., code not tested, config drift, async task not awaited)\n- **Category**: Classify the root cause into one of these categories:\n  - `settings-disconnect`: Config defined but not wired, loaded, or called\n  - `edge-case`: Untested input, OS-specific behavior, empty\u002Fnull\u002Ffirst-run state\n  - `async-race`: TOCTOU (time-of-check-time-of-use), stale closures, missing locks, zombie processes\n  - `security`: Unsanitized input, leaked secrets, missing auth\u002Fvalidation\n  - `deploy-gap`: Source differs from deployed, config not reloaded, code defined but not called at runtime\n\n### Step 3: Write Incident Entry\nCreate or update `.clade\u002Fincidents.md` with a new entry:\n\n```markdown\n## Incident — {date: YYYY-MM-DD}\n**What:** {1-2 sentence symptom - what went wrong}\n**Context:** {1-2 sentences - what was being done, what changed}\n**Root cause:** {1-2 sentences - why did it happen, which category}\n**Fix applied:** {how was it resolved, if immediate fix exists}\n**Prevention:** {what should prevent this next time - concrete steps, not vague}\n```\n\nExample:\n```markdown\n## Incident — 2026-02-26\n**What:** API endpoint returned 500 on startup, database connection string missing from error response.\n**Context:** Deploying to production with new secrets management; assumed .env would be loaded from system but it wasn't.\n**Root cause:** Secrets loading hook defined in config but never called during server startup. [deploy-gap]\n**Fix applied:** Added explicit `await loadSecrets()` call in server init before database connect.\n**Prevention:** Add startup checklist: (1) required envvars defined, (2) all config-loading hooks executed, (3) test startup on fresh container.\n```\n\n### Agent-caused incidents: extra fields\n\nIf the failure came from an agent run (unattended loop, dispatched worker,\ncron session) rather than a human-driven edit, the standard entry is not\nenough — agent incidents carry *delegated authority*, so the postmortem must\nreconstruct what the agent was allowed to do, not just what it did. Add:\n\n**Agent:** {which run\u002Fworker\u002Fsession, with its log or evidence-bundle path}\n**Authority scope:** {permissions granted vs. the ones actually exercised}\n**Tool-call trace:** {replayable record — session transcript, hook log, or evidence bundle}\n**Blast radius:** {compute\u002FAPI spend and external side effects (messages sent, pushes, deploys), not just code damage}\n**Facts vs. hypotheses:** {what the trace proves vs. what is inferred — mark each}\n\nAn agent-incident postmortem that names no trace is UNVERIFIED by\nconstruction: an agent's own summary of its run is a claim, not evidence.\n\n### Step 4: Extract Corrective Rule (Optional)\nIf the incident reveals a pattern worth remembering, offer to append a rule to `corrections\u002Frules.md`:\n\nFormat:\n```\n- [YYYY-MM-DD] {domain} ({root-cause-category}): {do this} instead of {not this}\n```\n\nExample:\n```\n- [2026-02-26] deploy (deploy-gap): Call `loadSecrets()` explicitly in server init — not rely on framework autoload\n```\n\nAsk the user if they want to add the rule. If yes, append it to the file. If no, skip.\n\n### Step 5: Confirm and Close\nOnce the incident entry is written, print:\n\n```\n✓ Incident logged to .clade\u002Fincidents.md — [link to timestamp]\n```\n\nIf a rule was added:\n```\n✓ Corrective rule added to corrections\u002Frules.md\n```\n\n---\n\n## Implementation Notes\n\n- **Keep it concise**: Incident entries should be scannable — one incident per date.\n- **Date format**: Use YYYY-MM-DD (e.g., 2026-02-27).\n- **Prevention is key**: The \"Prevention\" section is the most valuable part — it should be concrete and actionable, not vague.\n- **Root cause category** is required for rule extraction — it helps organize lessons by type.\n- **If .clade\u002Fincidents.md doesn't exist**, create it with a header: `# Incident Log\\n\\n`.\n- **If corrections\u002Frules.md doesn't exist**, create it with a header: `# Correction Rules\\n\\n`.\n\n---\n\n## User Interaction Model\n\n1. User runs `\u002Fincident` with optional description: `\u002Fincident \"API timeout during batch job\"`\n2. If no description, ask for what\u002Fcontext\u002Fimpact\n3. Conduct RCA together (ask clarifying questions if needed)\n4. Write the incident entry to `.clade\u002Fincidents.md`\n5. **Append the prevention work to `TODO.md`.** The entry's Prevention field is\n   already the follow-up task; a postmortem whose prevention lives only in an\n   incidents file is a postmortem nobody acts on. One checkbox per preventable\n   cause, each naming the file or gate that would have caught it. Say so if\n   there is genuinely nothing to prevent — that is a finding, not an omission.\n6. Offer to extract a rule — get user confirmation before appending\n7. Confirm logging is complete, and name the TODO items you added\n\n\n---\n\n## Completion Status\n\n- ✅ **DONE** — task completed successfully\n- ⚠ **DONE_WITH_CONCERNS** — completed but with caveats to note\n- ❌ **BLOCKED** — cannot proceed; write details to `.clade\u002Fblockers.md`\n- ❓ **NEEDS_CONTEXT** — missing information; use AskUserQuestion\n\n**3-strike rule:** If the same approach fails 3 times, switch to BLOCKED — do not retry indefinitely.\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\u002Fincident",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":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add shenxingy\u002FClade --skill incident",{"tool":60,"command":61},"bunx","bunx skills add shenxingy\u002FClade --skill incident",{"tool":63,"command":64},"pnpm","pnpm dlx skills add shenxingy\u002FClade --skill incident","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fincident\u002FSKILL.md",true,[],[69,88,121,142,166,182],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":76,"publishedAt":39},"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",[75],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[71,77,78,79,80,81,82,83,84,85,86,87],"adaptive","inspect","with","ownership","delivery routing","runtime","delivery","workspaces","git","routing","create",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":100,"publishedAt":39},"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",[94,95],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":96,"categoryName":97,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120],"web search","search","web","repository","file","research","MCP","requests","collection","reading","URL","native","bulk","progress","file search","route","tinyfish","evidence","check","api",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":128,"publishedAt":39},"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",[127],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[123,129,130,131,132,133,134,135,136,137,138,139,140,141],"app","single","features","which","interaction","tests","project","observe","autonomous","behavior","list","change","codex",{"skillNo":143,"name":26,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":39},"01M6FNNX95R9H29BNERFY15704","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",[147],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[26,149,150,151,135,152,153,154,155,156,157,158,159,160,31,161,162,163,164,165,141],"for","plans","work","shared","across","human","task","coordinate","kimi","snapshots","agent monitoring","dependency","using beads","beads","monitoring","acceptance","sessions",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":173,"publishedAt":39},"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",[172],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[168,174,175,176,177,178,179,180,114,181,34],"session","run","documentation","commit","only","documentation sync","updates","end",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":189,"publishedAt":39},"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",[188],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[184,82,190,191,149,180,192,193,114,194,83,195,196,31,197,151,198,199,85,200],"running","limits","usage","now","active","show","provider","snapshot","model","execution","identity"]