[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71E29RWQKM2EC497M2JBDYW":3,"skill-same:01M71E29RWQKM2EC497M2JBDYW":77},{"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":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M71E29RWQKM2EC497M2JBDYW","ship",null,"Take PRs through review, merge, deploy, smoke test, and monitoring until every KPI is healthy. Triggers: \"ship this\", \"take this to prod\".","indigoai-us\u002Fhq-core","indigoai-us","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F122242446?v=4","01M71DTQ5NGD10GT1Z7E6XKWC5","HQ","01M71DTQ6BKSYYBNC9RAKT3YDK",95,"MIT","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002F.claude\u002Fskills\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,38,39,40,41],"healthy","deploy","grep","take","edit","write","read","merge","test","smoke test","review","monitoring","Bash","triggers","prs","monitor","kpi","smoke","2026-11-10 10:12:30",false,"---\nname: ship\ndescription: \"Take PRs through review, merge, deploy, smoke test, and monitoring until every KPI is healthy. Triggers: \\\"ship this\\\", \\\"take this to prod\\\".\"\nallowed-tools: Bash, Read, Grep, Glob, Write, Edit, Agent, AskUserQuestion, TaskCreate, TaskUpdate, Monitor, CronCreate, CronList\n---\n\n# Ship\n\n**REVIEW → LAND → DEPLOY → SMOKE → HEAL (on any failure) → MONITOR → DOCUMENT.**\n\nThis skill is a meta-pipeline that composes existing pack skills into one\nclosed loop. It does not reimplement them — it sequences them and owns the\nfailure\u002Fheal\u002Fre-verify cycle plus standing monitoring. A PR is not \"shipped\"\nwhen it merges; it is shipped when the live user-facing path works and a\nstanding monitor is watching it.\n\nA worked example of the full loop looks like: one session takes a paired\nfrontend and backend PR from open through merged, deployed, smoke-verified\nagainst the live signup path, and monitored until the declared KPIs are healthy\n— with the session journal kept in that project's `journal\u002F` directory.\n\n## Input\n\nAccepts any combination of:\n\n- **PR refs** — one or more, each as `owner\u002Frepo#123`, a PR URL, a bare number\n  (repo inferred from cwd), or nothing (open PR for the current branch).\n- **KPI checklist** — a list of observable health criteria the shipped feature\n  must satisfy (e.g. \"funnel smoke passes\", \"no 5xx on \u002Fapi\u002Fme\u002Fsignup\u002F*\",\n  \"checkout redirect lands on Stripe\"). If omitted, derive one in Step 0 and\n  confirm it with the user.\n- **Flags** — `--no-monitor` (skip Step 6 standing monitor), `--skip-review`\n  (only when the PRs already carry a completed paranoid review this session),\n  `--no-docs` (skip Step 7 documentation sync).\n\n## Done Criteria (define BEFORE executing)\n\nThe pipeline is complete only when ALL of these are observably true:\n\n1. Every input PR is merged (state `MERGED`, merge commit recorded).\n2. Every production deploy triggered by those merges completed successfully\n   (Vercel deployment `READY` on the production target, and\u002For the deploy-prod\n   GitHub workflow run concluded `success`).\n3. A real end-to-end smoke against the LIVE deployed stack passed — real auth,\n   real data, whole loop, cleanup done (hard policy\n   `hq-smoke-cross-repo-contracts-before-done`).\n4. A standing monitor exists and is verified (cron smoke workflow or scheduled\n   task), OR `--no-monitor` was passed.\n5. Every KPI in the checklist reads healthy, and the final report includes the\n   KPI table.\n\nDocumentation sync (Step 7) is deliberately NOT in this list. A change is\n\"shipped\" when the live path works and a monitor watches it — whether the docs\ngot updated does not gate that status. Docs run last, foreground, after the\nabove are all true.\n\nWrite these as concrete, checkable statements for THIS run in Step 0 (with the\nactual repo names, URLs, workflow names, KPI probes) before touching anything.\n\n## Step 0: Resolve Scope + Ordering\n\n1. Resolve each PR ref → `{repo, number, title, branch, base}`. Anchor every\n   `gh` call with `-R owner\u002Frepo`.\n2. Resolve the owning company; load company policy constraints via\n   frontmatter-only scan of `companies\u002F{co}\u002Fpolicies\u002F` (digests are retired —\n   SessionStart uses `inject-policy-on-trigger`) and the manifest infra fields\n   for deploy targets. Never guess credentials.\n3. Identify each repo's production deploy mechanism:\n   - **Vercel git integration** — merge to main auto-deploys; watch via\n     `vercel ls`\u002F`vercel inspect` or the GitHub deployment status API.\n   - **GH deploy-prod workflow** — merge triggers (or you dispatch) a workflow;\n     watch the run.\n   - **Manual (SST etc.)** — merging does NOT deploy; the deploy is an explicit\n     pipeline step you must run and watch.\n4. **Multi-repo ordering (hard rule):** when PRs span a producer and consumer\n   of a shared contract, land in contract-safe order — **additive API fields \u002F\n   server first, defensive consumers second**. The server must tolerate old\n   clients before any client that depends on the new field\u002Froute deploys.\n   Removals invert: consumers stop reading first, producer removes last.\n   Build the merge order accordingly; within a tier, smallest\u002Flowest-risk first\n   (reuse `land-batch` triage semantics for >2 PRs).\n5. Derive or confirm the KPI checklist. Each KPI must name its probe (command,\n   URL, query, or workflow) — a KPI without a probe is not a KPI.\n6. Present the plan (PRs, order, deploy mechanisms, KPIs, done criteria) and\n   get an explicit go. Landing + deploying is irreversible-adjacent; this gate\n   is mandatory.\n\n## Step 1: REVIEW (pre-merge gate)\n\nFor each PR, run the paranoid pre-landing review — reuse\n`\u002Freview` semantics (two-pass: CRITICAL blocks, INFORMATIONAL\ngoes in the PR body), or `\u002Fcode-review` where available. For multi-PR ships,\nadditionally review the CROSS-PR contract: do the field names, envelopes,\nauth token types, and encodings match on both sides of every boundary the PRs\ntouch? (This is exactly where mocked unit tests lie — see the six-bug cascade\nin the smoke policy.)\n\n- CRITICAL findings → fix on the branch, push, wait for CI, re-review.\n- Never merge past an unresolved CRITICAL without explicit user override.\n\n## Step 2: LAND\n\nFor each PR in the Step 0 order, reuse `\u002Fland` semantics:\n\n1. Wait for CI green — use a background Monitor on\n   `gh pr checks {n} -R {repo}` (see Background Monitors below). Fix failures\n   at root cause; no skipped\u002Floosened tests, ever.\n2. Resolve outstanding review threads (bot suggestions applied if valid; human\n   comments summarized to the user).\n3. Merge: `gh pr merge {n} -R {repo} --squash --delete-branch` (respect repo\n   merge policy). Verify state `MERGED` and record the merge commit.\n4. Between PRs: pull main, re-check the next PR's `mergeable` (earlier merges\n   can create conflicts), and re-verify contract ordering still holds.\n\n## Step 3: DEPLOY (watch to completion)\n\nFor each merged PR, watch its production deploy to a terminal state:\n\n- **Vercel:** find the deployment created from the merge commit and watch\n  until `READY` on production (`gh api repos\u002F{owner}\u002F{repo}\u002Fdeployments` +\n  statuses, or `vercel inspect`). A `READY` preview is not done — it must be\n  the production target.\n- **GH workflow:** find the run triggered by the merge (or dispatch it), then\n  `gh run watch {id} -R {repo}` in the background until concluded `success`.\n- **Manual deploy repos:** run the documented deploy, watch it, and say so in\n  the report — never report \"merged\" as \"deployed\" for these.\n\nRespect the Step 0 ordering here too: do not start a consumer's deploy until\nits producer's deploy is live, when the consumer needs the new contract.\n\n### Own an infrastructure-only post-merge CI failure\n\nThe shipping owner keeps the next action when main CI fails and its automatic\ndeploy is skipped. Do not leave an approved change merely \"waiting for deploy.\"\nUnder the existing merge\u002Fdeploy authorization, the same owner may make **one\nfailed-jobs-only CI retry** for a documented runner disconnect or other\nconfirmed infrastructure interruption:\n\n1. Verify the repository, merged revision, CI run and failed job. Read the\n   failure evidence: an assertion failure, security\u002Fpolicy finding, permission\n   denial, failed approval or unexplained timeout is **not** an infra-only\n   classification. Route those to their existing owner; do not retry them into\n   green or weaken a check.\n2. Immediately before retrying, re-read the run's current attempt\u002Fstate and\n   check for another owner's recovery, a newer\u002Fsuperseding run or deployment.\n   If one already covers this revision, follow that work instead. If a prior\n   recovery retry failed, route to Infra with the exact evidence; do not loop.\n3. Confirm this is CI, not a publish, release or manual deployment job, and\n   that the existing production authorization covers its normal downstream\n   deploy. A hold or missing authorization stays in force. Do not dispatch a\n   deploy, provision capacity, change credentials or bypass a gate.\n4. Record the exact SHA, run\u002Fjob, infra evidence and retry owner, then run\n   `gh run rerun {run_id} -R {repo} --failed` once. Record its attempt\u002Fresult.\n   Follow the ordinary automatic deploy to its terminal exact-revision status,\n   then continue the existing smoke\u002FKPI requirements. A retry succeeding is\n   neither deployment nor acceptance proof.\n\nUse the current project's receipt\u002Fjournal and existing watch. This needs no\nnew desk, monitor or approval when the existing authorization already applies.\nIf another owner is actively recovering it, coordinate there rather than\nstarting a duplicate attempt. Report a repeated failure with its next owner\nand action, not an indefinite \"waiting\" state.\n\n## Step 4: SMOKE (live, end-to-end)\n\nHard gate per `hq-smoke-cross-repo-contracts-before-done`:\n\n- Exercise the WHOLE user-facing loop on the LIVE deployed stack with real\n  auth and real data — not unit tests, not previews, not mocked boundaries.\n  (Reference: the funnel ship created a real company via the new route and\n  followed the redirect all the way onto real Stripe checkout.)\n- Prefer agent-browser for browser flows (pack policy\n  `hq-prefer-agent-browser`); API loops via real authed requests.\n- **Clean up** every test artifact the smoke creates (delete smoke companies,\n  test records, orders) — or explicitly hand the leftover to the user in the\n  report with a deletion note.\n- Record exactly what was exercised and what was observed; \"it loaded\" is not\n  a smoke result.\n\n## Step 5: HEAL (on any failure, any step)\n\nOn any failure — CI red, review CRITICAL, deploy failed, smoke broke, KPI\nunhealthy — do NOT patch blind. Apply `\u002Finvestigate`\ndiscipline:\n\n1. Scope-lock to the failure; form ranked hypotheses; test one variable at a\n   time; 3-strike rule before widening scope.\n2. Fix at root cause, with a regression test (`hq-bugfix-requires-tests`).\n3. Re-enter the pipeline at the earliest affected step: fix → review the fix →\n   land it → watch its deploy → re-smoke. Never re-verify less than what the\n   fix could have affected.\n4. If the failure is in production and user-impacting, tell the user\n   immediately (security\u002Fblocker signal) and offer revert as an option before\n   a slow forward-fix.\n\n## Step 6: MONITOR (standing, until KPIs are green)\n\n1. **Verify or create a standing monitor:**\n   - Check for an existing cron smoke — a scheduled GitHub workflow smoking\n     this path, or a scheduled task (`CronList` \u002F scheduled-tasks) already\n     probing it. If one exists and covers the shipped path, verify it ran\n     green post-deploy.\n   - If none exists, create one: a scheduled smoke workflow in the owning\n     repo, or a scheduled task that runs the smoke and alerts on failure\n     (the funnel ship used a 6-hour scheduled task alerting #hq-dev).\n2. **Watch until healthy:** probe every KPI in the checklist. Use background\n   Monitors with sensible windows — not sleep loops (see below). Keep watching\n   until every KPI reads healthy for at least one full probe cycle\n   post-deploy, healing (Step 5) anything that reads unhealthy.\n3. Confirm the standing monitor itself works (trigger it once or verify its\n   most recent run) — an unverified monitor is not a monitor.\n\n## Background Monitors (not sleep loops)\n\nNEVER busy-wait with foreground `sleep` loops. Use the harness's background\nfacilities:\n\n- `gh run watch` \u002F long-poll commands via Bash `run_in_background: true` — the\n  harness re-invokes you when they exit.\n- The `Monitor` tool with an until-condition for waiting on external state.\n- Scheduled tasks \u002F cron workflows for anything beyond the session's horizon.\n\nMultiple independent watches (e.g. two repos' deploys) run as parallel\nbackground monitors, not serially.\n\n## Step 7: DOCUMENT (foreground, last — after everything above is green)\n\nOnly after Steps 1–6 are done (merged, deployed, smoked, monitored) sync the\ndocumentation to match what shipped. This runs **foreground and last** — never\nin the background, never racing the ship work, never a gate on \"shipped\". Skip\nthe whole step with `--no-docs`.\n\nCompose the two existing doc skills; do not reimplement them:\n\n1. **In-repo docs** — run `\u002Fdocument-release` for the shipped\n   repos. Syncs README, CLAUDE.md, architecture docs, and INDEX files to match\n   the diff. (This overlaps with what `\u002Fhandoff` runs, but running it here — with\n   the shipped diff hot in session — produces higher-fidelity edits than a later\n   headless handoff subagent reconstructing the diff from git. It is idempotent,\n   so the overlap is harmless.)\n2. **Published docs site** — run `publish-docs`. It resolves the active company's\n   docs-site sync skill (e.g. `{co}:sync-docs`) and runs it foreground, or cleanly\n   no-ops if the company has no published docs site. This covers the standalone\n   docs-site repo (e.g. `docs.{company}.com`) that `document-release` never touches.\n\nA failure in either doc skill is reported plainly in Step 8 but does NOT retroact\nthe ship's merged\u002Fdeployed\u002Fsmoked status — surface it and let the user decide\nwhether to heal or hand it off. Docs are not in the Done Criteria.\n\n## Step 8: Report\n\n```\nShip Complete\n─────────────\nPRs:      #{n} {repo} → merged {commit[:8]}  (one line each, in landed order)\nReview:   {pass | N criticals fixed}\nDeploys:  {repo}: {vercel READY | workflow success | manual done}  (each)\nSmoke:    {what was exercised} → PASS  (artifacts cleaned: {yes | handed off})\nHeals:    {none | N failures root-caused and re-landed, one line each}\nMonitor:  {existing verified | created: name + schedule + alert channel}\nDocs:     {in-repo synced + site published \u003Curl> | in-repo synced, no site | skipped (--no-docs)}\n\nKPI Table\n| KPI | Probe | Status |\n|-----|-------|--------|\n| ... | ...   | ✅\u002F❌  |\n```\n\nAll KPIs must be ✅ (or explicitly waived by the user) before reporting done.\nThen journal the ship per session-journal discipline.\n\n## Rules\n\n- Done criteria are written in Step 0 and never loosened mid-run.\n- Never skip CI, never fake or loosen a test, every bugfix ships a regression\n  test (`hq-no-test-shortcuts`, `hq-bugfix-requires-tests`).\n- Additive-first \u002F defensive-consumer ordering is a hard rule for multi-repo\n  ships — both for merge order and deploy order.\n- Merged ≠ deployed ≠ working. Only a live smoke plus healthy KPIs closes the\n  loop; a standing monitor keeps it closed.\n- Anchor every git\u002Fgh mutation (`git -C`, `gh -R`); never mutate from HQ root.\n- Company isolation: one company's credentials and deploy targets only.\n- Failures are reported plainly and immediately; healing is transparent in the\n  final report, not hidden.\n- Documentation (Step 7) is foreground, last, and non-gating: it runs only after\n  the ship is verified, never in the background, and a docs failure never\n  downgrades a merged\u002Fdeployed\u002Fsmoked ship. Compose `document-release` +\n  `publish-docs`; do not reimplement doc logic here.\n","# Ship\n\n**REVIEW → LAND → DEPLOY → SMOKE → HEAL (on any failure) → MONITOR → DOCUMENT.**\n\nThis skill is a meta-pipeline that composes existing pack skills into one\nclosed loop. It does not reimplement them — it sequences them and owns the\nfailure\u002Fheal\u002Fre-verify cycle plus standing monitoring. A PR is not \"shipped\"\nwhen it merges; it is shipped when the live user-facing path works and a\nstanding monitor is watching it.\n\nA worked example of the full loop looks like: one session takes a paired\nfrontend and backend PR from open through merged, deployed, smoke-verified\nagainst the live signup path, and monitored until the declared KPIs are healthy\n— with the session journal kept in that project's `journal\u002F` directory.\n\n## Input\n\nAccepts any combination of:\n\n- **PR refs** — one or more, each as `owner\u002Frepo#123`, a PR URL, a bare number\n  (repo inferred from cwd), or nothing (open PR for the current branch).\n- **KPI checklist** — a list of observable health criteria the shipped feature\n  must satisfy (e.g. \"funnel smoke passes\", \"no 5xx on \u002Fapi\u002Fme\u002Fsignup\u002F*\",\n  \"checkout redirect lands on Stripe\"). If omitted, derive one in Step 0 and\n  confirm it with the user.\n- **Flags** — `--no-monitor` (skip Step 6 standing monitor), `--skip-review`\n  (only when the PRs already carry a completed paranoid review this session),\n  `--no-docs` (skip Step 7 documentation sync).\n\n## Done Criteria (define BEFORE executing)\n\nThe pipeline is complete only when ALL of these are observably true:\n\n1. Every input PR is merged (state `MERGED`, merge commit recorded).\n2. Every production deploy triggered by those merges completed successfully\n   (Vercel deployment `READY` on the production target, and\u002For the deploy-prod\n   GitHub workflow run concluded `success`).\n3. A real end-to-end smoke against the LIVE deployed stack passed — real auth,\n   real data, whole loop, cleanup done (hard policy\n   `hq-smoke-cross-repo-contracts-before-done`).\n4. A standing monitor exists and is verified (cron smoke workflow or scheduled\n   task), OR `--no-monitor` was passed.\n5. Every KPI in the checklist reads healthy, and the final report includes the\n   KPI table.\n\nDocumentation sync (Step 7) is deliberately NOT in this list. A change is\n\"shipped\" when the live path works and a monitor watches it — whether the docs\ngot updated does not gate that status. Docs run last, foreground, after the\nabove are all true.\n\nWrite these as concrete, checkable statements for THIS run in Step 0 (with the\nactual repo names, URLs, workflow names, KPI probes) before touching anything.\n\n## Step 0: Resolve Scope + Ordering\n\n1. Resolve each PR ref → `{repo, number, title, branch, base}`. Anchor every\n   `gh` call with `-R owner\u002Frepo`.\n2. Resolve the owning company; load company policy constraints via\n   frontmatter-only scan of `companies\u002F{co}\u002Fpolicies\u002F` (digests are retired —\n   SessionStart uses `inject-policy-on-trigger`) and the manifest infra fields\n   for deploy targets. Never guess credentials.\n3. Identify each repo's production deploy mechanism:\n   - **Vercel git integration** — merge to main auto-deploys; watch via\n     `vercel ls`\u002F`vercel inspect` or the GitHub deployment status API.\n   - **GH deploy-prod workflow** — merge triggers (or you dispatch) a workflow;\n     watch the run.\n   - **Manual (SST etc.)** — merging does NOT deploy; the deploy is an explicit\n     pipeline step you must run and watch.\n4. **Multi-repo ordering (hard rule):** when PRs span a producer and consumer\n   of a shared contract, land in contract-safe order — **additive API fields \u002F\n   server first, defensive consumers second**. The server must tolerate old\n   clients before any client that depends on the new field\u002Froute deploys.\n   Removals invert: consumers stop reading first, producer removes last.\n   Build the merge order accordingly; within a tier, smallest\u002Flowest-risk first\n   (reuse `land-batch` triage semantics for >2 PRs).\n5. Derive or confirm the KPI checklist. Each KPI must name its probe (command,\n   URL, query, or workflow) — a KPI without a probe is not a KPI.\n6. Present the plan (PRs, order, deploy mechanisms, KPIs, done criteria) and\n   get an explicit go. Landing + deploying is irreversible-adjacent; this gate\n   is mandatory.\n\n## Step 1: REVIEW (pre-merge gate)\n\nFor each PR, run the paranoid pre-landing review — reuse\n`\u002Freview` semantics (two-pass: CRITICAL blocks, INFORMATIONAL\ngoes in the PR body), or `\u002Fcode-review` where available. For multi-PR ships,\nadditionally review the CROSS-PR contract: do the field names, envelopes,\nauth token types, and encodings match on both sides of every boundary the PRs\ntouch? (This is exactly where mocked unit tests lie — see the six-bug cascade\nin the smoke policy.)\n\n- CRITICAL findings → fix on the branch, push, wait for CI, re-review.\n- Never merge past an unresolved CRITICAL without explicit user override.\n\n## Step 2: LAND\n\nFor each PR in the Step 0 order, reuse `\u002Fland` semantics:\n\n1. Wait for CI green — use a background Monitor on\n   `gh pr checks {n} -R {repo}` (see Background Monitors below). Fix failures\n   at root cause; no skipped\u002Floosened tests, ever.\n2. Resolve outstanding review threads (bot suggestions applied if valid; human\n   comments summarized to the user).\n3. Merge: `gh pr merge {n} -R {repo} --squash --delete-branch` (respect repo\n   merge policy). Verify state `MERGED` and record the merge commit.\n4. Between PRs: pull main, re-check the next PR's `mergeable` (earlier merges\n   can create conflicts), and re-verify contract ordering still holds.\n\n## Step 3: DEPLOY (watch to completion)\n\nFor each merged PR, watch its production deploy to a terminal state:\n\n- **Vercel:** find the deployment created from the merge commit and watch\n  until `READY` on production (`gh api repos\u002F{owner}\u002F{repo}\u002Fdeployments` +\n  statuses, or `vercel inspect`). A `READY` preview is not done — it must be\n  the production target.\n- **GH workflow:** find the run triggered by the merge (or dispatch it), then\n  `gh run watch {id} -R {repo}` in the background until concluded `success`.\n- **Manual deploy repos:** run the documented deploy, watch it, and say so in\n  the report — never report \"merged\" as \"deployed\" for these.\n\nRespect the Step 0 ordering here too: do not start a consumer's deploy until\nits producer's deploy is live, when the consumer needs the new contract.\n\n### Own an infrastructure-only post-merge CI failure\n\nThe shipping owner keeps the next action when main CI fails and its automatic\ndeploy is skipped. Do not leave an approved change merely \"waiting for deploy.\"\nUnder the existing merge\u002Fdeploy authorization, the same owner may make **one\nfailed-jobs-only CI retry** for a documented runner disconnect or other\nconfirmed infrastructure interruption:\n\n1. Verify the repository, merged revision, CI run and failed job. Read the\n   failure evidence: an assertion failure, security\u002Fpolicy finding, permission\n   denial, failed approval or unexplained timeout is **not** an infra-only\n   classification. Route those to their existing owner; do not retry them into\n   green or weaken a check.\n2. Immediately before retrying, re-read the run's current attempt\u002Fstate and\n   check for another owner's recovery, a newer\u002Fsuperseding run or deployment.\n   If one already covers this revision, follow that work instead. If a prior\n   recovery retry failed, route to Infra with the exact evidence; do not loop.\n3. Confirm this is CI, not a publish, release or manual deployment job, and\n   that the existing production authorization covers its normal downstream\n   deploy. A hold or missing authorization stays in force. Do not dispatch a\n   deploy, provision capacity, change credentials or bypass a gate.\n4. Record the exact SHA, run\u002Fjob, infra evidence and retry owner, then run\n   `gh run rerun {run_id} -R {repo} --failed` once. Record its attempt\u002Fresult.\n   Follow the ordinary automatic deploy to its terminal exact-revision status,\n   then continue the existing smoke\u002FKPI requirements. A retry succeeding is\n   neither deployment nor acceptance proof.\n\nUse the current project's receipt\u002Fjournal and existing watch. This needs no\nnew desk, monitor or approval when the existing authorization already applies.\nIf another owner is actively recovering it, coordinate there rather than\nstarting a duplicate attempt. Report a repeated failure with its next owner\nand action, not an indefinite \"waiting\" state.\n\n## Step 4: SMOKE (live, end-to-end)\n\nHard gate per `hq-smoke-cross-repo-contracts-before-done`:\n\n- Exercise the WHOLE user-facing loop on the LIVE deployed stack with real\n  auth and real data — not unit tests, not previews, not mocked boundaries.\n  (Reference: the funnel ship created a real company via the new route and\n  followed the redirect all the way onto real Stripe checkout.)\n- Prefer agent-browser for browser flows (pack policy\n  `hq-prefer-agent-browser`); API loops via real authed requests.\n- **Clean up** every test artifact the smoke creates (delete smoke companies,\n  test records, orders) — or explicitly hand the leftover to the user in the\n  report with a deletion note.\n- Record exactly what was exercised and what was observed; \"it loaded\" is not\n  a smoke result.\n\n## Step 5: HEAL (on any failure, any step)\n\nOn any failure — CI red, review CRITICAL, deploy failed, smoke broke, KPI\nunhealthy — do NOT patch blind. Apply `\u002Finvestigate`\ndiscipline:\n\n1. Scope-lock to the failure; form ranked hypotheses; test one variable at a\n   time; 3-strike rule before widening scope.\n2. Fix at root cause, with a regression test (`hq-bugfix-requires-tests`).\n3. Re-enter the pipeline at the earliest affected step: fix → review the fix →\n   land it → watch its deploy → re-smoke. Never re-verify less than what the\n   fix could have affected.\n4. If the failure is in production and user-impacting, tell the user\n   immediately (security\u002Fblocker signal) and offer revert as an option before\n   a slow forward-fix.\n\n## Step 6: MONITOR (standing, until KPIs are green)\n\n1. **Verify or create a standing monitor:**\n   - Check for an existing cron smoke — a scheduled GitHub workflow smoking\n     this path, or a scheduled task (`CronList` \u002F scheduled-tasks) already\n     probing it. If one exists and covers the shipped path, verify it ran\n     green post-deploy.\n   - If none exists, create one: a scheduled smoke workflow in the owning\n     repo, or a scheduled task that runs the smoke and alerts on failure\n     (the funnel ship used a 6-hour scheduled task alerting #hq-dev).\n2. **Watch until healthy:** probe every KPI in the checklist. Use background\n   Monitors with sensible windows — not sleep loops (see below). Keep watching\n   until every KPI reads healthy for at least one full probe cycle\n   post-deploy, healing (Step 5) anything that reads unhealthy.\n3. Confirm the standing monitor itself works (trigger it once or verify its\n   most recent run) — an unverified monitor is not a monitor.\n\n## Background Monitors (not sleep loops)\n\nNEVER busy-wait with foreground `sleep` loops. Use the harness's background\nfacilities:\n\n- `gh run watch` \u002F long-poll commands via Bash `run_in_background: true` — the\n  harness re-invokes you when they exit.\n- The `Monitor` tool with an until-condition for waiting on external state.\n- Scheduled tasks \u002F cron workflows for anything beyond the session's horizon.\n\nMultiple independent watches (e.g. two repos' deploys) run as parallel\nbackground monitors, not serially.\n\n## Step 7: DOCUMENT (foreground, last — after everything above is green)\n\nOnly after Steps 1–6 are done (merged, deployed, smoked, monitored) sync the\ndocumentation to match what shipped. This runs **foreground and last** — never\nin the background, never racing the ship work, never a gate on \"shipped\". Skip\nthe whole step with `--no-docs`.\n\nCompose the two existing doc skills; do not reimplement them:\n\n1. **In-repo docs** — run `\u002Fdocument-release` for the shipped\n   repos. Syncs README, CLAUDE.md, architecture docs, and INDEX files to match\n   the diff. (This overlaps with what `\u002Fhandoff` runs, but running it here — with\n   the shipped diff hot in session — produces higher-fidelity edits than a later\n   headless handoff subagent reconstructing the diff from git. It is idempotent,\n   so the overlap is harmless.)\n2. **Published docs site** — run `publish-docs`. It resolves the active company's\n   docs-site sync skill (e.g. `{co}:sync-docs`) and runs it foreground, or cleanly\n   no-ops if the company has no published docs site. This covers the standalone\n   docs-site repo (e.g. `docs.{company}.com`) that `document-release` never touches.\n\nA failure in either doc skill is reported plainly in Step 8 but does NOT retroact\nthe ship's merged\u002Fdeployed\u002Fsmoked status — surface it and let the user decide\nwhether to heal or hand it off. Docs are not in the Done Criteria.\n\n## Step 8: Report\n\n```\nShip Complete\n─────────────\nPRs:      #{n} {repo} → merged {commit[:8]}  (one line each, in landed order)\nReview:   {pass | N criticals fixed}\nDeploys:  {repo}: {vercel READY | workflow success | manual done}  (each)\nSmoke:    {what was exercised} → PASS  (artifacts cleaned: {yes | handed off})\nHeals:    {none | N failures root-caused and re-landed, one line each}\nMonitor:  {existing verified | created: name + schedule + alert channel}\nDocs:     {in-repo synced + site published \u003Curl> | in-repo synced, no site | skipped (--no-docs)}\n\nKPI Table\n| KPI | Probe | Status |\n|-----|-------|--------|\n| ... | ...   | ✅\u002F❌  |\n```\n\nAll KPIs must be ✅ (or explicitly waived by the user) before reporting done.\nThen journal the ship per session-journal discipline.\n\n## Rules\n\n- Done criteria are written in Step 0 and never loosened mid-run.\n- Never skip CI, never fake or loosen a test, every bugfix ships a regression\n  test (`hq-no-test-shortcuts`, `hq-bugfix-requires-tests`).\n- Additive-first \u002F defensive-consumer ordering is a hard rule for multi-repo\n  ships — both for merge order and deploy order.\n- Merged ≠ deployed ≠ working. Only a live smoke plus healthy KPIs closes the\n  loop; a standing monitor keeps it closed.\n- Anchor every git\u002Fgh mutation (`git -C`, `gh -R`); never mutate from HQ root.\n- Company isolation: one company's credentials and deploy targets only.\n- Failures are reported plainly and immediately; healing is transparent in the\n  final report, not hidden.\n- Documentation (Step 7) is foreground, last, and non-gating: it runs only after\n  the ship is verified, never in the background, and a docs failure never\n  downgrades a merged\u002Fdeployed\u002Fsmoked ship. Compose `document-release` +\n  `publish-docs`; do not reimplement doc logic here.\n",{"name":5,"description":7,"allowed-tools":47},"Bash, Read, Grep, Glob, Write, Edit, Agent, AskUserQuestion, TaskCreate, TaskUpdate, Monitor, CronCreate, CronList","main","205cf61728a27ef15e9153aa38df5856fc8d82f5",".claude\u002Fskills\u002Fship",18,"https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core","https:\u002F\u002Fgithub.com\u002Findigoai-us","https:\u002F\u002Fhqforwork.com\u002F","The AI Context Layer for Teams","2026-11-12 06:53:38",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add indigoai-us\u002Fhq-core --skill ship",{"tool":63,"command":64},"bunx","bunx skills add indigoai-us\u002Fhq-core --skill ship",{"tool":66,"command":67},"pnpm","pnpm dlx skills add indigoai-us\u002Fhq-core --skill ship","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fship\u002FSKILL.md",true,[71],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"agents\u002Fopenai.yaml","REFERENCE","参考文档",141,"https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fship\u002Fagents\u002Fopenai.yaml",[78,96,124,148,158,168],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":42},"01M71E4MQ04WPK1EVDS7VKJ3E8","social-graphic","Generate 1080x1080 HTML social graphics for HQ update posts.","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fworkers\u002Fpublic\u002Fsocial-strategist\u002Fskills\u002Fsocial-graphic\u002FSKILL.md",[],[85,86,36,87,28,29,30,88,89,90,91,92,93,94,95],"social","social graphic","html","update","generate","graphics","browser","open","agent-browser","for","posts",{"skillNo":97,"name":93,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":107,"publishedAt":42},"01M71E4H33K4P5H5M7ENPTMFSC","Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to \"open a website\", \"fill out a form\", \"click a button\", \"take a screenshot\", \"scrape data from a page\", \"test this web app\", \"login to a site\", \"automate browser actions\", or any task requiring programmatic web interaction.","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fworkers\u002Fpublic\u002Fqa-tester\u002Fskills\u002Fagent-browser\u002FSKILL.md",[101,104],{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":105,"categoryName":106,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[108,91,109,110,111,112,36,113,114,115,116,117,92,118,93,119,120,121,122,123],"agent browser","click","ai agents","app","scrape","when","apps","actions","extracting","take a screenshot","testing","programmatic","browser automation","website","cli","interaction",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":42},"01M71E4FDBD7J8Y45JJ9KMMYGN","work-mesh","Work Mesh Live — automatic presence via hq mesh daemon; context reconcile\u002Forganize; manual session task-status, blocked, and note only.","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fwork-mesh\u002FSKILL.md",[],[131,132,133,36,134,135,136,137,138,139,140,141,142,143,30,144,145,146,147],"work mesh","work","mesh","status","context","note","live","presence","automatic","reconcile","only","organize","task","session","manual","daemon","via",{"skillNo":149,"name":34,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":42},"01M71E4EGHNAAGWAPV6KGBMQ9W","Parity worker review skill (materialization fixture).","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fscripts\u002Ftests\u002Ffixtures\u002Fagent-session\u002Fworker-materialization\u002Fparity-worker\u002Fskills\u002Freview\u002FSKILL.md",[],[34,154,155,156,157],"review skill","fixture","parity","worker",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":42},"01M71E4D1FZDJPDC15DRERKX8Y","run","Run or list HQ workers (parity fixture).","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fscripts\u002Ftests\u002Ffixtures\u002Fagent-session\u002Fskills\u002Frun\u002FSKILL.md",[],[160,165,166,156,167,155],"parity fixture","workers","list",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":42},"01M71E4BF4MV5SEWZJZ4T1QPQW","handoff","Preserve session state for a follow-up agent (parity fixture).","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fscripts\u002Ftests\u002Ffixtures\u002Fagent-session\u002Fskills\u002Fhandoff\u002FSKILL.md",[],[170,165,175,176,144,177,94,156,178,179,155],"up","preserve","session state","follow-up","state"]