Your Coding Agent Should Never Start From a Jira Ticket

"Ready for Development" Is Not Ready for Coding

You move a Jira issue to Ready for Development. An agent detects the transition, reads the ticket, changes six files, and opens a pull request before the next morning.

That sounds efficient—until you discover that the agent implemented a reasonable interpretation of the wrong requirement.

Most Jira issues contain the business request, not the technical contract. They may include acceptance criteria, screenshots, comments, and dependencies, but still leave critical questions unanswered.

Consider a ticket that says:

Allow administrators to disable a user account.

Before implementation, someone must answer:

• Can an administrator disable themselves?
• What happens to active sessions?
• Is reactivation included?
• Must the action be audited?
• What happens when session revocation fails?
• Does "administrator" mean a global role or a project-level permission?

An agent can identify these questions. It should not silently answer them.

In AEC software, the gap can be larger. "Support linked models," "export project data," or "synchronize parameters" can hide coordinate systems, model ownership, Revit-version compatibility, and customer-specific conventions.

The correct automation trigger is therefore not:

Start coding JIRA-142.

It is:

Start the structured design process for JIRA-142.

The Workflow: Automate Around an Approved Contract

The safe agentic workflow adds two artifacts between the ticket and the code:

1. A reviewed design specification
2. A validated implementation plan

The Jira issue remains the source of the business request. The approved specification becomes the source of implementation truth.

A practical Jira workflow might be:

READY FOR DISCOVERY
    → IN DESIGN
    → SPEC REVIEW
    → SPEC APPROVED
    → PLAN REVIEW
    → READY FOR IMPLEMENTATION
    → AGENTIC DEVELOPMENT
    → HUMAN REVIEW
    → READY TO MERGE

Explicit states matter. A comment saying "looks good" is difficult for an automation controller to interpret reliably.

First, Build a Read-Only Context Package

Do not make the brainstorming agent rediscover the repository from scratch during every conversation.

A read-only intake agent can collect:

Jira issue and linked issues
Relevant ADRs and documentation
Existing APIs and database schemas
Similar implementations
Recent related commits
Current tests
Deployment configuration
Security and monitoring requirements

Store the result beside the work:

docs/agent-work/JIRA-142/context.md

The context package should document facts and unresolved questions. It should not make product or architecture decisions.

## Existing implementation
 
- User state is stored by the User API.
- Authentication caches user status for five minutes.
- An audit-event pipeline already exists.
 
## Unresolved questions
 
- Must session revocation be immediate?
- Can the last active administrator disable themselves?
- Is reactivation part of this issue?

This separation is important: collection can run unattended; decisions cannot.

Turn the Context Into a Specification

A useful specification does more than restate the ticket. It defines externally observable behaviour and the boundaries of the change.

At minimum, capture:

• Problem, goals, and non-goals
• Functional and non-functional requirements
• UI behaviour or ASCII wireframes
• API and data changes
• Failure handling
• Security and authorization
• Observability
• Testing strategy
• Rollout and rollback
• Acceptance-criteria traceability
• Rejected alternatives
• Open questions

Diagrams should remove ambiguity, not decorate the document.

The useful question is not whether this is technically possible. It is what should happen when Session Service fails after the account status has changed.

That decision belongs in the specification.

The Hard Part: Preventing Context From Becoming Authority

Giving an agent more context does not make every decision safe to automate.

The agent may find an existing retry mechanism and conclude that asynchronous session revocation is appropriate. Technically, that may be consistent with the repository. Product owners may still require immediate revocation because a disabled employee must lose access at once.

Repository patterns describe what the system currently does. They do not automatically define what the business wants next.

Use separate agents for separate responsibilities:

The specification reviewer should start with a fresh context. Otherwise, it inherits the same assumptions as the writer.

Require traceability:

| Requirement         | Plan task | Verification                  |
| ------------------- | --------- | ----------------------------- |
| Admin authorization | Task 4    | End-to-end authorization test |
| Status transition   | Task 1    | Domain unit test              |
| Session revocation  | Task 3    | Integration test              |
| Audit event         | Task 5    | Event contract test           |

A requirement missing from the plan is likely to be missing from the implementation.

Let Agents Implement Tasks, Not Interpret the Project

Once the specification and plan are approved, autonomy becomes useful.

For each task:

Create isolated worktree
    → dispatch fresh implementation agent
    → write failing test
    → confirm expected failure
    → implement minimum change
    → run targeted and broader tests
    → self-review
    → commit
    → independent spec and quality review

Each task runs in its own worktreeDefinitionA separate working copy of the same repository, checked out to its own branch in its own directory. Multiple agents can work in parallel without overwriting each other's files., so parallel agents never collide.

Keep specification compliance separate from code quality. Elegant code that implements the wrong behaviour must fail review. Correct behaviour with unsafe or unmaintainable code must also fail.

Permissions should enforce the boundaries:

Allowed:
- Modify the assigned worktree
- Run approved tests and builds
- Commit to a feature branch
- Open a draft pull request
 
Not allowed:
- Push to main
- Merge its own pull request
- Access production credentials
- Change protected CI settings
- Deploy to production

The Stack We Run Today

The diagram above is tool-agnostic on purpose—the gates matter more than the brand names. But the intro promised the actual stack, so here is what runs each box this month. Every piece is replaceable; the shape is what we keep.

The whole thing is orchestrated from Claude Code, which gives us three primitives that map directly onto the workflow: subagents (each runs in its own context window with its own tools and permissions), git worktrees (an isolated branch + directory per task so parallel agents never collide), and skills (reusable, auto-triggering procedures). Most of those skills come from the Superpowers plugin, plus a layer of project-specific skills and agents we maintain per repository.

Here is how the abstract roles bind to real tools:

Two things make this work in practice. First, the Rovo MCP server keeps Jira as the intake surface without letting the agent treat the ticket as the spec—it can read and transition issues, but the source of implementation truth is still the committed specification. Second, Superpowers' skills auto-trigger on intent: describing a feature activates brainstorming and planning, starting implementation activates TDD, finishing a task activates review. That chaining is what enforces the gates without a human re-typing the process every time.

This stack will look different next month. The point is not the specific tools—it is that each one sits behind a gate, and no single agent owns more than one box.

Limits

This workflow costs more before the first line of production code is written. For a one-line configuration correction, the complete process may be excessive.

Apply gates according to risk.

Authentication, billing, infrastructure, migrations, public APIs, and destructive operations justify specification and plan approval. Low-risk internal changes may use a smaller specification and automated plan approval.

The goal is not maximum process. It is preventing agents from turning unresolved ambiguity into committed code.