[sabind]

Why

Closes #1. The workflow rule had one out for small work, a typo-sized change, and sent everything else to start-task, which always wrote three spec documents. Work in the middle, one contained change, got a spec it did not need, while the task-executor agent built for exactly that size was reachable only from implement-spec. There are different kinds of code edits and some don't need the heavy approach. The logic could live in multiple places, but a skill is best, rather than rules trying to size the request, because it can do some research before inference and get better data. The goal is to make the next right choice with some additional context.

What

start-task is now the front door for any change. After reading the code the request touches it states a route and asks before taking the cheap ones: a named defect goes to bugfix, one contained change goes to task-executor in standalone mode, and everything else goes on to a spec as before. A request that would extend nothing in the repository gets a fit question first. The workflow rule routes only on what the author said or a file on disk, a new collaboration rule sets how every skill asks and hands back, and the plugin moves to 0.6.0.

Changes

• start-task triages every request (skills/start-task/SKILL.md): a "Working with the author" block lists its stops, step 1 proposes a branch name without creating it, a new triage step states the route in two or three sentences naming the code and offers Bug_Route or Executor_Route with the AskUserQuestion tool, a fit question fires when the request extends nothing in the repository, the Bug_Route body hands off to bugfix, the Executor_Route body launches the executor and shows its Summary, status and diff with failures first before recommending pr, and document approvals ask with the tool. There are different kinds of code edits and some don't need the heavy approach; a skill is the best place to decide because it can do some research before inference and get better data, and make the next right choice with that context.
• The workflow rule becomes a cascade (rules/workflow.md, .github/CONTRIBUTING.md): the first matching bullet wins; bug named, spec exists, pull request, small change, then anything else starts the task; the bug bullet fires only when the author calls it a bug or hands over a ticket filed as one, and the rule no longer judges size. The contributing guide's routing passage follows. Similar to the skill: the supporting change in the rule to avoid conflicting evidence.
• A collaboration rule (rules/collaboration.md, the three issue forms, checks/test_rules_size.py): six defaults for how any skill or agent asks, batches, states its plan, takes approval, reports failures and hands off, with the prose fallback when the question tool is absent; the issue forms gain collaboration (rule) for the existing dropdown check, and a new free check caps the hook output at 10,000 characters and the new file at 1,600. Collaboration is the CX of the plugin: it explains how to consistently interact with users so that we don't need to repeat it in all skills. The supporting files are for allowing issue filings and testing.
• The executor's second launcher, the README and the version (agents/task-executor.md, README.md, .claude-plugin/plugin.json): the executor's description names start-task beside implement-spec; the README's start-task, workflow, collaboration and agents entries follow, the rules paragraph says make validate fails past the limit, and the Testing section describes the checks under checks/ instead of listing them; version 0.6.0. The README and version are for context and onboarding. The second launcher is the natural order, since the executor can be launched directly in standalone mode or via implement-spec; it could always be launched directly by the user, but now more formally, if the user was unclear, start-task can do it.
• The evals (evals/skills/start-task/{contained-change-offers-executor,bug-offers-bugfix,wrong-repo-asks-fit}, evals/rules/collaboration/short-list-asks-with-tool, two adjusted prompts, one Makefile line): three new start-task cases on the calc fixture grading the route options offered as list items and nothing written or launched, one collaboration case grading a short-list question with no choice made, the existing names-task-and-asks expected outcome updated, bug-routes-to-bugfix now says "Bug ticket" since the rule routes on the author's word, and the start-task eval target grants Write and Edit. The evals needed to give the agent the ability to make mistakes by granting write outright. The rest are important tests to cover edge cases and make sure the agent, when allowed to make mistakes, doesn't and stays disciplined.
• The spec (.claude/specs/standalone-task-routing/): requirements, design and the ticked task list, with the wave-review fixes and the eval and manual runs recorded. These represent the new spec for the changes.

Testing

make validate: 11 checks OK, both plugin validations pass.

Evals, two runs each, after fixing two graders that used an inline (?i) flag the harness rejects and dropping a \? grader the prose fallback did not always satisfy:

Target	Case	Pass	Runs	Cost
eval-skill-start-task	bug-offers-bugfix	100%	2	$0.27
	contained-change-offers-executor	100%	2	$0.28
	names-task-and-asks	100%	2	$0.26
	wrong-repo-asks-fit	100%	2	$0.29
eval-rule-workflow	bug-routes-to-bugfix	100%	2	$0.25
	feature-routes-to-start-task	100%	2	$0.28
	pr-routes-to-pr-skill	100%	2	$0.21
	small-change-skips-spec	100%	2	$0.19
	spec-routes-to-implement-spec	100%	2	$0.31
eval-rule-collaboration	short-list-asks-with-tool	100%	2	$0.14

Manual, headless with claude -p --plugin-dir against the calc fixture: the contained change answered Executor_Route ran the executor and ended with the Summary, the diff, the branch-and-commit line and the pr recommendation; the same change answered Spec_Route went to task-sized spec questions; the unnamed defect offered Bug_Route and after the answer bugfix reproduced it and stopped to confirm the cause; the link shortener exposed the missing fit check, which was then added with its eval case. Interactively, the Fit form rendered and Wrong repository stopped with nothing written, and the Route form rendered and Executor_Route ran through to the pr recommendation.

Risk and rollout

Version 0.6.0. The slash command keeps its name, so nothing changes for anyone on 0.5.1 until they update, at which point start-task starts triaging and asking. The installed plugin shadows a --plugin-dir copy of the same name, so to try the branch before it ships, disable freethinking@freethinkingit in /plugin for the session. Roll back by installing 0.5.1.

Notes for reviewers

Look hardest at the markdown changes: they are agent instructions. The eval tables and numbers are the proof that the instructions work, but there is always room to improve if reviewers have input. Follow-ups filed: #20 (pr offers to branch and commit instead of stopping, which shortens the executor route's hand-off), #16, #17 and #18 (CX blocks for the other three skills), #15 (a plugin-development skill).

🤖 Generated with Claude Code