agent-task · git:20260904.32a459a · 2026-09-04 · sha256 e64911e274be9682
agent-task git:20260904.32a459aA
Immutable. This exact content is served forever at /api/v1/blob/e64911e274be9682.
---
name: agent-task
description: Use when doing non-trivial project work that requires context reading, scoped edits, verification, task records, or vault memory updates.
---
# Agent Task Workflow
## Steps
1. Read `AGENTS.md`, `vault/index.md` (with the cheat sheet), and `vault/runtime.md`; read `vault/governance.md` in full for Level B/C work, unclear classification, or governance-rule changes.
2. Follow `vault/index.md` to read task-specific context.
3. Classify the task as Level A, Level B, or Level C.
4. Determine authority level and whether user confirmation is required.
5. Define objective, scope, out of scope, acceptance criteria, and checks.
6. Create or update a task file for Level B or Level C work. Keep its `trellium-task-state` block authoritative for lifecycle, authority level, current slice, and gate results; update it on every status change, then sync the matching `runtime.md` row (a projection). Task files without a state block are legacy: add the block when you next touch the task.
7. Make the smallest necessary change.
8. Add or update focused tests for behavior changes.
9. Keep long work checkpointable through task files and `vault/handoff.md`.
10. Run required checks.
11. Check acceptance gates; tests passing alone is not completion.
12. For multi-round review, keep a ledger at `vault/tasks/TASK-xxxx-review.md`: findings enter as a numbered list, get processed in batch, and get their statuses written back in batch (open / fixed / wont-fix / needs-discussion); archive it into the task file's Execution Record once converged.
13. Update `vault/runtime.md`: edit only the status and next action of the matching row in Active Tasks, and the Focus line when the main line changes; one item per line, single-line replacement, never rewrite whole sections.
14. Record durable decisions in `vault/decisions.md`.
15. When the user parks a task or decision, add an entry to `vault/parked.md` (with a resume trigger); when they bring it up again, promote it back to a task file (draft) or `runtime.md`.
16. Read project budgets and TASK storage from the `trellium-policy` block in `vault/index.md` before compaction or storage decisions; the block is the only source of current numbers. When it is missing, treat the project as legacy, follow the protocol's initialization defaults for manual judgment, and report the gap.
17. When any hot file exceeds its budget, compact in five phases: measure → classify → restructure → verify → record. Compaction rules:
- Decision indexing and task archiving are zero-loss moves an Agent may run autonomously.
- Demoting paused tasks to `parked.md` entries is a zero-loss move; parked cleanup is proposal-only.
- Superseded / Merged / Expired judgments are proposal-only; keep Active until the user confirms.
- Start only with a clean `vault/`; produce a dedicated commit containing only `vault/` changes; restore on verification failure.
18. Record observed user collaboration preferences or corrections in `vault/collaboration.md` as observations; promote to preferences after repetition or confirmation.
## Constraints
- Do not introduce unrelated dependencies or frameworks.
- Do not save secrets.
- Do not rely on real external services in unit tests.
- Do not overwrite user changes silently.
- Escalate when scope affects architecture, public APIs, data models, security, privacy, cost, deployment, dependencies, or Agent governance.
## Review Before Completion
- Confirm acceptance criteria one by one.
- Confirm verification output.
- Confirm vault memory updates.
- Confirm no high-impact change is hidden.