analyze-task

Analyze Task

Use this skill before coding for non-trivial repository work:

• new features
• cross-layer changes
• architecture or model changes
• complex bugs
• tasks that likely need multiple commits / reviews / loops

Do not use it for tiny local edits that can be implemented and verified immediately.

Purpose

Produce a short Analysis Brief that makes the task discussable and executable.

This skill is for:

• clarifying the goal
• defining non-goals
• identifying what must be decided before coding
• deciding whether a subagent is justified
• preparing the task for a scope-alignment discussion
• setting up the handoff to write-task-todo only after alignment

This skill is not for writing code and not for writing docs/todolist.md.

Core rules

1. Prioritize structure before UI
2. think about canonical docs/contracts, data model, types, interfaces, repo/service/runtime boundaries before UI details

1. Prefer explicit boundaries
2. say what is in scope and what is not
3. surface ambiguity instead of silently choosing

1. Use subagents selectively
2. default is local analysis
3. use an xhigh explorer subagent only when the task is cross-layer, ambiguous, high-risk, or likely to benefit from an independent architectural read
4. if you use a subagent, give it a narrow question; do not outsource the entire solution

1. Do not create a canonical doc yet unless the concept is already clearly stable and long-lived
2. early definitions belong in analysis/todo first

1. Every analysis should end with an alignment state:
2. ready for alignment discussion
3. ready for write-task-todo after confirmation
4. or blocked on a single clarification

Required output

Produce a brief with these sections:

## Analysis Brief

### Goal

### Product Boundary

### Scope

### Non-goals

### Canonical-Doc Impact

### Data / Type / Interface First

### Layer Impact

### Risks / Ambiguities

### Need Subagent?

### Test Strategy

### Alignment Questions

### Ready for Todo?

Section guidance

Goal

• one concise sentence

Product Boundary

• say whether the center of gravity is product, platform, or both

Scope

• list what this task must accomplish

Non-goals

• list what this task must not expand into

Canonical-Doc Impact

• identify whether an existing canonical doc already governs this area
• in Formax, prefer checking docs/contracts/*, docs/frontend/*, docs/environment-variables.md, CODEMAP.md, and package-local README deep dives
• if yes, say which doc(s) govern the area
• if not, say whether this task is likely to need a new canonical doc later

Data / Type / Interface First

• identify the definitions that should be settled before implementation
• examples:
• payload shape
• DTOs
• repo interfaces
• service boundaries
• route contracts
• surface/view state

Layer Impact

• name affected layers as applicable:
• core
• contracts
• db
• app
• routes
• schema
• repo
• service
• runtime
• ui

Risks / Ambiguities

• call out the likely failure modes or places where the task could go structurally wrong
• in Formax, explicitly consider parity drift, transcript/reset semantics, prompt/tool exposure drift, and thread/runtime state ownership when relevant

Need Subagent?

• answer yes or no
• if yes, explain exactly what question the subagent should investigate

Test Strategy

• identify what should be framed by tests first
• prefer focused tests over blanket integration-first thinking
• match Formax's repo guidance: targeted tests first, no coverage runs, protect user-visible behavior and runtime semantics

Alignment Questions

• list the decisions or tradeoffs that should be explicitly confirmed before writing docs/todolist.md
• if there are no meaningful open questions, say so directly

Ready for Todo?

• answer whether the task should proceed into write-task-todo
• default to no if important scope, boundary, or semantics questions are still open

Handoff rule

Do not treat this skill as an automatic handoff to write-task-todo.

The normal sequence is:

1. produce the Analysis Brief
2. discuss and align the analysis with the user
3. only then hand off to write-task-todo

If the task is non-trivial and the analysis is already aligned, hand off to write-task-todo.

If the task is trivial, explicitly say that a structured todo is not needed.