[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FNNTAD1BCZX5Q9TC55MZCH":3,"skill-same:01M6FNNTAD1BCZX5Q9TC55MZCH":63},{"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":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":44,"ownerHtmlUrl":45,"ownerBlogUrl":46,"ownerDescription":47,"updatedAt":48,"install":49,"resources":62},"01M6FNNTAD1BCZX5Q9TC55MZCH","sync",null,"End-of-session documentation sync — updates TODO.md and PROGRESS.md only (run \u002Fcommit after to commit everything)","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\u002Fsync\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],"commit","documentation","run","session","only","todo","end","progress","updates","documentation sync","2026-11-10 10:12:30",false,"---\nname: sync\ndescription: \"End-of-session documentation sync — updates TODO.md and PROGRESS.md only (run \u002Fcommit after to commit everything)\"\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:sync`; 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 Sync skill. You automate the end-of-session documentation ritual.\n\nThis skill only updates documentation files (TODO.md, PROGRESS.md). It does NOT commit.\nAfter \u002Fsync, the user runs `\u002Fcommit` to commit all changes (code + docs) split by module.\n\n---\n\n## Step 1: Review recent work\n\nFind what was done in this session:\n\n1. Get the time window: Look for the last sync marker in PROGRESS.md, or default to the last 8 hours.\n   ```bash\n   git log --since=\"8 hours ago\" --oneline\n   ```\n2. Get detailed changes:\n   ```bash\n   git log --since=\"8 hours ago\" --stat\n   ```\n3. Read the commit messages to understand what was accomplished.\n4. Also check for uncommitted changes via `git status --short`.\n\nBuild a mental model of: what features were added, what bugs were fixed, what was refactored.\n\n---\n\n## Step 2: Update TODO.md\n\n1. Read `TODO.md`\n2. For each unchecked `- [ ]` item, determine if the recent commits implemented it:\n   - Match commit messages against TODO item descriptions\n   - Use Grep to verify the implementation exists in code (e.g., if TODO says \"add X route\", grep for that route)\n   - Only check off items you can verify — don't guess\n3. Edit TODO.md to check off completed items: `- [ ]` → `- [x]`\n4. If you discover new sub-tasks during verification, add them under the relevant step\n5. Show what was checked off:\n   ```\n   TODO.md updated:\n     ✓ Checked off: \"Add project_repos table\" (verified: schema exists)\n     ✓ Checked off: \"GitHub API client\" (verified: lib\u002Fgithub-client.ts exists)\n     ? Skipped: \"OAuth integration\" (no matching commits found)\n   ```\n\n---\n\n## Step 3: Update PROGRESS.md\n\nAdd the session summary at the TOP of PROGRESS.md, immediately below the archive-pointer line — the log is newest-first and `archive-progress.py` keeps the newest entries that fit under the cap. Appending puts today's work first in line to be archived. Follow this format:\n\n```markdown\n### YYYY-MM-DD — [Brief session description]\n\n**What was done:**\n- [Feature\u002Ffix 1]: [one-line description of what and why]\n- [Feature\u002Ffix 2]: [one-line description]\n\n**What worked:**\n- [Pattern or approach that was effective]\n\n**What didn't work \u002F lessons:**\n- [Issue encountered and how it was resolved, or pitfall to avoid]\n\n**Open items:**\n- [Anything left unfinished that the next session should pick up]\n```\n\nGuidelines:\n- Be concise — each bullet is one line\n- Focus on lessons (what worked, what didn't) — this is the most valuable part\n- Don't list every file changed — focus on the \"why\" and insights\n- If nothing notable went wrong, skip \"What didn't work\"\n\n---\n\n## Step 3b: Prune old entries\n\nIf PROGRESS.md exceeds 100 lines, run the tool CI gates on rather than\narchiving by hand:\n\n```bash\npython3 configs\u002Fscripts\u002Farchive-progress.py --apply\n```\n\nIt keeps the newest entries that fit under the cap plus anything marked\n`[ACTIVE]`, writes the rest to `docs\u002Fprogress-archive\u002FYYYY-MM.md`, reroots their\nlinks, and refreshes the single archive pointer in the header. **Age is not the\ncriterion — the cap is.** This file used to say \"older than 30 days\", which\ndisagreed with the gate: a 40-day entry stays if it fits, and a 2-day entry\nmoves if it does not.\n\nReport what it printed.\n\n---\n\n\n## Step 3c: Generate session scorecard\n\nRun the session scorecard generator to log quality metrics:\n\n```bash\nbash ~\u002F.clade\u002Fscripts\u002Fsession-scorecard.sh\n```\n\nThis appends a JSON entry to `~\u002F.clade\u002Fcorrections\u002Fscorecards.jsonl` with correction counts, commits, and a quality score. If the script doesn't exist, skip this step silently.\n\n---\n\n## Step 3d: Archive tier files\n\nCheck for 3-tier issue handling files from autonomous loop runs:\n\n```bash\nls .clade\u002Fdecisions.md .clade\u002Fskipped.md .clade\u002Fblockers.md 2>\u002Fdev\u002Fnull\n```\n\nFor each file that exists:\n1. Append its contents to `.clade\u002F{name}-archive.md` (create if needed)\n2. Delete the original file\n3. Report what was archived\n\nIf none exist, skip silently.\n\n---\n\n## Step 3e: README length check\n\nA README is a landing page, not a reference manual: the cap is 300 lines.\nCheck every README at the repository root — `README.md` and its localized\nsiblings — and name the sections that should move into `docs\u002F`.\n\n```bash\n# Each oversized README, then its `##` sections largest-first.\nfor f in README.md README.*.md; do\n  [ -f \"$f\" ] || continue\n  n=$(awk 'END {print NR}' \"$f\")\n  [ \"$n\" -gt 300 ] || continue\n  echo \"OVER CAP: $f — $n lines (cap 300)\"\n  awk '\u002F^## \u002F{if (h != \"\") printf \"  %5d  %s\\n\", NR - s, h; h = $0; s = NR}\n       END {if (h != \"\") printf \"  %5d  %s\\n\", NR - s + 1, h}' \"$f\" | sort -rn\ndone\n```\n\nNothing printed: every README is inside the cap. Say nothing and move on.\n\nThe section sizes are a ranking hint, not a measurement — a `##` line inside a\nfenced code block counts as a heading here. Read the file before trusting a\nsurprising number.\n\nWhen a README is over the cap, name the move candidates. Four things stay in\nthe README however large it grows — install, the key-features table, the\ncommand table, and the links into `docs\u002F` — so the candidates are the largest\nof what is left, and each candidate names the `docs\u002F` file it would become.\n\nThen record the flag so it outlives the session. Only when `TODO.md` exists,\nand only when it is not already carrying this flag:\n\n```bash\ngrep -Fq \"over the 300-line landing-page cap\" TODO.md\n```\n\nIf that matches nothing, add one unchecked item per oversized README, in this\nwording — the fixed phrase is what the grep above matches on the next run, so\nkeep it verbatim:\n\n```\n- [ ] README.md is over the 300-line landing-page cap (310 lines). Move\n      \"Skills\" (64 lines) and \"MCP Server\" (32 lines) into docs\u002F, leaving a\n      link behind.\n```\n\nDo NOT move the sections yourself. This skill writes `TODO.md` and\n`PROGRESS.md` only; splitting a README is a separate edit with its own review.\n\n---\n\n## Step 3f: Repository entry-point follow-through\n\nWhen this session creates a repository or changes its README, setup, advertised\ncapabilities or first-use path, check the first-visitor journey as well as length:\n\n- root, language variants and independently distributed package entry points;\n- a clear audience\u002Foutcome, maturity and next action;\n- meaningful product\u002Fresult media, not only a logo or badge row; fixture and\n  illustration labels, privacy, alt text and maintained asset paths;\n- runnable first task and expected result, recovery\u002Fhelp, and real repository\n  responsibilities linked to the relevant documentation;\n- actual rendered desktop\u002Fphone and light\u002Fdark evidence, plus exercised links\n  and first-use commands. A Markdown diff or image count is not a visual pass.\n\nReuse still-valid evidence when these surfaces are unchanged. For missing or\nstale evidence, record the concrete gap and its next verification action in the\nexisting task\u002Fstatus record; do not mark the onboarding task complete. Detailed\nacceptance is in the installed `document-release` skill's\n`..\u002Fdocument-release\u002Freferences\u002Frepository-entrypoints.md`. This sync step does not expand its\nwrite scope or require a redesign on every code change. When README work is\nalready authorized, continue that work instead of asking the owner to repeat it.\n\n## Step 4: Print summary\n\nAlways end with a summary:\n\n```\nSync complete:\n  ? TODO.md: 3 items checked off, 1 new sub-task added\n  ? PROGRESS.md: Session summary appended\n  ? README.md: 310 lines — over the 300 cap, flagged in TODO.md\n\n  Run \u002Fcommit to commit all changes. It checkpoints LOCALLY by default and\n  publishes only with `--publish` or an existing delivery\u002Frepository\n  authority — there is no `--no-push`, and there never was.\n```\n\nDrop the ? line when every README is inside the cap.\n\n---\n\n## General rules\n\n- Be concise. This is a utility, not a conversation.\n- Only check off TODO items you can verify — false positives are worse than false negatives.\n- Don't modify TODO.md structure (don't reorder, don't delete items, don't change headers).\n- PROGRESS.md entries should be useful to future-you, not a changelog.\n- If there's nothing to sync (no recent commits, no changes), say so and exit.\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## Additional skill reference\n\n# Sync Skill\n\nEnd-of-session documentation ritual. Reviews what was done and updates project docs — no commit. Run `\u002Fcommit` after to commit everything (docs + code) split by module.\n\n## What it does\n\n1. Reviews recent git history to understand what was accomplished\n2. Auto-updates TODO.md (checks off completed items)\n3. Prepends a session summary to PROGRESS.md (newest-first; appending puts today's work first in line to be archived)\n4. Flags a root README over the 300-line landing-page cap, naming the sections that should move to `docs\u002F`\n\n## Usage\n\n```\n\u002Fsync            # Update TODO.md + PROGRESS.md\n\u002Fcommit          # Commit all changes (code + docs) split by module — local only\n\u002Fcommit --publish  # Commit, then publish the owned branch\n```\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:sync`; 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 Sync skill. You automate the end-of-session documentation ritual.\n\nThis skill only updates documentation files (TODO.md, PROGRESS.md). It does NOT commit.\nAfter \u002Fsync, the user runs `\u002Fcommit` to commit all changes (code + docs) split by module.\n\n---\n\n## Step 1: Review recent work\n\nFind what was done in this session:\n\n1. Get the time window: Look for the last sync marker in PROGRESS.md, or default to the last 8 hours.\n   ```bash\n   git log --since=\"8 hours ago\" --oneline\n   ```\n2. Get detailed changes:\n   ```bash\n   git log --since=\"8 hours ago\" --stat\n   ```\n3. Read the commit messages to understand what was accomplished.\n4. Also check for uncommitted changes via `git status --short`.\n\nBuild a mental model of: what features were added, what bugs were fixed, what was refactored.\n\n---\n\n## Step 2: Update TODO.md\n\n1. Read `TODO.md`\n2. For each unchecked `- [ ]` item, determine if the recent commits implemented it:\n   - Match commit messages against TODO item descriptions\n   - Use Grep to verify the implementation exists in code (e.g., if TODO says \"add X route\", grep for that route)\n   - Only check off items you can verify — don't guess\n3. Edit TODO.md to check off completed items: `- [ ]` → `- [x]`\n4. If you discover new sub-tasks during verification, add them under the relevant step\n5. Show what was checked off:\n   ```\n   TODO.md updated:\n     ✓ Checked off: \"Add project_repos table\" (verified: schema exists)\n     ✓ Checked off: \"GitHub API client\" (verified: lib\u002Fgithub-client.ts exists)\n     ? Skipped: \"OAuth integration\" (no matching commits found)\n   ```\n\n---\n\n## Step 3: Update PROGRESS.md\n\nAdd the session summary at the TOP of PROGRESS.md, immediately below the archive-pointer line — the log is newest-first and `archive-progress.py` keeps the newest entries that fit under the cap. Appending puts today's work first in line to be archived. Follow this format:\n\n```markdown\n### YYYY-MM-DD — [Brief session description]\n\n**What was done:**\n- [Feature\u002Ffix 1]: [one-line description of what and why]\n- [Feature\u002Ffix 2]: [one-line description]\n\n**What worked:**\n- [Pattern or approach that was effective]\n\n**What didn't work \u002F lessons:**\n- [Issue encountered and how it was resolved, or pitfall to avoid]\n\n**Open items:**\n- [Anything left unfinished that the next session should pick up]\n```\n\nGuidelines:\n- Be concise — each bullet is one line\n- Focus on lessons (what worked, what didn't) — this is the most valuable part\n- Don't list every file changed — focus on the \"why\" and insights\n- If nothing notable went wrong, skip \"What didn't work\"\n\n---\n\n## Step 3b: Prune old entries\n\nIf PROGRESS.md exceeds 100 lines, run the tool CI gates on rather than\narchiving by hand:\n\n```bash\npython3 configs\u002Fscripts\u002Farchive-progress.py --apply\n```\n\nIt keeps the newest entries that fit under the cap plus anything marked\n`[ACTIVE]`, writes the rest to `docs\u002Fprogress-archive\u002FYYYY-MM.md`, reroots their\nlinks, and refreshes the single archive pointer in the header. **Age is not the\ncriterion — the cap is.** This file used to say \"older than 30 days\", which\ndisagreed with the gate: a 40-day entry stays if it fits, and a 2-day entry\nmoves if it does not.\n\nReport what it printed.\n\n---\n\n\n## Step 3c: Generate session scorecard\n\nRun the session scorecard generator to log quality metrics:\n\n```bash\nbash ~\u002F.clade\u002Fscripts\u002Fsession-scorecard.sh\n```\n\nThis appends a JSON entry to `~\u002F.clade\u002Fcorrections\u002Fscorecards.jsonl` with correction counts, commits, and a quality score. If the script doesn't exist, skip this step silently.\n\n---\n\n## Step 3d: Archive tier files\n\nCheck for 3-tier issue handling files from autonomous loop runs:\n\n```bash\nls .clade\u002Fdecisions.md .clade\u002Fskipped.md .clade\u002Fblockers.md 2>\u002Fdev\u002Fnull\n```\n\nFor each file that exists:\n1. Append its contents to `.clade\u002F{name}-archive.md` (create if needed)\n2. Delete the original file\n3. Report what was archived\n\nIf none exist, skip silently.\n\n---\n\n## Step 3e: README length check\n\nA README is a landing page, not a reference manual: the cap is 300 lines.\nCheck every README at the repository root — `README.md` and its localized\nsiblings — and name the sections that should move into `docs\u002F`.\n\n```bash\n# Each oversized README, then its `##` sections largest-first.\nfor f in README.md README.*.md; do\n  [ -f \"$f\" ] || continue\n  n=$(awk 'END {print NR}' \"$f\")\n  [ \"$n\" -gt 300 ] || continue\n  echo \"OVER CAP: $f — $n lines (cap 300)\"\n  awk '\u002F^## \u002F{if (h != \"\") printf \"  %5d  %s\\n\", NR - s, h; h = $0; s = NR}\n       END {if (h != \"\") printf \"  %5d  %s\\n\", NR - s + 1, h}' \"$f\" | sort -rn\ndone\n```\n\nNothing printed: every README is inside the cap. Say nothing and move on.\n\nThe section sizes are a ranking hint, not a measurement — a `##` line inside a\nfenced code block counts as a heading here. Read the file before trusting a\nsurprising number.\n\nWhen a README is over the cap, name the move candidates. Four things stay in\nthe README however large it grows — install, the key-features table, the\ncommand table, and the links into `docs\u002F` — so the candidates are the largest\nof what is left, and each candidate names the `docs\u002F` file it would become.\n\nThen record the flag so it outlives the session. Only when `TODO.md` exists,\nand only when it is not already carrying this flag:\n\n```bash\ngrep -Fq \"over the 300-line landing-page cap\" TODO.md\n```\n\nIf that matches nothing, add one unchecked item per oversized README, in this\nwording — the fixed phrase is what the grep above matches on the next run, so\nkeep it verbatim:\n\n```\n- [ ] README.md is over the 300-line landing-page cap (310 lines). Move\n      \"Skills\" (64 lines) and \"MCP Server\" (32 lines) into docs\u002F, leaving a\n      link behind.\n```\n\nDo NOT move the sections yourself. This skill writes `TODO.md` and\n`PROGRESS.md` only; splitting a README is a separate edit with its own review.\n\n---\n\n## Step 3f: Repository entry-point follow-through\n\nWhen this session creates a repository or changes its README, setup, advertised\ncapabilities or first-use path, check the first-visitor journey as well as length:\n\n- root, language variants and independently distributed package entry points;\n- a clear audience\u002Foutcome, maturity and next action;\n- meaningful product\u002Fresult media, not only a logo or badge row; fixture and\n  illustration labels, privacy, alt text and maintained asset paths;\n- runnable first task and expected result, recovery\u002Fhelp, and real repository\n  responsibilities linked to the relevant documentation;\n- actual rendered desktop\u002Fphone and light\u002Fdark evidence, plus exercised links\n  and first-use commands. A Markdown diff or image count is not a visual pass.\n\nReuse still-valid evidence when these surfaces are unchanged. For missing or\nstale evidence, record the concrete gap and its next verification action in the\nexisting task\u002Fstatus record; do not mark the onboarding task complete. Detailed\nacceptance is in the installed `document-release` skill's\n`..\u002Fdocument-release\u002Freferences\u002Frepository-entrypoints.md`. This sync step does not expand its\nwrite scope or require a redesign on every code change. When README work is\nalready authorized, continue that work instead of asking the owner to repeat it.\n\n## Step 4: Print summary\n\nAlways end with a summary:\n\n```\nSync complete:\n  ? TODO.md: 3 items checked off, 1 new sub-task added\n  ? PROGRESS.md: Session summary appended\n  ? README.md: 310 lines — over the 300 cap, flagged in TODO.md\n\n  Run \u002Fcommit to commit all changes. It checkpoints LOCALLY by default and\n  publishes only with `--publish` or an existing delivery\u002Frepository\n  authority — there is no `--no-push`, and there never was.\n```\n\nDrop the ? line when every README is inside the cap.\n\n---\n\n## General rules\n\n- Be concise. This is a utility, not a conversation.\n- Only check off TODO items you can verify — false positives are worse than false negatives.\n- Don't modify TODO.md structure (don't reorder, don't delete items, don't change headers).\n- PROGRESS.md entries should be useful to future-you, not a changelog.\n- If there's nothing to sync (no recent commits, no changes), say so and exit.\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## Additional skill reference\n\n# Sync Skill\n\nEnd-of-session documentation ritual. Reviews what was done and updates project docs — no commit. Run `\u002Fcommit` after to commit everything (docs + code) split by module.\n\n## What it does\n\n1. Reviews recent git history to understand what was accomplished\n2. Auto-updates TODO.md (checks off completed items)\n3. Prepends a session summary to PROGRESS.md (newest-first; appending puts today's work first in line to be archived)\n4. Flags a root README over the 300-line landing-page cap, naming the sections that should move to `docs\u002F`\n\n## Usage\n\n```\n\u002Fsync            # Update TODO.md + PROGRESS.md\n\u002Fcommit          # Commit all changes (code + docs) split by module — local only\n\u002Fcommit --publish  # Commit, then publish the owned branch\n```\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\u002Fsync",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":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add shenxingy\u002FClade --skill sync",{"tool":55,"command":56},"bunx","bunx skills add shenxingy\u002FClade --skill sync",{"tool":58,"command":59},"pnpm","pnpm dlx skills add shenxingy\u002FClade --skill sync","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fsync\u002FSKILL.md",true,[],[64,83,115,136,162,181],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":71,"publishedAt":34},"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",[70],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[66,72,73,74,75,76,77,78,79,80,81,82],"create","routing","git","workspaces","delivery","runtime","delivery routing","ownership","with","inspect","adaptive",{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":95,"publishedAt":34},"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",[89,90],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[96,97,98,99,100,101,102,103,104,105,106,107,108,109,31,110,111,112,113,114],"web","search","web search","MCP","research","file","repository","collection","api","check","evidence","tinyfish","route","file search","bulk","native","URL","reading","requests",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":122,"publishedAt":34},"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",[121],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[117,123,124,125,126,127,128,129,130,131,132,133,134,135],"codex","change","list","behavior","autonomous","observe","project","tests","app","interaction","which","features","single",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":143,"publishedAt":34},"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",[142],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[138,123,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,129,159,160,161],"sessions","acceptance","monitoring","beads","work","use","dependency","agent monitoring","snapshots","kimi","coordinate","task","human","across","shared","plans","using beads","for",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":169,"publishedAt":34},"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",[168],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[164,170,74,171,172,148,173,149,174,175,76,176,77,31,177,178,32,161,179,180],"identity","execution","model","snapshot","provider","show","active","now","usage","limits","running",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":191,"publishedAt":34},"01M6FNNH4NKKR00N6WQ9WWMJY6","review","Clade coverage-driven project review — walks every VERIFY.md checkpoint, fixes failures in-session, converges when all pass. NOT the Codex built-in \u002Freview (single PR diff) — route PR reviews to \u002Freview-pr or the CC built-in.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Freview\u002FSKILL.md",[187,190],{"categoryNo":188,"categoryName":189,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[183,123,192,117,193,194,27,195,196,108,197,129,198,199,200,201,135,202,203],"pr","checkpoint","coverage","diff","cc","project review","driven","reviews","fixes","review-pr","when","all pass"]