You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
49 lines
4.6 KiB
49 lines
4.6 KiB
2 months ago
|
---
|
||
|
|
name: "clawvibe"
|
||
|
|
description: "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.
|