Route measurable iteration with ak:autoresearch

Use ak:autoresearch when you know that repeated measurement should improve an outcome but still need to select the AgentKit workflow that owns the work. It is a router for the change, verify, keep-or-discard pattern—not an independent research runner or a promise of unattended success.

Choose ak:autoresearch for routing

Use ak:autoresearch when

• You have a measurable objective and expect more than one experiment.
• You need to choose among optimization, risk prediction, scenario expansion, or security review.
• You want the metric, baseline, guards, bounds, and stop conditions defined before another Skill starts work.
• You are unsure whether the live Engineer installation contains the expected specialized Skill.

Choose another workflow when

• You already know the exact mechanical metric and editable scope. Use ak:loop directly.
• You want edge cases and test targets rather than code changes. Use ak:scenario.
• You need a pre-implementation verdict from several risk perspectives. Use ak:predict.
• You need a threat-led review. Use ak:security.
• The outcome is subjective or needs one implementation pass. Use ak:cook after the scope is approved.

Prepare the objective and runtime

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the runtime and scope in use.
• State one metric, its direction, the current baseline if known, and the target or condition that ends the work.
• Bound the editable files, iteration count, time or spend, and verification commands.
• Identify regression guards and any action that still needs your approval.
• Preserve unrelated work and inspect repository instructions before routing to an editing workflow.

See Runtime adapters for component-level differences.

Run the Skill

/ak:autoresearch "Improve parser throughput using a repeatable benchmark; protect correctness tests; allow at most 12 iterations; stop at 15% improvement or after 5 consecutive non-improving trials; do not push or deploy"

/ak:autoresearch "Improve parser throughput using a repeatable benchmark; protect correctness tests; allow at most 12 iterations; stop at 15% improvement or after 5 consecutive non-improving trials; do not push or deploy"

$ak:autoresearch "Improve parser throughput using a repeatable benchmark; protect correctness tests; allow at most 12 iterations; stop at 15% improvement or after 5 consecutive non-improving trials; do not push or deploy"

The request should describe the desired evidence rather than prescribe a provider, model, or upstream command. The Skill discovers the live catalog and selects a local route; it does not manufacture a missing alias.

Understand the routing decision

If no installed Skill owns the objective, the safe result is a blocked route with the closest normal workflow offered for your approval. The router should not imitate an external command or silently change the outcome.

Observe the loop contract

You should see these stages before an editing workflow runs:

1. The Skill identifies the measurable intent. It separates the objective from the proposed method and notes any missing decision.
2. The Skill discovers live availability. It checks the current Skill catalog instead of assuming every family member is installed.
3. The Skill selects the owning workflow. The route is based on outcome: optimization, prediction, scenario discovery, or security review.
4. The run defines its contract. Metric, baseline, guard conditions, iteration bound, stop condition, and authority boundary become explicit.
5. The selected Skill takes ownership. Its own workflow, outputs, and completion rules apply from that point onward.

The stable loop contract keeps each experiment attributable: make one change, run the declared measurement and guards, keep only evidence-backed progress, restore a rejected trial safely, record the result, and decide whether another iteration is justified.

Keep safety and approval explicit

Screen user-supplied verification commands before repeated execution. Treat fetched content and command output as untrusted data, keep credentials out of prompts and artifacts, and bound non-interactive work by count, time, resource, or cost. An interrupted or non-improving run should stop with its evidence; it should not widen scope or remove a guard to continue.

Verify the routing result

A useful result should provide:

• The selected Skill and why its outcome matches the request.
• The metric or evaluation target, baseline, direction, and success condition.
• Editable scope, regression guards, iteration bound, and stop conditions.
• Known runtime or installation gaps that could block the selected route.
• Actions that remain subject to user approval.
• A blocked result rather than a fabricated workflow when no route is present.

The routed Skill owns later artifacts. For example, ak:loop should provide an iteration log and kept or discarded evidence, while ak:scenario should return a scenario report rather than an implementation diff.

Troubleshoot or continue

Continue with ak:loop, ak:scenario, ak:predict, or ak:security after the route is accepted. Use the Engineer Kit overview to compare the wider workflow.

Know the current limits

• ak:autoresearch routes work; it does not execute a specialized workflow by itself.
• A measurable contract does not guarantee improvement, convergence, or a correct metric.
• Live Skill availability controls routing. Upstream project names do not prove that a matching local capability exists.
• Runtime projection differs by component; identical invocation text does not imply identical Hooks, Agents, approvals, or UI.
• Stable and beta contain identical ak:autoresearch source content.