菜单
Review implementation plan for business value alignment. Use when asked to 'review my plan', 'walk through implementation', 'check plan against PRD', 'review technical decomposition', or 'is my plan aligned with requirements'. NOT for code review (use /sr), NOT for creating tasks (use /ct), NOT for static code analysis (use /code-analysis).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Internal reference skill — coding standards and patterns for developer agents. Not user-invocable.
Close out work by committing local changes, pushing, waiting for green CI, and merging the PR. Universal — works on any branch with an open PR; no task structure required. Use when asked to 'merge the PR', 'ship it', 'merge and close', 'commit push merge', 'finalize the PR', 'land it on main', 'we're done — close it out', or whenever the user signals end-of-work and the next step is to merge. If (and only if) the current work is one phase of a multi-phase task in `tasks/**/phase-N-*/`, also make upcoming phase tech-decomposition documents accurate for the implementation that just landed by adding handoff notes or updating stale assumptions before merging — otherwise this step is silently skipped. Make sure to use this skill whenever the user signals end-of-implementation and wants the changes merged — even if they don't say the word "skill". NOT for opening a new PR (use plain `gh pr create`). NOT for addressing review comments (use /prc). NOT for preparing a session handoff to a fresh context (use /ph).
Use when a plan, design, or discovery document needs stress-testing for hidden assumptions, scope gaps, unresolved branches, or ambiguous wording; also when the user explicitly says "grill me".
Internal reference skill — shared conventions for all code review agents. Not user-invocable.
Implements a feature from a technical decomposition using TDD, keeping the task document updated and handing off cleanly to review. Use when starting, continuing, or resuming implementation from a tech-decomposition or task directory. Trigger: 'implement this task', 'start implementation', 'continue/resume implementation', 'build from the tech decomposition', or after /ct produces a decomposition. NOT for creating the plan (/ct), feature discovery (/nf), small untracked changes (/si-quick or /quick), or code review (/sr).
Use when asked to review code before merge or review a PR, branch, commit range, task path, or current working tree. Trigger on requests like 'review PR', 'review my changes', 'review this branch', 'is this ready to merge', or other pre-merge review requests. Supports task/spec-aware review when task docs exist. NOT for addressing review comments (use /prc).
| name | rip |
| description | Review implementation plan for business value alignment. Use when asked to 'review my plan', 'walk through implementation', 'check plan against PRD', 'review technical decomposition', or 'is my plan aligned with requirements'. NOT for code review (use /sr), NOT for creating tasks (use /ct), NOT for static code analysis (use /code-analysis). |
| argument-hint | ["plan-file-path"] |
| allowed-tools | Read, Grep, Glob, AskUserQuestion |
Announcement: Begin with: "I'm using the rip skill for implementation plan review."
Step-by-step review of implementation plan. Focus: business value through technical understanding.
Before responding:
tech-decomposition-*.md, *implementation-plan*.md) before giving up.Record mismatches (extra features, missed requirements, logic conflicts) for discussion. Frame each as facts + question rather than a verdict — the plan author knows the product context you don't, and a question invites a fix instead of a defense.
Review format:
## Overview
**Business goal:** [what problem it solves]
**Scope:** [components] | [files] | [complexity]
**Plan:** [N steps with names]
**Warnings (include uncertain ones with confidence tag):**
- [Problem] — contradicts [source]
Ready for first step?
Default to a continuous walkthrough in one response (all steps, back-to-back) — 4.7 calibrates length well and one message is cheaper than N turns. Pause only when (a) the user asks you to pause, (b) you need to resolve a PRD mismatch before the next step makes sense, or (c) the plan has more than ~6 steps and a mid-review check-in improves comprehension.
Step format:
### Step [N]: [Name]
**Why:** [business reason]
**What:** [technical essence]
**Concepts:** [term]: [analogy]
**Impact:** [code] → [user-facing change]
**Code:** [if relevant]
**Warnings (include uncertain ones with confidence tag):**
- [PRD issue]
- **Question:** [clarification]
---
Questions? Next?
## Summary
**Covered:** [recap]
**Value:** [why it matters to user]
**Concepts:** [list]
**Self-check:**
1. [Business question]
2. [Technical question]
| Principle | Action |
|---|---|
| Business-first | Start with "why for the user" |
| Simplicity | Term = analogy |
| Specificity | Real files/endpoints |
| Progress | Every 3-4 steps: "X of N" |
| Criticality | Surface every potential PRD mismatch, including uncertain ones; mark each with confidence (high/medium/low). Present them all in the Warning block — let the user decide what is in scope. |
| Constructiveness | Facts + question, no dismissiveness |
Input: Progress tracking plan
Overview:
Business goal: Users see progress → motivation Scope: backend + DB |
src/modules/progress/| medium Plan: 4 steps (model, API, logic, integration)Warning:
- Plan doesn't mention visualization — PRD requires charts. Out of scope?
- PRD: PDF export — not in plan. Include?
Step 1:
Why: Store word learning history What:
WordProgresstable links user+word, stores metrics Concepts: Database schema = DB blueprint as code Impact: "Progress" screen → word-level statsWarning:
- PRD: track repetition intervals (spaced repetition). Schema: only
lastSeen, no history.- Question: Plan — current state only or full history?
| Need | Use |
|---|---|
| Review code before merge | /sr |
| Create implementation plan | /ct |
| Analyze code architecture | /code-analysis |
| Create/update PRD or JTBD | /product |