[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SY9V75R9B5DT59EBBRDAD":3,"skill-same:01M71SY9V75R9B5DT59EBBRDAD":73},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":66},"01M71SY9V75R9B5DT59EBBRDAD","extract-system-spec",null,"Use when you need a portable, anonymized reconstruction spec for a whole system (or a single wing or targeted slice) — a standalone rebuild blueprint an independent team could implement in a fresh session without the original repo. Exhaustive and expensive by design: reserve it for when a full rebuild spec is genuinely worth the token spend. For finding problems in a system you are keeping, use \u002Fclaudna:audit; this instead extracts a portable spec to rebuild the system elsewhere.","Claudfather\u002FclauDNA","Claudfather","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F281278891?v=4","01M71SX82K0TBGQ394AB2G1T5Z","01M71SX83CE1S8YC06K9P3P962",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fextract-system-spec\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"extract system spec","spec","extract","system","team","you","when","Blueprint","use","single","design","true","depth","session","tokens","slice","repo","for","scope","standalone","2026-11-10 13:02:02",false,"---\nname: extract-system-spec\nuser-invocable: true\ndescription: \"Use when you need a portable, anonymized reconstruction spec for a whole system (or a single wing or targeted slice) — a standalone rebuild blueprint an independent team could implement in a fresh session without the original repo. Exhaustive and expensive by design: reserve it for when a full rebuild spec is genuinely worth the token spend. For finding problems in a system you are keeping, use \u002Fclaudna:audit; this instead extracts a portable spec to rebuild the system elsewhere.\"\nargument-hint: \"[full-system | wing \u003Cname> | targeted \u003Cscope>] [--budget \u003Ctokens>] [--depth standard|exhaustive] [--out \u003Cpath>]\"\n---\n\n# Extract System Spec\n\n> **Codex:** Read `..\u002F_shared\u002Fcodex-tools.md` before following this skill. Apply its tool, root and dispatch mappings throughout.\n\nProduce a single, standalone, anonymized Markdown specification from which a capable team could rebuild a system from scratch — without the original repo. Orchestrator + subagents; coverage-gated; hard-anonymized; adversarially reviewed. The full 6-phase method lives in `extraction-prompt.md` in this skill directory; this file governs *when* to run it, at *what scope*, and at *what cost*.\n\n## When to use this — and when NOT\n\n**Use when** the payoff of a portable rebuild blueprint justifies a large, deliberate token spend:\n- Porting \u002F re-platforming a system to a new stack or new owner.\n- A vendor-neutral or anonymized spec of a proprietary or legacy system (due diligence, handoff, escrow, disaster-recovery documentation).\n- Rebuilding a system cleanly while preserving its exact behavior, data semantics, and contracts.\n\n**Do NOT use for** — cheaper tools exist:\n- Finding problems in a system you are keeping → `\u002Fclaudna:audit` (see the table below).\n- Understanding one module or orienting quickly → read it, or `\u002Fclaudna:recall`.\n- Documenting a small or simple project → just write the docs.\n- Casual curiosity. Reserve this for a genuine rebuild need.\n\n### Not \u002Fclaudna:audit\n\nSame deep-recon technique, opposite purpose:\n\n| | extract-system-spec | \u002Fclaudna:audit |\n|---|---|---|\n| Question | \"How do I rebuild this elsewhere?\" | \"What is wrong with this?\" |\n| Output | A portable, anonymized reconstruction spec | Findings — ranked issues with fixes |\n| Disposition | Rebuild clean; original not kept | Keep and fix in place |\n| Anonymization | Mandatory — no identity, PII, paths, symbols | N\u002FA — works in-repo |\n| Cost | Exhaustive by design; hundreds of K tokens | Bounded to the chosen concern |\n\n## Cost\n\nA full-system extraction is heavy multi-agent archaeology. Empirically, one full-system run on a mid-size repo produced a ~130k-word spec backed by ~11 wing dossiers, 5 adversarial reviews, and a full set of control ledgers — many subagents across several research waves. Budget accordingly. The scope dial and the Phase 0 gate keep that spend deliberate.\n\n## Scope dial\n\nThe first argument selects scope. All three scopes run the *same* method (`extraction-prompt.md`); scope only changes how much of the system is in scope — never how thoroughly the in-scope area is covered.\n\n| Scope | Covers | Use when |\n|---|---|---|\n| `full-system` (default) | Every wing + all cross-cutting seams | You need a complete rebuild blueprint |\n| `wing \u003Cname>` | One functional wing + its seams | You only need to rebuild or port one capability |\n| `targeted \u003Cscope>` | The specific flows\u002Fareas you name (quote multi-word scopes) | You need a bounded slice, e.g. `targeted \"auth + billing flows\"` |\n\n## Procedure\n\n### Phase 0 — scope & cost pre-flight\n\n`\u003CHARD-GATE>` — do this before loading the method or launching any subagent.\n\n1. Parse args: scope (default `full-system`), `--budget \u003Ctokens>`, `--depth` (default `standard`), `--out \u003Cpath>`. The default output name is scope-derived, written at the project root: FULL_SYSTEM_SPEC.md for full-system, WING-\u003Cname>-SPEC.md for a wing, TARGETED-SPEC.md for a targeted slice.\n2. Cheap, read-only size estimate — this is NOT the Phase 1 inventory yet:\n   - `git ls-files | wc -l` (fallback: `find . -type f` minus vendor\u002Fbuild dirs).\n   - Approximate LOC over source globs; count deployable units; get rough entry-point and persisted-entity counts; note languages\u002Fframeworks.\n3. Project the work and a cost band: estimated wings, subagents, research waves, deliverable size, and a rough token + wall-clock range — anchored to the reference run above and scaled by files \u002F LOC \u002F wings.\n4. **STOP and confirm** before launching when EITHER scope is `full-system` OR the projected cost exceeds `--budget` (or the default high-cost threshold). Present the estimate, the chosen scope, and the cheaper alternatives (narrow to `wing` \u002F `targeted`).\n   - If over `--budget`: narrow scope explicitly, or stop and ask. **Never** silently reduce in-scope coverage to fit a budget — the budget governs scope, not gate-completeness.\n5. Proceed only on explicit confirmation, or when the estimate is within `--budget` and scope is not `full-system`.\n\n### Phases 1–6 — run the method\n\nRead `extraction-prompt.md` in this skill directory and execute it faithfully as the orchestrator. Fill its template variables from Phase 0:\n\n- `{{PROJECT_ROOT}}` → the target repo root (default: cwd).\n- `{{OUTPUT_PATH}}` → `--out`.\n- `{{SCOPE_NOTES}}` → derived from the scope dial:\n  - `full-system` → none (inspect the full project).\n  - `wing \u003Cname>` → \"Restrict primary coverage to the '\u003Cname>' wing\u002Fcapability and the seams where it meets the rest of the system; classify the remainder as out-of-scope context, not a coverage target.\"\n  - `targeted \u003Cscope>` → the caller's scope notes verbatim, plus \"Treat everything outside this scope as out-of-scope context.\"\n\nThe method owns the rigor; do not weaken it — a complete inventory + coverage ledger (Phase 1 gate), a full dossier per wing (Phase 2), cross-cutting investigations across flows \u002F data \u002F rules \u002F interfaces \u002F runtime \u002F security \u002F tests \u002F UI (Phase 3), whole-system reconciliation (Phase 4), the standalone anonymized specification (Phase 5), and the fresh-reviewer adversarial panel — coverage, reconstruction, flexibility, privacy, consistency (Phase 6).\n\n`--depth exhaustive` adds extra reconciliation + re-verification waves and a second privacy re-scan; it never removes gates. `standard` runs every gate once.\n\n### Phase 7 — verify gates & report\n\n1. Confirm every applicable completion gate in the method passed — or the deliverable is honestly marked **Incomplete Specification** with the blocked gates named.\n2. Confirm the final Markdown exists at `--out`, that the Phase 6 privacy gate passed (plus the exhaustive re-scan if `--depth exhaustive`), and that it contains all required sections.\n3. Report: output path, gate pass\u002Ffail, anonymized coverage totals, and the count of unresolved known unknowns. No project-identifying details.\n\n## Rules\n\n- **Read-only on the target.** The only writes are scratch research artifacts (in a private directory made with `mktemp -d`) and the final Markdown. Never mutate source, config, schemas, data, or external systems.\n- **Coverage, not length.** Completion is gate-based. Context pressure means subdivide into another wave — never omit scope.\n- **Hard anonymization.** The deliverable carries no PII, secrets, identity, source paths, symbols, or repo metadata. The private alias ledger is scratch — never shipped with the spec.\n- **Never fabricate.** Uncertain or contradictory behavior is labeled, not invented.\n\n## Red flags — you are rationalizing\n\n| Thought | Reality |\n|---|---|\n| \"Just run full-system, it'll be fine.\" | It's the most expensive path. Confirm the Phase 0 estimate first, or narrow scope. |\n| \"I'm over budget but close — I'll just trim a wing.\" | The budget governs scope, not coverage. Narrow scope explicitly or stop; never silently drop an in-scope wing. || \"I found bugs; I'll note them in the spec.\" | That's `\u002Fclaudna:audit`. The spec describes required behavior, not defects to fix. |\n| \"The docs describe it, so I can skip the code.\" | Documentation is a lead, not truth. Load-bearing claims come from inspected source. |\n","# Extract System Spec\n\n> **Codex:** Read `..\u002F_shared\u002Fcodex-tools.md` before following this skill. Apply its tool, root and dispatch mappings throughout.\n\nProduce a single, standalone, anonymized Markdown specification from which a capable team could rebuild a system from scratch — without the original repo. Orchestrator + subagents; coverage-gated; hard-anonymized; adversarially reviewed. The full 6-phase method lives in `extraction-prompt.md` in this skill directory; this file governs *when* to run it, at *what scope*, and at *what cost*.\n\n## When to use this — and when NOT\n\n**Use when** the payoff of a portable rebuild blueprint justifies a large, deliberate token spend:\n- Porting \u002F re-platforming a system to a new stack or new owner.\n- A vendor-neutral or anonymized spec of a proprietary or legacy system (due diligence, handoff, escrow, disaster-recovery documentation).\n- Rebuilding a system cleanly while preserving its exact behavior, data semantics, and contracts.\n\n**Do NOT use for** — cheaper tools exist:\n- Finding problems in a system you are keeping → `\u002Fclaudna:audit` (see the table below).\n- Understanding one module or orienting quickly → read it, or `\u002Fclaudna:recall`.\n- Documenting a small or simple project → just write the docs.\n- Casual curiosity. Reserve this for a genuine rebuild need.\n\n### Not \u002Fclaudna:audit\n\nSame deep-recon technique, opposite purpose:\n\n| | extract-system-spec | \u002Fclaudna:audit |\n|---|---|---|\n| Question | \"How do I rebuild this elsewhere?\" | \"What is wrong with this?\" |\n| Output | A portable, anonymized reconstruction spec | Findings — ranked issues with fixes |\n| Disposition | Rebuild clean; original not kept | Keep and fix in place |\n| Anonymization | Mandatory — no identity, PII, paths, symbols | N\u002FA — works in-repo |\n| Cost | Exhaustive by design; hundreds of K tokens | Bounded to the chosen concern |\n\n## Cost\n\nA full-system extraction is heavy multi-agent archaeology. Empirically, one full-system run on a mid-size repo produced a ~130k-word spec backed by ~11 wing dossiers, 5 adversarial reviews, and a full set of control ledgers — many subagents across several research waves. Budget accordingly. The scope dial and the Phase 0 gate keep that spend deliberate.\n\n## Scope dial\n\nThe first argument selects scope. All three scopes run the *same* method (`extraction-prompt.md`); scope only changes how much of the system is in scope — never how thoroughly the in-scope area is covered.\n\n| Scope | Covers | Use when |\n|---|---|---|\n| `full-system` (default) | Every wing + all cross-cutting seams | You need a complete rebuild blueprint |\n| `wing \u003Cname>` | One functional wing + its seams | You only need to rebuild or port one capability |\n| `targeted \u003Cscope>` | The specific flows\u002Fareas you name (quote multi-word scopes) | You need a bounded slice, e.g. `targeted \"auth + billing flows\"` |\n\n## Procedure\n\n### Phase 0 — scope & cost pre-flight\n\n`\u003CHARD-GATE>` — do this before loading the method or launching any subagent.\n\n1. Parse args: scope (default `full-system`), `--budget \u003Ctokens>`, `--depth` (default `standard`), `--out \u003Cpath>`. The default output name is scope-derived, written at the project root: FULL_SYSTEM_SPEC.md for full-system, WING-\u003Cname>-SPEC.md for a wing, TARGETED-SPEC.md for a targeted slice.\n2. Cheap, read-only size estimate — this is NOT the Phase 1 inventory yet:\n   - `git ls-files | wc -l` (fallback: `find . -type f` minus vendor\u002Fbuild dirs).\n   - Approximate LOC over source globs; count deployable units; get rough entry-point and persisted-entity counts; note languages\u002Fframeworks.\n3. Project the work and a cost band: estimated wings, subagents, research waves, deliverable size, and a rough token + wall-clock range — anchored to the reference run above and scaled by files \u002F LOC \u002F wings.\n4. **STOP and confirm** before launching when EITHER scope is `full-system` OR the projected cost exceeds `--budget` (or the default high-cost threshold). Present the estimate, the chosen scope, and the cheaper alternatives (narrow to `wing` \u002F `targeted`).\n   - If over `--budget`: narrow scope explicitly, or stop and ask. **Never** silently reduce in-scope coverage to fit a budget — the budget governs scope, not gate-completeness.\n5. Proceed only on explicit confirmation, or when the estimate is within `--budget` and scope is not `full-system`.\n\n### Phases 1–6 — run the method\n\nRead `extraction-prompt.md` in this skill directory and execute it faithfully as the orchestrator. Fill its template variables from Phase 0:\n\n- `{{PROJECT_ROOT}}` → the target repo root (default: cwd).\n- `{{OUTPUT_PATH}}` → `--out`.\n- `{{SCOPE_NOTES}}` → derived from the scope dial:\n  - `full-system` → none (inspect the full project).\n  - `wing \u003Cname>` → \"Restrict primary coverage to the '\u003Cname>' wing\u002Fcapability and the seams where it meets the rest of the system; classify the remainder as out-of-scope context, not a coverage target.\"\n  - `targeted \u003Cscope>` → the caller's scope notes verbatim, plus \"Treat everything outside this scope as out-of-scope context.\"\n\nThe method owns the rigor; do not weaken it — a complete inventory + coverage ledger (Phase 1 gate), a full dossier per wing (Phase 2), cross-cutting investigations across flows \u002F data \u002F rules \u002F interfaces \u002F runtime \u002F security \u002F tests \u002F UI (Phase 3), whole-system reconciliation (Phase 4), the standalone anonymized specification (Phase 5), and the fresh-reviewer adversarial panel — coverage, reconstruction, flexibility, privacy, consistency (Phase 6).\n\n`--depth exhaustive` adds extra reconciliation + re-verification waves and a second privacy re-scan; it never removes gates. `standard` runs every gate once.\n\n### Phase 7 — verify gates & report\n\n1. Confirm every applicable completion gate in the method passed — or the deliverable is honestly marked **Incomplete Specification** with the blocked gates named.\n2. Confirm the final Markdown exists at `--out`, that the Phase 6 privacy gate passed (plus the exhaustive re-scan if `--depth exhaustive`), and that it contains all required sections.\n3. Report: output path, gate pass\u002Ffail, anonymized coverage totals, and the count of unresolved known unknowns. No project-identifying details.\n\n## Rules\n\n- **Read-only on the target.** The only writes are scratch research artifacts (in a private directory made with `mktemp -d`) and the final Markdown. Never mutate source, config, schemas, data, or external systems.\n- **Coverage, not length.** Completion is gate-based. Context pressure means subdivide into another wave — never omit scope.\n- **Hard anonymization.** The deliverable carries no PII, secrets, identity, source paths, symbols, or repo metadata. The private alias ledger is scratch — never shipped with the spec.\n- **Never fabricate.** Uncertain or contradictory behavior is labeled, not invented.\n\n## Red flags — you are rationalizing\n\n| Thought | Reality |\n|---|---|\n| \"Just run full-system, it'll be fine.\" | It's the most expensive path. Confirm the Phase 0 estimate first, or narrow scope. |\n| \"I'm over budget but close — I'll just trim a wing.\" | The budget governs scope, not coverage. Narrow scope explicitly or stop; never silently drop an in-scope wing. || \"I found bugs; I'll note them in the spec.\" | That's `\u002Fclaudna:audit`. The spec describes required behavior, not defects to fix. |\n| \"The docs describe it, so I can skip the code.\" | Documentation is a lead, not truth. Load-bearing claims come from inspected source. |\n",{"name":5,"description":7,"argument-hint":43,"user-invocable":44},"[full-system | wing \u003Cname> | targeted \u003Cscope>] [--budget \u003Ctokens>] [--depth standard|exhaustive] [--out \u003Cpath>]",true,"main","fc776f04574726e261087dbb521c1831bf0ea9d5","skills\u002Fextract-system-spec",1,"https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA","https:\u002F\u002Fgithub.com\u002FClaudfather","https:\u002F\u002Fcrog.gg","Rise of the machines","2026-11-12 04:46:22",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":44},[56,59,62],{"tool":57,"command":58},"npx","npx skills add Claudfather\u002FclauDNA --skill extract-system-spec",{"tool":60,"command":61},"bunx","bunx skills add Claudfather\u002FclauDNA --skill extract-system-spec",{"tool":63,"command":64},"pnpm","pnpm dlx skills add Claudfather\u002FclauDNA --skill extract-system-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fextract-system-spec\u002FSKILL.md",[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"extraction-prompt.md","REFERENCE","参考文档",35633,"https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fextract-system-spec\u002Fextraction-prompt.md",[74,98,108,131,156,172],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":38},"01M71T1STJ99BE1C0JYHCQW0XN","example-review","Use when you want to review pull requests with detailed, actionable feedback on code quality, correctness, and maintainability.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fvalid-package\u002FSKILL.md",[],[81,82,83,84,85,86,87,88,89,23,24,26,90,91,92,93,94,95,96,97],"review","example","example review","actionable","pull requests","with","code","correctness","Bash","gh","gh pr","diff","view","pr","code quality","feedback","pull",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":38},"01M71T1RMCD30MAJC954JC7580","bad-skill","Too short","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Ffailing-package\u002FSKILL.md",[],[105,106,107],"bad","bad skill","short",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":38},"01M71T1NS97NJ2MQ993V7FBES7","worktree","Use when starting feature work that needs isolation from the current workspace, or when running multiple Claude sessions in parallel on different branches — creates and manages git worktrees. For fetching latest main into every existing worktree and branch across your sibling repos, use \u002Fclaudna:sync-branches instead.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fworktree\u002FSKILL.md",[],[110,115,116,117,118,119,120,121,122,123,124,125,24,126,45,127,128,129,35,130],"sync","repos","git","isolation","running","sessions","worktrees","work","across","needs","git worktrees","claude sessions","branches","branch","parallel","feature",{"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":137,"publishedAt":38},"01M71T1HNVG1CZY8P904P6RB7P","weigh-development-paths","Use when at a development junction with multiple viable approaches — architecture choices, refactoring strategies, where to put new code, or which pattern to follow. Triggers on 'which approach', 'how should I', 'Option A vs B', or any point where the next step isn't obvious and the wrong choice creates rework.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fweigh-development-paths\u002FSKILL.md",[],[138,139,140,141,142,143,144,145,146,147,148,149,150,87,24,151,152,153,154,155],"development","weigh development paths","paths","next step","path","refactoring","choice","pattern","at","how","next","strategies","architecture","auto","new","junction","option","which",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":38},"01M71T1ECV1T5E168GH70AY5B3","verify-completion","Use when about to claim work is complete, fixed, or passing -- requires running verification commands and confirming output before making any success claims.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fverify-completion\u002FSKILL.md",[],[163,164,165,166,119,29,167,168,122,169,170,171,24,26],"verify completion","verify","claim","complete","commands","about","verification","claims","output",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":183,"publishedAt":38},"01M71T1BC1HA7XQH0Q1H574FYS","vercel","Use for Vercel operations — deploy to production or preview (or roll back), view, filter, or debug deployment logs, or check project status (deployments, domains, env vars, config). Replaces \u002Fvercel-deploy, \u002Fvercel-logs, \u002Fvercel-status.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fvercel\u002FSKILL.md",[178],{"categoryNo":179,"categoryName":180,"taxonomyType":181,"taxonomyTypeDesc":182},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[174,184,185,186,187,188,189,190,191,26,192,29,193,194,195,196,35,93,197,198],"inspection","check","filter","env","logs","preview","debug deployment","debug","deployments","domains","deployment","env vars","project","project status","back"]