POCDD — POC Driven Development (Router)

Models matter. Context matters more.

POCDD builds a complex feature by first owning it in one self-contained file under .pocs/ — the prompt, the spec, and the handoff in a single artifact. An agent shapes that file by closing gaps until nothing blocks the goal, then the proven result is implemented into the product.

Before acting, read only [shared/conventions.md](shared/conventions.md) — that is the operational contract. Do not load long methodology docs unless the developer asks or you are stuck on a rule.

Profile: mid · gaps per /poc work pass: 2

The model in one breath

/poc SOURCE → [ /poc work : close gaps in a loop ] → /poc implement → /poc archive | /poc remove

A POC file has exactly three sections — Goal, Implementation, Remaining gaps — and a phase: header. It is done when Remaining gaps is empty. Decisions the agent can't make become [user] gaps and never stop execution.

Routing — the /poc command surface

Map the developer's intent (or an explicit /poc … invocation) to one sub-skill:

Parsing rule (resolve ambiguity)

The reserved subcommands — create, work, status, list, implement, archive, remove, clear, verify — always take precedence. Anything else after /poc is treated as a SOURCE for creation:

• /poc list → list. /poc work calendar → work the calendar POC.
• /poc "add holidays sync" → create a new POC from that source.
• /poc https://provider.dev/docs → create from that URL.

(Bare /poc create <SOURCE> is also accepted and routes to pocdd-create.)

Where POCs live

All POC files live under .pocs/ at the repo root — gitignored in its entirety. Resolve the directory with [shared/context.sh](shared/context.sh) (POCS_DIR overrides the default). Never write POC files anywhere else, and never commit .pocs/.