Skip to main content

Plan a technical ticket

Describe how the intended outcome will be implemented and proven. Prefer a few testable steps over a speculative inventory of every file that might change. This is the last stage of preparing the plan. Pathway 2 assumes this plan is ready and can be executed. Do not start pathway 2 until the ticket meets the Definition of Ready.

Approved AI tools and MCP-backed agents may draft the plan, scope, dangers, and decision candidates from the research record. They find most data, add, change, upstream, and downstream impacts. They do not make the decision. The planning owner accepts each sensitive choice before the Planning Phase owner splits the plan into phases. See Responsible AI use.

Prerequisites​

  • Researched understanding sufficient to choose an approach, or a named owner for any remaining blocking decision.
  • Acceptance criteria that a tester can later pass or fail.

Write the smallest useful plan​

For ordinary work, this is enough:

Plan:
  Scope:
  Out of scope:
  Approach:
    -
  Decisions:
    - Decision:
      Adds:
      Changes:
      Data:
      Upstream:
      Downstream:
      Chose:
      Rejected:
  Dangers:
    -
  Verify:
    -

Dangers are what can go wrong. Decisions are the sensitive choices the plan is making: add something, change something, or leave existing data and contracts in place. A danger without an accepted decision is not ready to execute.

Omit empty lines. A contained bug may record one decision in a few lines. Add Builder work, migration, rollout, monitoring, rollback, documentation, or support steps only when the change needs them. Order blocking dependencies before the work that consumes them.

Ask, at minimum:

  • What data is added, changed, migrated, or left as-is?
  • What callers must send that they did not send before?
  • What consumers will read a different shape, default, or empty value?
  • What existing records, APIs, Builder config, or permissions break if this ships?
  • Which of these did an agent surface, and which did a human accept?

If the agent found an impact and nobody accepted or rejected it, the plan is not ready. Use an RFC or design review only when the choice is consequential enough to need structured agreement beyond this ticket.

Prefer independently verifiable slices that leave the system in a valid state. A slice may cross frontend and backend boundaries when both are required to produce a meaningful result. The Planning Phase owner turns those slices into the phased approach at the start of pathway 2.

Example of a contained bug:

Plan:
  Scope: Require email when saving a contact.
  Out of scope: Changing other contact fields.
  Approach:
    - Reuse the existing contact validator to require email on save.
  Decisions:
    - Decision: Enforce email on new saves only.
      Adds: A required-email validation on save.
      Changes: none
      Data: Do not backfill existing contacts.
      Upstream: Save callers must send an email for new contacts.
      Downstream: Readers of existing contacts may still see an empty email.
      Chose: Keep existing empty emails readable.
      Rejected: Migrate existing contacts to a placeholder email.
  Dangers:
    - Existing contacts with empty email must still be readable.
  Verify:
    - Saving without email shows the error and does not persist the contact.
    - Saving with a valid email still succeeds.
    - Opening an existing contact with empty email still works.

Check readiness​

Pathway gate

Pathway 2 starts only when this plan is ready to execute. The first pathway 2 step is to split the plan into phases, not to open an implementation branch. If the plan is not ready, return it to detail or research instead of hiding uncertainty inside the plan.

Before pathway 2, confirm that:

  • the intended outcome and acceptance criteria are understood;
  • important technical questions have been answered;
  • blocking dependencies are available or explicitly ordered;
  • accepted decisions for data, additions, changes, and upstream or downstream impact are visible;
  • dangers and the verification method are visible; and
  • ownership and required review are clear.

Use the Definition of Ready for the complete quality gate. Match evidence strength to the delivery risk tier.

Expected result​

The implementation owner and reviewers can explain the approach, the accepted decisions, the dangers, and how they will know it worked. The plan is ready for the Planning Phase owner to split into phases.

If the plan is not ready​

Return to detail or research. Name the missing outcome, dependency, or decision. Do not open an execution branch to discover the plan.

Next: Split the plan into phases.