Engineering leadership · Agentic development · Development workflow
No Linear. No Asana. How I designed ticketing for agentic development
As a lead, I designed a GitHub-native workflow that turns development tickets into clear contracts between teammates and coding agents—without adding another source of truth.
As a lead, I wanted a development workflow built for the way teams work now: people make the decisions, coding agents accelerate the execution, and the ticket keeps both sides aligned. I designed that workflow around GitHub itself—no separate planning system, no duplicated backlog, and no ambiguity about where the work lives.
The leadership decision
The issue is the shared contract between the team and the agent.
One source of truth
No Linear. No Asana.
Those are capable products. My decision was not about declaring them bad; it was about removing an unnecessary translation layer. If the repositories, pull requests, reviews, and releases already live in GitHub, the development backlog can live there too.
A separate tracker often means someone has to keep a product card, a GitHub issue, and a pull request synchronized. Agents make that duplication more expensive because stale context can now produce code at high speed.
In an agentic workflow, duplicated context is not administration. It is a source of implementation errors.
I removed the handoff between planning context and implementation context.
Copy and reconcile
The team repeats scope, status, links, and decisions across systems.
- Planning card
- Repository issue
- Pull request
- Manual status sync
Plan beside the code
The issue owns intent; the project organizes it; the pull request provides proof.
- One issue
- One project view
- Native relationships
- Automatic lifecycle
The unit of work
A ticket is a context contract, not a one-line prompt.
“Build the settings page” is not a useful contract for a teammate or an agent. A strong issue explains the result, the boundary, the proof, and the decisions that should not be rediscovered during implementation.
Every issue answers the questions an implementation agent will otherwise guess.
| Decision | What the ticket records | Why it matters |
|---|---|---|
| Outcome | An independently demonstrable result | Defines success in product language |
| Context + scope | Problem, users, domain terms, in scope, and out of scope | Prevents accidental expansion |
| Implementation plan | Decision-level steps without brittle code prescriptions | Provides direction while leaving room for engineering judgment |
| Acceptance + tests | Observable criteria and concrete test cases | Turns completion into evidence |
| Risk | Security, privacy, observability, rollout, and rollback | Makes operational impact visible before coding |
| Relationships | Parent, blockers, related work, and definition of done | Keeps sequencing explicit |
The workflow
The board represents readiness, not activity theater.
I kept the states intentionally small. Each one answers a real question about whether the work is understood, ordered, executable, under review, or proven complete.
Six states are enough to make ownership and readiness visible.
- InboxTriage
Is this real, safe to discuss, and owned by the right repository?
- InventoryBacklog
Is the work worth retaining even if it is not scheduled yet?
- CommitmentReady
Are scope, dependencies, acceptance criteria, and tests clear?
- ExecutionIn progress
Does one accountable owner have the work?
- EvidenceIn review
Is the implementation ready for human and automated review?
- OutcomeDone
Has the observable result been verified and documented?
Agent-assisted planning
The agent interviews before it implements.
I created a reusable product-management workflow that starts by asking focused questions, recording durable decisions, and exposing ambiguity. Only after the scope is approved does it break the outcome into independently deliverable issues.
The agent can inspect repository context, suggest the destination, draft the issue, identify dependencies, and propose a ticket stack. A person still approves the decisions and the act of publishing or modifying work.
Automation has a role at every stage—but never silent authority.
- DiscoverInterview the outcome
Ask one decision at a time and recommend a concrete answer.
- DocumentRetain the decisions
Update shared terminology and durable architecture records when needed.
- StructureSlice the work
Create vertical, verifiable issues with explicit ownership and dependencies.
- ApproveHuman publication gate
Show exactly what will be created or changed before acting.
- TrackConnect delivery evidence
Link branches, pull requests, reviews, checks, and closure back to the issue.
Repository ownership
Cross-system work should be coordinated, not collapsed.
One oversized issue is easy to create and hard to deliver. For work spanning several repositories, I use one coordination issue in the repository that owns the user-facing outcome, then create independently testable implementation issues where each change belongs.
Every repository receives work it can own and verify.
- Product surface
Owns the user-visible outcome and the coordination issue.
- Owner
- Outcome owner
- Allowed
- Experience + acceptance
- Application service
Owns business rules, persistence, and APIs required by the outcome.
- Owner
- Service team
- Allowed
- Contract + tests
- Data or AI system
Owns models, pipelines, evaluation, and bounded processing behavior.
- Owner
- Data or AI team
- Allowed
- Evaluation + failure modes
- Infrastructure
Owns deployment, identity, networking, configuration, and rollback.
- Owner
- Platform team
- Allowed
- Environment + operations
Shared operating context
I put the workflow in the repository so it can multiply across the team.
A process that lives only in my head does not scale. I encoded the ticket format, questioning method, repository routing, engineering standards, security rules, and documentation policy as versioned agent instructions beside the code.
That canonical source can be synchronized into the coding tools the team uses. The adapters may differ, but the expectations do not. CI detects drift, and the generated copies point teammates back to the source instead of becoming competing manuals.
Team judgment becomes reusable context, then returns as verifiable work.
- AuthorityCanonical playbook
Ticketing, architecture, standards, security, and domain language.
- DistributionTool adapters
The same expectations reach each supported coding agent.
- PlanningStructured issue
The agent produces a consistent, reviewable context contract.
- DeliveryLinked implementation
Code, tests, review, and rollout evidence stay attached.
- LearningUpdated context
Durable corrections return to the playbook for the next task.
What leadership means here
As a lead, I designed the system—not just the next assignment.
My role is not to personally translate every conversation into tasks forever. It is to create a development operating system that helps the team make good decisions consistently, whether the next contributor is a senior engineer, a new teammate, or a coding agent.
No Linear. No Asana. Just one clear source of truth, strong tickets, explicit human gates, and a workflow that keeps learning from the work it ships.