Turn an existing codebase into an agent-ready backlog.

Before you generate tickets

Define what “agent-ready” means

A list of feature names is not yet a workable backlog. A coding agent needs enough context to understand the intended outcome, where the change belongs, what must happen first, and how a reviewer will know the work is complete.

An agent-ready ticket should make these points reviewable:

• The user or product outcome the ticket supports.
• The work boundary and important implementation context.
• Dependencies on other tickets or existing behavior.
• Testable acceptance criteria.
• An effort estimate and a clear parent epic.

Starting from a new idea instead? Follow the product-idea-to-MVP workflow.

Step 1

Start with one confirmed product goal

Avoid asking an agent to “find everything wrong” and turn the result into a roadmap. That mixes technical observations with product priorities and often produces a backlog no one has actually approved.

Instead, describe the current product stage, the next desired outcome, and any explicit exclusions.

This MVP is already live.
The next confirmed goal is team workspaces.
Billing changes are out of scope for this release.
Inspect the repository before proposing the backlog.

A non-technical product owner can write this in plain language. The important part is the decision, not the project-management vocabulary.

Step 2

Let the coding agent inspect the current implementation

In an existing repository, Codex or Claude Code reads and reasons about the codebase. Ticketly provides the planning workflow, then its local deterministic engine validates and renders the resulting planning data.

Ask the agent to summarize evidence before proposing tickets:

• Current product areas and important entry points.
• Existing data models, services, and user-facing flows.
• Relevant tests, TODOs, and incomplete paths.
• Constraints that affect the confirmed goal.
• Questions that cannot be answered from the repository.

use Ticketly on this existing product
inspect the repository for the confirmed workspace goal
show me your findings and questions before generating tickets

/ticketly
Review this existing product for the confirmed workspace goal.
Pause for my approval before generating the backlog.

This checkpoint prevents repository guesses from quietly becoming requirements.

Step 3

Turn findings into confirmed scope

Review the agent's repository profile with the people who own the product decision. Correct missing context and separate three different kinds of information:

1. Current facts: behavior that already exists and can be verified in the repository.
2. Required change: work needed for the confirmed goal.
3. Deferred ideas: useful work that does not belong in this release.

Ticketly supports a lean MVP or a full backlog. For an existing product, use the same choice to decide whether you are planning the smallest usable version of the upgrade or the complete confirmed phase.

Step 4

Structure the backlog around dependencies

Group related work into epics, then split each area into child tickets that can be reviewed independently. Dependencies should reflect real ordering constraints rather than the order in which ideas happened to appear in the conversation.

WORK-001  Confirm workspace membership rules
    ↓
WORK-002  Add workspace and membership data model
    ↓
WORK-003  Enforce workspace access boundaries
    ↓
WORK-004  Add workspace management UI

Acceptance criteria should describe observable behavior. For example, “A member cannot access a workspace they do not belong to” is testable; “Handle permissions correctly” is too vague.

Step 5

Validate the plan before implementation

Ticketly checks the backlog structure for issues such as missing dependencies, circular dependencies, invalid parent relationships, and missing or potentially vague acceptance criteria.

Validation does not prove that the roadmap decision is correct. It gives the team a cleaner planning artifact to review. Read the backlog from beginning to end and ask:

• Does every ticket support the confirmed goal?
• Are deferred ideas clearly outside this release?
• Can independent tickets actually be worked independently?
• Do acceptance criteria describe observable outcomes?
• Can a reviewer understand why each dependency exists?

For a first-party example with saved output and explicit limitations, read the controlled post-MVP Ticketly-on-Codex run.

Step 6

Choose the right handoff artifact

Ticketly exports a readable Markdown backlog, a general CSV, an agent-ready Markdown checklist, and a Notion-import CSV.

• Use backlog.md for product and engineering review.
• Use tasks.md as the ordered checklist for a coding agent.
• Use backlog.csv when adapting the plan to another tracker or custom workflow.
• Use backlog.notion.csv for manual Notion import.

The Assignee field stays blank unless an owner is supplied. The destination tracker and team process handle assignment, permissions, notifications, and ongoing collaboration. Ticketly v1.2.1 does not provide a native GitHub Projects importer or ongoing tracker synchronization.

Final review

Use this checklist before anyone starts coding

• The next product goal has a named human owner.
• The repository findings were reviewed and corrected.
• Unknowns are questions, not invented requirements.
• The MVP or full-scope choice is explicit.
• Every ticket supports the confirmed release goal.
• Dependencies and acceptance criteria are reviewable.
• Deferred work is recorded outside the active scope.
• The team has chosen a handoff format and assignment process.