Agent Task Brief
Agent Task Brief
Use this brief when handing work to an AI agent.
Task
-
Task Mode
Choose one:
- Spec authoring
- Implementation from accepted spec
- Reverse spec review
- Evidence mapping / test bridge
- Release audit
- Method update / upstream rule propagation
- Repository maintenance
Selected mode completion rule:
-
Authority
| Item | Source |
|---|---|
| Product decision | |
| Platform / upstream contract | |
| L0 value or invariant | |
| L1 domain term or state | |
| Proposal or sample import to re-authorize |
Standard / Evidence Boundary
Before reviewing code, state the boundary:
| Check | Answer |
|---|---|
| Is the relevant spec accepted as the product/system standard? | yes / no / unknown |
| If code is missing, will the spec remain unchanged? | yes / no / needs decision |
| Where will implementation status be recorded? | Verification Map / review ledger / release tracker |
Do Not Downgrade: do not downgrade accepted specs to match incomplete code. If
implementation evidence is missing or partial, classify
missing_implementation, partial_implementation, missing_test, or
wrong_code, then fix code/evidence or record the blocker.
Layer Impact
| Layer | Impact |
|---|---|
| L0 | none / update |
| L1 | none / update |
| L2 | none / update |
| L3 | none / update |
Method Update Propagation
Fill this section when applying a newer ILS version, upstream rule, or template to an existing project. Governance updates alone are not completion.
| Item | Answer |
|---|---|
| Upstream rule/version applied | |
| Governance installed | AGENTS / README / guide / template / script / generated |
| Authoritative spec inventory command or list | |
| In-scope specs reviewed | |
| Specs excluded and why | |
| Specs still pending | |
| Residual gap ledger path | |
| Completion status | complete / partial |
Do not mark complete until every in-scope authoritative spec was inventoried,
reviewed under the new rule, updated or explicitly excluded, and regenerated
artifacts/checks have passed.
Feature Archetype Packs
Select all that apply before implementation. If a selected pack has no
corresponding L2 [Unwanted], state behavior, or L3 contract, update the spec
first.
| Pack | Applies? | Governing REQ/S or decision |
|---|---|---|
| Async customer operation | yes / no | |
| Source or file ingestion | yes / no | |
| External AI or automation | yes / no | |
| Approval or decision | yes / no | |
| Payment, entitlement, or billing | yes / no | |
| Auth or account | yes / no | |
| Deletion or privacy | yes / no | |
| External integration | yes / no |
Latency And Valid Input Failure
| Check | Answer |
|---|---|
| Can any customer-visible operation outlive the generic API timeout? | no / synchronous / long request / polling / background job / streaming |
| If the user provides valid input and automation fails, what is preserved? | |
| Recovery result | recoverable draft / still-processing / retry path / actionable error / not applicable |
| Is there any empty manual-only fallback after valid input? | no / yes, needs spec decision |
Implementation Verification Obligation
Fill this before implementation. If a touched statement has no evidence path, the implementation is not ready to be called complete.
| Requirement / statement | Current evidence state | Evidence to add or update | Owner / location |
|---|---|---|---|
| REQ-XXX-001:S1 | generated_stub / mapped / traced / verified / manual_only / blocked | unit / integration / API / UI / guardrail / smoke / manual UX |
Edge-Case Prompt
For the target action, answer each before implementation:
| Case | Accepted spec behavior / candidate / not applicable |
|---|---|
| duplicate submit | |
| stale state | |
| wrong actor, ownership, or permission | |
| external success + local failure | |
| local success + downstream failure | |
| pending too long | |
| generic timeout exceeded by normal processing | |
| valid input + automation failure | |
| empty manual-only fallback risk | |
| cancel / reject / retry / expire | |
| user-visible next action |
Release Impact
Do not mark blocker until all four are checked.
| Check | Result |
|---|---|
| Authoritative requirement | yes / no / unknown |
| In target release | yes / no / unknown |
| Implementation evidence missing or partial | yes / no / unknown |
| Required for core journey | yes / no / unknown |
Release impact: blocker / non_blocker / proposal_only / not_applicable / unknown
Verification Plan
| Requirement / statement | Evidence type | Evidence target | Execution / record | Status |
|---|---|---|---|---|
| REQ-XXX-001:S1 | unit / integration / guardrail / smoke / manual UX | command/result, reviewer/date, or block reason | generated_stub / mapped / traced / verified / manual_only / blocked |
Generated stubs create work slots. A statement is not verified until the mapped test, guardrail, smoke check, or named manual UX/runtime review has executed or been recorded.
Completion Status
Use the selected mode’s completion rule from
guide/agent-mode-router.md.
Completion status: complete / partial / blocked / unverified / manual_only
Reason:
-
Stop Conditions
Stop and ask for a decision when:
- authority is unknown;
- target release scope is unknown but release impact is requested;
- an edge case is plausible but has no authority basis;
- L3 is needed but rollback, idempotency, or partial failure behavior is not knowable.