| name | one-off |
| description | Lightweight pipeline for single, bounded implementation tasks — use this for any small change that doesn't need a full feature or bug workflow. Trigger whenever a user asks to: add a flag or option to an existing function or script, extract duplicated code into a constant or helper, rename a method or variable, make a hardcoded value configurable via an env var or parameter, add input validation to a specific function, or implement any other isolated change touching 1-3 files. Also trigger for phrases like 'small change', 'quick task', 'single task', 'one-off', or 'quick fix'followed by an implementation request. Do NOT trigger for bugs with unclear root cause (use diagnose), multi-file features (use grill-me → to-prd → to-tickets), architecture questions, PR reviews, or diagnostics. |
/one-off — Single Task Implementation
Lightweight pipeline for simple, bounded tasks that don't warrant a full feature or bug workflow.
When to Use
- Single concern: add a config option, refactor a function, update a script, add a small utility
- Clear scope: touches 1-3 files, no architectural decision needed
- Not a bug (use diagnose), not a multi-file feature (use grill-me → to-prd → to-tickets)
Trigger
User types /one-off, "one-off task", or "quick task".
Steps
Step 1 — Capture Task
If user included a description with the trigger, use it. Otherwise ask: "What do you want to do?"
Step 2 — Ask 2-3 Clarifying Questions
Ask only what's genuinely ambiguous. Max 3 questions in one message. Choose from:
- Scope: "Does this touch just
[file X] or also [related file Y]?"
- Approach: "Should this follow [existing pattern] or [alternative]?"
- Constraints: "Any edge cases to handle? Tests that must keep passing?"
- Stack: If language/framework isn't clear from context.
Skip questions that are obvious from context.
Step 3 — Confirm Scope
After user answers, write a brief implementation summary (3-5 lines):
- What exactly changes
- Which files are touched
- Approach / key decision
- Test strategy (what test will prove it works)
Ask: "Does this match what you want? Say yes to proceed."
Step 4 — Dispatch Subagent
Dispatch a general-purpose subagent (model: claude-sonnet-4-6) with:
- Exact files to touch (from step 3)
- Scope boundary — what to implement AND what not to touch
- TDD requirement — write failing test first, then implementation, then refactor
- Done criteria — specific observable outcome that means "done"
Step 5 — Report
After subagent completes, report back:
- Files changed
- Test added/modified
Constraints
- No kanban tickets
- No PRD
- No ship-it (user pushes manually or asks)
- If scope grows during clarification → stop, redirect to
/feature-flow
- If it's a bug → redirect to
bug-flow
