メニュー
Process `REVIEW:` inline comments left in code after implementation review. Fix each comment locally and remove it. Use after execute-plan when a human has added `REVIEW:` annotations to the codebase.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use for GitHub operations: creating issues, posting issue comments, creating draft PRs, and adding PR review comments.
Facilitate structured divergent idea generation using the SCAMPER technique (Bob Eberle). An orchestrator elicits a concrete target, applies seven transformation lenses (Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse) in parallel via focused subagents, then converges into evaluated, prioritized ideas. Use when the user asks for a SCAMPER analysis, systematic ideation, or improvement ideas for an existing product, service, process, or idea.
Facilitate structured multi-perspective analysis using Edward de Bono's Six Thinking Hats. A Blue Hat orchestrator applies one hat at a time in sequence over a single shared record, using five focused hat subagents. Use when the user asks for a Six Hats or 6 hat analysis, a multi-perspective breakdown of a decision, idea, or problem, or systematic structured thinking on a topic.
Author markmap-format Markdown. Use when writing a mindmap (マインドマップ / markmap) in Markdown.
Sample skill for verifying plugin wiring. Trigger when the user asks to run the sample greeting or test the sample plugin.
Use when resolving or addressing PR review comments.
| name | review-fix |
| description | Process `REVIEW:` inline comments left in code after implementation review. Fix each comment locally and remove it. Use after execute-plan when a human has added `REVIEW:` annotations to the codebase. |
| user-invocable | true |
| disable-model-invocation | false |
Process REVIEW: comments that a human has added to source code after a code
review. Apply each local fix, then delete the resolved comment. Do not touch
the planning file and do not handle design-level changes here.
docs/planning.md).REVIEW: comments.REVIEW: comment, decide:
write-plan instead.REVIEW: comments remain. Report any that were intentionally deferred.plan.md to be updatedWhen a REVIEW: comment falls into one of these categories, do not implement it.
Report it clearly and instruct the user to run write-plan first.
REVIEW: comment without implementing the fix it requests.REVIEW: comments or leave them in production code.any or unknown without a specific, justified reason.REVIEW: comment conflicts with plan.md, follow plan.md and report the conflict.