القائمة
Create a feature's spec (intent.md + contract.md) from the bundled templates.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
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.
استنادا إلى تصنيف SOC المهني
| name | spec-scaffold |
| description | Create a feature's spec (intent.md + contract.md) from the bundled templates. |
| when_to_use | Invoked by /steer:spec, /steer:build, /steer:init, or /steer:adopt with a resolved feature id to instantiate intent.md + contract.md — not a direct entry point. |
| argument-hint | [feature-id] |
| allowed-tools | ["Bash(sh *scripts/template-reconcile.sh*)"] |
| user-invocable | false |
Create /spec/features/[id]/intent.md and contract.md for a new user-facing
feature, using the canonical templates bundled with this plugin.
Determine the feature [id] — a short kebab-case slug (user-login,
export-csv). Ask the dev if it isn't obvious.
Create the folder spec/features/[id]/ in the product repo. If it already
exists, this [id] was scaffolded before — do not clobber it; go to step 3's
reconcile branch.
Instantiate the two spec files from the bundled templates:
${CLAUDE_PLUGIN_ROOT}/templates/spec/feature-intent.md → spec/features/[id]/intent.md${CLAUDE_PLUGIN_ROOT}/templates/spec/feature-contract.md → spec/features/[id]/contract.mdFor a new feature, copy them in. For an existing feature (a re-run, or a feature spec'd under an older plugin version), reconcile instead of copy — don't eyeball it; run the diff first and act on its output (per file, intent then contract):
sh "${CLAUDE_PLUGIN_ROOT}/scripts/template-reconcile.sh" \
spec/features/[id]/intent.md "${CLAUDE_PLUGIN_ROOT}/templates/spec/feature-intent.md"
# repeat with contract.md vs feature-contract.md
Splice in only the genuinely-new sections/items it reports (empty/unchecked),
preserving everything already written; never overwrite filled-in
intent/contract content or re-add a placeholder the dev replaced. Full rules —
the plugin-wide Template reconciliation convention (over-reports handling,
anchor matching, additive-only):
${CLAUDE_PLUGIN_ROOT}/templates/reference/SPEC-FRAMEWORK.md §"Template
reconciliation".
Fill in what you know from the conversation/issue (feature name, what it does,
why, in/out of scope). Leave PO-acceptance checkboxes unchecked and flag any
ambiguity in this feature's own ## Open questions section rather than
inventing details (run /steer:questions later to drive them to answers).
For a Greenfield/design-originated feature, populate the Design source
section per /steer:reference design-sources.
The spec ↔ code rules (drift resolution, behavior vs. implementation, PO
acceptance, naming) are in the bundled reference at
${CLAUDE_PLUGIN_ROOT}/templates/reference/SPEC-FRAMEWORK.md — read it if you
need the full rules. Key points: specs are organized by feature not code layout;
spec and code change together in the same PR; resolve drift explicitly, never
silently.
intent.md is the what and why (PO-facing); contract.md is the testable
behavior + data/API surface (dev-owned). Get PO approval on the intent before
broad implementation.