A small collection of role-focused Pi subagents that makes Ticket-Driven Development a little more convenient.
TiDD means Ticket-Driven Development here: review the ticket, preserve its decisions, implement the scoped work, and review the pull request before merging.
This package is intentionally small. It does not define a TiDD standard, enforce a workflow, or automate an issue tracker. It only provides a few practical agent definitions for teams that already develop from tickets and pull requests.
- Pi
- pi-subagents
- Access to the model identifiers used by the selected agents
Install pi-subagents first:
pi install npm:pi-subagentsInstall from a local checkout:
pi install ~/git/pi-tidd-agentsAfter the repository is published, it can also be installed from Git:
pi install git:github.com/<owner>/pi-tidd-agents| Agent | Model | Purpose |
|---|---|---|
luna-worker |
gpt-5.6-luna |
General implementation work |
terra-worker |
gpt-5.6-terra |
Implementation work with an emphasis on low-level correctness |
glm-worker |
glm-5.2 |
Alternative implementation worker |
sol-reviewer |
gpt-5.6-sol |
Read-only requirements, contract, scope, and maintainability review |
terra-reviewer |
gpt-5.6-terra |
Read-only concurrency, lifetime, ownership, and portability review |
terra-oracle |
gpt-5.6-terra |
Read-only decision-drift and contradiction review |
Ask Pi to delegate in ordinary language:
Use sol-reviewer to review Issue #18 and append pre-implementation notes.
Use luna-worker to implement Issue #18 and create a pull request.
For a typical Issue-to-pull-request workflow, use the following sequence.
| Stage | Agent | Example prompt |
|---|---|---|
| Issue pre-implementation notes | sol-reviewer |
Use sol-reviewer to review Issue #18 and append pre-implementation notes. |
| Issue pre-implementation addendum | terra-oracle |
Use terra-oracle to review Issue #18 and append a pre-implementation addendum. |
| Implementation and pull request | luna-worker |
Use luna-worker to implement Issue #18 and create a pull request. |
| Standard pull request review | sol-reviewer |
Use sol-reviewer to review PR #42 and append the review. |
| Concurrency, lifetime, and ownership review when relevant | terra-reviewer |
Use terra-reviewer to review PR #42 for concurrency, lifetime, and ownership issues, then append the review. |
| Address approved pull request findings | luna-worker |
Use luna-worker to address the approved findings on PR #42 and push the fixes. |
The reviewer and oracle agents remain read-only. The parent Pi session is responsible for any requested issue or pull-request comment.
Workers can edit files and run tests, but they do not commit, push, create branches or pull requests, rewrite history, post to GitHub, or resolve review threads unless the delegated task explicitly authorizes the relevant action.
For example:
Use luna-worker to implement Issue #18.
This permits implementation and validation, but not a local commit.
Use luna-worker to implement Issue #18 and create a pull request.
This authorizes the parent workflow to delegate the required local commits, push, and pull-request creation. It does not authorize merging or history rewriting.
The included definitions use provider-unqualified model IDs. Pi resolves each ID through the active provider when that provider offers it. If a model is unavailable in your environment, copy or override the agent definition through pi-subagents configuration before running it.
User and project agent definitions have higher discovery precedence than package-provided definitions with the same runtime name.
- Workers use forked conversation context and inherit project instructions.
- Reviewers use fresh context and have read-only tool allowlists.
- The oracle uses forked context to reconstruct inherited decisions and detect drift.
- External side effects require explicit delegation.
- Agent runtime names stay short and unqualified.
MIT. See LICENSE and THIRD_PARTY_NOTICES.md.