Overview
There are two ways to supply guidance:
- Push: place an instruction in persistent project or system context so that every relevant
session receives it automatically.
- Pull: make a skill or reference available so that the agent can load it when the task
requires it.
Push is appropriate when omission would invalidate the activity. Pull is appropriate when the information is optional, specialized, or costly to include in every session.
Coding standards illustrate the difference. During implementation, standards can be available as pull-based skills. The implementer can retrieve the guidance when it needs to answer a question about style or architecture without filling every context with the full standard.
During automated review, the standards should be pushed. The reviewer must compare the submitted code against them, so the rules are part of the review task rather than optional background.
This approach also supports ownership of the planning stack. Small skills can be inspected, tuned, and replaced. If an interviewing skill asks too many questions, change it. If the
PRD-to-issues skill produces horizontal tasks, strengthen the vertical-slice rule.
Observability and control are more valuable than dependence on a large opaque framework that the team cannot debug.
Documentation requires similar control. A completed product requirements document may be accurate on the day it is written but become misleading after implementation, refactoring, user feedback, and renamed modules. An agent that discovers the old document may treat it as current truth even when the code has moved on. This is documentation rot.
One response is to remove completed planning documents from the active repository or mark their issues closed. A closed issue remains retrievable but visibly signals that it is historical. Negative decisions and out-of-scope items should be preserved during active work because they define completion, but they should not remain indefinitely as unqualified current instructions.