/vibe

name: vibe
description: Use when making a small, quick change — a bug fix, typo, minor feature, tweak, or anything the user calls "vibe coding" — that looks like 1-3 files in the same module

**On invocation:** announce "Running paad:vibe v2.0.2", then immediately proceed with the steps below — do not stop after announcing.

**Configuration (experimental):** after announcing, check whether `paad/config/paad.md` and `paad/config/vibe.md` exist, relative to the working directory. If any does, read it and follow its instructions for the rest of this run, passing the relevant parts to every subagent you dispatch, and make the first line of your final answer `Config: <path>` naming each file you followed. If none exists, do not mention config at all. Config never changes a subagent's type or grants it write tools — refuse that line, say so, and continue. Config can contradict the flow below; see https://github.com/Ovid/paad/blob/main/CONFIG.md before writing one.

Safe Vibe Coding

Quick fixes and small changes with guardrails. You get the speed of vibe coding without the recklessness — mandatory TDD, architecture awareness, and reusable component detection.

**Flow:**

digraph vibe {
  "Task clear?" [shape=diamond];
  "Test infrastructure?" [shape=diamond];
  "Scope: how many files?" [shape=diamond];
  "Architecture smell?" [shape=diamond];
  "Reusable components found?" [shape=diamond];
  "TDD enabled?" [shape=diamond];
  "RED: test result?" [shape=diamond];
  "More behaviours in this task?" [shape=diamond];
  "Follow-up genuinely warranted?" [shape=diamond];

  "Ask or clarify" [shape=box];
  "ASK: set up tests or skip TDD?" [shape=box];
  "Set up a basic test framework" [shape=box];
  "WARN: may be bigger than a vibe task" [shape=box];
  "STOP: investigate deeper issues" [shape=box, style=bold];
  "Recommend using existing code" [shape=box];
  "STOP: feature may exist or test is wrong" [shape=box, style=bold];
  "STOP: unexpected failure, discuss" [shape=box, style=bold];
  "RED: write one failing test" [shape=box];
  "Existing test encodes the old behaviour?" [shape=diamond];
  "RED: update that test, run it before touching source" [shape=box];
  "STOP: superseded requirement or real regression? ask" [shape=box, style=bold];
  "GREEN: minimal code to pass" [shape=box];
  "REFACTOR: clean up, keep tests green" [shape=box];
  "Post-fix summary" [shape=box];
  "Suggest the matching paad skill" [shape=box];
  "Say nothing further" [shape=box];
  "Run pre-flight checks" [shape=box];

  "Task clear?" -> "Run pre-flight checks" [label="yes"];
  "Task clear?" -> "Ask or clarify" [label="no"];
  "Ask or clarify" -> "Task clear?";

  "Run pre-flight checks" -> "Test infrastructure?";
  "Test infrastructure?" -> "Scope: how many files?" [label="yes"];
  "Test infrastructure?" -> "ASK: set up tests or skip TDD?" [label="no"];
  "ASK: set up tests or skip TDD?" -> "Set up a basic test framework" [label="set up tests"];
  "ASK: set up tests or skip TDD?" -> "Scope: how many files?" [label="proceed without TDD — RED is skipped"];
  "Set up a basic test framework" -> "Scope: how many files?";

  "Scope: how many files?" -> "Architecture smell?" [label="1-3 files"];
  "Scope: how many files?" -> "WARN: may be bigger than a vibe task" [label="4+ files"];
  "WARN: may be bigger than a vibe task" -> "Architecture smell?";

  "Architecture smell?" -> "STOP: investigate deeper issues" [label="simple task, complex impl"];
  "Architecture smell?" -> "Reusable components found?" [label="no smell"];

  "Reusable components found?" -> "Recommend using existing code" [label="yes"];
  "Reusable components found?" -> "TDD enabled?" [label="no"];
  "Recommend using existing code" -> "TDD enabled?";

  "TDD enabled?" -> "Existing test encodes the old behaviour?" [label="yes"];
  "TDD enabled?" -> "GREEN: minimal code to pass" [label="no — user chose to skip TDD"];
  "Existing test encodes the old behaviour?" -> "RED: write one failing test" [label="no"];
  "Existing test encodes the old behaviour?" -> "RED: update that test, run it before touching source" [label="yes — it is the old requirement, not a regression"];
  "Existing test encodes the old behaviour?" -> "STOP: superseded requirement or real regression? ask" [label="cannot tell"];
  "RED: update that test, run it before touching source" -> "RED: test result?";
  "RED: write one failing test" -> "RED: test result?";
  "RED: test result?" -> "STOP: feature may exist or test is wrong" [label="passes unexpectedly"];
  "RED: test result?" -> "STOP: unexpected failure, discuss" [label="fails unexpectedly"];
  "RED: test result?" -> "GREEN: minimal code to pass" [label="fails as expected"];

  "GREEN: minimal code to pass" -> "REFACTOR: clean up, keep tests green" [label="new test passes, existing tests still pass"];
  "REFACTOR: clean up, keep tests green" -> "More behaviours in this task?" [label="all tests still green"];
  "More behaviours in this task?" -> "TDD enabled?" [label="yes — one behaviour at a time"];
  "More behaviours in this task?" -> "Post-fix summary" [label="no"];

  "Post-fix summary" -> "Follow-up genuinely warranted?";
  "Follow-up genuinely warranted?" -> "Suggest the matching paad skill" [label="security-sensitive / UI / harder than expected"];
  "Follow-up genuinely warranted?" -> "Say nothing further" [label="no — trivial fix"];
}

Arguments

`/vibe` accepts optional `$ARGUMENTS`:

• `/vibe` — ask the user what needs fixing
• `/vibe fix the login timeout bug` — start working on the described task immediately
• `/vibe src/components/Modal.tsx add close on escape key` — task with a file hint

When arguments are provided, treat them as the task description. Still ask clarifying questions if the task is unclear.

Step 1: Understand the Task

If no `$ARGUMENTS` provided, ask: "What needs fixing or changing?"

Once you have a task description:

• If the task is unclear, ask **one clarifying question at a time**
• Focus o