Intake

The funnel into planning: every work item gets intent captured, size estimated, and (for tracked issues/PRs) a triage state before implementation.

Intent capture

Every ticket/spec/PRD needs an Intent section before implementation:

1. Objective — what the user wants to achieve.
2. Landing zone — which project/module/feature is affected.
3. User impact — how the change affects the user.
4. Boundaries — what's in and out of scope.

## Intent

- **Objective:** Add OAuth2 login to the mobile app.
- **Landing zone:** `src/auth/` module, `LoginScreen` component.
- **User impact:** Users can sign in with Google or Apple instead of email.
- **Boundaries:** No password reset flow, no social profile sync.

Unclear intent → ask for clarification before proceeding (or grilling for a full interview). Vague boundaries cause scope creep; missing landing zones cause edits in the wrong module.

Task sizing

Estimate lines added/modified/deleted, files touched, system boundaries crossed (API/DB/auth = more risk), and test additions.

Helper: python3 scripts/estimate.py (in this skill's scripts/). Don't estimate only the happy path — tests count. Split by logical boundaries, not arbitrary file count.

Issue/PR triage

Move issues on the project tracker through a small state machine. External PRs are covered too: a PR is an issue with attached code — same roles, same states.

Every comment posted during triage must start with:

> *This was generated by AI during triage.*

Reference docs: AGENT-BRIEF.md (durable agent briefs), OUT-OF-SCOPE.md (the .out-of-scope/ rejected-requests KB).

Roles

Category (pick one): bug, enhancement. State (pick one): needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix.

Every triaged issue carries exactly one of each; conflicting state roles → flag and ask the maintainer. Canonical names — the actual label strings come from the tracker config. needs-info returns to needs-triage on reporter reply; maintainer overrides win.

Flow

1. Gather context — full issue/PR (body, comments, labels, diff for PRs); prior triage notes (don't re-ask). Two codebase checks: (a) redundancy — search by domain concept for an existing implementation (found → wontfix: already implemented, no .out-of-scope/ write); (b) prior rejection — check .out-of-scope/*.md.
2. Recommend — category + state with reasoning; wait for direction.
3. Verify the claim — reproduce bugs; check out PRs and run their tests. Confirmed verification strengthens the agent brief.
4. Grill if needed — grilling + domain modeling, one round at a time.
5. Apply the outcome — ready-for-agent → post agent brief; ready-for-human → same structure + why not delegable; needs-info → triage notes template below; wontfix → close (rejected enhancement → .out-of-scope/ + link).

Quick override: "move #42 to ready-for-agent" → confirm and apply directly, skip grilling.

Needs-info template

## Triage Notes

**What we've established so far:**
- point 1

**What we still need from you (@reporter):**
- question 1

Questions must be specific and actionable. On resume, read prior notes first.

Optional Laya assist (off by default): profile issue-category-v1 suggests bug/enhancement/needs_info via laya_cli.py recommend — a label suggestion only; triage transitions stay manual/deterministic.