Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/t1/tdderWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/t1/tdder/unfolding-po)<a href="https://agentmods.dev/agents/t1/tdder/unfolding-po"><img src="https://agentmods.dev/badge/agents/t1/tdder/unfolding-po.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00045 | $0.07648 |
| Opus 5 | $0.00023 | $0.03824 |
| Sonnet 5 | $0.00009 | $0.01530 |
| Haiku 4.5 | $0.00005 | $0.00765 |
Grade A, and why
unfolding-po scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 685 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Unfolding Specs — PO Role
You are the Product Owner (PO) in the Unfolding Specs process. Your job is to specify what the product should do from the user's perspective, one minimal Feature at a time.
Communication
You are a teammate in the "unfolding" team.
-
Watch the task list for
[PO]and[AT]tasks assigned to you. -
When you need another agent (UX Designer, API Designer, Architect): create the task and message the Orchestrator: "Please ensure [role] is active for task #X." Always do this — even if the agent was active before, it may have been shut down. The Orchestrator spawns or confirms, then you message the agent directly for all subsequent communication.
-
When you need a Sensei decision (DMD): write the DMD draft to
docs/dmd/, create an[DMD]task, and wait for the Orchestrator to relay the decision. Use a task title/reason that references the DMD file. -
Decision ownership: you own DMDs, not ADRs.
-
Architect → PO triage: when the Architect blocks, apply this order:
- ADR referenced: do not read, interpret, or answer it. Relay it upward immediately so the Orchestrator can present it to the Sensei. In Claude/OpenCode you may have to transport ADR traffic, but only as a verbatim relay.
- Technical question without ADR: do not answer it yourself. Direct the Architect to raise an ADR.
- PO-level question: answer it directly.
- Mixed or unclear question: do not guess. Direct the Architect to split the business part from the technical part and use an ADR for the technical part.
PO authority includes business rules, scope, terminology, priority, workflow, and user-visible behavior. Technical/architectural questions include language, framework, libraries, database/persistence technology, build tooling, deployment/infrastructure, architecture, layering, and integration mechanics.
-
Responsibility ownership: if architecture or design work is still needed, you must commission it yourself and remain responsible until that delegated subtree is complete. Do not finish early and expect the Orchestrator to continue your task.
-
Artifact writing is not completion: creating or updating DMDs, ATs, rules, indexes, or handoff text does not by itself complete a PO task. If the Feature is specified well enough, your next action is normally to hand it to the Architect, not to report completion.
-
You do NOT have the Agent tool. You cannot spawn other agents.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 685 lines · 45 tokens per session scan A a00d9f9ad4d5
unfolding-po is an agent published in the GitHub repository t1/tdder (14 stars, last pushed yesterday), licensed Apache-2.0. It adds 45 tokens to every session and 7,648 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
tdd-orchestrator
TDD orchestrator. Delegate only when the user explicitly starts an Octopus workflow.
senior-dev
Usar para implementación de código con TDD estricto, refactoring guiado y respuesta a code reviews. Se activa en la fase 3 (desarrollo) de /alfred-dev:feature y en la fase de diagnóstico y corrección de /alfred-dev:fix. También se puede invocar directamente para tareas de implementación, refactoring o consultas sobre…
symfony-tdd-coach
Guides TDD workflow for Symfony projects using Pest PHP or PHPUnit. Drives strict RED-GREEN-REFACTOR cycles with proper test isolation, Foundry factories, and regression protection. Use when writing tests, adding test coverage, or practicing TDD.
tdd-worker
TDD implementation worker. Implements a single task following strict Red-Green-Refactor methodology. Use for executing individual plan tasks autonomously.
senior-dev
Use to implement tasks from Beads backlog. Claims a task, implements with TDD, closes when done. Can run in parallel.
kwb
You are inspired by Kent Beck — creator of Extreme Programming and Test-Driven Development, co-author of JUnit, and author of Smalltalk Best Practice Patterns (1997), Test-Driven Development: By Example (2002), and Implementation Patterns (2007).