菜单
Scaffold a new steer plugin skill with correct frontmatter for its invocation tier, plus a CHANGELOG [Unreleased] stub. Repo-local dev helper for e22-plugins; does not ship. Use when adding a skill under plugins/steer/skills/.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | new-skill |
| description | Scaffold a new steer plugin skill with correct frontmatter for its invocation tier, plus a CHANGELOG [Unreleased] stub. Repo-local dev helper for e22-plugins; does not ship. Use when adding a skill under plugins/steer/skills/. |
| allowed-tools | ["Read","Write","Edit","Glob","Bash(uv run python scripts/check_plugin.py)","Bash(uv run python scripts/check_standards.py)","Bash(mise run plugin-check)"] |
A repo-local convenience wrapper. It does not bypass any validation — it
generates a correct starting point and then runs the existing plugin-check.
See AUTHORING.md → "Skill frontmatter schema" for the full rules.
Could this be a mode or a hidden delegate instead? (See AUTHORING.md →
"Skill vs. mode".) Every new visible skill widens the menu, so ask first:
argument-hint + <!-- steer:modes … -->), not a new skill.user-invocable: false) and add the hand-off to its parent./steer:setup).
Only continue scaffolding a new front door if none of these fit. If the new
skill is hidden, also add a routing line to plugins/steer/rules/00-router.md.Gather inputs (ask the user, or take them from the invocation):
name — kebab-case, no /steer: prefix. Must not already exist under
plugins/steer/skills/.description — one prose sentence.when_to_use — when to invoke (use a folded >- block if it contains
quotes or colons; see the quoting gotcha in AUTHORING.md).read-only (Tier 1): add disallowed-tools: Edit, Write, NotebookEdit, EnterWorktree.side-effecting (Tier 2): may edit/commit; add allowed-tools for the
routine idempotent ops it always runs (keep git push/PR gated).internal (Tier 3): add user-invocable: false.Verify the name is free: Glob plugins/steer/skills/*/SKILL.md and
confirm no directory already matches name.
Create plugins/steer/skills/<name>/SKILL.md with frontmatter built from
the inputs (always name, description, when_to_use; tier-specific tool
fields as above) and a short imperative body skeleton (# /steer:<name> title,
a one-line purpose, a ## Steps placeholder). Do not leave literal
TODO/FIXME/[Replace tokens — check_plugin.py rejects them in skills.
Add a CHANGELOG stub: under ## steer → ### [Unreleased] in
CHANGELOG.md, add a bullet like - Add /steer:<name> skill (<one-line>).
Create the ### [Unreleased] heading if absent (above the newest version).
Validate and report: run mise run plugin-check (or
uv run python scripts/check_plugin.py && uv run python scripts/check_standards.py).
Report pass/fail and remind the user to fill in the skill body and run
mise run check before committing.
Scaffold an autonomous loop for a managed repo — a scheduled GitHub Actions workflow that wakes on its own, triages work (CI failures, open issues, drift) via /steer:audit + /steer:next, drafts fixes in isolated worktrees reviewed by steer-reviewer, and opens draft PRs. Wired to stop at every human gate (rule 53): it delivers up to the PR, it never merges/deploys. Instantiates templates/github/workflows/steer-loop.yml and lands it via the normal autonomous branch-push + PR (Commit autonomy — the merge review is the gate).
Adopt an existing repo that never went through bootstrap (a "vibe-coded" app) into the standards — reverse-engineer the /spec from the code, triage productionization (Keep/Refactor/Rewrite/Reject per area), and sync the plugin's bundled scaffolding without clobbering working code.
Guided flow for a non-technical product owner — idea → interview → approved spec → working local app → handoff for dev review, with Claude driving all tooling.
One-time setup for a new managed repo — bootstrap the /spec spine + repo scaffolding from the plugin's bundled scaffold (the plugin replaces the old static repository-template as the bootstrap source), or resolve placeholders in a legacy template fork. In both cases pin the toolchain and leave the repo working spec-first.
Absorb a PO-supplied spec/roadmap document (docx/pptx/xlsx/pdf) into the /spec spine — version-stamp and commit the binary plus a normalized Markdown extraction under spec/sources/ — relocating the dropped file into that canonical home so it does not linger where it was uploaded — git-diff it against the prior version, and surface a structured what-changed report. Then route the real changes into intent/contract/vision/roadmap and the tracker via the relevant skills, never clobbering human-authored prose (conflicts become Open questions). Idempotent on an unchanged document. In clarify mode, absorbs a client clarification document instead: it segments the extraction, maps each unit against open questions and the feature list, and sorts them into a three-bucket worklist — answers routed to /steer:questions, new scope to the reconcile rows, unmatched surfaced for the human.
Make GitHub branch protection — the real gate against direct-push-to-main — reliable on a managed repo: read policy/branch-protection.yml, diff it against the repo's live protection, and on explicit confirmation apply the missing settings via gh api (branch protection, secret scanning, Dependabot alerts). Verify by default; configures the GitHub-side gate only — steer is advisory in the local session (rule 95) and cannot block local pushes.