[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GXJZW20M0PSZDEMP9ZF179":3,"skill-same:01M6GXJZW20M0PSZDEMP9ZF179":82},{"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":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":55,"ownerDescription":57,"updatedAt":58,"install":59,"resources":71},"01M6GXJZW20M0PSZDEMP9ZF179","autopilot",null,"Intake-to-delivery pipeline. Processes pending items from .planning\u002Fintake\u002F: briefs new ideas, executes approved work through research → plan → build → verify. Drop a file in .planning\u002Fintake\u002F and invoke this skill.","SethGammon\u002FCitadel","SethGammon","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5523585?v=4","01M6GXJ90FD2CE9QF5GQERWN06","Seth Gammon","01M6GXJ94VXYGK5KAW14EYE901",931,"MIT","https:\u002F\u002Fgithub.com\u002FSethGammon\u002FCitadel\u002Fblob\u002Fmain\u002Fskills\u002Fautopilot\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"build","true","briefs","processes","false","ideas","delivery","drop","research","process","work","plan","verify","pipeline","file","intake","planning","2026-11-10 10:12:30",false,"---\nname: autopilot\nlicense: MIT\ndescription: >-\n  Intake-to-delivery pipeline. Processes pending items from .planning\u002Fintake\u002F:\n  briefs new ideas, executes approved work through research → plan → build → verify.\n  Drop a file in .planning\u002Fintake\u002F and invoke this skill.\nuser-invocable: true\nauto-trigger: false\ntrigger_keywords:\n  - intake\n  - process pending\n  - pipeline\nlast-updated: 2026-03-20\n---\n\n# \u002Fautopilot — Intake Pipeline\n\n## Orientation\n\nUse Autopilot when:\n- There are pending items in `.planning\u002Fintake\u002F`\n- You want to process intake items without manual orchestration\n- The work is scoped and well-defined (Small or Medium complexity)\n\nDo NOT use Autopilot for:\n- Large, multi-session campaigns (use Archon)\n- Parallel execution (use Fleet)\n- Exploratory or open-ended work (use Marshal)\n\n## Protocol\n\n### Step 0: DELIVERY PREFLIGHT\n\nWhen the user names a specific intake file or asks for \"intake to PR\", prefer\nthe deterministic delivery preflight before freeform build work:\n\n```bash\nnode scripts\u002Fdeliver.js --intake .planning\u002Fintake\u002F{item}.md\n```\n\nIf no specific intake file is named, use:\n\n```\nnode scripts\u002Fdeliver.js --next\n```\n\nThis selects the highest-priority pending item in `.planning\u002Fintake\u002F` and keeps\nthe golden path deterministic.\n\nThis creates an active campaign with claimed scope, acceptance criteria, map\ncontext, and exit evidence rows, then marks the intake item `in-progress`.\nContinue from the created campaign with `\u002Fdo continue`.\n\nAfter build and verification, package the delivery before marking the campaign\ncomplete:\n\n```bash\nnode scripts\u002Fpackage-delivery.js {campaign-slug}\n```\n\nIf a PR exists, record the PR as the review target:\n\n```bash\nnode scripts\u002Fpackage-delivery.js {campaign-slug} --pr https:\u002F\u002Fgithub.com\u002F{owner}\u002F{repo}\u002Fpull\u002F{number}\n```\n\n### Step 1: SCAN\n\nRead all files in `.planning\u002Fintake\u002F` and identify:\n- `status: pending` → needs briefing\n- `status: briefed` → ready to build\n- `status: approved` → ready to build\n- `status: in-progress` → check if stuck\n\n### Step 2: BRIEF (for pending items)\n\nFor each pending item:\n\n1. Read the intake file\n2. Read related files mentioned in the description\n3. Research the scope: what files exist, what patterns are established\n4. Write the brief:\n   - **Scope**: Small \u002F Medium \u002F Large\n   - **Approach**: How to implement (2-3 sentences)\n   - **Files**: Which files to create or modify\n   - **Quality gates**: What must be true when done\n   - **Risks**: What could go wrong\n5. Update the item's status to `briefed`\n\n### Step 3: BUILD (for briefed\u002Fapproved items)\n\nFor each briefed item (smallest first):\n\n1. Read the brief\n2. Execute the approach:\n   - Create or modify the listed files\n   - Follow the project's conventions (CLAUDE.md)\n   - Run typecheck after each change\n3. Verify:\n   - All quality gates pass\n   - Typecheck clean\n   - Tests pass (if applicable)\n4. Update status to `completed`\n\n### Step 4: REPORT\n\nOutput a summary of what was processed:\n\n```\nAutopilot processed {N} items:\n  ✓ {item-1}: briefed → built → verified\n  ✓ {item-2}: briefed\n  ✗ {item-3}: blocked — {reason}\n```\n\n## Intake Item Format\n\n```markdown\n---\ntitle: \"Feature Name\"\nstatus: pending | briefed | approved | in-progress | completed\npriority: normal | high\ntarget: src\u002Fpath\u002Fto\u002Faffected\u002Farea\u002F\n---\n\nDescription of what needs to be done...\n```\n\n## Fringe Cases\n\n- **`.planning\u002Fintake\u002F` is empty or does not exist**: Output \"Nothing to process — `.planning\u002Fintake\u002F` is empty. Drop a file there or run `\u002Fdo setup` to initialize.\" Do not error.\n- **Intake item has no clear action**: If the description is too vague to execute, ask the user one clarifying question or skip the item with a note: \"Skipped — direction unclear. Update the intake file and re-run.\"\n- **Item status is unrecognized**: Treat unknown statuses as `pending` and proceed through the brief → build flow.\n- **Typecheck fails during build**: Record the failure in the item's status, move on to the next item, and report the blocker in the exit summary.\n- **`.planning\u002F` does not exist**: Output a setup hint and exit cleanly. Autopilot requires `.planning\u002Fintake\u002F` to operate — if the directory is absent, treat as empty intake and suggest running `\u002Fdo setup`.\n\n## Contextual Gates\n\n**Disclosure:** \"Processing intake queue: N items pending. Will dispatch skills per item.\"\n**Reversibility:** amber — processes intake items by dispatching other skills that may modify files; undo depends on dispatched skills\n**Trust gates:**\n- Any: review intake and briefing.\n- Familiar (5+ sessions): autopilot runs autonomously on queued items; novices should review intake before running.\n\n## Quality Gates\n\n- Never build without reading the project guidance (AGENTS.md, then CLAUDE.md) first\n- Run typecheck after every file change\n- Mark items as completed only when verification passes\n- If an item is blocked, record the reason and move on\n\n## Exit Protocol\n\n```\n---HANDOFF---\n- Processed {N} intake items\n- Built: {list of completed items}\n- Blocked: {list with reasons}\n- Remaining: {count of items still pending}\n---\n```\n","# \u002Fautopilot — Intake Pipeline\n\n## Orientation\n\nUse Autopilot when:\n- There are pending items in `.planning\u002Fintake\u002F`\n- You want to process intake items without manual orchestration\n- The work is scoped and well-defined (Small or Medium complexity)\n\nDo NOT use Autopilot for:\n- Large, multi-session campaigns (use Archon)\n- Parallel execution (use Fleet)\n- Exploratory or open-ended work (use Marshal)\n\n## Protocol\n\n### Step 0: DELIVERY PREFLIGHT\n\nWhen the user names a specific intake file or asks for \"intake to PR\", prefer\nthe deterministic delivery preflight before freeform build work:\n\n```bash\nnode scripts\u002Fdeliver.js --intake .planning\u002Fintake\u002F{item}.md\n```\n\nIf no specific intake file is named, use:\n\n```\nnode scripts\u002Fdeliver.js --next\n```\n\nThis selects the highest-priority pending item in `.planning\u002Fintake\u002F` and keeps\nthe golden path deterministic.\n\nThis creates an active campaign with claimed scope, acceptance criteria, map\ncontext, and exit evidence rows, then marks the intake item `in-progress`.\nContinue from the created campaign with `\u002Fdo continue`.\n\nAfter build and verification, package the delivery before marking the campaign\ncomplete:\n\n```bash\nnode scripts\u002Fpackage-delivery.js {campaign-slug}\n```\n\nIf a PR exists, record the PR as the review target:\n\n```bash\nnode scripts\u002Fpackage-delivery.js {campaign-slug} --pr https:\u002F\u002Fgithub.com\u002F{owner}\u002F{repo}\u002Fpull\u002F{number}\n```\n\n### Step 1: SCAN\n\nRead all files in `.planning\u002Fintake\u002F` and identify:\n- `status: pending` → needs briefing\n- `status: briefed` → ready to build\n- `status: approved` → ready to build\n- `status: in-progress` → check if stuck\n\n### Step 2: BRIEF (for pending items)\n\nFor each pending item:\n\n1. Read the intake file\n2. Read related files mentioned in the description\n3. Research the scope: what files exist, what patterns are established\n4. Write the brief:\n   - **Scope**: Small \u002F Medium \u002F Large\n   - **Approach**: How to implement (2-3 sentences)\n   - **Files**: Which files to create or modify\n   - **Quality gates**: What must be true when done\n   - **Risks**: What could go wrong\n5. Update the item's status to `briefed`\n\n### Step 3: BUILD (for briefed\u002Fapproved items)\n\nFor each briefed item (smallest first):\n\n1. Read the brief\n2. Execute the approach:\n   - Create or modify the listed files\n   - Follow the project's conventions (CLAUDE.md)\n   - Run typecheck after each change\n3. Verify:\n   - All quality gates pass\n   - Typecheck clean\n   - Tests pass (if applicable)\n4. Update status to `completed`\n\n### Step 4: REPORT\n\nOutput a summary of what was processed:\n\n```\nAutopilot processed {N} items:\n  ✓ {item-1}: briefed → built → verified\n  ✓ {item-2}: briefed\n  ✗ {item-3}: blocked — {reason}\n```\n\n## Intake Item Format\n\n```markdown\n---\ntitle: \"Feature Name\"\nstatus: pending | briefed | approved | in-progress | completed\npriority: normal | high\ntarget: src\u002Fpath\u002Fto\u002Faffected\u002Farea\u002F\n---\n\nDescription of what needs to be done...\n```\n\n## Fringe Cases\n\n- **`.planning\u002Fintake\u002F` is empty or does not exist**: Output \"Nothing to process — `.planning\u002Fintake\u002F` is empty. Drop a file there or run `\u002Fdo setup` to initialize.\" Do not error.\n- **Intake item has no clear action**: If the description is too vague to execute, ask the user one clarifying question or skip the item with a note: \"Skipped — direction unclear. Update the intake file and re-run.\"\n- **Item status is unrecognized**: Treat unknown statuses as `pending` and proceed through the brief → build flow.\n- **Typecheck fails during build**: Record the failure in the item's status, move on to the next item, and report the blocker in the exit summary.\n- **`.planning\u002F` does not exist**: Output a setup hint and exit cleanly. Autopilot requires `.planning\u002Fintake\u002F` to operate — if the directory is absent, treat as empty intake and suggest running `\u002Fdo setup`.\n\n## Contextual Gates\n\n**Disclosure:** \"Processing intake queue: N items pending. Will dispatch skills per item.\"\n**Reversibility:** amber — processes intake items by dispatching other skills that may modify files; undo depends on dispatched skills\n**Trust gates:**\n- Any: review intake and briefing.\n- Familiar (5+ sessions): autopilot runs autonomously on queued items; novices should review intake before running.\n\n## Quality Gates\n\n- Never build without reading the project guidance (AGENTS.md, then CLAUDE.md) first\n- Run typecheck after every file change\n- Mark items as completed only when verification passes\n- If an item is blocked, record the reason and move on\n\n## Exit Protocol\n\n```\n---HANDOFF---\n- Processed {N} intake items\n- Built: {list of completed items}\n- Blocked: {list with reasons}\n- Remaining: {count of items still pending}\n---\n```\n",{"name":5,"license":15,"description":7,"auto-trigger":42,"last-updated":46,"user-invocable":47,"trigger_keywords":48},1773964800000,true,[39,49,37],"process pending","main","e1a3d45697a0f323aaedcbea0ab6a0387b5fe722","skills\u002Fautopilot",84,"https:\u002F\u002Fgithub.com\u002FSethGammon\u002FCitadel","https:\u002F\u002Fsethgammon.github.io\u002FCitadel\u002F","https:\u002F\u002Fgithub.com\u002FSethGammon","Building Citadel, the repo-local operating layer for Claude Code and Codex. Persistent work, routing, verification, and coordinated agent fleets.","2026-11-13 02:05:13",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":47},[61,64,67],{"tool":62,"command":63},"npx","npx skills add SethGammon\u002FCitadel --skill autopilot",{"tool":65,"command":66},"bunx","bunx skills add SethGammon\u002FCitadel --skill autopilot",{"tool":68,"command":69},"pnpm","pnpm dlx skills add SethGammon\u002FCitadel --skill autopilot","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSethGammon\u002FCitadel\u002Fblob\u002Fmain\u002Fskills\u002Fautopilot\u002FSKILL.md",[72,78],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"__benchmarks__\u002Fbriefed-item-build.md","REFERENCE","参考文档",924,"https:\u002F\u002Fgithub.com\u002FSethGammon\u002FCitadel\u002Fblob\u002Fmain\u002Fskills\u002Fautopilot\u002F__benchmarks__\u002Fbriefed-item-build.md",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"__benchmarks__\u002Fempty-intake.md",907,"https:\u002F\u002Fgithub.com\u002FSethGammon\u002FCitadel\u002Fblob\u002Fmain\u002Fskills\u002Fautopilot\u002F__benchmarks__\u002Fempty-intake.md",[83,107,134,158,182,200],{"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":89,"publishedAt":41},"01M6GXSBKE9A2HQWF8QRAZ4WJ5","workspace","Multi-repo campaign coordinator. Same lifecycle as fleet -- scope claims, discovery relay, wave-based execution -- but the unit of work is a repo, not a file. Coordinates campaigns across repositories with shared context.","https:\u002F\u002Fgithub.com\u002FSethGammon\u002FCitadel\u002Fblob\u002Fmain\u002Fskills\u002Fworkspace\u002FSKILL.md",[],[85,90,91,92,34,93,94,95,96,97,98,99,100,28,101,102,103,104,105,106],"repos","snowflake","multi-repo","context","campaign","coordinate","but","across","campaigns","shared","as","scope","add","unit","coordinator","fleet","claims",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":116,"publishedAt":41},"01M6GXS873AD1Y6RTM6GV47F3E","wiki","Markdown-first knowledge base where the LLM acts as librarian. Ingests raw sources, compiles and interlinks topic files, self-maintains an index. No vector DB or embeddings required -- uses LLM-native navigation over structured markdown up to ~400K words.","https:\u002F\u002Fgithub.com\u002FSethGammon\u002FCitadel\u002Fblob\u002Fmain\u002Fskills\u002Fwiki\u002FSKILL.md",[113],{"categoryNo":114,"categoryName":115,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[109,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,100,28,132,133],"vector","embeddings","librarian","markdown","knowledge","karpathy","knowledge management","karpathy wiki","up","files","maintain","self","knowledge base","project","db","sources","native",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":41},"01M6GXS2840SJ61285SZ43EJC3","watch","File sentinel that monitors the working directory for changes and marker comments, then auto-triggers appropriate skills. Poll-based via git diff against the last scan commit. Writes intake items for batch processing and routes marker actions through \u002Fdo. Use for automatic reactions to file changes; do NOT use for one-off inspection or tasks needing human judgment per file.","https:\u002F\u002Fgithub.com\u002FSethGammon\u002FCitadel\u002Fblob\u002Fmain\u002Fskills\u002Fwatch\u002FSKILL.md",[],[136,141,142,143,144,145,146,147,148,149,150,151,126,152,153,154,155,156,28,157],"directory","commit","tasks","git","batch","actions","start","sentinel","diff","auto","stop","do","scan","human","judgment","reactions","processing",{"skillNo":159,"name":36,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":166,"publishedAt":41},"01M6GXRXHYJ5RD9RZP81S2VFSW","Self-test the Citadel hook pipeline from within a live session. Exercises real tool calls (Write, Edit, Bash, Read) and checks that hooks fired, telemetry accumulated, and no errors occurred. Reports HOOK HEALTH: PASS or HOOK HEALTH: FAIL with a per-hook breakdown.","https:\u002F\u002Fgithub.com\u002FSethGammon\u002FCitadel\u002Fblob\u002Fmain\u002Fskills\u002Fverify\u002FSKILL.md",[163],{"categoryNo":164,"categoryName":165,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[36,167,168,169,37,170,171,172,173,174,175,176,177,128,178,28,179,180,181,25],"citadel","telemetry","harness","Bash","tool","read","write","edit","session","hooks","reports","live","hook","errors","calls",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":41},"01M6GXRS9MCJFMQZ917H2XH3AC","unharness","Safely leave Citadel using the active adoption receipt. Produces a no-write, reviewable plan, preserves a portable archive, removes only exact owned material, and reports modified or externally registered surfaces as retained or unknown. Legacy installs must be imported before exact leave is claimed.","https:\u002F\u002Fgithub.com\u002FSethGammon\u002FCitadel\u002Fblob\u002Fmain\u002Fskills\u002Funharness\u002FSKILL.md",[],[184,189,167,169,190,35,191,192,193,125,177,194,195,196,197,198,100,28,199,25],"uninstall","adoption","archive","remove","only","Legacy","surfaces","clean","imported","active","material",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":214,"publishedAt":41},"01M6GXRMEJ2VHD43R9FNPD4910","triage","GitHub issue and PR investigator. Pulls open issues\u002FPRs, classifies them, searches the codebase for root cause or reviews contributed code, proposes fixes with file:line references, and optionally implements fixes. Use for investigating GitHub issues and reviewing PRs; do NOT use for general code review unrelated to GitHub issues.","https:\u002F\u002Fgithub.com\u002FSethGammon\u002FCitadel\u002Fblob\u002Fmain\u002Fskills\u002Ftriage\u002FSKILL.md",[206,209],{"categoryNo":207,"categoryName":208,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":210,"categoryName":211,"taxonomyType":212,"taxonomyTypeDesc":213},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[202,215,216,217,218,219,220,221,222,223,224,225,226,227,152,28,228,229,230,25],"code review","review","review pr","pr","code","github issues","issues","open","use","unrelated","issue","general","references","line","investigator","reviews"]