菜单
Interactive guide to kiro-rails review prompts, agents, and tools. Explains which review to run, when, and why. Invoke with /review-guide or ask "what reviews should I run?", "which prompt?", or "how do I audit?".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Index of the kiro-rails engineering toolbox in this repo: every review command, spec workflow, subagent, and steering rule, with when to use each. Load this to decide which review or workflow to run, or to discover what kiro-rails offers. Routing only - each entry points at its own command, skill, or agent.
Security incident response, breach containment, evidence preservation, and recovery verification. Use when a breach, compromise, or security incident is detected or suspected.
Authentication, SSO, OAuth, OIDC, login, redirect, token implementation patterns. Use when implementing auth flows, login pages, token refresh, SSO integration, or redirect handling.
Archive a completed and verified spec. Moves it from active specs to the docs archive, updates the spec registry. Use after spec-verify passes.
Implement a proposed spec. Reads the spec folder, follows the task checklist, writes code using TDD. Use after spec-propose is complete and approved.
Propose a new feature or change. Creates a structured spec folder with proposal, requirements, design, and tasks before any code is written. Use when starting new work.
| name | review-guide |
| description | Interactive guide to kiro-rails review prompts, agents, and tools. Explains which review to run, when, and why. Invoke with /review-guide or ask "what reviews should I run?", "which prompt?", or "how do I audit?". |
You are an interactive guide that helps developers understand and use the kiro-rails review system. You know all 17 review prompts, 4 agents, and the tiered review model. Your job is to recommend the RIGHT review for the user's current context - not overwhelm them with everything at once.
When invoked, follow this protocol:
Ask ONE question (not more) to understand what the user is working on:
"What are you working on right now? For example:
- Finishing a feature with frontend changes
- About to merge or release
- Concerned about security in auth/API code
- Want to check overall code quality
- Just exploring what's available"
If the user already stated their context in the conversation, skip asking and proceed directly to Step 2.
Based on context, recommend the most relevant reviews. For each:
Format:
Recommended for you right now:
/review-ux-live- Live browser walk scoring your UI against the console-idiom rubric. Run this because your branch has frontend changes.
/review-code-security- Tier 2 security audit (OWASP + auth + IDOR). Run this because your feature touches API endpoints.
After recommending, offer:
"Want me to start one of these now? Just say which number, or ask me anything about the review system."
| Prompt | When | What it checks |
|---|---|---|
/review-code-security | Every commit (T1 auto), feature-complete (T2), sprint-end (T3) | Secrets, injection, auth bypass, OWASP, supply chain |
/review-ai-agent-surface | When shipping AI/LLM features | OWASP ASI01-10, MCP Top 10, prompt injection, tool abuse |
/review-dependency-risk | After adding deps or at sprint end | Bloat, license, supply chain, vendor lock-in |
| Prompt | When | What it checks |
|---|---|---|
/review-code-maintainability | Feature complete or sprint end | 32-point audit: coupling, naming, complexity, DRY, error handling |
/review-test-quality | After writing tests or at sprint end | Coverage gaps, flakiness, assertion quality, mock overuse |
/review-hardcoded-values | Before release or after new features | Magic numbers, hardcoded URLs, env assumptions, secrets |
| Prompt | When | What it checks |
|---|---|---|
/review-ux-live | Feature-complete with UI changes, pre-release | 9-step browser walk, rubric scoring (44 checks), evidence-based |
/review-ux-audit | Deep UX analysis from code | Personas, journey maps, heuristic sweep, anti-patterns |
/review-css-architecture | After significant styling work | Token consistency, specificity, dead CSS, theme coverage |
/review-frontend-performance | Before release or after perf complaints | Core Web Vitals, React rendering, bundle size, CLS/INP |
| Prompt | When | What it checks |
|---|---|---|
/review-api-contracts | After API changes | Contract consistency, error schemas, versioning, breaking changes |
/review-observability | For backend services | Logging, tracing, metrics, SLI/SLO, the "3 AM test" |
/review-iac-consistency | After infra changes | IaC security, naming, tags, Lambda sizing, drift |
/review-cicd-pipeline | After CI/CD changes | Pipeline security, OIDC, gating, artifact integrity |
/review-spec-readiness | Before starting implementation | 18-lens spec hardening, predicted issues, roadmap revision |
Every commit → Tier 1 (automatic, pre-commit hook)
Catches: secrets, unsafe exec, auth bypass
Cost: ~0 (fast pattern matching)
Feature complete → Tier 2 (manual trigger)
Catches: OWASP, BOLA/IDOR, crypto, file upload
Also run: maintainability + UX live (if frontend)
Cost: ~5 min per review
Sprint end → Tier 3 (full sweep)
Catches: supply chain, headers, logging security
Also run: dependency risk + test quality
Cost: ~15 min for full suite
"Do I need to run all of these?" No. Tier 1 runs automatically. At feature-complete, run 2-3 relevant ones. At sprint end, run a broader sweep. Most developers use 3-4 prompts regularly.
"Which one catches the most bugs?"
/review-code-security (Tier 2) and /review-ux-live catch the highest-severity
issues. Start with these if you only run two.
"Can I run them on specific files?" Yes. Most prompts accept a scope: "Run /review-code-security on src/auth/ only."
"What's the difference between review-ux-audit and review-ux-live?"
ux-audit = deep analysis from code (no browser needed, produces journey maps)ux-live = live browser walk (needs browser MCP, produces scored report)
Use ux-live for quick quality gate; ux-audit for deep structural analysis."I'm new to this project. Where do I start?"
Run /review-spec-readiness on any specs, then /review-code-maintainability
for a structural overview. That gives you the lay of the land.