Choosing the right workflow
Match the ceremony to the risk: route a task to the full pipeline, a standalone skill like hotfix or bug-hunting, or Pocket Education.
Pocketto has one rule for routing: match the ceremony to the risk. Features that span files and phases get the full pipeline; small, clear work gets a focused skill.
The router
| Your situation | Start with |
|---|---|
| Rough idea, no clear problem yet: need to explore | pocket-pitching |
| Clear problem: need a spec + acceptance criteria | pocket-grinding |
| Approved spec: need a TDD execution plan | pocket-planning |
| Execution plan ready: sequence/phase it | pocket-structuring |
| Plan or phase file ready: execute task-by-task | pocket-development |
| Phase-level pass complete: reconcile and close | pocket-closing |
| A bug, a failure, or "audit this code" | bug-hunting |
| Small-to-medium change, full pipeline is overkill | hotfix |
| Design system / brand identity / UI tokens | brand-design |
| An assumption to validate before planning | structured-research |
| Review a plan before executing it | validate-plan |
| Existing repo needs a local project guide or learner calibration | pocket-init |
| You want to write the code yourself, with guidance | pocket-education |
| Team needs GitHub lifecycle synchronization | Pocket Enterprise |
Rules of thumb from the built-in router (pocket-help):
- Don't know if the problem is well-formed? →
pocket-pitching - Problem is clear but needs a real feature plan? →
pocket-grinding - It's a quick, well-understood change? →
hotfix - Something is broken? →
bug-hunting - Holding an unverified assumption? →
structured-research - Already have an approved spec? →
pocket-planning
The triviality off-ramp
pocket-grinding checks task size as soon as the context scan makes it estimable. A task is trivial when it touches only 1–4 files and is resolvable in 1–2 requests, with none of these complexity signals: a new system or architectural decision, unclear or contested requirements, or API contract / system-boundary changes.
When the heuristic fires, the skill recommends hotfix, which still enforces a brief-plan + subagent-review gate, before the multi-stage ceremony starts. "New feature" alone does not suppress the check: a small, clearly-specified feature like "add a zoom button" is a hotfix candidate. The discriminator is requirement clarity + size + architectural impact, not the label.
The gate is advisory: continue with grinding if you expect hidden complexity.
Entry points into the pipeline
You do not always start at the top:
| You already have… | Start at |
|---|---|
| Only a fuzzy idea | pocket-pitching |
| A clear problem | pocket-grinding |
| An approved spec | pocket-planning |
| An execution plan | pocket-structuring |
| A plan/phase file ready to build | pocket-development |
| A finished, passing phase | pocket-closing |