Keep project context usable
Attach the rules, decisions and source material needed for a task. Keep that context aligned with the repository as the product changes.
Project documents explain lasting constraints. Task records explain a particular request, run and review decision. Use each to answer a concrete question before starting more work.
Project rules
Keep repository instructions, architecture decisions and setup requirements where people and agents can inspect them. Select the material relevant to the next task.
A real Stable workspace: generated Pulse signals beside the project wiki.
Task scope and evidence
Record the requested outcome, permitted scope and checks beside the run history and resulting Git changes. Use exact findings from that record when requesting rework.
Exception example: DEMO-9 has exhausted its reissue budget. Open findings and pending integration remain visible beside the decision controls.
Choose sources deliberately
README files explain setup; AGENTS.md files define repository instructions; ADRs preserve architecture decisions; prompts and skills describe recurring work. Check which source answers the task’s question before adding more text.
Check the instructions an agent will use
Outdated documents can become incorrect execution instructions. Compare important constraints with the current code and link the source revision when it matters.
Project history and task history
Use project history to understand why a rule or architecture decision exists. Use task history to inspect prompts, runs, findings, screenshots and the decision on one change.
Read related work first
Search existing tasks and inspect their evidence before repeating an investigation. Use the available history views and API. Keep generated summaries linked to their source records so they can be checked.
Activity across projects: a queryable ledger of signals, decisions, and actions with per-project and event-class filters.
Assign documentation repair
Give an outdated setup guide or missing decision record its own task. Specify the affected documents, the source of truth and the evidence needed to review the correction.
Review the effects on documentation
A code change may invalidate examples, prompts, screenshots or public claims. Record the mismatch and update the affected material or create a linked follow-up.