PromptWorks/clawvibe/SKILL.md

name	description
clawvibe	Explicitly invoked (e.g. /clawvibe, "let's clawvibe this", "run the full workflow on this") to route a specific task through the complete brainstorm -> plan -> implement -> review -> finish pipeline using the locally installed skills. Does NOT trigger automatically — opt-in only, unlike a standing gatekeeper.

ClawVibe is the opt-in entry point for the full software-development pipeline. It only activates when the user explicitly invokes it for a task (/clawvibe, "clawvibe this", "run the full workflow on this"). It is NOT a standing rule — it does not hijack every message, and its elevated process rigor applies only to the task it was invoked for, not to unrelated later requests in the same conversation.

Announce at start: "Using clawvibe — routing this through the pipeline."

Routing — pick ONE entry point based on what's actually being asked

• "Let's build/add/create X" / anything resembling new functionality → start at the brainstorming skill
• User already has a design/spec and wants it turned into tasks → start at writing-plans
• User has a written plan and wants it implemented → subagent-driven-development (same session, subagents available, tasks mostly independent) or executing-plans (separate/parallel session, or no subagent support)
• Bug report / failing test / unexpected behavior → start at systematic-debugging (root cause before any fix is proposed)
• "Review this diff/PR" → requesting-code-review (dispatch a reviewer) or receiving-code-review (feedback already came in and needs a response)
• "Wrap this branch up" / implementation is done and tests pass → finishing-a-development-branch
• 2+ independent, unrelated failures across different files/subsystems → dispatching-parallel-agents
• Writing or editing a skill itself (including this one) → writing-skills

If the request is ambiguous between entry points, ask the user which one fits, or default to brainstorming for anything that smells like new work rather than guessing and skipping design.

While active for this task

Hold the same discipline the underlying skills describe, for the duration of this one task:

• Don't skip brainstorming/design because the task "seems simple" — every project gets a design pass, scaled to its complexity.
• Don't write production code before a failing test exists (test-driven-development).
• Don't propose a fix before completing root-cause investigation (systematic-debugging).
• Don't claim something is done/fixed/passing without running the verification-before-completion gate.
• Chain forward using each skill's own "what's next" pointers rather than stopping short: brainstorming → writing-plans → (subagent-driven-development or executing-plans) → requesting-code-review/receiving-code-review → finishing-a-development-branch.
• Use using-git-worktrees at the point implementation actually starts, to keep the work isolated.
• Use dispatching-parallel-agents when the per-task loop surfaces multiple unrelated failures.

Common rationalizations to reject while clawvibe is active for THIS task

Thought	Reality
"This is too simple for a design pass"	Scale the design down, don't skip it.
"I'll just start coding, tests can come after"	Delete-and-restart-with-TDD territory.
"It's probably X, let me just fix it"	Root-cause first — see systematic-debugging.
"Tests should pass now"	Run them. Evidence before the claim.
"I'll skip the worktree, it's a small change"	Still isolate — cheap insurance.
"One more review round is overkill"	Review after every task, not just at the end.

Where clawvibe stops

Its elevated rigor covers the invoked task end-to-end but does not roll forward onto unrelated later requests in the same conversation. Treat it as concluded once: a design doc is written and approved with no build requested yet, or finishing-a-development-branch completes (merged/PR'd/kept/discarded), or the user redirects to something unrelated. Re-invoke explicitly for the next task.

Pipeline skills available locally (invoke by name, no prefix)

brainstorming, writing-plans, executing-plans, subagent-driven-development, systematic-debugging, test-driven-development, verification-before-completion, requesting-code-review, receiving-code-review, finishing-a-development-branch, using-git-worktrees, dispatching-parallel-agents, writing-skills

User instructions and direct requests always take precedence over this routing — if the user explicitly says to skip a phase, skip it; don't argue the case they already decided.