菜单
Synthesize the current conversation into a spec (problem, solution, user stories, decisions, test seams, enforcement plan) and publish it to the tracker. No interview — pure synthesis. Use when the user wants a spec (aka PRD) written up from what's been discussed.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Regroup the commits since the previous bump (or a given base) into logical commits — one per concern, bump kept last — via scripts/fleet/consolidate-commits.mts. "Consolidate commits" never means squash-to-one; that is squashing-history.
Drives the Cursor Bugbot review-and-fix loop on a PR. Inventories open Bugbot threads, classifies each (real bug / false positive / already fixed), fixes the real ones, replies on the inline thread (never as a detached PR comment), updates the PR title/body if scope shifted, and pushes. Use when reviewing a PR you just authored, after `gh pr create`, or after a new Bugbot pass on an existing PR.
Reviews the current branch against a base ref using multiple AI backends. Runs a Workflow that streams the diff through discovery, discovery-secondary, remediation, and adversarial-verify stages, routing each stage to the available agents (codex, claude, opencode, kimi, …) and gracefully skipping any backend that isn't installed. Writes a markdown findings report under docs/. Use when preparing or updating a PR, before merging a feature branch, or when wanting an independent second opinion from a different agent.
Full repo onboarding wizard. Orchestrates all setup concerns for a new engineer or a fresh clone — API token, OS keychain, shell rc bridge, native messaging host, security tools, and repo-specific initialization. Invoke with /setup-repo.
Propagate a wheelhouse template change to every fleet repo. Packages the canonical fleet-repo list, the FLEET_SYNC=1 sentinel pattern, the worktree-per-repo loop, push-direct + PR-fallback, and worktree-cleanup that survives mid-loop crashes. Use when a wheelhouse template SHA needs to land in every fleet repo, or when batching multiple template SHAs into one cascade wave. Tool-version pin propagation is the wheelhouse pipeline's job (scripts/repo/pipeline.mts), not this skill's.
Manages git worktrees per the fleet's parallel-Claude-sessions rule. Creates new task-worktrees, fans out one worktree per open PR for parallel review, and prunes spent worktrees that have nothing left to land — clean trees whose branch was deleted upstream OR is fully merged into the remote default branch. Use when starting a task that needs an isolated working tree, when reviewing every open PR locally without disturbing the primary checkout, or when cleaning up after merges.
| name | authoring-spec |
| description | Synthesize the current conversation into a spec (problem, solution, user stories, decisions, test seams, enforcement plan) and publish it to the tracker. No interview — pure synthesis. Use when the user wants a spec (aka PRD) written up from what's been discussed. |
| user-invocable | true |
Turn the conversation + codebase understanding into a spec. Do NOT interview — just
synthesize what you already know. Adapted from mattpocock/to-spec; the natural
input to decomposing-tickets. Two fleet additions: test seams are a first-class
output, and every spec names its enforcement plan.
Explore the repo (if you haven't) so the spec uses the project's domain vocabulary; respect ADRs in the area.
Sketch the seams at which the feature is tested. Prefer existing seams; use the
highest seam possible; the fewer across the codebase the better — the ideal is
one. New seams go in at the highest point. Fleet seam doctrine:
test-layout (public interface, no
source-text assertions). Check the seams with the user before writing.
Sections: Problem (user's perspective) · Solution (user's perspective) · User Stories (a long numbered "As an , I want , so that " list, exhaustive) · Implementation Decisions (modules, interfaces, schema/API contracts — no file paths or code snippets, they go stale; exception: a prototype snippet that encodes a decision more precisely than prose) · Testing Decisions (what makes a good test here, which modules, prior art) · Enforcement plan · Out of Scope.
Enforcement plan is the fleet's code-is-law addition: name which hook / lint
rule / check script will verify each discipline the feature introduces. A spec that
introduces a rule with no enforcer is policy on paper
(code-is-law).
The spec is a public-facing surface. Run the prose skill over it and apply
prose-style-and-doctrine:
lead with the point, cut throat-clearers/hedges/filler, evidence over assertion.
Public-surface hygiene: no real customer/company name, no private repo, no Linear
ref, no bare #N.
Publish to the tracker (GitHub via gh, or the Linear MCP save_document /
save_issue tool) with the ready-for-agent triage label. Publishing is mutating +
outward-facing — confirm the destination first.
The spec has all sections including named test seams and an enforcement plan, passed the prose + doctrine pass, leaks no private name, and is published to the confirmed tracker.
