From superpowers
Use when reviewing SyRS documents in improved_system_Requirement/ against the four project references (engineering plan ASPICE SYS.2, requirement_spec_guide, SyRS_Writing_Protocol, CLAUDE.md). Triggers on "SyRS 검토", "사양 검토", "엔지니어링 리뷰", "engineering review", "spec review", or when the user provides a SyRS path and asks for audit/review/검토.
npx claudepluginhub threestn/rs4_pe --plugin superpowersThis skill uses the workspace's default tool permissions.
Review a SyRS document against the 4-Layer engineering reference stack and emit a structured findings report. The reviewer enforces **ASPICE SYS.2 compliance + Mando SyRS template + project writing protocol + CLAUDE.md project rules** in a single pass, so the engineer does not have to remember all four rulebooks at once.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Review a SyRS document against the 4-Layer engineering reference stack and emit a structured findings report. The reviewer enforces ASPICE SYS.2 compliance + Mando SyRS template + project writing protocol + CLAUDE.md project rules in a single pass, so the engineer does not have to remember all four rulebooks at once.
Core principle: Safety violations outrank everything else. Within a single pass, rule priority is Safety > Protocol > Template > Style (Layer 4 Rule 4 > Layer 3 Safety 5-layer > Layer 2 required attributes > Layer 4 tone).
Invoke when:
improved_system_Requirement/)Do NOT invoke when:
spec-write dispatch — not review)requesting-code-review, not this skill)| Input | Example |
|---|---|
| Target SyRS path | improved_system_Requirement/VSM_SyRS.md |
args)| Argument | Effect | Default |
|---|---|---|
--layer=<1,2,3,4> | Restrict review to selected layer(s), comma-separated | 1,2,3,4 (all) |
--baseline=<path_or_rev> | Diff-only review against a prior version | full-doc review |
--focus=<section> | Restrict to one section (e.g. §4.2 state machine only) | whole document |
--severity=<P0,P1,...> | Filter findings by severity | all severities |
Example invocations:
/engineering-reviewer improved_system_Requirement/VSM_SyRS.md (full 4-layer review)/engineering-reviewer improved_system_Requirement/HDA4_SyRS.md --layer=1,4 (ASPICE + CLAUDE rules only)/engineering-reviewer improved_system_Requirement/PA_SyRS.md --focus=§3.2 --severity=P0,P1 (state machine section, blockers only)If the user invokes the skill without a path, ask for the target SyRS path before proceeding (§2.3 요청 명확화 프로토콜).
Goal: Verify the document's skeleton before diving into per-requirement review.
Goal: Apply Layer 1-4 rules to each SyRS_XXXXXX in the document.
For each requirement ID found (grep -n "SyRS_[0-9]"):
{id, severity, layer, rule, location, issue, recommendation}See checklist-layers.md for the full per-layer detection list.
Goal: Verify §3.9 Impact Analysis has been completed for any signals touched by this SyRS.
Delegate to Explore subagent (to protect main-session context) with this prompt:
For the SyRS file <PATH>:
1. List every CAN signal, SyRS_ID, and parameter this doc defines or consumes.
2. For each, grep across improved_system_Requirement/ (Interface_Signal_Dictionary.md, data_dictionary.md, all sister SyRS files) and report:
- Is the signal registered in Interface_Signal_Dictionary.md (authoritative)?
- Does data_dictionary.md have a matching SWC mapping row?
- Are there consumer SyRS files still referencing a stale name/value?
- If this is a Type 5 (variant-prune) scenario, any dead-branch keywords left?
3. Report as a table: | Signal/ID | Dictionary? | SWC row? | Stale references (file:line) | Impact Type (1-5) |
Under 600 words.
Feed the subagent's output into Phase 4.
Generate the review report using report-template.md. The report must include:
Do NOT auto-modify the SyRS file. The skill is advisory — the engineer decides which findings to apply.
| Phase | Run where | Reason |
|---|---|---|
| Phase 1 | Main session | Fast, single file read |
| Phase 2 | Main session | Needs full rule context in one place |
| Phase 3 | Explore subagent | Grep-heavy across 30+ sister docs → protect main context |
| Phase 4 | Main session | Report assembly from prior phase outputs |
Dispatch pattern (Phase 3): single Agent call with subagent_type=Explore, thoroughness medium, embed the subagent prompt above. Wait for result before Phase 4.
checklist-layers.md — Full per-layer detection rules and grep patterns (this directory)report-template.md — Output report template (this directory)/home/user/RS4_PE/CLAUDE.md — Project rules (Rule 1-4, §3.5 checklist, §3.9 Impact Analysis, §4.5 tone, §4.6 abstraction)/home/user/RS4_PE/SyRS_Writing_Protocol.md — Project writing protocol (Layer 3)/home/user/RS4_PE/engineering plan.md — ASPICE SYS.2 engineering plan (Layer 1)/home/user/RS4_PE/requirement_spec_guide.md — Mando SyRS template (Layer 2)/home/user/RS4_PE/claude_references/Specification_Review_Guide.md — Supplemental 7-domain framework/home/user/RS4_PE/improved_system_Requirement/Interface_Signal_Dictionary.md — §3.9 정본/home/user/RS4_PE/improved_system_Requirement/Change_Management_Tracker.md — §3.6 정본spec-write (§3.7), not review