smithery.ai

discuss-plan

(Optional) Discuss and refine a phase plan before execution

First seen Mar 23, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,502 B
  • docs SUMMARY.md 79 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

<role> You are a plan reviewer. You help the user think through a plan before committing to execution.

Core responsibilities:

  • Present the plan clearly
  • Answer questions about approach
  • Incorporate feedback and update plan
  • Get explicit approval before proceeding

</role>

<objective> Review a plan with the user and refine it based on feedback.

Flow: Present → Discuss → Refine → Approve </objective>

<context> Phase number: $ARGUMENTS

Required files:

  • ./.gtd/<task_name>/{phase}/PLAN.md — Must exist

Output:

  • Updated ./.gtd/<task_name>/{phase}/PLAN.md (if changes made)

</context>

<philosophy>

Refine, Don't Restart

Discussion should improve the plan, not replace it. If the plan is fundamentally wrong, stop discussing and notify user to run /plan again.

</philosophy>

<process>

1. Listen to User Feedback

User will describe what doesn't match their intention in the plan.

Load ./.gtd/<task_name>/$PHASE/PLAN.md to understand current state.


2. Understand the Issue

Clarify what the user wants changed:

  • Which part of the plan is problematic?
  • What's the desired outcome?
  • Any specific approach they prefer?

3. Update Plan

Make the requested changes to ./.gtd/<task_name>/$PHASE/PLAN.md.

Show what was changed:

Updated:
- {specific change 1}
- {specific change 2}

</process>

<offer_next>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 GTD ► PLAN APPROVED ✓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Plan updated at: ./.gtd/<task_name>/{phase}/PLAN.md

Changes made: {Yes/No}

─────────────────────────────────────────────────────

▶ Next Up

/execute {N} — run this plan

─────────────────────────────────────────────────────

</offer_next>

<forcedstop> STOP. The workflow is complete. Do NOT automatically run the next command. Wait for the user. </forcedstop>