القائمة
Reviews and refines brainstorm or planning documents before implementation. Identifies gaps, clarifies assumptions, and ensures the approach is sound.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | refine-approach |
| user-invocable | true |
| description | Reviews and refines brainstorm or planning documents before implementation. Identifies gaps, clarifies assumptions, and ensures the approach is sound. |
| when_to_use | Use when user says "refine this", "review my approach", or "is this ready". |
| argument-hint | path to document to refine |
| compatibility | Designed for Claude Code (or similar products with agent support) |
Improve brainstorm and/or planning documents through structured review.
Document path: $ARGUMENTS
If $ARGUMENTS is non-empty, treat it as the document path and proceed to Step 2. Assess.
If $ARGUMENTS is empty, ask the user which document to review. Check docs/brainstorm/ and docs/plan/ for recent documents to suggest.
Read the document, then ask and clarify:
Do not fix yet anything. Simply take notes about what you find to inform what you do in Step 3. Evaluate and score.
Apply the following criteria to evaluate the document:
| Criteria | What to evaluate |
|---|---|
| Clarity | Problem statement is clear, no vague language ("probably," "consider," "try to") |
| Completeness | Required sections present, constraints stated, open questions flagged |
| Specificity | Concrete enough for next step (brainstorm → can plan, plan → can implement) |
| YAGNI | No hypothetical features, simplest approach chosen |
| Scope | Scope is well defined and constrained, not overly ambitious |
If invoked during a brainstorm phase (after /brainstorm), validate that the document reflects with fidelity the user intent.
Among everything found in Steps 2-3, does one issue stand out? If something would significantly improve the document's quality, this is the must address item. Highlight it prominently.
Present your findings, then:
Simplification is purposeful removal of unnecessary complexity, not shortening for its own sake.
Simplify when:
Don't simplify:
After changes are complete, ask:
When invoked directly by the user (not as part of another skill), also determine the document type and offer clear context handoff as the first option:
If the document is a brainstorm (from docs/brainstorm/):
If the document is a plan (from docs/plan/):
If the user selects "Clear context and plan" → Follow the clear context handoff for /plan with the actual brainstorm doc path. Then stop.
If the user selects "Clear context and build" → Follow the clear context handoff for /build with the actual plan file path. Then stop.
When invoked by another skill (e.g., from /brainstorm or /plan), only offer "Refine again" and "Review complete", then return control to the caller.
After 2 refinement passes, recommend completion—diminishing returns are likely. But if the user wants to continue, allow it.
Executes an implementation plan — writes code and tests, runs quality review, and ships a pull request.
Turns high-level brainstorming and ideas into well-structured, actionable implementation plans.
Reviews an externally-authored implementation plan for quality, VGV conventions, and scope. Plans created by /plan are already reviewed during creation.
Applies a minimal, targeted fix for emergency bugs — enforces review and testing without brainstorm or planning phases.
Runs quality review agents on demand — reviews code against VGV standards for architecture, tests, and simplicity, then writes one consolidated, numbered report.
Explores requirements and approaches through collaborative dialogue before planning implementation.
