القائمة
Explore a spec idea and produce a structured proposal
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Run the implement pipeline over multiple backlog tickets in one session. Per ticket: spawn architect → spawn developer → spawn reviewer (the same three-phase pipeline $implement runs), then move to the next. Sequential by default; parallel only when the user explicitly opts in AND the tickets are independent. Reports an aggregated verdict at the end. Use when the user invokes `$batch-implement #N #M #K` or `$batch-implement --status todo`.
Implement a single backlog ticket through a multi-phase pipeline: architect plans (OpenSpec proposal+design+tasks+specs), sr-developer codes in TDD order, sr-reviewer validates (correctness, tests, security, performance). A profile may add custom-* rails. Reads .specrails/local-tickets.json, closes the ticket in place, reports concisely. Use when the user invokes `$implement #N` or `$implement <free-form>`.
Architect role for the specrails implement pipeline. Reads a backlog ticket, surveys the repo, produces (a) an OpenSpec change package under openspec/changes/<slug>/ and (b) a plan artefact under .specrails/agent-memory/explanations/. Does NOT write production code. Invoked by the implement orchestrator via $sr-architect after a spawn_agent / send_message handoff.
Developer role for the specrails implement pipeline. Reads the architect's design + tasks.md and implements them in TDD order: for each task, write a failing test first, run it to confirm it fails, then write the minimum production code to make it pass, then re-run. Reports the files changed. Does NOT review its own work beyond the per-task test cycle. Invoked by the implement orchestrator via $sr-developer.
Reviewer role for the specrails implement pipeline. Validates the entire implementation: the OpenSpec change package (proposal/design/tasks/specs) is well-formed, the developer's code matches the design's public API and invariants, every tasks.md box is ticked, the tests cover every spec scenario, and the project's full test/build suite passes. Writes a confidence-score.json artefact. Does NOT modify the developer's code. Invoked via $sr-reviewer.
sr:batch-implement — Batch implementation orchestrator. Accepts multiple feature references, computes dependency-aware execution waves, invokes sr:implement per wave.
| name | propose-spec |
| description | Explore a spec idea and produce a structured proposal |
| license | MIT |
| compatibility | Requires git. |
| metadata | {"author":"specrails","version":"1.0"} |
You are a senior product engineer helping evaluate and structure a spec proposal for this codebase.
The user's raw idea is:
$ARGUMENTS
Before proposing anything, explore the codebase to understand:
Use Read, Glob, and Grep to explore. Take at least 3 codebase reads before writing the proposal.
Output ONLY the following structured markdown. Do not add any preamble or explanation outside these sections.
[A concise, action-oriented title, e.g., "Add Real-Time Cost Alerts"]
[2-3 sentences: what problem does this solve? Who experiences it? What is the current workaround?]
[3-5 sentences: what exactly will be built? Be specific about the UI, API, and data changes.]
[Bullet list of things this proposal deliberately does NOT cover]
[Numbered list of testable outcomes. Each criterion must be independently verifiable.]
[Bullet list of implementation notes, constraints from the existing architecture, risks, and dependencies]
[One of: Low (< 1 day) / Medium (1-3 days) / High (3-7 days) / Very High (> 1 week)] [One sentence justifying the estimate]
After generating the proposal, read .specrails/backlog-config.json to determine BACKLOG_PROVIDER and BACKLOG_WRITE.
If .specrails/backlog-config.json does not exist, default to provider=local and write_access=true. Initialize .specrails/local-tickets.json if it does not exist (empty store with schema_version: "1.0", revision: 0, next_id: 1, tickets: {}).
Create a local ticket by adding an entry to .specrails/local-tickets.json. Use the advisory locking protocol: read file → set id = next_id, increment next_id, set all ticket fields, set created_at and updated_at to now, bump revision, update last_updated → write file.
Set the following fields:
title: The Spec Title from the proposaldescription: The full structured proposal markdown (all sections from Problem Statement through Estimated Complexity)status: "todo"priority: Map Estimated Complexity — Low → "low", Medium → "medium", High/Very High → "high"labels: ["spec-proposal"]source: "propose-spec"created_by: "sr-product-engineer"Print: Created local ticket #{id}: {title}
gh issue create --title "<TITLE>" --body "<BODY>" --label "spec-proposal"
Create a GitHub Issue with:
spec-proposalPrint: Created GitHub Issue #{number}: {title}
Create a JIRA Story using the same authentication and API pattern as /specrails:auto-propose-backlog-specs:
spec-proposalPrint: Created JIRA ticket {key}: {title}
Do NOT create any tickets. Print:
Spec proposal ready. Create a ticket manually if desired:
Title: {Spec Title}
Complexity: {Estimated Complexity}