القائمة
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]**
...