feat(skills): add brainstorming + executing-plans wrappers + fix spawn prompt to lead with slash command

Author: AndreJorgeLopes

devflow-plugin/.claude-plugin/plugin.json

@@ -24,6 +24,8 @@
     "./skills/visualizations-config/SKILL.md",
     "./skills/dependency-update/SKILL.md",
     "./skills/writing-plans/SKILL.md",
+    "./skills/brainstorming/SKILL.md",
+    "./skills/executing-plans/SKILL.md",
     "./skills/lock-tests/SKILL.md",
     "./skills/phase-handoff/SKILL.md",
     "./skills/best-roi-task/SKILL.md",

devflow-plugin/commands/brainstorming.md

@@ -0,0 +1,30 @@
+---
+description: Devflow wrapper for the upstream brainstorming skill. Use when starting any creative work — creating features, building components, adding functionality, or modifying behavior — to explore user intent, requirements, and design before implementation. Always invoke `/devflow:brainstorming` rather than the upstream skill directly so devflow can layer in project-specific behavior (recall hooks, phase-handoff entry points) without callers ever needing to know about the upstream.
+---
+
+You are the devflow wrapper for the upstream brainstorming workflow. The wrapper exists so the rest of the devflow pipeline (new-feature, spec-feature, etc.) has a single canonical entry point (`/devflow:brainstorming`) and never reaches past it to the upstream skill directly.
+
+## Steps
+
+1. **Delegate to the upstream brainstorming skill.** Invoke `superpowers:brainstorming` via the Skill tool. Pass through `$ARGUMENTS` verbatim so the upstream skill receives the user's original input.
+
+2. **Let the upstream skill drive.** Do NOT layer additional questions, gates, or prompts on top of the upstream flow inside this wrapper — the upstream skill already runs the full requirements/design/approach exploration loop with `AskUserQuestion` gates. Your job is to be a transparent pass-through.
+
+3. **On completion, return control.** The upstream brainstorming skill's terminal state is invoking `superpowers:writing-plans`. Devflow does NOT short-circuit that — when the user is ready to spec, they invoke `/devflow:spec-feature` (devflow's spec-writing wrapper) directly. Brainstorming → spec-feature happens in the SAME session (no `phase-handoff` between them — the phase handoff fires only at spec → plan, plan → lock-tests, and lock-tests → impl boundaries).
+
+## Why this wrapper exists
+
+- **Single canonical entry point.** All devflow callers (new-feature.md, future skills) invoke `/devflow:brainstorming` instead of `/brainstorming` or `superpowers:brainstorming`. If devflow ever needs to layer in project context (Hindsight recall, prior-feature memory) before brainstorming starts, that layering happens here without touching call sites.
+- **Consistency with the rest of the devflow pipeline.** Other devflow phases (`writing-plans`, `executing-plans`, `lock-tests`, `phase-handoff`) all have explicit devflow surface. Brainstorming gets the same treatment for symmetry.
+- **Decoupling from upstream API changes.** If `superpowers:brainstorming` is renamed/moved/replaced, only this wrapper needs to update — call sites stay stable.
+
+## Fallback if upstream is unavailable
+
+If `superpowers:brainstorming` is not loaded in the current session (older Claude Code, plugin disabled, etc.), search the available-skills list for variants matching `*brainstorm*`. If none found, surface a clear error: `Upstream brainstorming skill not found. Verify the superpowers plugin is installed (re-run the OMC setup flow or check ~/.claude/plugins/).` Then exit — do NOT attempt to re-implement the brainstorming logic inline.
+
+## Important
+
+- This wrapper is intentionally thin. Resist the temptation to add custom phases here — that lives in the upstream skill, or in dedicated devflow skills (`spec-feature`, `writing-plans`, etc.).
+- Do NOT auto-invoke `/devflow:spec-feature` from inside the brainstorming flow — the upstream skill's HARD-GATE forbids invoking implementation skills before user-approved design exists, and devflow respects that.
+
+$ARGUMENTS

devflow-plugin/commands/executing-plans.md

@@ -0,0 +1,53 @@
+---
+description: Devflow wrapper for the upstream executing-plans skill. Use when you have a written implementation plan to execute task-by-task. ALWAYS invoke `/devflow:executing-plans` rather than the upstream skill directly — this wrapper guarantees that the post-implementation handoff goes to `/devflow:finish-feature` (devflow's verification + PR/MR creation flow) instead of `superpowers:finishing-a-development-branch` (the upstream default, which doesn't integrate with devflow's VCS-coherent finish flow).
+---
+
+You are the devflow wrapper for the upstream executing-plans workflow. The wrapper exists for TWO reasons:
+
+1. **Forced finish-feature handoff.** Upstream `executing-plans` natively chains to `superpowers:finishing-a-development-branch` after the last task. Devflow has its own `/devflow:finish-feature` flow that runs verification, creates a PR/MR via devflow's VCS-coherent logic, and retains learnings to Hindsight. This wrapper intercepts the terminal handoff so the devflow finish flow runs instead.
+2. **Single canonical entry point.** All devflow callers (`lock-tests.md` Phase 2, `phase-handoff.md`'s impl-phase invocation, the resume prompt in a spawned implementation session) invoke `/devflow:executing-plans` instead of `/executing-plans` or `superpowers:executing-plans`. If the upstream skill is renamed/moved/replaced, only this wrapper updates.
+
+## Phase 0 — Locate the upstream skill
+
+1. Try invoking `superpowers:executing-plans` via the Skill tool. If it loads, proceed to Phase 1.
+
+2. **If the upstream skill is missing**, search the available-skills list for variants matching `*executing*plans*` or `*implementing*plans*`. If a variant matches (rename case), use it and warn the user inline: `Note: superpowers:executing-plans renamed to <variant>. Update devflow:executing-plans skill body to point at the new name.`
+
+3. **If still missing**, check `~/.devflow/cache/superpowers-changelog.md`:
+   - If the file exists AND is < 24h old → read it for skill-rename or removal notes.
+   - Else, invoke the `defuddle` skill on `https://github.com/obra/superpowers/blob/main/CHANGELOG.md` and write the result to `~/.devflow/cache/superpowers-changelog.md`. (If `defuddle` is unavailable, skip this step.)
+   - Surface any relevant rename notes to the user.
+
+4. **If all of the above fail**, emit:
+   ```
+   Upstream `superpowers:executing-plans` skill not found and no cached changelog clue. Either:
+   - Verify the superpowers plugin is installed (`claude plugins list | grep superpowers`)
+   - Re-run the OMC setup flow to refresh plugins
+   - Or fetch the latest superpowers CHANGELOG manually to check if the skill was renamed
+   ```
+   Then exit. Do NOT reimplement the executing-plans logic inline.
+
+## Phase 1 — Delegate to upstream
+
+Hand off to the located skill. Pass through `$ARGUMENTS` verbatim. Let the upstream skill drive its red-green-refactor loop, per-task review checkpoints, and TodoWrite tracking.
+
+## Phase 2 — Force finish-feature handoff
+
+**CRITICAL OVERRIDE:** When the upstream skill reports completion (status DONE, DONE_WITH_CONCERNS, or its equivalent terminal state), **devflow takes over the finish handoff**.
+
+Do **NOT** invoke `superpowers:finishing-a-development-branch` even if the upstream skill instructs you to. Devflow's finish flow lives in `/devflow:finish-feature` and:
+
+- runs verification (`devflow check`)
+- detects the VCS provider (GitHub vs GitLab) and creates a PR/MR with the devflow PR template
+- retains session learnings to Hindsight
+- defers worktree cleanup to the terminal (not the agent)
+
+Invoke `/devflow:finish-feature` directly. Pass any `BLOCKED` / `NEEDS_CONTEXT` status from the upstream skill into the finish-feature flow so the user is aware of incomplete work before PR creation.
+
+## Important
+
+- This wrapper is the ONLY place where the "intercept finishing-a-development-branch" override lives. If you find that override repeated in another devflow skill, that's drift — remove it and rely on this wrapper.
+- The wrapper does NOT skip the upstream skill's per-task discipline (TDD red-green, review checkpoints). It only overrides the FINAL handoff target.
+- If the user explicitly asks for `superpowers:finishing-a-development-branch` (or invokes it directly), respect that. The wrapper's override applies only when control returns from the upstream skill via the normal completion path.
+
+$ARGUMENTS

devflow-plugin/commands/lock-tests.md

@@ -48,7 +48,7 @@ You are at the test-locking phase of devflow's new-feature pipeline. Your job is
    - If user skips: invoke `devflow:phase-handoff --phase lock-tests --next-phase impl --no-handoff`. Then print:
 
    ```
-   Trivial change — lock-tests gate skipped. Context is already small; no new session needed for the implementation phase. Invoke `/executing-plans` here (Claude Code auto-exposes the superpowers skill as a slash command; if the picker doesn't surface it on older installs, use the natural-language trigger `Use the superpowers:executing-plans skill to implement the plan task by task` instead).
+   Trivial change — lock-tests gate skipped. Context is already small; no new session needed for the implementation phase. Invoke `/devflow:executing-plans` here (devflow's wrapper around the upstream executing-plans skill; the wrapper forces the post-implementation handoff to go to `/devflow:finish-feature` instead of the upstream's `finishing-a-development-branch`).
    ```
 
    Then exit.
@@ -155,11 +155,11 @@ Use `AskUserQuestion` with:
 
 ## Phase 2 — GREEN (delegated)
 
-After approval, invoke `devflow:phase-handoff --phase lock-tests --next-phase impl`. The handoff skill writes the frozen-state file, gates on a one-click `AskUserQuestion`, then spawns a new Claude Desktop session via `mcp__ccd_session__spawn_task` titled `[<TICKET>] [MR#<N>] Implementation` (visible in the sidebar). The spawned session starts cold; its initial prompt points at the frozen-state file plus absolute artefact paths and instructs it to invoke `/executing-plans` (the superpowers skill auto-exposed as a slash command by Claude Code's plugin runtime), which drives per-task red/green against the tests already locked in this phase.
+After approval, invoke `devflow:phase-handoff --phase lock-tests --next-phase impl`. The handoff skill writes the frozen-state file, gates on a one-click `AskUserQuestion`, then spawns a new Claude Desktop session via `mcp__ccd_session__spawn_task` titled `[<TICKET>] [MR#<N>] Implementation` (visible in the sidebar). The spawned session starts cold; its initial prompt leads with the slash-command invocation `/devflow:executing-plans` (devflow's wrapper around the upstream executing-plans skill — guarantees the post-implementation handoff goes to `/devflow:finish-feature`) and hands it absolute paths to the frozen-state file plus the locked test inventory, which drives per-task red/green against the tests already locked in this phase.
 
 ## Phase 3 — REFACTOR (delegated)
 
-Handled per-task inside `superpowers:executing-plans`, not centrally.
+Handled per-task inside `/devflow:executing-plans` (the devflow wrapper, which delegates to the upstream executing-plans flow), not centrally.
 
 ## Important
 

devflow-plugin/commands/new-feature.md

@@ -65,7 +65,7 @@ You have been launched inside a feature worktree. Your job is to orient yourself
 
    If yes, invoke the `codebase-walkthrough` skill with the feature context. After the walkthrough completes, continue to brainstorming.
 
-6. **Transition to brainstorming.** Once you understand the feature (and optionally completed the walkthrough), invoke the `brainstorming` skill to explore requirements, design, and approach before writing any code.
+6. **Transition to brainstorming.** Once you understand the feature (and optionally completed the walkthrough), invoke `/devflow:brainstorming` (devflow's thin wrapper around the upstream brainstorming skill — always use the devflow surface, never `/brainstorming` or the upstream skill directly) to explore requirements, design, and approach before writing any code.
 
    The full pipeline from here is:
    ```

devflow-plugin/commands/phase-handoff.md

@@ -91,9 +91,9 @@ If `--no-handoff` is present, print "phase-handoff skipped" and exit.
    |---|---|---|
    | `plan` | `Plan` | `/devflow:writing-plans` |
    | `lock-tests` | `Lock Tests` | `/devflow:lock-tests` |
-   | `impl` | `Implementation` | `/executing-plans` |
+   | `impl` | `Implementation` | `/devflow:executing-plans` |
 
-   **Note on `impl`:** Claude Code's plugin runtime auto-exposes superpowers skills as `/`-prefixed slash commands, so `/executing-plans` resolves to the upstream `superpowers:executing-plans` skill at invocation time. If the slash picker doesn't surface it in a given install (older Claude Code, plugin disabled, etc.), the natural-language fallback is `Use the superpowers:executing-plans skill to implement the plan task by task`.
+   **Why every entry uses a `/devflow:` wrapper:** devflow's policy is that no skill in the pipeline ever invokes an upstream skill directly — all calls go through a devflow wrapper. `/devflow:executing-plans` is the wrapper for the upstream executing-plans skill; it delegates the per-task red-green-refactor loop to the upstream flow AND intercepts the terminal handoff so it goes to `/devflow:finish-feature` instead of the upstream default. If the wrapper is missing on a given install, the user can fall back to invoking the upstream skill directly — but the wrapper is the canonical entry point.
 
 8. **Detect MR/PR number for the current branch.** Optional — included in the spawned-session title when available:
 
@@ -121,10 +121,14 @@ If `--no-handoff` is present, print "phase-handoff skipped" and exit.
 
    - `tldr`: 1-2 sentence tooltip. Format: `Continue <feature-area-from-branch>: <next-phase-label> phase. Reads <frozen-state-relpath> + <N> artefact path(s).` Keep under 200 chars.
 
-   - `prompt`: self-contained initial message for the new session. The new session has ZERO conversational memory; the prompt must include everything it needs. Format:
+   - `prompt`: self-contained initial message for the new session. The new session has ZERO conversational memory; the prompt must include everything it needs.
+
+     **CRITICAL ordering: the FIRST LINE of the prompt MUST be the slash-command invocation for the next phase.** Claude Code's plugin runtime triggers a slash command only when it is the leading content of the user message. If the slash command is buried mid-body, the spawned session treats the prompt as a conversational request — reads the files, then waits for further input — instead of auto-invoking the next-phase skill. Lead with the slash, then provide the context as supporting paths the wrapper skill reads next. Format:
 
      ```
-     You are picking up the <next-phase-label> phase of <TICKET-ID>. Read these source-of-truth artefacts (absolute paths — readable from any cwd):
+     <invocation slash command from step 7's table>
+
+     You are continuing devflow's new-feature pipeline for <TICKET-ID> at the <next-phase-label> phase. The slash command above is your first action — invoke it now, then read these absolute paths inside the invoked skill:
 
      - Frozen state (entry point — read first): <worktree-root>/.devflow/state/${branch_slug}/<current-phase>.md
      - Spec: <worktree-root>/<rel-spec-path>  (or "not yet produced")
@@ -136,9 +140,27 @@ If `--no-handoff` is present, print "phase-handoff skipped" and exit.
      Ticket: <TICKET-ID>
      <If mr_num: MR/PR: #<mr_num>>
 
-     After reading the artefacts above, invoke: <invocation text from step 7's table>
+     Do NOT carry over assumptions from any prior session — the frozen-state file and artefact paths above are the only authoritative inputs.
+     ```
+
+     **Example for an `impl` phase handoff on ticket MES-4282, MR #29:**
+
+     ```
+     /devflow:executing-plans
+
+     You are continuing devflow's new-feature pipeline for MES-4282 at the Implementation phase. The slash command above is your first action — invoke it now, then read these absolute paths inside the invoked skill:
+
+     - Frozen state (entry point — read first): /Users/foo/dev/.worktrees/messaging/MES-4282/.devflow/state/MES-4282/lock-tests.md
+     - Spec: /Users/foo/dev/.worktrees/messaging/MES-4282/docs/specs/whatsapp-user-send.md
+     - Plan: /Users/foo/dev/.worktrees/messaging/MES-4282/docs/plans/2026-05-27-whatsapp-user-send-plan.md
+     - Test inventory: /Users/foo/dev/.worktrees/messaging/MES-4282/docs/specs/whatsapp-user-send-test-inventory.md
+
+     Worktree: /Users/foo/dev/.worktrees/messaging/MES-4282
+     Branch: feat/MES-4282/whatsapp-user-send
+     Ticket: MES-4282
+     MR/PR: #29
 
-     Do NOT carry over assumptions from any prior session — the artefacts above are the only authoritative inputs.
+     Do NOT carry over assumptions from any prior session — the frozen-state file and artefact paths above are the only authoritative inputs.
      ```
 
 10. **One-click handoff gate (`AskUserQuestion`).** Ask the user: