[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C15A4SC65WB0WRGWY70ASE":3,"skill-same:01M6C15A4SC65WB0WRGWY70ASE":98},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":13,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":47,"install":48,"resources":61},"01M6C15A4SC65WB0WRGWY70ASE","project-graveyard",null,"Scans the developer's machine for dead side projects, autopsies each one from its git history (died at the payments wall, killed by a newer project, finished but never shipped), surfaces their personal death patterns, and picks the corpse most worth resurrecting — then helps ship it. Use when the user mentions abandoned, unfinished, or old side projects, asks \"what should I finish\", wants to revive or resurrect a project, says \"run the graveyard\", wonders why they never finish anything, or is about to start a new project that sounds like one they already built. Runs entirely locally.","WhiteChronos\u002FChatGPT","WhiteChronos","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F159819369?v=4","01M6C1435VSN8A1DR5856GM8NC","01M6C143A8CCX6VAGT2PVTBGXC",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FWhiteChronos\u002FChatGPT\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fproject-graveyard\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32],"project graveyard","personal","github","run","git","https","developer","payments","start","ship","why","new project","projects","history","user","2026-11-10 10:12:30",false,"---\nname: project-graveyard\ndescription: >-\n  Scans the developer's machine for dead side projects, autopsies each one from\n  its git history (died at the payments wall, killed by a newer project,\n  finished but never shipped), surfaces their personal death patterns, and picks\n  the corpse most worth resurrecting — then helps ship it. Use when the user\n  mentions abandoned, unfinished, or old side projects, asks \"what should I\n  finish\", wants to revive or resurrect a project, says \"run the graveyard\",\n  wonders why they never finish anything, or is about to start a new project\n  that sounds like one they already built. Runs entirely locally.\nlicense: Apache-2.0\nmetadata:\n  author: \"Shubham Saboo\"\n  version: \"1.0.0\"\n  source: \"https:\u002F\u002Fgithub.com\u002FShubhamsaboo\u002Fawesome-llm-apps\"\n---\n\n# Project Graveyard\n\nEvery developer has a folder full of dead projects. Nobody has ever gotten an\nautopsy report. This skill scans the machine for abandoned repos, works out why\neach one died from its git history, finds the user's personal death patterns,\nand picks the one corpse worth digging up — then helps ship it.\n\nEverything runs locally. No API, no network, nothing leaves the machine.\n\n## When to use\n\n- The user asks about abandoned\u002Funfinished\u002Fold side projects, or what to finish\n- The user wants to revive, resurrect, or \"finally ship\" something\n- The user asks why they never finish projects\n- The user proposes a new project — check the graveyard first (see Necromancer\n  mode). There's a decent chance they already built half of it.\n\n## When not to use\n\n- Cleaning up disk space or node_modules — that's `kondo`\u002F`npkill`, not this\n- Archiving repos on GitHub — this works on local clones and never-pushed work\n- Analyzing one specific repo's history in depth — just read the git log\n\n## Run it\n\n```bash\npython3 scripts\u002Fgraveyard.py ~\u002Fdev ~\u002Fprojects\n```\n\nPoint it at wherever projects actually live. If you don't know where that\nis, ask — one question beats sweeping someone's home directory uninvited.\nNo args scans the usual suspects (~\u002Fdev, ~\u002Fprojects, ~\u002Fcode, ~\u002FDesktop, ...).\nUseful flags:\n\n- `--days 90` — how long silent before a repo counts as dead (default 45)\n- `--json report.json` — full machine-readable data\n- `--me work@email.com` — claim commits made under other emails (repeatable);\n  without it, projects committed via a work identity or a builder tool get\n  skipped as \"not yours\"\n- `--include-foreign` — also include repos the user barely committed to\n  (skipped by default: clones, forks, work checkouts are not their corpses)\n- `--state FILE` — remember scans and resurrections; enables relapse watch\n\nThe script is read-only. It never writes inside a scanned repo.\n\n## Reading the report\n\nThe script gives you four blocks: census, the dead (with cause of death),\npatterns, and the top 3 by \"pulse\" (resurrectability score). Causes are\nevidence-based guesses, not verdicts — each comes with the evidence line that\njustifies it. If a cause looks wrong, check the evidence before repeating it.\nThe cause taxonomy and what each one means for resurrection is in\n`references\u002Fcauses-of-death.md` — read it before writing the report.\n\n## The autopsy interview\n\nThe script can only read git. You can ask. For corpses whose primary cause is\n`unknown` or `slow_fade` — the low-confidence verdicts — ask the user one\nquestion each, two or three total at most:\n\n> \"`recipe-scraper` — the history just shows it drifting. Do you remember\n> what actually stopped you?\"\n\nBlend the answers in, and label verdicts honestly in the report:\n**(forensic)** for what git showed, **(confirmed)** for what the user told\nyou. Testimony beats a forensic guess — update the tombstone, not just the\nprose. Two questions is a conversation; five is a deposition.\n\n## Writing the tombstone report\n\nTurn the script output into a report the user will actually feel. Format:\n\n1. **The census.** Deaths, combined lifespan, oldest corpse. Plain numbers —\n   they land on their own.\n2. **Tombstones.** One per dead project, worst-to-best pulse. Name, lifespan,\n   commit count, cause of death with its evidence, and a one-line epitaph.\n   Above ~10 corpses, give full tombstones only to the 6-8 most interesting\n   (highest pulse, most distinctive deaths) and bury the rest together in one\n   line — \"...plus 11 one-day experiments, buried in a shared plot.\" A wall\n   of 23 tombstones kills the funeral.\n3. **The patterns.** This is the part they'll remember. \"Your projects die at\n   day 19.\" \"Four of six were killed by a newer project.\" Quote the script's\n   numbers; add anything you can see that it can't.\n4. **The resurrection.** One project. Not three. See below.\n\nCarve the resurrection pick (and only it) as an ASCII tombstone card —\nstone is earned, not sprayed; every other corpse stays a line in the table:\n\n```\n        .------------------------.\n       \u002F                          \\\n      |        tab-sensei          |\n      |      Apr — May 2026        |\n      |   54 commits · 12 days     |\n      |                            |\n      |   died of deploy fear      |\n      |                            |\n      |   \"It worked. It just      |\n      |     never shipped.\"        |\n   ___|____________________________|___\n      ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~\n```\n\nCenter the text, keep the card under 44 columns so it never wraps, epitaph\nlast. If the graveyard is empty, no card — don't carve a stone for nobody.\n\nEpitaph rules — this is where the whole thing lives or dies:\n\n- Every epitaph must be traceable to evidence from the scan. \"Died as it\n  lived: configuring webpack\" works because the config ratio was 78%. Made-up\n  jokes about code you haven't seen don't work and the user will know.\n- Punch at the pattern, not the person. \"It worked. It just never shipped\" is\n  fine. \"You were too scared to ship\" is not.\n- Dry beats wacky. One sentence. No puns unless they're earned.\n- If a project deserves respect, give it. A 26-commit repo with a finished\n  README that never shipped is a small tragedy, not a punchline.\n\nOffer `--redact` framing if the user wants to share the report: project names\nswapped for `project-1..n`, causes and patterns intact.\n\n## The resurrection\n\nPick ONE corpse. Highest pulse wins unless its idea is dead in the world too.\nBefore deciding, read the top candidate's README and skim the code — then do\nthe **world-check**, the part only you can do because the script can't see\nthe present:\n\n- Search whether what blocked it got easier since it died: the API it fought\n  may have an official SDK now, the model that was too expensive may be 20x\n  cheaper, the thing it hand-rolled may be a library today.\n- Search whether the world shipped the idea. If three funded products do\n  exactly this now, say so — that changes the plan from \"ship it\" to \"ship it\n  for yourself,\" or to \"let it rest.\"\n\nCite what you find in the plan. \"This got easier: X exists now\" is the\nstrongest argument for digging; \"the window closed\" is the strongest for\nleaving it buried.\n\nThen write the resurrection plan. The per-cause dig strategy is in\n`references\u002Fcauses-of-death.md` (each cause has a \"resurrection angle\" —\ndeploy-fear corpses need shipping steps only, wall deaths need the managed\nalternative, scope explosions get one feature extracted). Plan rules:\n\n- At most 7 concrete steps, ending at *shipped* (a URL, a release, a\n  published package — not \"keep working on it\")\n- Step 0 is always: confirm it still runs. Deps rot; prove the install and\n  the entry point before promising anything.\n- Step 1 must be completable today — the first session has to end with\n  visible progress\n- Ask before touching the repo. Then offer to start on step 1 right now —\n  that offer is the entire point of running this inside an agent.\n\n**When to leave it buried** — say it plainly when it's true: the user doesn't\ncare anymore (a shrug at the interview is closure, not a project); the\nwindow closed and the world shipped the idea; or every candidate is weak.\n\"Nothing here is worth digging up, and that's fine — here's what the patterns\nsay about the *next* project\" is a legitimate and useful ending.\n\nWhen the user commits to a resurrection, record it (ask once where to keep\nthe state file — `~\u002F.project-graveyard.json` is a sane default):\n\n```bash\npython3 scripts\u002Fgraveyard.py --state ~\u002F.project-graveyard.json \\\n    --mark-resurrected \u002Fpath\u002Fto\u002Fthe\u002Fcorpse\n```\n\n## Relapse watch\n\nScans run with `--state` hold past resurrections to their promise: the report\ngains a RELAPSE WATCH block showing whether each resurrected project is\nholding or going silent again. When one relapses, say it plainly and make the\nuser choose — recommit or bury it honestly. A second silent death is an\nanswer, not a failure; close the loop instead of prescribing a third attempt.\nNo tool follows up on its own prescription. This one does — that's the point\nof keeping state.\n\n## Necromancer mode\n\nWhen the user proposes building something new, check the graveyard for prior\nattempts before scaffolding anything — grep the state file (or a fresh\n`--json` report) for name and README overlap. If there's a match:\n\n> \"You already built about 60% of this. It's called `project-14`, it died in\n> March at the auth step, and its parser still works. Resurrect instead?\"\n\nDon't be preachy about it. Mention it once, let them choose, drop it.\n\n## Gotchas\n\n- **~\u002FDesktop might itself be a git repo** (accidental `git init`, backup\n  tools). The scanner handles nested repos, but if the census looks absurd,\n  that's usually why.\n- **Ownership filter uses git email.** If the user commits under multiple\n  emails (work address, GitHub web edits, builder tools), real corpses get\n  skipped as \"not yours\" — the census names what it skipped; claim yours with\n  `--me that@email.com`.\n- **\"Dead\" is a threshold, not a truth.** A stable finished tool looks dead at\n  45 days. The script separates `finished` (deploy config + pushed + README)\n  from dead, but the heuristic is rough — ask before eulogizing anything the\n  user considers done.\n- **One-day corpses are usually vibe-coded bursts**, not failures — a project\n  built in one sitting and never reopened. The pattern worth surfacing is how\n  many of them there are, not that each one \"died.\"\n- **Don't resurrect by default.** The report is the product; the resurrection\n  is an offer. Some corpses should stay buried — see \"When to leave it buried\"\n  above.\n\n## Files\n\n- `scripts\u002Fgraveyard.py` — scanner + autopsy + pulse ranking (stdlib, offline, read-only)\n- `references\u002Fcauses-of-death.md` — the taxonomy: signals, confidence, and the per-cause resurrection strategy\n","# Project Graveyard\n\nEvery developer has a folder full of dead projects. Nobody has ever gotten an\nautopsy report. This skill scans the machine for abandoned repos, works out why\neach one died from its git history, finds the user's personal death patterns,\nand picks the one corpse worth digging up — then helps ship it.\n\nEverything runs locally. No API, no network, nothing leaves the machine.\n\n## When to use\n\n- The user asks about abandoned\u002Funfinished\u002Fold side projects, or what to finish\n- The user wants to revive, resurrect, or \"finally ship\" something\n- The user asks why they never finish projects\n- The user proposes a new project — check the graveyard first (see Necromancer\n  mode). There's a decent chance they already built half of it.\n\n## When not to use\n\n- Cleaning up disk space or node_modules — that's `kondo`\u002F`npkill`, not this\n- Archiving repos on GitHub — this works on local clones and never-pushed work\n- Analyzing one specific repo's history in depth — just read the git log\n\n## Run it\n\n```bash\npython3 scripts\u002Fgraveyard.py ~\u002Fdev ~\u002Fprojects\n```\n\nPoint it at wherever projects actually live. If you don't know where that\nis, ask — one question beats sweeping someone's home directory uninvited.\nNo args scans the usual suspects (~\u002Fdev, ~\u002Fprojects, ~\u002Fcode, ~\u002FDesktop, ...).\nUseful flags:\n\n- `--days 90` — how long silent before a repo counts as dead (default 45)\n- `--json report.json` — full machine-readable data\n- `--me work@email.com` — claim commits made under other emails (repeatable);\n  without it, projects committed via a work identity or a builder tool get\n  skipped as \"not yours\"\n- `--include-foreign` — also include repos the user barely committed to\n  (skipped by default: clones, forks, work checkouts are not their corpses)\n- `--state FILE` — remember scans and resurrections; enables relapse watch\n\nThe script is read-only. It never writes inside a scanned repo.\n\n## Reading the report\n\nThe script gives you four blocks: census, the dead (with cause of death),\npatterns, and the top 3 by \"pulse\" (resurrectability score). Causes are\nevidence-based guesses, not verdicts — each comes with the evidence line that\njustifies it. If a cause looks wrong, check the evidence before repeating it.\nThe cause taxonomy and what each one means for resurrection is in\n`references\u002Fcauses-of-death.md` — read it before writing the report.\n\n## The autopsy interview\n\nThe script can only read git. You can ask. For corpses whose primary cause is\n`unknown` or `slow_fade` — the low-confidence verdicts — ask the user one\nquestion each, two or three total at most:\n\n> \"`recipe-scraper` — the history just shows it drifting. Do you remember\n> what actually stopped you?\"\n\nBlend the answers in, and label verdicts honestly in the report:\n**(forensic)** for what git showed, **(confirmed)** for what the user told\nyou. Testimony beats a forensic guess — update the tombstone, not just the\nprose. Two questions is a conversation; five is a deposition.\n\n## Writing the tombstone report\n\nTurn the script output into a report the user will actually feel. Format:\n\n1. **The census.** Deaths, combined lifespan, oldest corpse. Plain numbers —\n   they land on their own.\n2. **Tombstones.** One per dead project, worst-to-best pulse. Name, lifespan,\n   commit count, cause of death with its evidence, and a one-line epitaph.\n   Above ~10 corpses, give full tombstones only to the 6-8 most interesting\n   (highest pulse, most distinctive deaths) and bury the rest together in one\n   line — \"...plus 11 one-day experiments, buried in a shared plot.\" A wall\n   of 23 tombstones kills the funeral.\n3. **The patterns.** This is the part they'll remember. \"Your projects die at\n   day 19.\" \"Four of six were killed by a newer project.\" Quote the script's\n   numbers; add anything you can see that it can't.\n4. **The resurrection.** One project. Not three. See below.\n\nCarve the resurrection pick (and only it) as an ASCII tombstone card —\nstone is earned, not sprayed; every other corpse stays a line in the table:\n\n```\n        .------------------------.\n       \u002F                          \\\n      |        tab-sensei          |\n      |      Apr — May 2026        |\n      |   54 commits · 12 days     |\n      |                            |\n      |   died of deploy fear      |\n      |                            |\n      |   \"It worked. It just      |\n      |     never shipped.\"        |\n   ___|____________________________|___\n      ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~\n```\n\nCenter the text, keep the card under 44 columns so it never wraps, epitaph\nlast. If the graveyard is empty, no card — don't carve a stone for nobody.\n\nEpitaph rules — this is where the whole thing lives or dies:\n\n- Every epitaph must be traceable to evidence from the scan. \"Died as it\n  lived: configuring webpack\" works because the config ratio was 78%. Made-up\n  jokes about code you haven't seen don't work and the user will know.\n- Punch at the pattern, not the person. \"It worked. It just never shipped\" is\n  fine. \"You were too scared to ship\" is not.\n- Dry beats wacky. One sentence. No puns unless they're earned.\n- If a project deserves respect, give it. A 26-commit repo with a finished\n  README that never shipped is a small tragedy, not a punchline.\n\nOffer `--redact` framing if the user wants to share the report: project names\nswapped for `project-1..n`, causes and patterns intact.\n\n## The resurrection\n\nPick ONE corpse. Highest pulse wins unless its idea is dead in the world too.\nBefore deciding, read the top candidate's README and skim the code — then do\nthe **world-check**, the part only you can do because the script can't see\nthe present:\n\n- Search whether what blocked it got easier since it died: the API it fought\n  may have an official SDK now, the model that was too expensive may be 20x\n  cheaper, the thing it hand-rolled may be a library today.\n- Search whether the world shipped the idea. If three funded products do\n  exactly this now, say so — that changes the plan from \"ship it\" to \"ship it\n  for yourself,\" or to \"let it rest.\"\n\nCite what you find in the plan. \"This got easier: X exists now\" is the\nstrongest argument for digging; \"the window closed\" is the strongest for\nleaving it buried.\n\nThen write the resurrection plan. The per-cause dig strategy is in\n`references\u002Fcauses-of-death.md` (each cause has a \"resurrection angle\" —\ndeploy-fear corpses need shipping steps only, wall deaths need the managed\nalternative, scope explosions get one feature extracted). Plan rules:\n\n- At most 7 concrete steps, ending at *shipped* (a URL, a release, a\n  published package — not \"keep working on it\")\n- Step 0 is always: confirm it still runs. Deps rot; prove the install and\n  the entry point before promising anything.\n- Step 1 must be completable today — the first session has to end with\n  visible progress\n- Ask before touching the repo. Then offer to start on step 1 right now —\n  that offer is the entire point of running this inside an agent.\n\n**When to leave it buried** — say it plainly when it's true: the user doesn't\ncare anymore (a shrug at the interview is closure, not a project); the\nwindow closed and the world shipped the idea; or every candidate is weak.\n\"Nothing here is worth digging up, and that's fine — here's what the patterns\nsay about the *next* project\" is a legitimate and useful ending.\n\nWhen the user commits to a resurrection, record it (ask once where to keep\nthe state file — `~\u002F.project-graveyard.json` is a sane default):\n\n```bash\npython3 scripts\u002Fgraveyard.py --state ~\u002F.project-graveyard.json \\\n    --mark-resurrected \u002Fpath\u002Fto\u002Fthe\u002Fcorpse\n```\n\n## Relapse watch\n\nScans run with `--state` hold past resurrections to their promise: the report\ngains a RELAPSE WATCH block showing whether each resurrected project is\nholding or going silent again. When one relapses, say it plainly and make the\nuser choose — recommit or bury it honestly. A second silent death is an\nanswer, not a failure; close the loop instead of prescribing a third attempt.\nNo tool follows up on its own prescription. This one does — that's the point\nof keeping state.\n\n## Necromancer mode\n\nWhen the user proposes building something new, check the graveyard for prior\nattempts before scaffolding anything — grep the state file (or a fresh\n`--json` report) for name and README overlap. If there's a match:\n\n> \"You already built about 60% of this. It's called `project-14`, it died in\n> March at the auth step, and its parser still works. Resurrect instead?\"\n\nDon't be preachy about it. Mention it once, let them choose, drop it.\n\n## Gotchas\n\n- **~\u002FDesktop might itself be a git repo** (accidental `git init`, backup\n  tools). The scanner handles nested repos, but if the census looks absurd,\n  that's usually why.\n- **Ownership filter uses git email.** If the user commits under multiple\n  emails (work address, GitHub web edits, builder tools), real corpses get\n  skipped as \"not yours\" — the census names what it skipped; claim yours with\n  `--me that@email.com`.\n- **\"Dead\" is a threshold, not a truth.** A stable finished tool looks dead at\n  45 days. The script separates `finished` (deploy config + pushed + README)\n  from dead, but the heuristic is rough — ask before eulogizing anything the\n  user considers done.\n- **One-day corpses are usually vibe-coded bursts**, not failures — a project\n  built in one sitting and never reopened. The pattern worth surfacing is how\n  many of them there are, not that each one \"died.\"\n- **Don't resurrect by default.** The report is the product; the resurrection\n  is an offer. Some corpses should stay buried — see \"When to leave it buried\"\n  above.\n\n## Files\n\n- `scripts\u002Fgraveyard.py` — scanner + autopsy + pulse ranking (stdlib, offline, read-only)\n- `references\u002Fcauses-of-death.md` — the taxonomy: signals, confidence, and the per-cause resurrection strategy\n",{"name":5,"license":14,"metadata":38,"description":7},{"author":39,"source":40,"version":41},"Shubham Saboo","https:\u002F\u002Fgithub.com\u002FShubhamsaboo\u002Fawesome-llm-apps","1.0.0","main","d32244fd815eaa4d6bb54fa1751c70f44528fa42",".agents\u002Fskills\u002Fproject-graveyard","https:\u002F\u002Fgithub.com\u002FWhiteChronos\u002FChatGPT","https:\u002F\u002Fgithub.com\u002FWhiteChronos","2026-11-13 00:02:30",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add WhiteChronos\u002FChatGPT --skill project-graveyard",{"tool":54,"command":55},"bunx","bunx skills add WhiteChronos\u002FChatGPT --skill project-graveyard",{"tool":57,"command":58},"pnpm","pnpm dlx skills add WhiteChronos\u002FChatGPT --skill project-graveyard","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FWhiteChronos\u002FChatGPT\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fproject-graveyard\u002FSKILL.md",true,[62,68,72,76,80,84,88,92],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"README.md","REFERENCE","参考文档",4729,"https:\u002F\u002Fgithub.com\u002FWhiteChronos\u002FChatGPT\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fproject-graveyard\u002FREADME.md",{"path":69,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":70,"sourceHtmlUrl":71},"references\u002Fcauses-of-death.md",4602,"https:\u002F\u002Fgithub.com\u002FWhiteChronos\u002FChatGPT\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fproject-graveyard\u002Freferences\u002Fcauses-of-death.md",{"path":73,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Ferror-handling-pattern.md",1375,"https:\u002F\u002Fgithub.com\u002FDicklesworthstone\u002Fpi_agent_rust\u002Fblob\u002Fmain\u002Ftests\u002Fext_conformance\u002Fartifacts\u002Fplugins-community\u002Fplugins\u002Fsaas-packs\u002Fklingai-pack\u002Fskills\u002Fklingai-sdk-patterns\u002Freferences\u002Ferror-handling-pattern.md",{"path":77,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Ferrors.md",275,"https:\u002F\u002Fgithub.com\u002FDicklesworthstone\u002Fpi_agent_rust\u002Fblob\u002Fmain\u002Ftests\u002Fext_conformance\u002Fartifacts\u002Fplugins-community\u002Fplugins\u002Fsaas-packs\u002Fklingai-pack\u002Fskills\u002Fklingai-sdk-patterns\u002Freferences\u002Ferrors.md",{"path":81,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fexamples.md",75,"https:\u002F\u002Fgithub.com\u002FDicklesworthstone\u002Fpi_agent_rust\u002Fblob\u002Fmain\u002Ftests\u002Fext_conformance\u002Fartifacts\u002Fplugins-community\u002Fplugins\u002Fsaas-packs\u002Fklingai-pack\u002Fskills\u002Fklingai-sdk-patterns\u002Freferences\u002Fexamples.md",{"path":85,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fpython-client-pattern.md",5430,"https:\u002F\u002Fgithub.com\u002FDicklesworthstone\u002Fpi_agent_rust\u002Fblob\u002Fmain\u002Ftests\u002Fext_conformance\u002Fartifacts\u002Fplugins-community\u002Fplugins\u002Fsaas-packs\u002Fklingai-pack\u002Fskills\u002Fklingai-sdk-patterns\u002Freferences\u002Fpython-client-pattern.md",{"path":89,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Ftypescript-client-pattern.md",4172,"https:\u002F\u002Fgithub.com\u002FDicklesworthstone\u002Fpi_agent_rust\u002Fblob\u002Fmain\u002Ftests\u002Fext_conformance\u002Fartifacts\u002Fplugins-community\u002Fplugins\u002Fsaas-packs\u002Fklingai-pack\u002Fskills\u002Fklingai-sdk-patterns\u002Freferences\u002Ftypescript-client-pattern.md",{"path":93,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":96,"sourceHtmlUrl":97},"scripts\u002Fgraveyard.py","SCRIPT","脚本",25533,"https:\u002F\u002Fgithub.com\u002FWhiteChronos\u002FChatGPT\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fproject-graveyard\u002Fscripts\u002Fgraveyard.py",[99,131,157,176,197,209],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":103,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":111,"publishedAt":33},"01M6C168GWBGK7PDCHN1TEGSP7","typesafe-ai","Build AI-powered software with TypeSafe: small units of AI intelligence you can use like programming primitives. Its System One models, including Jev, turn natural language and application state into typed judgments and probabilities that code can combine. Use when a feature needs programmable common sense, when brainstorming what AI could make possible in an app, or when an LLM prompt-and-parse step could become a structured decision. Applications include routing, ranking, extraction, verification, and interactive experiences; these are starting points, not the limits. Read live docs and cookbooks to find useful patterns and discover new combinations.","MIT","https:\u002F\u002Fgithub.com\u002FWhiteChronos\u002FChatGPT\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftypesafe-ai\u002FSKILL.md",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130],"typesafe ai","docs","brainstorming","routing","code","state","verification","extraction","applications","system","decision","common","programming","find","prompt","read","interactive","jev","primitives",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":140,"publishedAt":33},"01M6C15XR6QZGZPZ7ASNTZC776","thinking-out-loud","A contract for what the agent does when a long, messy, stream-of-consciousness ramble arrives (usually voice dictation): act on nothing until the echo brief is approved. The echo audits the entire transfer, mission, locked decisions and constraints, open questions, flips and parked tangents, with the model's inferences and guesses quarantined away from the user's own phrasing, so the user verifies what the model believes, not just what it doubts. Use when the user says \"let me think out loud\" or wants to ramble a bit before building anything, when a message opens with a speech-to-text preamble like \"switching to voice, sorry for typos\", when input is a long weakly punctuated stream with restarts and mid-message reversals (\"actually no, wait, scrap that idea entirely\"), or when the user asks to be interviewed about a fuzzy half-formed idea. Includes an optional capture mode for rambles spread across several messages and an optional targeted interview.","https:\u002F\u002Fgithub.com\u002FWhiteChronos\u002FChatGPT\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fthinking-out-loud\u002FSKILL.md",[137],{"categoryNo":138,"categoryName":139,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000037","律师与法务",[141,20,142,23,143,144,145,146,147,148,149,150,151,152,153,154,155,32,156],"thinking out loud","speech","transfer","brief","messages","constraints","open","scrap","voice","text","model","just","capture","before building","decisions","interview",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"publishedAt":33},"01M6C15JZZ4X1GR2NNC2DV6Q61","scope-creep-detector","Analyzes git diffs against a stated intent to detect scope creep, unrelated files, broad pull requests, changes that grew beyond a fix, dependency additions, public API renames, config or CI edits, oversized hunks, and formatting-only files. Use when the user asks whether a change grew beyond the fix, a PR is too broad, or what unrelated stuff they touched, and wants keep, split, or justify guidance. Operates locally and offline.","https:\u002F\u002Fgithub.com\u002FWhiteChronos\u002FChatGPT\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fscope-creep-detector\u002FSKILL.md",[],[164,165,20,166,167,168,169,22,170,171,23,172,173,174,32,175],"scope creep detector","diffs","pull requests","change","config","pr","pull","offline","ci","api","public","fix",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":33},"01M6C14HYZJG8AR9DM81CWA5WH","dependency-doctor","Checks requirements.txt, pyproject.toml, and package.json dependency manifests for surface-level direct-dependency footguns: standard-library shadowing pins, abandoned backports, unpinned dependencies, and obvious intra-manifest conflicts, plus opt-in PyPI yanked releases. Use when the user asks to check a manifest for dependency problems, asks why dependencies won't install or whether anything is wrong with their dependencies, wants a dependency autopsy, or suspects dependency manifest rot. Runs offline by default as a local tool for the user's own project, not repository CI.","https:\u002F\u002Fgithub.com\u002FWhiteChronos\u002FChatGPT\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdependency-doctor\u002FSKILL.md",[],[183,184,185,20,186,171,23,187,188,189,172,190,191,192,28,193,194,195,196,32],"doctor","dependency doctor","python","package","library","pypi","repository","autopsy","network","manifest","access","tool","json","direct",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":203,"publishedAt":33},"01M6C14F35NTFQ7VZWX9JNE7MG","commit-archaeologist","Reconstructs why code exists from local git history, including the introducing commit, later changes, current authors, repeated companion files, and likely intent. Use when the user asks \"why does this code exist\", \"who wrote this function and why\", or to \"explain the history of this function\" before a rewrite, refactor, or risky edit. Runs entirely locally.","https:\u002F\u002Fgithub.com\u002FWhiteChronos\u002FChatGPT\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcommit-archaeologist\u002FSKILL.md",[],[204,205,20,116,22,23,206,28,207,31,208,32],"commit","commit archaeologist","refactor","explain","edit",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":33},"01M6C145Y9JKJ2H8DJ1SCAA1SD","advisor-orchestrator-worker","Use when a task is too large for one model pass, needs parallel research or generation across many subtasks (like researching a dozen competitors at once), or the user asks to orchestrate multiple models, split work across a model team, run an advisor-worker loop, have a stronger model review the plan while cheap workers execute, or says \"too big for one model\" or \"fan this out\". Not for single-file edits or tasks one model handles in one pass.","https:\u002F\u002Fgithub.com\u002FWhiteChronos\u002FChatGPT\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fadvisor-orchestrator-worker\u002FSKILL.md",[],[216,217,218,219,220,221,222,223,224,225,226,227,173,228,229,230,231,151,232,233],"orchestrator","advisor orchestrator worker","review","cli","gemini","gemini api","antigravity","research","tasks","harness","orchestrate","file","team","Bash","loop","plan","parallel","work"]