메뉴
sr:why — Search explanation records written by specrails agents during the OpenSpec implementation pipeline.
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 | why |
| description | sr:why — Search explanation records written by specrails agents during the OpenSpec implementation pipeline. |
| license | MIT |
| compatibility | Requires git. |
| metadata | {"author":"specrails","version":"1.0"} |
Searches explanation records written by sr-architect, sr-developer, and sr-reviewer agents during the OpenSpec implementation pipeline.
Records are stored in .claude/agent-memory/explanations/ as Markdown files with
YAML frontmatter (agent, feature, tags, date).
Usage:
/specrails:why — list the 20 most recent explanation records/specrails:why <query> — search records by keyword or tagGlob all files matching .claude/agent-memory/explanations/*.md.
If the directory does not exist or contains no files: Print:
No explanation records found yet.
Explanation records are written by the sr-architect, sr-developer, and sr-reviewer agents
when they make significant decisions during feature implementation.
Run `/specrails:implement` on a feature to generate your first explanation records.
Then stop.
If $ARGUMENTS is empty:
Read each explanation record file. Extract from frontmatter: date, agent, feature, tags.
Extract the first sentence of the ## Decision section as the decision summary.
Sort records by date descending. Print the 20 most recent as a Markdown table:
## Recent Explanation Records
| Date | Agent | Feature | Tags | Decision |
|------|-------|---------|------|----------|
| 2026-03-14 | sr-architect | in-context-help | [templates, commands] | Chose flat directory over per-agent subdirectories. |
| ... | ... | ... | ... | ... |
Then stop.
If $ARGUMENTS is non-empty, treat the full string as the search query.
For each explanation record file:
tags array contains an exact query word: +3 points per matching tagfeature contains a query word: +2 pointsSort records by score descending. Take the top 5 records with score > 0.
If no records score > 0: Print:
No explanation records match "<query>".
Then list all unique tags from existing records:
## Available Tags
[sorted list of all unique tags from all explanation records]
Try `/specrails:why <tag>` with one of the tags above, or `/specrails:why` to browse all records.
If records match, print each matching record in full, separated by ---:
## Results for "<query>" (N matches)
---
**[date] [agent] — [feature]**
Tags: [tag1, tag2]
[full record body]
---
**[date] [agent] — [feature]**
...