The problem

Jira issues often move forward with incomplete scope, unclear expectations, missing evidence or unresolved decisions.

Experienced team members can usually recognise these gaps. The challenge is turning that judgement into a repeatable process that works across teams, roles and issue types.

Poorly prepared issues create predictable costs:

• developers reconstruct intent after work begins;
• product managers repeat context across meetings and messages;
• QA lacks enough evidence to investigate reliably;
• estimates are based on partial information;
• dependencies appear late;
• decisions become scattered across chats and calls;
• agents repeatedly process the same background information.

General-purpose AI does not solve this automatically. Its output can still vary by prompt, platform and available context. It may overlook important gaps, invent plausible details or produce more information than the team can practically use.

The design challenge was to turn cross-functional delivery judgement into a system an agent could apply consistently, while keeping decisions and accountability with people.

‍

Product objective

The kits help teams answer one practical question before work progresses:

Does this issue contain enough reliable information for the next person or agent to act?

The reviewer identifies:

• what is clearly provided;
• what is incomplete or unclear;
• what has been inferred;
• which decisions remain open;
• which gaps could block or delay the next stage.

The agent does not decide product direction, invent requirements, choose the technical solution or edit the Jira issue on the team’s behalf.

‍

The framework

Each kit uses a domain-specific readiness model.

The agent is not asked whether an issue is generally “good.” It checks whether the issue answers the minimum questions required for the next delivery stage.

‍

Task Handoff Readiness Reviewer

The task framework assesses:

• objective and user value;
• scope and boundaries;
• expected behaviour;
• acceptance conditions;
• dependencies and constraints;
• design or technical references;
• unresolved decisions;
• overall implementation readiness.

The final test is practical:

Can a developer begin without reconstructing the task’s intent or repeatedly requesting essential information?

‍

Bug / Defect Readiness Reviewer

The defect framework assesses:

• observed behaviour;
• expected behaviour;
• reproduction steps;
• environment and conditions;
• supporting evidence;
• frequency and impact;
• affected users or systems;
• regression information;
• overall investigation readiness.

The final test is:

Can a developer or QA specialist investigate the issue reliably using the information provided?

‍

‍

Product principles

Human decisions stay human

The agent assesses information quality. Product direction, scope and implementation choices remain with the team.

‍

Evidence is visible

The reviewer separates confirmed information, supported inference and missing information.

‍

The method is repeatable

Each review uses the same structure and terminology, making results easier to compare and act on.

‍

The issue works for both audiences

A Jira issue must be quick for a person to scan and structured enough for an agent to interpret reliably.

‍

Context has a cost

The agent should retrieve, process and repeat only what is needed for the current decision.

‍

Boundaries are part of the experience

The product makes the agent’s authority, assumptions and limitations visible.

‍

Designing the interaction flows

I designed the flows around how product managers, developers and QA specialists already work.

The kits fit around Jira, backlog refinement, investigation and implementation. They do not introduce a separate process that teams must maintain.

The flow begins with the work item and returns the outcome to the work item.

‍

Core review flow

1. The user provides an issue through a connector, issue link or pasted content.
2. The agent checks whether enough information is available.
3. It selects the relevant task or defect framework.
4. It evaluates each readiness area.
5. It separates clear, incomplete, inferred and missing information.
6. It returns an overall readiness assessment.
7. It highlights the gaps most likely to affect the next stage.
8. It recommends specific actions.
9. The human updates the issue or resolves the open decisions.
10. The issue can be reviewed again when needed.

The agent acts as a checkpoint. It does not become another owner of the work.

‍

‍

Why the flows work this way

They begin with existing context

The agent starts from the issue and its linked material instead of putting the user through a long interview.

It asks for clarification only when the missing information prevents a useful assessment.

‍

The agent remains a reviewer

It identifies gaps and explains why they matter.

It does not silently rewrite the requirement, decide expected behaviour or introduce unapproved technical decisions.

‍

The output supports the next action

The report does not repeat the entire issue. It surfaces:

• readiness status;
• important gaps;
• unresolved questions;
• delivery risks;
• recommended next steps.
  ‍

Knowledge returns to Jira

Questions and decisions are added back to the shared work item.

This prevents important context from remaining inside a temporary agent conversation or being repeated in another sync.

‍

Larger scopes use a staged flow

An epic with dozens of issues cannot be handled like one task.

The agent first inspects a lightweight issue list, then offers batching, filtering or issue selection before loading full content.

This protects context quality, token use and report readability.

‍

Product manager flow

The product manager typically uses the task reviewer earlier in the lifecycle.

1. Create or select the issue.
2. Request a readiness review.
3. Review the gaps identified by the agent.
4. Add missing context, evidence or decisions.
5. Re-run the review when necessary.
6. Move the issue forward once it is ready.

This reduces the likelihood of discovering basic gaps during implementation.

‍

Developer and QA flow

Developers and QA specialists use the framework closer to implementation or investigation.

1. Pick up a task or defect.
2. Check the existing readiness result or request a new review.
3. Confirm whether the required technical context is present.
4. Return unresolved questions to the Jira issue.
5. Begin work from a clearer and more stable starting point.

The same framework supports different roles without forcing them into identical workflows.

‍

‍

Output design

The report is designed to help the team act.

A standard review includes:

• overall readiness;
• a short issue summary;
• readiness by assessment area;
• confirmed information;
• incomplete or unclear information;
• unresolved decisions;
• key risks;
• recommended next steps;
• a reminder that readiness is not an effort estimate or guarantee of implementation quality.

The output uses standard chat formatting rather than a separate dashboard, so the user can run the kit inside an existing agent interface.

‍

Key challenges and iterations

1. Review quality varied with the prompt

Early versions depended too heavily on the user explaining how the assessment should work.

Similar issues could receive different levels of detail and different recommendations.

What changed

I turned the prompt into a fixed operating model with:

• defined assessment areas;
• explicit sufficiency criteria;
• standard readiness states;
• consistent evidence classifications;
• a repeatable report structure.

The agent no longer invents the method during each conversation.

‍

2. Jira templates were designed only for humans

Broad fields such as “Description” and “Context” are understandable to experienced team members but provide weak signals for an agent.

What changed

I redesigned the templates as part of the agent interface.

Each field explains:

• what information belongs there;
• why it matters;
• what sufficient detail looks like;
• what should be marked as unknown;
• what the agent must not assume.

The person writing the issue and the agent reviewing it now use the same information model.

‍

‍

3. The agent could sound certain when information was missing

Language models can turn gaps into plausible answers.

In delivery work, plausible information can easily be mistaken for an approved requirement or confirmed fact.

What changed

I introduced explicit evidence handling.

The reviewer separates:

• directly provided information;
• supported inference;
• information requiring confirmation;
• missing information;
• information that is not applicable.

The kits prohibit invented requirements, evidence, reproduction details and implementation decisions.

‍

4. Detail created new costs

As the framework became more complete, the templates and reports became longer.

More detail helped the agent, but it also increased:

• human reading time;
• token consumption;
• repeated context processing;
• duplicated information;
• the number of follow-up syncs needed to establish what actually mattered.

A template that is highly effective for the agent but exhausting for the team defeats the purpose.

What changed

I separated the information the agent needs to operate from the information the human needs to read.

The final structure uses:

• concise Jira fields focused on facts, evidence and decisions;
• short field-level prompts;
• detailed rules stored inside the agent framework;
• reports that surface only relevant gaps;
• summaries that avoid repeating the source issue;
• staged retrieval for larger scopes.

I also removed duplicated guidance across the templates, instructions and outputs.

The result is a shared format that remains readable to people while giving agents enough structure to work reliably.

Every field must earn its place.

‍

5. Large epics exhausted context

Loading dozens of issues at once increased token use, reduced review quality and created reports that were difficult to use.

What changed

For groups with more than 20 child items, the agent first retrieves a lightweight list and offers a controlled choice:

• review the recommended first batch;
• review all issues in batches of up to 20;
• filter by status, type or priority;
• select specific issues.

Completed batches can then be combined into one summary.

‍

‍

‍

6. Platforms handled the instructions differently

AI platforms vary in how they handle tools, context, files and instruction hierarchy.

What changed

I separated the stable method from the platform implementation.

The kits now use:

• one shared framework;
• aligned terminology and outputs;
• platform-specific setup instructions;
• connector-specific fallbacks;
• consistent safeguards.

The methodology remains stable even when the execution changes.

‍

7. The agent needed firm boundaries

An agent connected to delivery systems can easily appear more authoritative than it is.

What changed

I embedded clear operating boundaries:

• reviewer-only behaviour;
• no automatic Jira editing;
• no hidden assumptions;
• no invented requirements or evidence;
• transparent handling of inaccessible information;
• human confirmation for consequential decisions;
• data-handling and permitted-use guidance.

The limitations are part of the product design.

‍

‍

Expected impact

The kits do not yet have enough production data to support numerical claims.

The expected outcomes are based on the workflow design and practical experience across product and engineering delivery.

‍

Better issue quality

Missing scope, acceptance conditions, dependencies and defect evidence should become visible before work reaches the next stage.

‍

Fewer clarification loops and syncs

Teams should spend less time repeating context, arranging follow-up meetings and resolving basic questions after implementation has started.

‍

Faster handoffs

Developers and QA specialists should receive a clearer starting point for estimation, implementation and investigation.

‍

More consistent readiness decisions

A shared framework gives teams a common definition of readiness.

‍

Earlier risk identification

Missing evidence, dependencies and unresolved decisions are surfaced while they are still relatively inexpensive to address.

‍

More efficient AI use

Structured templates, reduced duplication and controlled retrieval should reduce unnecessary prompts, repeated context loading and token waste.

‍

Better investment decisions

The reviewer creates a pause before execution, helping teams establish whether an issue is sufficiently understood before time, budget or agent capacity is committed.

‍

More effective developer agents

A developer agent receiving a reviewed task should spend less time reconstructing intent, requesting clarification or making unsupported assumptions.

‍

‍

‍

Validation approach

Future testing should compare reviewed and unreviewed issues using measures such as:

• clarification rounds before work begins;
• follow-up syncs required after handoff;
• time spent manually reviewing issues;
• repeated context shared across chats and meetings;
• common missing-information categories;
• consistency across repeated reviews;
• changes made after the readiness report;
• unsupported assumptions produced by the agent;
• token use for individual and batch reviews;
• issues returned after work begins;
• developer-agent performance on reviewed and unreviewed tasks.

This would allow future claims to be based on observed delivery outcomes.

‍

Current outcome

The project produced two aligned, commercially packaged skill packs:

1. Task Handoff Readiness Reviewer
2. Bug / Defect Readiness Reviewer

Each pack includes:

• the core readiness framework;
• platform-specific agent instructions;
• AI-readable Jira templates;
• interaction and batching flows;
• structured report formats;
• examples and documentation;
• fallback behaviour;
• operational and behavioural safeguards.

The system can be used independently without requiring live guidance for each review.

‍

‍

Future work

Atlassian Rovo integration

The framework could run through Atlassian Rovo, using Jira and Confluence context from the team’s existing environment.

This would reduce repeated copying of linked issues, documentation, dependencies and historical decisions.

‍

Agent-assisted issue creation

A product, support or research agent could turn notes, customer feedback or investigation findings into a structured Jira issue.

A separate readiness agent would then review it before it progressed.

Using different agents for creation and review reduces the risk of one agent approving its own assumptions.

‍

Quiet, logged agent collaboration

Most agent activity should remain in the background.

The system could record:

• what was reviewed;
• which agent created or assessed the issue;
• what changed between iterations;
• which assumptions were rejected;
• when the issue became ready;
• which human decisions remain open.

People would be alerted only when an issue is incomplete, contradictory or requires judgement.

‍

Readiness as an agent-to-agent contract

The readiness report could eventually act as a contract between the issue-writing agent and the developer agent.

The developer agent would receive:

• a clear objective;
• explicit scope;
• expected behaviour;
• acceptance conditions;
• dependencies and references;
• unresolved decisions;
• confirmation that the issue passed an independent review.

This should reduce context reconstruction, repeated prompts, clarification loops and unnecessary human syncs.

The longer-term opportunity is a delivery process where agents handle routine preparation, checking and coordination quietly, while people retain control over direction, trade-offs and accountability.

‍

‍

‍

‍

‍

‍

‍