task-autoresearch

Task Autoresearch

A lightweight framework for finishing bounded coding or analysis work with evidence — not for running open-ended experiment loops. The goal is to close the task with a clear record of what was confirmed, what was inferred, what changed, and what was verified.

This is the orchestrator. The framework also installs:

• Companion skills: task-autoresearch-verify (run the narrow verification step), task-autoresearch-report (render the final report).
• Subagents: evidence-collector, reverse-analyst, verifier.
• Template: templates/REPORT.md.

You can complete most tasks with this skill alone; reach for the companion skills and subagents when the work benefits from a dedicated context window or a structured handoff.

Entry Steps

1. Pick the mode — Development (build/fix/refactor/migrate) or Reverse analysis (explain/diagnose/recover-contract). If both apply, start in reverse-analysis until the failure point is clear, then switch.
2. State the boundary — write one or two sentences naming what is in scope and what is out of scope. Do not skip this step.
3. Inspect before claiming — read the closest relevant files, logs, or artifacts before forming a hypothesis.

Pick the Mode

• Development: build, fix, refactor, migrate, add tests, or verify code behavior.
• Reverse analysis: explain how something works, diagnose automation/UI/network/log/HAR behavior, identify root cause, or recover a protocol/contract boundary.

If both apply, start with reverse analysis until the failure point or contract is clear, then switch to development for the smallest fix.

Universal Loop

1. Read the user's task and inspect the closest project files or artifacts before making claims.
2. State the current task boundary in one or two sentences.
3. Work in small steps: inspect, hypothesize, change or probe, verify.
4. Keep evidence: commands, important outputs, file paths, extracted artifacts, screenshots, or logs.
5. Separate confirmed facts from inference.
6. Stop when the task is handled, a blocker is proven, or the next step needs user authority.

Development Mode

• Prefer the repo's existing patterns and local helper APIs.
• Keep edits scoped to the requested behavior.
• Preserve unrelated worktree changes.
• Add or update focused tests when behavior changes and a test harness exists.
• Run the narrowest useful verification first; broaden only when the touched surface is shared.
• Report changed files, verification commands, and remaining risk.

When verification has more than a handful of steps, delegate to the verifier subagent so the verification context stays separate from the implementation context.

Reverse Analysis Mode

• Default to read-only inspection.
• Preserve original evidence; create derived extracts instead of modifying source captures.
• For JSON, HAR, logs, and protocol data, prefer structured parsing over ad hoc string matching.
• Find the earliest actionable failure point before explaining downstream symptoms.
• Distinguish: observed evidence, inference from evidence, unknowns.
• Stop broad probing once multiple checks point to the same upstream blocker.

For large captures (multi-MB HAR, sprawling logs, unfamiliar codebases), spawn the evidence-collector subagent first to gather pointers, then reverse-analyst for the failure-point reasoning. Both are read-only by design.

Minimal Report Shape

Use this shape in the final answer or in a local REPORT.md if the user asks for an artifact (the template lives at templates/REPORT.md inside this plugin):

## Summary

## Confirmed

## Inferred

## Evidence

## Changes

## Verification

## Remaining Risk

Omit empty sections for small tasks. Keep the report short unless the user asks for a full dossier.

Closing the Task

• When a scoped change is ready, hand off to the task-autoresearch-verify skill to run the narrow check and capture the result.
• After verification passes, hand off to the task-autoresearch-report skill to synthesize the final write-up from the collected evidence.