Skip to content
Agents Pack

Opinionated workflow

Every coding session starts from a blank context. Claude Code, Codex, and Cursor do not remember your last conversation — a new session knows only what it can read from the repository itself, plus whatever you type in that turn.

Agents Pack’s required core instructions already push against this: before planning, changing code, or brainstorming, every agent is told to check the repository root for PRD.md, TECHNICAL_REQUIREMENTS.md, and TODOs.md, and to read whichever exist. That check happens automatically in every session because it lives in the always-loaded ap-core-instructions component — you do not have to remind the agent.

We recommend keeping all three files at your repository root:

PRD.md

Section titled “PRD.md”

A short file describing the repository, its goals, users, and main components. It gives the agent the “why” — what the product is for and what matters — without you re-explaining it every session.

TECHNICAL_REQUIREMENTS.md

Section titled “TECHNICAL_REQUIREMENTS.md”

A short file describing the technologies, frameworks, and overall technical decisions used in the repository. It gives the agent the “how” — the stack, constraints, and conventions it should follow instead of guessing or introducing something inconsistent.

TODOs.md

Section titled “TODOs.md”

A file the coding agent uses to track the work it is about to do and mark items complete as it finishes them. Because it is read at the start of a session, a fresh session — or a teammate’s session — gets an accurate view of what has already shipped and what is still open, instead of re-deriving it from git history or asking you to recap.

Keep all three genuinely short. They are read on top of the core instructions in most sessions, so bloated files work against the same context budget they are meant to protect.

Skills that support this workflow

Section titled “Skills that support this workflow”

A few installed skills are built around exactly these files:

  • ap-start-dev-session (recommended) orients a new session from PRD.md, TECHNICAL_REQUIREMENTS.md, and TODOs.md before starting the requested work.
  • ap-create-prd (optional) interviews you and drafts or updates PRD.md — install it if you want help writing one instead of drafting it yourself.
  • ap-compress-todos (recommended) condenses TODOs.md once it gets noisy, without losing active work, decisions, or open risks.
  • ap-clear-dev-context and ap-continue-dev-session (recommended) hand a session off before you clear a long context and resume it afterward, relying on TODOs.md and the other project files to stay accurate in between.
  • ap-refresh-repo-docs (recommended) reconciles PRD.md, TECHNICAL_REQUIREMENTS.md, and other documentation with the implementation once the repository has moved past what they describe.

There is no dedicated skill for authoring TECHNICAL_REQUIREMENTS.md from scratch. Ask your coding agent to draft one directly from the current stack and decisions, then keep it current with ap-refresh-repo-docs.

Getting started

Section titled “Getting started”

If the files do not exist yet, ask your coding agent directly:

Create a PRD.md, TECHNICAL_REQUIREMENTS.md, and TODOs.md at the repository
root for this project. Base them on the current code, dependencies, and
architecture — do not invent goals or requirements that aren't evident.

Recommended and required skills are installed automatically during initialization, so ap-start-dev-session, ap-compress-todos, ap-clear-dev-context, and ap-continue-dev-session are ready to use right away. See Component selection if you also want ap-create-prd.

Section titled “Related”