[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CEB7Z7VD8CBTACJXW7KBMH":3,"skill-same:01M6CEB7Z7VD8CBTACJXW7KBMH":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6CEB7Z7VD8CBTACJXW7KBMH","ship-pr",null,"Use when the user is done editing and wants to ship the current branch via a pull request — phrases like \"open a PR\", \"ship it\", \"ship this\", \"submit the PR\", \"let's send it\", \"merge it\", \"land this\", \"提 PR\", \"提个 PR\", \"提个 MR\". Trigger whenever the user signals a change is finished and should head to the default branch, even if they don't say the word \"PR\". Walks the whole branch-to-merge flow for any GitHub repo with a mandatory review gate — the steps and their rules live in the body. Do NOT trigger for `gh pr view` \u002F status checks on an existing PR, for draft \u002F WIP PRs the user wants opened but not merged, or for cutting a release tag.","openbootdotdev\u002Fopenboot","openbootdotdev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F258731499?v=4","01M6CEB0H2QJFM87B03REQN33B","01M6CEB0MWC2NSC2NMM7R5F2PV",278,"MIT","https:\u002F\u002Fgithub.com\u002Fopenbootdotdev\u002Fopenboot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fship-pr\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"ship pr","pr","ship","default","review","view","repo","branch","editing","Word","gh pr","open","flow","pull","land","git","release","status","merge","change","2026-11-10 10:12:30",false,"---\nname: ship-pr\ndescription: Use when the user is done editing and wants to ship the current branch via a pull request — phrases like \"open a PR\", \"ship it\", \"ship this\", \"submit the PR\", \"let's send it\", \"merge it\", \"land this\", \"提 PR\", \"提个 PR\", \"提个 MR\". Trigger whenever the user signals a change is finished and should head to the default branch, even if they don't say the word \"PR\". Walks the whole branch-to-merge flow for any GitHub repo with a mandatory review gate — the steps and their rules live in the body. Do NOT trigger for `gh pr view` \u002F status checks on an existing PR, for draft \u002F WIP PRs the user wants opened but not merged, or for cutting a release tag.\nlicense: MIT\nmetadata:\n  category: git\n  language: en\n---\n\n# Ship a PR\n\nThe canonical way to move a finished change from a feature branch to the\nrepo's default branch through a pull request — for **any** GitHub repo,\nwithout hardcoding one project's build commands or check names.\n\nThere are two gates between your branch and the default branch:\n\n- **Mechanical** — the repo's required CI checks. GitHub already enforces\n  these via branch protection; let them run.\n- **Inferential** — a human-judgment review of the diff. CI catches what\n  it knows how to check; this catches behaviour, design, test coverage,\n  risk, and rollback. This gate is the reason the skill exists.\n\n**Auto-merge is intentionally not used.** `gh pr merge --auto` merges the\nmoment CI passes, which skips the review gate entirely — that defeats the\npurpose. The merge command is run from this session, *after* the diff has\nbeen reviewed.\n\n## When NOT to use\n\n- **Draft \u002F WIP PRs** the user wants opened but not merged → not this\n  flow; if it's already been invoked, just `gh pr create --draft` and stop.\n- **Changes to `.github\u002Fworkflows\u002F`, branch protection, or repo settings**\n  → these usually need a human in the GitHub UI too; flag it.\n- **Cutting a release** (tags like `v1.2.3`) → releases follow the repo's\n  own release process, not this flow.\n\n## The flow\n\n### Step 1 — Confirm the branch is shippable\n\n```bash\ngit status -sb                                # clean except the expected diff?\ngit rev-parse --abbrev-ref HEAD               # the current branch\ngit fetch origin --quiet                      # refresh the remote base ref\ngit remote set-head origin --auto >\u002Fdev\u002Fnull  # fetch never creates origin\u002FHEAD; this does\nBASE=$(git symbolic-ref --quiet --short refs\u002Fremotes\u002Forigin\u002FHEAD 2>\u002Fdev\u002Fnull | sed 's@^origin\u002F@@')\nBASE=${BASE:-main}                            # the repo's default branch\ngit log --oneline \"origin\u002F$BASE..HEAD\"        # commits actually exist\n```\n\n`$BASE` is the repo's default branch — usually `main`, sometimes `master`\nor `develop`. Don't assume `main`; use what was detected. Comparisons run\nagainst the **remote** ref `origin\u002F$BASE` (hence the `git fetch`), so they\nmatch what GitHub will diff the PR against even when the local base branch\nis missing or stale — common in worktrees and feature-only checkouts.\n\n- The remote isn't GitHub (`git remote get-url origin`) → **stop**; this\n  flow is `gh`-only, tell the user (a GitLab \"MR\" needs a different flow).\n- On the base branch → **stop**, make a feature branch first.\n- No commits ahead of `origin\u002F$BASE` → **stop**, nothing to ship.\n- A PR may already exist for this branch (`gh pr view` succeeds) → still\n  push (Step 2) so the PR has the latest commits, then skip Step 3 and\n  continue at Step 4.\n\n### Step 2 — Push\n\n```bash\ngit push -u origin \"$(git rev-parse --abbrev-ref HEAD)\"\n```\n\nIf the repo installs a `pre-push` hook (Husky, `core.hooksPath`, etc.) it\nruns here automatically — don't re-run the same lint\u002Ftest suite by hand.\nIf no hook is installed, that's the user's setup; CI is still the gate.\n\n### Step 3 — Open the PR\n\nCheck for a PR template first — using it keeps the PR consistent with the\nrepo's conventions instead of inventing a different shape:\n\n```bash\nls .github\u002Fpull_request_template.md .github\u002FPULL_REQUEST_TEMPLATE.md \\\n   PULL_REQUEST_TEMPLATE.md pull_request_template.md \\\n   docs\u002FPULL_REQUEST_TEMPLATE.md docs\u002Fpull_request_template.md \\\n   .github\u002FPULL_REQUEST_TEMPLATE\u002F 2>\u002Fdev\u002Fnull\n```\n\nIf a template exists, fill in its sections honestly — including any\ncross-repo \u002F checklist items (e.g. \"needs a docs update?\"). Do **not**\ndiscard it by passing a wholly custom `--body`. `gh pr create` without\n`--body` tries to open an interactive editor, so fill the template\noffline and pass it back:\n\n```bash\ngh pr create --title \"\u003Cconventional commit subject>\" --body-file \u003Cfilled-template-file>\n```\n\nIf there's no template, fall back to a sensible default:\n\n```bash\ngh pr create --title \"\u003Cconventional commit subject>\" --body \"$(cat \u003C\u003C'EOF'\n## Summary\n\n- \u003Cwhat changed and why>\n\n## Test plan\n\n- [ ] \u003Chow you verified>\nEOF\n)\"\n```\n\nTitle rules:\n\n- Conventional Commits prefix: `feat:` \u002F `fix:` \u002F `docs:` \u002F `refactor:` \u002F\n  `test:` \u002F `chore:` \u002F `ci:` \u002F `perf:` \u002F `style:` \u002F `build:` \u002F `revert:`.\n- Optional scope: `fix(api):`, `feat(editor):`.\n- Keep under ~70 chars. Detail goes in the body.\n- Several commits on the branch → write a fresh subject that sums up the\n  whole PR (squash merge makes it the final commit subject).\n\n### Step 4 — Wait for CI\n\n```bash\ngh pr checks --watch\n```\n\nThis blocks until every check finishes. (Run straight after `gh pr create`\nit can error with \"no checks reported\" before the first check registers —\nwait a few seconds and re-run; exit code 8 just means checks are still\npending.) If a **required** check fails:\n\n- **Stop. Do not proceed to review or merge.**\n- Read the failure (`gh run view --log-failed`), explain it to the user,\n  and ask whether to fix it now.\n- Checks that aren't required (drift sensors, optional coverage, advisory\n  scans) are informational — flag them, but they don't block the merge.\n\nIf you can't tell which checks are required, the ones branch protection\nenforces are; `gh pr checks` marks the rest, and the merge in Step 7 will\nrefuse anyway if a required one is red.\n\n### Step 5 — Review the full diff locally\n\nOnce CI is green, review the **full PR diff** locally for behaviour, design,\ntest coverage, risk, and rollback:\n\n```bash\ngit diff \"origin\u002F$BASE\"...HEAD\n```\n\n- Use a repo-specific review skill when available; otherwise review the diff\n  directly against the repository's conventions and the PR's stated scope.\n- Read existing PR comments and formal reviews for any unresolved findings.\n- Summarize the findings and relevant verification in the session. Passing CI\n  alone does not satisfy this review gate.\n\nCarry the findings into Step 6.\n\n### Step 6 — Triage the findings\n\nEvery finding lands in exactly one bucket. Getting this right is what\nkeeps the gate from failing open.\n\n**Self-fixable → fix now, then loop back to Step 4.** Mechanical\ncorrections clearly inside the PR's stated scope: typos, formatting, doc\nwording, dead code this PR introduced, missing imports, missing tests for\nbranches this PR adds, bug fixes that don't change observable behaviour,\nor following through on a rule the user already stated this session. Fix\nit, push to the same branch, wait for CI again, then review the updated\nfull diff locally as in Step 5 and re-triage. Don't prompt the user — the\npoint is to spend their attention only on real decisions.\n\n**Needs user judgment → surface and stop.** Anything with a genuine\nchoice: design \u002F API shape \u002F behaviour changes, anything touching a\ndeliberate prior decision or an existing convention, anything that would\nexpand the PR beyond its stated scope — anything you'd ask a teammate\nabout before pushing. State the file\u002Fline, the option, and the question;\nstop the flow.\n\n**Clean → merge directly.** If CI is green AND nothing is self-fixable\nAND nothing needs judgment, go straight to Step 7. Don't ask \"want me to\nmerge?\" — asking when there's nothing to decide just burns attention. The\nloop is supposed to close itself.\n\nRule of thumb: would a thoughtful engineer file this as a question, push\na follow-up commit, or just merge it? Escalate \u002F fix \u002F merge accordingly.\n\n### Step 7 — Merge\n\nReached on a clean review, or after the user approved a merge following an\nescalation.\n\n```bash\ngh pr merge --squash --delete-branch\n```\n\n- **No `--auto`** — it skips the review gate (Step 5).\n- **No `--admin`** — it bypasses branch protection.\n- `--squash` keeps the default branch at one commit per PR; if the repo\n  only allows merge commits or rebase, use `--merge` \u002F `--rebase` instead\n  (`gh` errors and tells you if the method isn't enabled).\n- Branch protection still applies — if something flipped red since Step 4,\n  GitHub refuses and you loop back to Step 4.\n- Refused for missing approvals \u002F unresolved conversations → that's an\n  org-policy gate, not CI; looping back to Step 4 can never clear it.\n  Surface it to the user instead.\n\nReport the result as a one-liner (\"PR #N merged, branch deleted, local\nsynced\"). On a clean review, don't ask for confirmation *before* merging.\n\n### Step 8 — Local cleanup\n\n`--delete-branch` deleted the local *and* remote branch, and `gh` already\nswitched the checkout back to the base branch — so don't `git branch -d`\nafterwards; the branch is gone and the command just errors. The one thing\n`gh` doesn't do is pull:\n\n```bash\ngit pull --ff-only\n```\n\nIf the merge ran from somewhere unusual (a worktree, detached HEAD) and\nthe local branch survived, delete it manually with `git branch -d`. This\nstep is part of the loop, not optional: because the merge is synchronous\n(no `--auto`), there's no reason to leave the checkout behind the base.\n\n## What NOT to do\n\n- **No `--auto` by default** — it skips the review gate, the whole reason\n  for this skill. If the user explicitly asks for it: don't arm it\n  silently — say what it skips, and offer to close the gate now (review\n  the diff first, then arm auto-merge; at that point `--auto` only skips\n  the CI wait). If they still want it after being told, do it: their\n  repo, their call. Caveat: auto-merge stays armed across later pushes,\n  so disarm or re-review before pushing anything else.\n- **No `--admin`** — bypasses branch protection.\n- **Don't merge before CI finishes** — even a trivial-looking diff; drift\n  checks sometimes catch surprising things.\n- **Don't amend \u002F force-push after `gh pr create`** unless the user asks —\n  it invalidates in-flight reviews and re-runs CI from scratch.\n- **Don't push directly to the default branch** — branch protection\n  rejects it, and it skips both gates.\n- **Don't auto-fix findings that need judgment** — behaviour changes,\n  scope expansion, or anything touching a prior deliberate choice gets\n  surfaced in Step 6, not silently committed. What counts as self-fixable\n  is exactly Step 6's first bucket — when in doubt, escalate.\n","# Ship a PR\n\nThe canonical way to move a finished change from a feature branch to the\nrepo's default branch through a pull request — for **any** GitHub repo,\nwithout hardcoding one project's build commands or check names.\n\nThere are two gates between your branch and the default branch:\n\n- **Mechanical** — the repo's required CI checks. GitHub already enforces\n  these via branch protection; let them run.\n- **Inferential** — a human-judgment review of the diff. CI catches what\n  it knows how to check; this catches behaviour, design, test coverage,\n  risk, and rollback. This gate is the reason the skill exists.\n\n**Auto-merge is intentionally not used.** `gh pr merge --auto` merges the\nmoment CI passes, which skips the review gate entirely — that defeats the\npurpose. The merge command is run from this session, *after* the diff has\nbeen reviewed.\n\n## When NOT to use\n\n- **Draft \u002F WIP PRs** the user wants opened but not merged → not this\n  flow; if it's already been invoked, just `gh pr create --draft` and stop.\n- **Changes to `.github\u002Fworkflows\u002F`, branch protection, or repo settings**\n  → these usually need a human in the GitHub UI too; flag it.\n- **Cutting a release** (tags like `v1.2.3`) → releases follow the repo's\n  own release process, not this flow.\n\n## The flow\n\n### Step 1 — Confirm the branch is shippable\n\n```bash\ngit status -sb                                # clean except the expected diff?\ngit rev-parse --abbrev-ref HEAD               # the current branch\ngit fetch origin --quiet                      # refresh the remote base ref\ngit remote set-head origin --auto >\u002Fdev\u002Fnull  # fetch never creates origin\u002FHEAD; this does\nBASE=$(git symbolic-ref --quiet --short refs\u002Fremotes\u002Forigin\u002FHEAD 2>\u002Fdev\u002Fnull | sed 's@^origin\u002F@@')\nBASE=${BASE:-main}                            # the repo's default branch\ngit log --oneline \"origin\u002F$BASE..HEAD\"        # commits actually exist\n```\n\n`$BASE` is the repo's default branch — usually `main`, sometimes `master`\nor `develop`. Don't assume `main`; use what was detected. Comparisons run\nagainst the **remote** ref `origin\u002F$BASE` (hence the `git fetch`), so they\nmatch what GitHub will diff the PR against even when the local base branch\nis missing or stale — common in worktrees and feature-only checkouts.\n\n- The remote isn't GitHub (`git remote get-url origin`) → **stop**; this\n  flow is `gh`-only, tell the user (a GitLab \"MR\" needs a different flow).\n- On the base branch → **stop**, make a feature branch first.\n- No commits ahead of `origin\u002F$BASE` → **stop**, nothing to ship.\n- A PR may already exist for this branch (`gh pr view` succeeds) → still\n  push (Step 2) so the PR has the latest commits, then skip Step 3 and\n  continue at Step 4.\n\n### Step 2 — Push\n\n```bash\ngit push -u origin \"$(git rev-parse --abbrev-ref HEAD)\"\n```\n\nIf the repo installs a `pre-push` hook (Husky, `core.hooksPath`, etc.) it\nruns here automatically — don't re-run the same lint\u002Ftest suite by hand.\nIf no hook is installed, that's the user's setup; CI is still the gate.\n\n### Step 3 — Open the PR\n\nCheck for a PR template first — using it keeps the PR consistent with the\nrepo's conventions instead of inventing a different shape:\n\n```bash\nls .github\u002Fpull_request_template.md .github\u002FPULL_REQUEST_TEMPLATE.md \\\n   PULL_REQUEST_TEMPLATE.md pull_request_template.md \\\n   docs\u002FPULL_REQUEST_TEMPLATE.md docs\u002Fpull_request_template.md \\\n   .github\u002FPULL_REQUEST_TEMPLATE\u002F 2>\u002Fdev\u002Fnull\n```\n\nIf a template exists, fill in its sections honestly — including any\ncross-repo \u002F checklist items (e.g. \"needs a docs update?\"). Do **not**\ndiscard it by passing a wholly custom `--body`. `gh pr create` without\n`--body` tries to open an interactive editor, so fill the template\noffline and pass it back:\n\n```bash\ngh pr create --title \"\u003Cconventional commit subject>\" --body-file \u003Cfilled-template-file>\n```\n\nIf there's no template, fall back to a sensible default:\n\n```bash\ngh pr create --title \"\u003Cconventional commit subject>\" --body \"$(cat \u003C\u003C'EOF'\n## Summary\n\n- \u003Cwhat changed and why>\n\n## Test plan\n\n- [ ] \u003Chow you verified>\nEOF\n)\"\n```\n\nTitle rules:\n\n- Conventional Commits prefix: `feat:` \u002F `fix:` \u002F `docs:` \u002F `refactor:` \u002F\n  `test:` \u002F `chore:` \u002F `ci:` \u002F `perf:` \u002F `style:` \u002F `build:` \u002F `revert:`.\n- Optional scope: `fix(api):`, `feat(editor):`.\n- Keep under ~70 chars. Detail goes in the body.\n- Several commits on the branch → write a fresh subject that sums up the\n  whole PR (squash merge makes it the final commit subject).\n\n### Step 4 — Wait for CI\n\n```bash\ngh pr checks --watch\n```\n\nThis blocks until every check finishes. (Run straight after `gh pr create`\nit can error with \"no checks reported\" before the first check registers —\nwait a few seconds and re-run; exit code 8 just means checks are still\npending.) If a **required** check fails:\n\n- **Stop. Do not proceed to review or merge.**\n- Read the failure (`gh run view --log-failed`), explain it to the user,\n  and ask whether to fix it now.\n- Checks that aren't required (drift sensors, optional coverage, advisory\n  scans) are informational — flag them, but they don't block the merge.\n\nIf you can't tell which checks are required, the ones branch protection\nenforces are; `gh pr checks` marks the rest, and the merge in Step 7 will\nrefuse anyway if a required one is red.\n\n### Step 5 — Review the full diff locally\n\nOnce CI is green, review the **full PR diff** locally for behaviour, design,\ntest coverage, risk, and rollback:\n\n```bash\ngit diff \"origin\u002F$BASE\"...HEAD\n```\n\n- Use a repo-specific review skill when available; otherwise review the diff\n  directly against the repository's conventions and the PR's stated scope.\n- Read existing PR comments and formal reviews for any unresolved findings.\n- Summarize the findings and relevant verification in the session. Passing CI\n  alone does not satisfy this review gate.\n\nCarry the findings into Step 6.\n\n### Step 6 — Triage the findings\n\nEvery finding lands in exactly one bucket. Getting this right is what\nkeeps the gate from failing open.\n\n**Self-fixable → fix now, then loop back to Step 4.** Mechanical\ncorrections clearly inside the PR's stated scope: typos, formatting, doc\nwording, dead code this PR introduced, missing imports, missing tests for\nbranches this PR adds, bug fixes that don't change observable behaviour,\nor following through on a rule the user already stated this session. Fix\nit, push to the same branch, wait for CI again, then review the updated\nfull diff locally as in Step 5 and re-triage. Don't prompt the user — the\npoint is to spend their attention only on real decisions.\n\n**Needs user judgment → surface and stop.** Anything with a genuine\nchoice: design \u002F API shape \u002F behaviour changes, anything touching a\ndeliberate prior decision or an existing convention, anything that would\nexpand the PR beyond its stated scope — anything you'd ask a teammate\nabout before pushing. State the file\u002Fline, the option, and the question;\nstop the flow.\n\n**Clean → merge directly.** If CI is green AND nothing is self-fixable\nAND nothing needs judgment, go straight to Step 7. Don't ask \"want me to\nmerge?\" — asking when there's nothing to decide just burns attention. The\nloop is supposed to close itself.\n\nRule of thumb: would a thoughtful engineer file this as a question, push\na follow-up commit, or just merge it? Escalate \u002F fix \u002F merge accordingly.\n\n### Step 7 — Merge\n\nReached on a clean review, or after the user approved a merge following an\nescalation.\n\n```bash\ngh pr merge --squash --delete-branch\n```\n\n- **No `--auto`** — it skips the review gate (Step 5).\n- **No `--admin`** — it bypasses branch protection.\n- `--squash` keeps the default branch at one commit per PR; if the repo\n  only allows merge commits or rebase, use `--merge` \u002F `--rebase` instead\n  (`gh` errors and tells you if the method isn't enabled).\n- Branch protection still applies — if something flipped red since Step 4,\n  GitHub refuses and you loop back to Step 4.\n- Refused for missing approvals \u002F unresolved conversations → that's an\n  org-policy gate, not CI; looping back to Step 4 can never clear it.\n  Surface it to the user instead.\n\nReport the result as a one-liner (\"PR #N merged, branch deleted, local\nsynced\"). On a clean review, don't ask for confirmation *before* merging.\n\n### Step 8 — Local cleanup\n\n`--delete-branch` deleted the local *and* remote branch, and `gh` already\nswitched the checkout back to the base branch — so don't `git branch -d`\nafterwards; the branch is gone and the command just errors. The one thing\n`gh` doesn't do is pull:\n\n```bash\ngit pull --ff-only\n```\n\nIf the merge ran from somewhere unusual (a worktree, detached HEAD) and\nthe local branch survived, delete it manually with `git branch -d`. This\nstep is part of the loop, not optional: because the merge is synchronous\n(no `--auto`), there's no reason to leave the checkout behind the base.\n\n## What NOT to do\n\n- **No `--auto` by default** — it skips the review gate, the whole reason\n  for this skill. If the user explicitly asks for it: don't arm it\n  silently — say what it skips, and offer to close the gate now (review\n  the diff first, then arm auto-merge; at that point `--auto` only skips\n  the CI wait). If they still want it after being told, do it: their\n  repo, their call. Caveat: auto-merge stays armed across later pushes,\n  so disarm or re-review before pushing anything else.\n- **No `--admin`** — bypasses branch protection.\n- **Don't merge before CI finishes** — even a trivial-looking diff; drift\n  checks sometimes catch surprising things.\n- **Don't amend \u002F force-push after `gh pr create`** unless the user asks —\n  it invalidates in-flight reviews and re-runs CI from scratch.\n- **Don't push directly to the default branch** — branch protection\n  rejects it, and it skips both gates.\n- **Don't auto-fix findings that need judgment** — behaviour changes,\n  scope expansion, or anything touching a prior deliberate choice gets\n  surfaced in Step 6, not silently committed. What counts as self-fixable\n  is exactly Step 6's first bucket — when in doubt, escalate.\n",{"name":5,"license":14,"metadata":43,"description":7},{"category":33,"language":44},"en","main","e91cfab35d791527997fa91f39a171f590c3a9c0",".agents\u002Fskills\u002Fship-pr",14,"https:\u002F\u002Fgithub.com\u002Fopenbootdotdev\u002Fopenboot","https:\u002F\u002Fgithub.com\u002Fopenbootdotdev","https:\u002F\u002Fopenboot.dev","One-line macOS development environment setup","2026-11-03 15:51:25",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add openbootdotdev\u002Fopenboot --skill ship-pr",{"tool":60,"command":61},"bunx","bunx skills add openbootdotdev\u002Fopenboot --skill ship-pr",{"tool":63,"command":64},"pnpm","pnpm dlx skills add openbootdotdev\u002Fopenboot --skill ship-pr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fopenbootdotdev\u002Fopenboot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fship-pr\u002FSKILL.md",true,[68],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"agents\u002Fopenai.yaml","REFERENCE","参考文档",198,"https:\u002F\u002Fgithub.com\u002Fopenbootdotdev\u002Fopenboot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fship-pr\u002Fagents\u002Fopenai.yaml",[75,80,88,96,109],{"skillNo":76,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":38},"01M6CEBFJG99P67S657BG19QX1","https:\u002F\u002Fgithub.com\u002Fopenbootdotdev\u002Fopenboot\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fship-pr\u002FSKILL.md",[],[18,19,20],{"skillNo":81,"name":82,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":38},"01M6CEBD6NCGP09SNVT7FGQ3AN","bootstrap-feature","https:\u002F\u002Fgithub.com\u002Fopenbootdotdev\u002Fopenboot\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbootstrap-feature\u002FSKILL.md",[],[86,87],"bootstrap","bootstrap feature",{"skillNo":89,"name":90,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":38},"01M6CEBB2Y58WJK0HEGA8BGK9T","architecture-review","https:\u002F\u002Fgithub.com\u002Fopenbootdotdev\u002Fopenboot\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Farchitecture-review\u002FSKILL.md",[],[22,94,95],"architecture","architecture review",{"skillNo":97,"name":82,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":38},"01M6CEB54695DZXA9H6463HWFM","Use when adding a new CLI subcommand or feature to openboot. Walks through the canonical pattern: cobra command registration, runner wiring, archtest awareness, and test placement. Trigger when the user says \"add a command\", \"new subcommand\", \"implement feature X for the CLI\", or starts editing under internal\u002Fcli\u002F.","https:\u002F\u002Fgithub.com\u002Fopenbootdotdev\u002Fopenboot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fbootstrap-feature\u002FSKILL.md",[],[86,87,102,103,104,26,105,106,107,108],"use","user","command","awareness","cli","test","implement",{"skillNo":110,"name":90,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":38},"01M6CEB28241PPSFKVCHX7FVND","Use when reviewing a PR, branch, or staged diff in the openboot repo. Audits the change against project invariants from AGENTS.md — subprocess hygiene, HTTP wrapper usage, error wrapping, dry-run gating, UI helper usage, test placement. Trigger when user says \"review this\", \"check this PR\", \"audit the diff\", or asks about whether a change follows project conventions.","https:\u002F\u002Fgithub.com\u002Fopenbootdotdev\u002Fopenboot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Farchitecture-review\u002FSKILL.md",[],[22,95,94,115,116,102,103,117,24,25,118,119,120,121,19,122,37,107],"Wrapper","diff","check","ui","audit","run","project conventions","http"]