Menú
Explore a spec idea and produce a structured proposal
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional 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}