[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D9CMR9W4G0XWEF3PBYN825":3,"skill-same:01M6D9CMR9W4G0XWEF3PBYN825":75},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6D9CMR9W4G0XWEF3PBYN825","ship",null,"Ship current work (update docs, commit, push, deploy) and optionally plan the next step","GeorgeQLe\u002Fagentic-skills","GeorgeQLe","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F21134126?v=4","01M6D2JP418S0VGJGF8M93EC3H","George Le","01M6D2JPBAKYD82TA5FS6HKQ3D",1,"MIT","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fexec-loop\u002Fclaude\u002Fship\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"docs","commit","deploy","update","shipping","push","save","plan","work","orchestrator","v0","update docs","conversation","next","2026-11-10 10:12:30",false,"---\nname: ship\ndescription: Ship current work (update docs, commit, push, deploy) and optionally plan the next step\ntype: shipping\nversion: v0.12\nargument-hint: \"[--no-plan] [--no-deploy] [--save-conversation] [--save-all-conversations]\"\ninvocation: orchestrator\n---\n\n# Ship\n\nShip current work, commit, push, deploy, and plan the next step. If `$ARGUMENTS` contains `--no-plan`, skip planning. If `$ARGUMENTS` contains `--no-deploy`, skip deployment. If `$ARGUMENTS` contains `--save-conversation`, save the current conversation to `conversations\u002F`. If `$ARGUMENTS` contains `--save-all-conversations`, export all past conversations to `conversations\u002F`.\n\n## Process\n\n### 1. Check if there's anything to ship\nRun `git status` and `git diff --stat`.\n- If the working tree is clean AND there are no unpushed commits: skip to step 3 (or stop if `--no-plan`).\n- If there are changes: continue to step 2.\n\n### 1b. Pre-ship error check\nBefore shipping, check for pre-existing errors so they get fixed and included in this step's commit.\n\na) **Check conversation context first.** If lint, typecheck, or test output already exists in the current session (e.g., from a TDD run step or plan-mode execution), use that output. Do NOT re-run commands whose results are already available.\n\nb) **Run only what's missing.** For any validation category (lint, typecheck, tests) that was NOT already run this session, find and run the project's commands. Check these sources:\n   - `CLAUDE.md` — look for lint, typecheck, or test commands\n   - `Makefile` \u002F `Justfile` — look for `check`, `lint`, `typecheck`, `test` targets\n   - `package.json` — look for `lint`, `typecheck`, `check`, `test` scripts\n   - `pyproject.toml` \u002F `setup.cfg` — look for tool configs (ruff, mypy, pytest)\n   - `Cargo.toml` — `cargo check`, `cargo clippy`\n   - If no validation commands are found and no prior output exists, skip this step.\n\nc) **Fix errors.** If any pre-existing errors are found (from prior session output or fresh runs):\n   - Fix them.\n   - Re-run only the previously-failing commands to confirm the fixes.\n   - These fixes will be committed alongside the current work in step 2d (or as a separate commit if the fixes are unrelated to the current feature).\n\nd) **If errors can't be auto-fixed** (e.g., requires user decision, third-party dependency issue), **STOP. Do not ship.** Report the errors clearly to the user and ask how they want to proceed. Never commit or push code with known build\u002Flint\u002Ftype\u002Ftest failures.\n\n### 1c. Quality gate for non-trivial mutations\n   - Apply `docs\u002Fquality-gate-contract.md` when the work to ship changes source code, scripts, configuration, schemas, generated runtime assets, deploy behavior, workflow policy, validation rules, command surfaces, or multiple files.\n   - Build a ship manifest from the exact diff and unpushed commits that will be included in the shipping boundary. The manifest must include: User goal, Changed files, Per-file purpose, User-goal mapping, Tests run, Skipped tests, Adversarial review, Residual risk, Rollback note, and Next command. The `Next command` field must use Claude slash-command syntax; for a completed `\u002Fship` run, default to `\u002Fexec` unless project state names a more specific next route. Do not leave `Next command` blank unless all planned work is genuinely complete, in which case use `none`.\n   - For non-trivial source changes, run a targeted `quality-sweep audit`, `\u002Fcode-review`, configured review lane, or explicitly justified equivalent adversarial review before commit\u002Fpush. Fix findings or record accepted residual concerns in the manifest.\n   - Final output must distinguish executable verification from documentation-only or task-only checks. Documentation\u002Ftask checks can support source changes, but cannot be the only proof for non-trivial source mutations.\n   - If the tree contains unrelated pre-existing changes, the manifest must separate included files from untouched files and explain why the ship boundary is safe. If that cannot be proven, stop instead of shipping.\n   - **Pack install artifact boundary:** Treat `.agents\u002Fproject.json` as the committed project designation. When pack configuration changed, include `.agents\u002Fproject.json` in the shipping boundary. Treat `.claude\u002Fskills\u002F**` and `.codex\u002Fskills\u002F**` as generated local skill roots recreated by `scripts\u002Fpack.sh refresh`; generated skill roots must not be staged or committed. If those roots are untracked, leave them uncommitted and report them as generated local artifacts. If any path under those roots is already tracked or modified as a tracked file, stop unless the current task explicitly includes repository hygiene to untrack or ignore generated skill roots.\n   - If the user corrected the agent during the work being shipped, the pre-commit ship manifest must prove the exact shipping boundary includes a `tasks\u002Flessons.md` update for the current correction. Treat the correction as repeatable unless the manifest proves otherwise.\n\n### 1d. Public Skills Catalog Freshness\nIf the shipping boundary creates, deletes, renames, or changes behavior\u002Fmetadata in any tracked `SKILL.md` or `PACK.md`, refresh the public skills catalog export before commit:\n\n- `node scripts\u002Fgenerate-skills-catalog-export.mjs`\n- `scripts\u002Fvalidate-skills-catalog-export.sh`\n\nInclude changed `exports\u002Fskills-catalog\u002Fv1\u002F**` artifacts in the same shipping boundary. The Skills Showcase lives in the separate `agentic-skills-showcase` repository and imports this public export; do not run Showcase app generators, Next.js builds, or website asset refreshes during normal `agentic-skills` shipping. If a skill change needs curated website copy, record the follow-up for the Showcase repo instead of editing app files here.\n\n### 1e. Ship manifest route convention\nWhen writing a ship manifest, summary, task review note, or final response with a `Next command` field, use Claude slash-command syntax. For a completed `\u002Fship` run, the default executable handoff is `\u002Fexec` unless project state names a more specific next route. Do not leave `Next command` blank unless all planned work is genuinely complete, in which case use `none`.\n\n### 2. Ship the work\na) Read the project's CLAUDE.md to understand current progress.\nb) Update `tasks\u002Ftodo.md` — mark completed items as done (check off steps and milestone criteria).\nc) Update `tasks\u002Fhistory.md` — append a brief record of what was accomplished this session (phase\u002Fstep completed, key changes). Create it if it doesn't exist.\nd) If `tasks\u002Ftodo.md`, `tasks\u002Froadmap.md`, `tasks\u002Fmanual-todo.md`, `tasks\u002Frecord-todo.md`, or `tasks\u002Frecurring-todo.md` changed and `scripts\u002Faudit-task-docs.mjs` exists, run `node scripts\u002Faudit-task-docs.mjs` and fix any failures before final next-work routing.\ne) **Save conversation (skip if `--save-conversation` and `--save-all-conversations` both absent):**\n   Run `scripts\u002Fsave-conversation.sh` to export the current Claude Code conversation as a markdown file in `conversations\u002F`. If the script is not found or fails (e.g., not running in Claude Code, no local conversation history), warn and continue — do not block shipping. Include the generated file in the shipping boundary.\n   - If `$ARGUMENTS` contains `--save-all-conversations`, run `scripts\u002Fsave-conversation.sh --all` instead.\n\nf) Ship the changes using the `\u002Fcommit-and-push-by-feature` compatibility workflow and `docs\u002Fgithub-delivery-contract.md`:\n   - Group changes into logical feature\u002Ffunction buckets.\n   - Use conventional commit messages.\n   - Ensure or reuse the linked issue and issue-backed non-primary branch before committing.\n   - Publish the branch and create or update one ready pull request; do not merge it.\n\n### 3. Deploy (skip if `--no-deploy`)\n\nIf the ready pull request is not merged into the current primary branch, defer deployment and route to explicit review\u002F`github-pr merge`. Never deploy development state from the work branch.\nAfter shipping, deploy only when the project has an explicit manual deploy contract.\n\na) **Check for deploy contract.** Look for `deploy.md` or `tasks\u002Fdeploy.md`.\n   - If neither file exists, skip deploy and report `Deploy skipped: no explicit manual deploy contract (deploy.md or tasks\u002Fdeploy.md)`.\n   - If a deploy contract exists, continue.\n\nb) **Invoke `\u002Fdeploy`** (release-ops pack) targeting the default environment (staging).\n   - Pass the deploy contract context to `\u002Fdeploy` (release-ops pack).\n   - Skip ledger recording and staleness reporting — those are for standalone `\u002Fdeploy` (release-ops pack) invocations only.\n   - If `\u002Fdeploy` (release-ops pack) reports failure, report the error. Do not retry.\n\n### 4. Plan the next step (skip if `--no-plan`)\n\n**Prerequisite:** If neither `tasks\u002Ftodo.md` nor `tasks\u002Froadmap.md` exists, or if no uncompleted steps remain, there is no plan to continue. Run `\u002Froadmap` to scan task pipeline health and recommend the next context-aware action (stale todo, missing steps, etc.). Then stop (do not enter plan mode).\n\na) **Migration check:** If `tasks\u002Froadmap.md` does not exist but `tasks\u002Ftodo.md` contains multiple `## Phase` headers, migrate: copy `tasks\u002Ftodo.md` → `tasks\u002Froadmap.md`, then trim `tasks\u002Ftodo.md` to just the current phase (first phase with unchecked steps). Commit with `chore: migrate to roadmap.md + todo.md split`.\nb) Read only the current active task\u002Fphase in `tasks\u002Ftodo.md` to identify the next uncompleted step. Do not select unchecked boxes from completed sections, historical roadmap notes, reconciliation reports, manual\u002Frecord\u002Frecurring advisory files, or any roadmap section not explicitly promoted into the current todo surface.\nb2) If `tasks\u002Frecord-todo.md` or `tasks\u002Frecurring-todo.md` exists, count unchecked advisory items for status only. Do not select them as next work.\nc) **Check if the current phase is complete** (all steps checked, milestone criteria met):\n   - If **YES — Phase transition:**\n     1. Archive the completed phase: copy `tasks\u002Ftodo.md` → `tasks\u002Fphases\u002Fphase-N.md` (create `tasks\u002Fphases\u002F` if needed). Fill in the \"On Completion\" section.\n     1b. If `tasks\u002Fmanual-todo.md` exists, inspect unchecked items before advancing phases:\n         - If any unchecked `_(blocks: Step N.X)_` items still apply to the completed phase, stop. Do NOT archive the manual task file, mark the phase complete, or advance to the next phase unless the user explicitly overrides the blocker.\n         - Unchecked `_(after: Step N.X)_` items are non-blocking follow-up tasks. Archive them with the phase and warn the user that they remain incomplete.\n     2. Check off the phase milestone in `tasks\u002Froadmap.md`.\n     3. Copy the next phase from `tasks\u002Froadmap.md` → overwrite `tasks\u002Ftodo.md`.\n     3b. Extract the next phase's manual tasks (from `**Manual Tasks:**` in `tasks\u002Froadmap.md`) into a fresh `tasks\u002Fmanual-todo.md`. If the next phase has no manual tasks, delete `tasks\u002Fmanual-todo.md` if it exists.\n     4. If no more phases remain, run `\u002Froadmap` to recommend the next action based on project state. Then stop (do not enter plan mode).\n     5. **Just-in-time planning:** **You MUST invoke `\u002Fplan-phase` for the new phase** — do NOT tell the user the phase is \"deferred\" or ask them to run `\u002Fplan-phase` manually. A phase without implementation steps is NOT deferred; it simply hasn't been decomposed yet (only items under the `## Deferred \u002F Future Work` heading in the roadmap are actually deferred). This auto-invocation generates implementation steps, the phase `### Execution Profile`, and file-level detail using the full context of what was learned during prior phases. The roadmap only stores strategic outlines — implementation detail is generated when a phase is started, not upfront.\n   - If **NO:** find the next uncompleted step within the current phase.\nd0) **Skip no-op verification handoffs:** If the next uncompleted step is verification-only\u002Fno-op-only (for example, \"refactor if validation exposes drift\", \"verify\", \"run validation\", or `Files: no source changes expected`) and the current session already has passing validation evidence for the same scope, do not write a clear-context plan for it. Mark the step complete in `tasks\u002Ftodo.md`, record the no-op result in the review\u002Fhistory, ship those task-doc updates, then continue selecting the next substantive step. If verification found failures, drift, warnings needing judgment, or source edits are required, treat that remediation as substantive work and plan it normally.\nd) Write a **self-contained** implementation plan for the next step into `tasks\u002Ftodo.md`. This plan must be complete enough that a fresh context can execute it by reading only CLAUDE.md and `tasks\u002Ftodo.md`. Include:\n   - What needs to be built\u002Fchanged\n   - Which files will be affected (full paths)\n   - Key technical decisions or risks\n   - Relevant context from the current session (gotchas, patterns established, conventions used)\n   - If test strategy is `tdd`: which tests to write first and what they should assert\n   - If test strategy is `tests-after`: note that tests will be written in the Green step\n   - The current phase's `### Execution Profile`, including whether the next execution is serial, research-only, review-only, implementation-safe, or agent-team\n   - Acceptance criteria: how to verify the step is done\n   - **Ship-one-step handoff contract:** the next clear-context implementation session must implement only this step, validate it, then run `\u002Fship` when done.\ne) Include task-document changes in the same issue-backed branch and ready pull-request boundary via `\u002Fcommit-and-push-by-feature`.\n\n### 5. Enter plan mode (skip if `--no-plan`)\n**YOU MUST run the full plan-mode approval sequence.** This is not optional. A next-step plan being written or already present is not a completed `\u002Fship` unless `--no-plan` is set or the approval UI is presented successfully.\n\n1. Call `EnterPlanMode`. This enters plan mode.\n2. In plan mode, write the plan file to the path specified by the plan-mode system prompt. Keep it brief: name the next step, state that the full implementation plan is in `tasks\u002Ftodo.md`, and include the ship-one-step handoff: \"implement only this step, validate it, then run `\u002Fship` when done.\" Do not explore the codebase or perform multi-phase planning; this is a pass-through to present the approval UI.\n3. Call `ExitPlanMode`. This presents the approval UI where the user can choose \"clear context and implement\" to start a fresh context that reads `tasks\u002Ftodo.md` and implements the plan.\n\n`EnterPlanMode` alone does not present the approval UI. `ExitPlanMode` must only be called after `EnterPlanMode` has succeeded and the session is visibly in plan mode. If Claude Code reports \"You are not in plan mode\", do not retry `ExitPlanMode`; call `EnterPlanMode` first, then write the brief pass-through plan and call `ExitPlanMode`.\n\nThere is no normal final-answer checkpoint between writing\u002Ffinding the next plan and presenting the approval UI. If the prior tool call was interrupted after the plan was written, resume by calling `EnterPlanMode` rather than summarizing and stopping, unless the session is already visibly in plan mode.\n\n### 6. Plan-mode approval content (skip if `--no-plan`)\nWhen writing the brief pass-through plan in step 5, include a short ship summary (2-3 lines max) and **present the execution plan** to the user. Summarize the plan that was written to `tasks\u002Ftodo.md` in step 4d:\n- What was shipped (if anything)\n- Deploy status (if deployed or skipped)\n- Test status — **explicitly state whether any failing tests are expected (red phase: tests written before implementation) or unexpected (regressions\u002Fbugs that need fixing)**\n- Manual tasks — pending count from `tasks\u002Fmanual-todo.md` (if it exists), note any that block upcoming steps\n- Advisory tasks — pending record\u002Frecurring counts from `tasks\u002Frecord-todo.md` and `tasks\u002Frecurring-todo.md` if they exist\n- What needs to be built\u002Fchanged\n- Which files will be created or modified (full paths)\n- The approach (e.g., test strategy, key technical decisions)\n- **Ship-one-step handoff contract:** after approval, implement only this step, validate it, then run `\u002Fship` when done.\n- Any decisions or trade-offs the user should weigh in on\n\nThis gives the user something concrete to review before selecting \"clear context and implement\".\n\n## Next-Step Routing\n\nAfter writing the next-step plan and before entering plan mode (or before stopping when `--no-plan` is set), identify the next concrete work item from project state, then recommend the executor and invocation.\n\nOutput exactly two lines beyond the normal ship summary:\n\n- **Next work:** \u003Cspecific task name, manual blocker, verification gap, or \"none\">\n- **Recommended next command:** \u003Cone command or route>\n\nRules:\n\n- Make the next work item primary. Derive it from the next-step plan, `tasks\u002Ftodo.md`, `tasks\u002Fmanual-todo.md`, deploy status, validation gaps, smoke-test gaps, or the absence of remaining work. Do not use agent mode itself as the next work item.\n- Treat `tasks\u002Ftodo.md` as the only executable current-task surface. Historical roadmap entries and unchecked advisory\u002Fmanual\u002Frecord\u002Frecurring items are reconciliation candidates, not next executable work, unless the current active todo section explicitly promotes them.\n- If no remaining work exists — no unchecked steps in `tasks\u002Ftodo.md`, no phases remaining in `tasks\u002Froadmap.md`, no pending manual blockers, no validation gaps, and no deploy failures — emit `**Next work:** none` and `**Recommended next command:** none — all planned work is complete`. Do not force a route to `\u002Fexec` when there is genuinely nothing to execute.\n- Never recommend `\u002Fship`, `\u002Fship --no-deploy`, or `\u002Fship --no-plan` as the routine next command from a completed `\u002Fship` run. `\u002Fship` packages current work; after it completes, hand off to the next executable route such as `\u002Fexec`, check `.agents\u002Fproject.json.enabled_packs` for `agent-work-admin` — if `agent-work-admin` is not enabled, recommend `npx skillpacks install agent-work-admin` from the project shell first; if `agent-work-admin` is enabled, recommend `\u002Froadmap`, check `.agents\u002Fproject.json.enabled_packs` for `guided-walkthrough` — if `guided-walkthrough` is not enabled, recommend `npx skillpacks install guided-walkthrough` from the project shell first; if `guided-walkthrough` is enabled, recommend `\u002Fguide`, or check `.agents\u002Fproject.json.enabled_packs` for `docs-health` — if `docs-health` is not enabled, recommend `npx skillpacks install docs-health` from the project shell first; if `docs-health` is enabled, recommend `\u002Freconcile-dev-docs fix tasks` based on project state. Recommend `\u002Fship` again only when shipping failed before commit\u002Fpush or when the next concrete work is explicitly to retry an incomplete shipping operation.\n- Use `.\u002Fscripts\u002Fagent-mode.sh` only to choose command text. If it is missing, unset, or non-zero, infer routing from the current invocation and task type instead of asking the user to select a mode by default.\n- Normalize copied task routes to Claude syntax before final output. If `tasks\u002Ftodo.md`, `tasks\u002Froadmap.md`, benchmark reports, or prior handoffs contain Codex dollar commands for base skills (for example `$exec`, `$ship`, `$roadmap`, `$guide`, `$reconcile-dev-docs`), treat them as task identifiers, not final command text. Convert the final `Recommended next command` to the equivalent Claude `\u002F...` route unless the next action is explicitly a Codex handoff — check `.agents\u002Fproject.json.enabled_packs` for `agent-bridge` — if `agent-bridge` is not enabled, recommend `npx skillpacks install agent-bridge` from the project shell first; if `agent-bridge` is enabled, recommend `\u002Fdelegate $exec`.\n- Inference defaults:\n  - Hybrid execution handoff → check `.agents\u002Fproject.json.enabled_packs` for `agent-bridge` — if `agent-bridge` is not enabled, recommend `npx skillpacks install agent-bridge` from the project shell first; if `agent-bridge` is enabled, recommend `\u002Fdelegate $exec`.\n  - Claude-only or orchestration-heavy work → recommend `\u002Fexec`.\n  - Codex-only execution → recommend `$exec`.\n  - External human-only manual work (browser\u002Fauth\u002FDNS\u002Fservice dashboard work with no reliable authenticated CLI\u002FAPI path, paid account setup, real-device checks, or production smoke-test work needing human sign-off) → check `.agents\u002Fproject.json.enabled_packs` for `guided-walkthrough` — if `guided-walkthrough` is not enabled, recommend `npx skillpacks install guided-walkthrough` from the project shell first; if `guided-walkthrough` is enabled, recommend `\u002Fguide` — or a Claude-guided manual step rather than `\u002Fexec`.\n  - Agent-executable work misfiled in `tasks\u002Fmanual-todo.md`, task-doc bookkeeping, stale `tasks\u002Fmanual-todo.md` cleanup, or reconciliation against repo\u002Fhistory reality → check `.agents\u002Fproject.json.enabled_packs` for `docs-health` — if `docs-health` is not enabled, recommend `npx skillpacks install docs-health` from the project shell first; if `docs-health` is enabled, recommend `\u002Freconcile-dev-docs fix tasks` — promotion to `tasks\u002Ftodo.md`, or a direct dev-doc audit, not `\u002Fguide`.\n- Only present multiple commands when the ambiguity materially changes execution safety or there are equally valid next work items. Otherwise choose the best route and mention degraded mode lookup inline.\n- Final route contract: completed `\u002Fship` runs must not self-route back to `\u002Fship`; route to `\u002Fexec` or a more specific next actionable skill unless shipping itself failed before commit\u002Fpush, or emit `none` when all planned work is genuinely complete.\n\n## Constraints\n- When recommending a skill from another pack, verify the pack is installed via `.agents\u002Fproject.json` `enabled_packs`. If not installed, include `npx skillpacks install \u003Cpack-name>` from the project shell as the prerequisite.\n- **Fix unrelated issues:** If any step surfaces errors, warnings, or lint issues — even ones unrelated to the current work — investigate and fix them before continuing. Commit these fixes separately with a descriptive message (e.g., `fix: resolve unused import warning in auth.ts`).\n- Do NOT write plans into CLAUDE.md. CLAUDE.md is for project conventions and config only.\n- `tasks\u002Froadmap.md` is the source of truth for the full phased plan. `tasks\u002Ftodo.md` holds only the current phase.\n- Do NOT create `tasks\u002Ftodo.md` from scratch — if it doesn't exist and there's no roadmap, suggest discovery skills instead.\n- Do NOT re-read files you've already read this session. Use what's in context.\n- Do NOT explore the codebase extensively for planning. Keep context footprint minimal.\n- If the tree is clean and the next step plan already exists in `tasks\u002Ftodo.md`, skip straight to step 5.\n- Do not enter plan mode solely for verification-only\u002Fno-op-only work whose commands already passed in the current session and whose expected source changes are none. Record the completed verification\u002Fno-op result and advance to the next substantive item.\n- Unless `--no-plan` is set or a documented blocker stops planning, do not end the turn after writing, finding, or shipping the next-step plan; run the full `EnterPlanMode` -> pass-through plan -> `ExitPlanMode` approval sequence.\n- The plan shown to the clear-context implementation session must include the ship-one-step handoff: \"implement only this step, validate it, then run `\u002Fship` when done.\" The plan-mode prompt is the human approval boundary that prevents a runaway loop.\n- The plan must be actionable, not vague. Include specific file paths, technical details, and the current phase's `### Execution Profile`.\n- Do not execute or plan from `tasks\u002Frecord-todo.md` or `tasks\u002Frecurring-todo.md`; report their counts only unless an item has been promoted into `tasks\u002Ftodo.md`.\n- When task docs changed, do not finish with a next-work recommendation until `node scripts\u002Faudit-task-docs.mjs` passes, if that script exists.\n\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","# Ship\n\nShip current work, commit, push, deploy, and plan the next step. If `$ARGUMENTS` contains `--no-plan`, skip planning. If `$ARGUMENTS` contains `--no-deploy`, skip deployment. If `$ARGUMENTS` contains `--save-conversation`, save the current conversation to `conversations\u002F`. If `$ARGUMENTS` contains `--save-all-conversations`, export all past conversations to `conversations\u002F`.\n\n## Process\n\n### 1. Check if there's anything to ship\nRun `git status` and `git diff --stat`.\n- If the working tree is clean AND there are no unpushed commits: skip to step 3 (or stop if `--no-plan`).\n- If there are changes: continue to step 2.\n\n### 1b. Pre-ship error check\nBefore shipping, check for pre-existing errors so they get fixed and included in this step's commit.\n\na) **Check conversation context first.** If lint, typecheck, or test output already exists in the current session (e.g., from a TDD run step or plan-mode execution), use that output. Do NOT re-run commands whose results are already available.\n\nb) **Run only what's missing.** For any validation category (lint, typecheck, tests) that was NOT already run this session, find and run the project's commands. Check these sources:\n   - `CLAUDE.md` — look for lint, typecheck, or test commands\n   - `Makefile` \u002F `Justfile` — look for `check`, `lint`, `typecheck`, `test` targets\n   - `package.json` — look for `lint`, `typecheck`, `check`, `test` scripts\n   - `pyproject.toml` \u002F `setup.cfg` — look for tool configs (ruff, mypy, pytest)\n   - `Cargo.toml` — `cargo check`, `cargo clippy`\n   - If no validation commands are found and no prior output exists, skip this step.\n\nc) **Fix errors.** If any pre-existing errors are found (from prior session output or fresh runs):\n   - Fix them.\n   - Re-run only the previously-failing commands to confirm the fixes.\n   - These fixes will be committed alongside the current work in step 2d (or as a separate commit if the fixes are unrelated to the current feature).\n\nd) **If errors can't be auto-fixed** (e.g., requires user decision, third-party dependency issue), **STOP. Do not ship.** Report the errors clearly to the user and ask how they want to proceed. Never commit or push code with known build\u002Flint\u002Ftype\u002Ftest failures.\n\n### 1c. Quality gate for non-trivial mutations\n   - Apply `docs\u002Fquality-gate-contract.md` when the work to ship changes source code, scripts, configuration, schemas, generated runtime assets, deploy behavior, workflow policy, validation rules, command surfaces, or multiple files.\n   - Build a ship manifest from the exact diff and unpushed commits that will be included in the shipping boundary. The manifest must include: User goal, Changed files, Per-file purpose, User-goal mapping, Tests run, Skipped tests, Adversarial review, Residual risk, Rollback note, and Next command. The `Next command` field must use Claude slash-command syntax; for a completed `\u002Fship` run, default to `\u002Fexec` unless project state names a more specific next route. Do not leave `Next command` blank unless all planned work is genuinely complete, in which case use `none`.\n   - For non-trivial source changes, run a targeted `quality-sweep audit`, `\u002Fcode-review`, configured review lane, or explicitly justified equivalent adversarial review before commit\u002Fpush. Fix findings or record accepted residual concerns in the manifest.\n   - Final output must distinguish executable verification from documentation-only or task-only checks. Documentation\u002Ftask checks can support source changes, but cannot be the only proof for non-trivial source mutations.\n   - If the tree contains unrelated pre-existing changes, the manifest must separate included files from untouched files and explain why the ship boundary is safe. If that cannot be proven, stop instead of shipping.\n   - **Pack install artifact boundary:** Treat `.agents\u002Fproject.json` as the committed project designation. When pack configuration changed, include `.agents\u002Fproject.json` in the shipping boundary. Treat `.claude\u002Fskills\u002F**` and `.codex\u002Fskills\u002F**` as generated local skill roots recreated by `scripts\u002Fpack.sh refresh`; generated skill roots must not be staged or committed. If those roots are untracked, leave them uncommitted and report them as generated local artifacts. If any path under those roots is already tracked or modified as a tracked file, stop unless the current task explicitly includes repository hygiene to untrack or ignore generated skill roots.\n   - If the user corrected the agent during the work being shipped, the pre-commit ship manifest must prove the exact shipping boundary includes a `tasks\u002Flessons.md` update for the current correction. Treat the correction as repeatable unless the manifest proves otherwise.\n\n### 1d. Public Skills Catalog Freshness\nIf the shipping boundary creates, deletes, renames, or changes behavior\u002Fmetadata in any tracked `SKILL.md` or `PACK.md`, refresh the public skills catalog export before commit:\n\n- `node scripts\u002Fgenerate-skills-catalog-export.mjs`\n- `scripts\u002Fvalidate-skills-catalog-export.sh`\n\nInclude changed `exports\u002Fskills-catalog\u002Fv1\u002F**` artifacts in the same shipping boundary. The Skills Showcase lives in the separate `agentic-skills-showcase` repository and imports this public export; do not run Showcase app generators, Next.js builds, or website asset refreshes during normal `agentic-skills` shipping. If a skill change needs curated website copy, record the follow-up for the Showcase repo instead of editing app files here.\n\n### 1e. Ship manifest route convention\nWhen writing a ship manifest, summary, task review note, or final response with a `Next command` field, use Claude slash-command syntax. For a completed `\u002Fship` run, the default executable handoff is `\u002Fexec` unless project state names a more specific next route. Do not leave `Next command` blank unless all planned work is genuinely complete, in which case use `none`.\n\n### 2. Ship the work\na) Read the project's CLAUDE.md to understand current progress.\nb) Update `tasks\u002Ftodo.md` — mark completed items as done (check off steps and milestone criteria).\nc) Update `tasks\u002Fhistory.md` — append a brief record of what was accomplished this session (phase\u002Fstep completed, key changes). Create it if it doesn't exist.\nd) If `tasks\u002Ftodo.md`, `tasks\u002Froadmap.md`, `tasks\u002Fmanual-todo.md`, `tasks\u002Frecord-todo.md`, or `tasks\u002Frecurring-todo.md` changed and `scripts\u002Faudit-task-docs.mjs` exists, run `node scripts\u002Faudit-task-docs.mjs` and fix any failures before final next-work routing.\ne) **Save conversation (skip if `--save-conversation` and `--save-all-conversations` both absent):**\n   Run `scripts\u002Fsave-conversation.sh` to export the current Claude Code conversation as a markdown file in `conversations\u002F`. If the script is not found or fails (e.g., not running in Claude Code, no local conversation history), warn and continue — do not block shipping. Include the generated file in the shipping boundary.\n   - If `$ARGUMENTS` contains `--save-all-conversations`, run `scripts\u002Fsave-conversation.sh --all` instead.\n\nf) Ship the changes using the `\u002Fcommit-and-push-by-feature` compatibility workflow and `docs\u002Fgithub-delivery-contract.md`:\n   - Group changes into logical feature\u002Ffunction buckets.\n   - Use conventional commit messages.\n   - Ensure or reuse the linked issue and issue-backed non-primary branch before committing.\n   - Publish the branch and create or update one ready pull request; do not merge it.\n\n### 3. Deploy (skip if `--no-deploy`)\n\nIf the ready pull request is not merged into the current primary branch, defer deployment and route to explicit review\u002F`github-pr merge`. Never deploy development state from the work branch.\nAfter shipping, deploy only when the project has an explicit manual deploy contract.\n\na) **Check for deploy contract.** Look for `deploy.md` or `tasks\u002Fdeploy.md`.\n   - If neither file exists, skip deploy and report `Deploy skipped: no explicit manual deploy contract (deploy.md or tasks\u002Fdeploy.md)`.\n   - If a deploy contract exists, continue.\n\nb) **Invoke `\u002Fdeploy`** (release-ops pack) targeting the default environment (staging).\n   - Pass the deploy contract context to `\u002Fdeploy` (release-ops pack).\n   - Skip ledger recording and staleness reporting — those are for standalone `\u002Fdeploy` (release-ops pack) invocations only.\n   - If `\u002Fdeploy` (release-ops pack) reports failure, report the error. Do not retry.\n\n### 4. Plan the next step (skip if `--no-plan`)\n\n**Prerequisite:** If neither `tasks\u002Ftodo.md` nor `tasks\u002Froadmap.md` exists, or if no uncompleted steps remain, there is no plan to continue. Run `\u002Froadmap` to scan task pipeline health and recommend the next context-aware action (stale todo, missing steps, etc.). Then stop (do not enter plan mode).\n\na) **Migration check:** If `tasks\u002Froadmap.md` does not exist but `tasks\u002Ftodo.md` contains multiple `## Phase` headers, migrate: copy `tasks\u002Ftodo.md` → `tasks\u002Froadmap.md`, then trim `tasks\u002Ftodo.md` to just the current phase (first phase with unchecked steps). Commit with `chore: migrate to roadmap.md + todo.md split`.\nb) Read only the current active task\u002Fphase in `tasks\u002Ftodo.md` to identify the next uncompleted step. Do not select unchecked boxes from completed sections, historical roadmap notes, reconciliation reports, manual\u002Frecord\u002Frecurring advisory files, or any roadmap section not explicitly promoted into the current todo surface.\nb2) If `tasks\u002Frecord-todo.md` or `tasks\u002Frecurring-todo.md` exists, count unchecked advisory items for status only. Do not select them as next work.\nc) **Check if the current phase is complete** (all steps checked, milestone criteria met):\n   - If **YES — Phase transition:**\n     1. Archive the completed phase: copy `tasks\u002Ftodo.md` → `tasks\u002Fphases\u002Fphase-N.md` (create `tasks\u002Fphases\u002F` if needed). Fill in the \"On Completion\" section.\n     1b. If `tasks\u002Fmanual-todo.md` exists, inspect unchecked items before advancing phases:\n         - If any unchecked `_(blocks: Step N.X)_` items still apply to the completed phase, stop. Do NOT archive the manual task file, mark the phase complete, or advance to the next phase unless the user explicitly overrides the blocker.\n         - Unchecked `_(after: Step N.X)_` items are non-blocking follow-up tasks. Archive them with the phase and warn the user that they remain incomplete.\n     2. Check off the phase milestone in `tasks\u002Froadmap.md`.\n     3. Copy the next phase from `tasks\u002Froadmap.md` → overwrite `tasks\u002Ftodo.md`.\n     3b. Extract the next phase's manual tasks (from `**Manual Tasks:**` in `tasks\u002Froadmap.md`) into a fresh `tasks\u002Fmanual-todo.md`. If the next phase has no manual tasks, delete `tasks\u002Fmanual-todo.md` if it exists.\n     4. If no more phases remain, run `\u002Froadmap` to recommend the next action based on project state. Then stop (do not enter plan mode).\n     5. **Just-in-time planning:** **You MUST invoke `\u002Fplan-phase` for the new phase** — do NOT tell the user the phase is \"deferred\" or ask them to run `\u002Fplan-phase` manually. A phase without implementation steps is NOT deferred; it simply hasn't been decomposed yet (only items under the `## Deferred \u002F Future Work` heading in the roadmap are actually deferred). This auto-invocation generates implementation steps, the phase `### Execution Profile`, and file-level detail using the full context of what was learned during prior phases. The roadmap only stores strategic outlines — implementation detail is generated when a phase is started, not upfront.\n   - If **NO:** find the next uncompleted step within the current phase.\nd0) **Skip no-op verification handoffs:** If the next uncompleted step is verification-only\u002Fno-op-only (for example, \"refactor if validation exposes drift\", \"verify\", \"run validation\", or `Files: no source changes expected`) and the current session already has passing validation evidence for the same scope, do not write a clear-context plan for it. Mark the step complete in `tasks\u002Ftodo.md`, record the no-op result in the review\u002Fhistory, ship those task-doc updates, then continue selecting the next substantive step. If verification found failures, drift, warnings needing judgment, or source edits are required, treat that remediation as substantive work and plan it normally.\nd) Write a **self-contained** implementation plan for the next step into `tasks\u002Ftodo.md`. This plan must be complete enough that a fresh context can execute it by reading only CLAUDE.md and `tasks\u002Ftodo.md`. Include:\n   - What needs to be built\u002Fchanged\n   - Which files will be affected (full paths)\n   - Key technical decisions or risks\n   - Relevant context from the current session (gotchas, patterns established, conventions used)\n   - If test strategy is `tdd`: which tests to write first and what they should assert\n   - If test strategy is `tests-after`: note that tests will be written in the Green step\n   - The current phase's `### Execution Profile`, including whether the next execution is serial, research-only, review-only, implementation-safe, or agent-team\n   - Acceptance criteria: how to verify the step is done\n   - **Ship-one-step handoff contract:** the next clear-context implementation session must implement only this step, validate it, then run `\u002Fship` when done.\ne) Include task-document changes in the same issue-backed branch and ready pull-request boundary via `\u002Fcommit-and-push-by-feature`.\n\n### 5. Enter plan mode (skip if `--no-plan`)\n**YOU MUST run the full plan-mode approval sequence.** This is not optional. A next-step plan being written or already present is not a completed `\u002Fship` unless `--no-plan` is set or the approval UI is presented successfully.\n\n1. Call `EnterPlanMode`. This enters plan mode.\n2. In plan mode, write the plan file to the path specified by the plan-mode system prompt. Keep it brief: name the next step, state that the full implementation plan is in `tasks\u002Ftodo.md`, and include the ship-one-step handoff: \"implement only this step, validate it, then run `\u002Fship` when done.\" Do not explore the codebase or perform multi-phase planning; this is a pass-through to present the approval UI.\n3. Call `ExitPlanMode`. This presents the approval UI where the user can choose \"clear context and implement\" to start a fresh context that reads `tasks\u002Ftodo.md` and implements the plan.\n\n`EnterPlanMode` alone does not present the approval UI. `ExitPlanMode` must only be called after `EnterPlanMode` has succeeded and the session is visibly in plan mode. If Claude Code reports \"You are not in plan mode\", do not retry `ExitPlanMode`; call `EnterPlanMode` first, then write the brief pass-through plan and call `ExitPlanMode`.\n\nThere is no normal final-answer checkpoint between writing\u002Ffinding the next plan and presenting the approval UI. If the prior tool call was interrupted after the plan was written, resume by calling `EnterPlanMode` rather than summarizing and stopping, unless the session is already visibly in plan mode.\n\n### 6. Plan-mode approval content (skip if `--no-plan`)\nWhen writing the brief pass-through plan in step 5, include a short ship summary (2-3 lines max) and **present the execution plan** to the user. Summarize the plan that was written to `tasks\u002Ftodo.md` in step 4d:\n- What was shipped (if anything)\n- Deploy status (if deployed or skipped)\n- Test status — **explicitly state whether any failing tests are expected (red phase: tests written before implementation) or unexpected (regressions\u002Fbugs that need fixing)**\n- Manual tasks — pending count from `tasks\u002Fmanual-todo.md` (if it exists), note any that block upcoming steps\n- Advisory tasks — pending record\u002Frecurring counts from `tasks\u002Frecord-todo.md` and `tasks\u002Frecurring-todo.md` if they exist\n- What needs to be built\u002Fchanged\n- Which files will be created or modified (full paths)\n- The approach (e.g., test strategy, key technical decisions)\n- **Ship-one-step handoff contract:** after approval, implement only this step, validate it, then run `\u002Fship` when done.\n- Any decisions or trade-offs the user should weigh in on\n\nThis gives the user something concrete to review before selecting \"clear context and implement\".\n\n## Next-Step Routing\n\nAfter writing the next-step plan and before entering plan mode (or before stopping when `--no-plan` is set), identify the next concrete work item from project state, then recommend the executor and invocation.\n\nOutput exactly two lines beyond the normal ship summary:\n\n- **Next work:** \u003Cspecific task name, manual blocker, verification gap, or \"none\">\n- **Recommended next command:** \u003Cone command or route>\n\nRules:\n\n- Make the next work item primary. Derive it from the next-step plan, `tasks\u002Ftodo.md`, `tasks\u002Fmanual-todo.md`, deploy status, validation gaps, smoke-test gaps, or the absence of remaining work. Do not use agent mode itself as the next work item.\n- Treat `tasks\u002Ftodo.md` as the only executable current-task surface. Historical roadmap entries and unchecked advisory\u002Fmanual\u002Frecord\u002Frecurring items are reconciliation candidates, not next executable work, unless the current active todo section explicitly promotes them.\n- If no remaining work exists — no unchecked steps in `tasks\u002Ftodo.md`, no phases remaining in `tasks\u002Froadmap.md`, no pending manual blockers, no validation gaps, and no deploy failures — emit `**Next work:** none` and `**Recommended next command:** none — all planned work is complete`. Do not force a route to `\u002Fexec` when there is genuinely nothing to execute.\n- Never recommend `\u002Fship`, `\u002Fship --no-deploy`, or `\u002Fship --no-plan` as the routine next command from a completed `\u002Fship` run. `\u002Fship` packages current work; after it completes, hand off to the next executable route such as `\u002Fexec`, check `.agents\u002Fproject.json.enabled_packs` for `agent-work-admin` — if `agent-work-admin` is not enabled, recommend `npx skillpacks install agent-work-admin` from the project shell first; if `agent-work-admin` is enabled, recommend `\u002Froadmap`, check `.agents\u002Fproject.json.enabled_packs` for `guided-walkthrough` — if `guided-walkthrough` is not enabled, recommend `npx skillpacks install guided-walkthrough` from the project shell first; if `guided-walkthrough` is enabled, recommend `\u002Fguide`, or check `.agents\u002Fproject.json.enabled_packs` for `docs-health` — if `docs-health` is not enabled, recommend `npx skillpacks install docs-health` from the project shell first; if `docs-health` is enabled, recommend `\u002Freconcile-dev-docs fix tasks` based on project state. Recommend `\u002Fship` again only when shipping failed before commit\u002Fpush or when the next concrete work is explicitly to retry an incomplete shipping operation.\n- Use `.\u002Fscripts\u002Fagent-mode.sh` only to choose command text. If it is missing, unset, or non-zero, infer routing from the current invocation and task type instead of asking the user to select a mode by default.\n- Normalize copied task routes to Claude syntax before final output. If `tasks\u002Ftodo.md`, `tasks\u002Froadmap.md`, benchmark reports, or prior handoffs contain Codex dollar commands for base skills (for example `$exec`, `$ship`, `$roadmap`, `$guide`, `$reconcile-dev-docs`), treat them as task identifiers, not final command text. Convert the final `Recommended next command` to the equivalent Claude `\u002F...` route unless the next action is explicitly a Codex handoff — check `.agents\u002Fproject.json.enabled_packs` for `agent-bridge` — if `agent-bridge` is not enabled, recommend `npx skillpacks install agent-bridge` from the project shell first; if `agent-bridge` is enabled, recommend `\u002Fdelegate $exec`.\n- Inference defaults:\n  - Hybrid execution handoff → check `.agents\u002Fproject.json.enabled_packs` for `agent-bridge` — if `agent-bridge` is not enabled, recommend `npx skillpacks install agent-bridge` from the project shell first; if `agent-bridge` is enabled, recommend `\u002Fdelegate $exec`.\n  - Claude-only or orchestration-heavy work → recommend `\u002Fexec`.\n  - Codex-only execution → recommend `$exec`.\n  - External human-only manual work (browser\u002Fauth\u002FDNS\u002Fservice dashboard work with no reliable authenticated CLI\u002FAPI path, paid account setup, real-device checks, or production smoke-test work needing human sign-off) → check `.agents\u002Fproject.json.enabled_packs` for `guided-walkthrough` — if `guided-walkthrough` is not enabled, recommend `npx skillpacks install guided-walkthrough` from the project shell first; if `guided-walkthrough` is enabled, recommend `\u002Fguide` — or a Claude-guided manual step rather than `\u002Fexec`.\n  - Agent-executable work misfiled in `tasks\u002Fmanual-todo.md`, task-doc bookkeeping, stale `tasks\u002Fmanual-todo.md` cleanup, or reconciliation against repo\u002Fhistory reality → check `.agents\u002Fproject.json.enabled_packs` for `docs-health` — if `docs-health` is not enabled, recommend `npx skillpacks install docs-health` from the project shell first; if `docs-health` is enabled, recommend `\u002Freconcile-dev-docs fix tasks` — promotion to `tasks\u002Ftodo.md`, or a direct dev-doc audit, not `\u002Fguide`.\n- Only present multiple commands when the ambiguity materially changes execution safety or there are equally valid next work items. Otherwise choose the best route and mention degraded mode lookup inline.\n- Final route contract: completed `\u002Fship` runs must not self-route back to `\u002Fship`; route to `\u002Fexec` or a more specific next actionable skill unless shipping itself failed before commit\u002Fpush, or emit `none` when all planned work is genuinely complete.\n\n## Constraints\n- When recommending a skill from another pack, verify the pack is installed via `.agents\u002Fproject.json` `enabled_packs`. If not installed, include `npx skillpacks install \u003Cpack-name>` from the project shell as the prerequisite.\n- **Fix unrelated issues:** If any step surfaces errors, warnings, or lint issues — even ones unrelated to the current work — investigate and fix them before continuing. Commit these fixes separately with a descriptive message (e.g., `fix: resolve unused import warning in auth.ts`).\n- Do NOT write plans into CLAUDE.md. CLAUDE.md is for project conventions and config only.\n- `tasks\u002Froadmap.md` is the source of truth for the full phased plan. `tasks\u002Ftodo.md` holds only the current phase.\n- Do NOT create `tasks\u002Ftodo.md` from scratch — if it doesn't exist and there's no roadmap, suggest discovery skills instead.\n- Do NOT re-read files you've already read this session. Use what's in context.\n- Do NOT explore the codebase extensively for planning. Keep context footprint minimal.\n- If the tree is clean and the next step plan already exists in `tasks\u002Ftodo.md`, skip straight to step 5.\n- Do not enter plan mode solely for verification-only\u002Fno-op-only work whose commands already passed in the current session and whose expected source changes are none. Record the completed verification\u002Fno-op result and advance to the next substantive item.\n- Unless `--no-plan` is set or a documented blocker stops planning, do not end the turn after writing, finding, or shipping the next-step plan; run the full `EnterPlanMode` -> pass-through plan -> `ExitPlanMode` approval sequence.\n- The plan shown to the clear-context implementation session must include the ship-one-step handoff: \"implement only this step, validate it, then run `\u002Fship` when done.\" The plan-mode prompt is the human approval boundary that prevents a runaway loop.\n- The plan must be actionable, not vague. Include specific file paths, technical details, and the current phase's `### Execution Profile`.\n- Do not execute or plan from `tasks\u002Frecord-todo.md` or `tasks\u002Frecurring-todo.md`; report their counts only unless an item has been promoted into `tasks\u002Ftodo.md`.\n- When task docs changed, do not finish with a next-work recommendation until `node scripts\u002Faudit-task-docs.mjs` passes, if that script exists.\n\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":28,"version":43,"invocation":33,"description":7,"argument-hint":44},"v0.12","[--no-plan] [--no-deploy] [--save-conversation] [--save-all-conversations]","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fexec-loop\u002Fclaude\u002Fship",0,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills","https:\u002F\u002Fagentic-skills-blush.vercel.app","https:\u002F\u002Fgithub.com\u002FGeorgeQLe","georgeqle.com","George Le is a futurist and serial tech entrepreneur who wants to work toward a world where humanity is free from robotic tasks.","2026-11-10 04:07:24",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill ship",{"tool":61,"command":62},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill ship",{"tool":64,"command":65},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill ship","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fexec-loop\u002Fclaude\u002Fship\u002FSKILL.md",true,[69],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"CHANGELOG.md","REFERENCE","参考文档",2230,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fexec-loop\u002Fclaude\u002Fship\u002FCHANGELOG.md",[76,88,98,110,123,134],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":38},"01M6G0NJES15RJKZE6YZ0TSYGF","source-checkout-allowed","Valid source-checkout-only fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fsource-checkout-allowed\u002FSKILL.md",[],[83,84,85,86,34,87],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":38},"01M6G0NFZ3R1MNB1E3DVTM0WB7","deck-install-valid","Valid deck install fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fdeck-install\u002FSKILL.md",[],[95,96,97,87,85,34],"deck install valid","deck","install",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":38},"01M6G0ND3QZQC4MDZ9NVB97PT2","codex-pack-guard-valid","Valid Codex Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-pack-guard\u002FSKILL.md",[],[105,106,107,87,108,109,85,34],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":119,"publishedAt":38},"01M6G0NA9YB3NKGZKD3S96JMNB","codex-missing-skill-valid","Valid Codex missing skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-missing-skill-fallback\u002FSKILL.md",[116],{"categoryNo":117,"categoryName":118,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[120,121,87,108,34,122,85],"codex missing skill valid","missing","fallback",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":130,"publishedAt":38},"01M6G0N7PC0EKFD40ZWQAXSAQ9","codex-base-skill-fallback-valid","Valid Codex base skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-base-skill-fallback\u002FSKILL.md",[129],{"categoryNo":117,"categoryName":118,"taxonomyType":21,"taxonomyTypeDesc":22},[87,108,122,131,132,133,34,85],"base skill","codex base skill fallback valid","base",{"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":38},"01M6G0N4VRR2YKZQ6N3Y6S2BQA","claude-pack-guard-valid","Valid Claude Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fclaude-pack-guard\u002FSKILL.md",[],[87,107,106,141,109,34,85],"claude pack guard valid"]