09 / 10 · Worked example

TEAM-12084 — SES email validation

A real, shipped ticket from the marketing-app repo. Walked through here so the workflow becomes concrete instead of abstract.

The ticket

On contact creation, validate the email via AWS SES's validate-email endpoint. If validation fails, the contact moves to bounced_suppressed state. Linked to TEAM-12085 (suppression flow on contact create).

The session

Workspace: a marketing-app workspace.
Branch: feature/TEAM-12084_validate_emails_with_ses.
Total user input: roughly 14 messages, 200 words typed.
Wall-clock: ~90 minutes.
Outcome: PR opened, reviewer assigned, both tickets transitioned, two tickets resolved by one diff.

The prompt sequence

> /chowly:implement_jira TEAM-12084
[agent: pulls ticket, plans]

> show original ticket
[agent: prints the verbatim Jira description]

> on creating a contact, it should call the SES endpoint to validate
  an email and if it fails the check it gets moved to a bounced
  suppressed state: see (https://docs.aws.amazon.com/ses/latest/dg/
  email-validation-api.html)
[agent: incorporates user's elaboration into plan]

> ensure these changes cover the needs of 12085 as well
[agent: re-plans, including 12085's suppression flow]

> this uses the api to validate on contact creation and then
  transitions them to suppressed if they fail?
[agent: confirms exactly that]

> ok
[agent: implements: ContactValidator service, callback wiring, specs]

> sure send a PR
[agent: opens PR, sets reviewer, transitions ticket]

> check CI and fix the failing spec
[agent: pulls CI logs; identifies a pre-existing default-value spec]

> look at CI were still failing
> [paste of failure stack trace]
> fix it
[agent: applies fix, pushes; CI green]

What worked

1. The "show original ticket" recovery

When the agent's plan summary drifted, the user asked for the verbatim ticket. Two-word recovery; re-anchored the conversation.

2. Adding constraints in turn 3

The user added a specific architectural detail (SES validate-email endpoint) with a docs link. The agent used the link to confirm the API shape rather than guessing.

3. Coupling the linked ticket explicitly

"ensure these changes cover the needs of 12085 as well" — single sentence that collapsed two tickets into one PR. The agent re-planned and integrated.

4. The "this is what I think you'll do" verification

Before approving, the user paraphrased the plan and asked Claude to confirm. A useful pattern when you want alignment before approval.

5. The CI fail was triaged correctly

The failure was pre-existing, not caused by the new code, but exposed by the new migration. The agent identified that and fixed it properly rather than skipping the spec.

What this case demonstrates

Two tickets in one PR is fine when they're truly linked. This is the canonical case for batching.
The "show original ticket" recovery is fast and useful.
Architectural detail in chat works, as long as you front-load it. Better in the ticket, but chat is acceptable.
CI failure recovery is a phase, not an emergency. The same agent who implemented the change can fix the CI failure.

What you'd do better next time. The "on creating a contact, it should call SES…" constraint could have been in the ticket description, saving turn 3. That's a ticket-quality point, not a workflow one — but it compounds over the year.