Skip to main content

cto-review

Open a CTO-review ticket so the CTO can review a feature before R&D commits to building it. The ticket carries the whole Product→R&D handoff package in one place, so the review needs no extra digging.

Two entry paths:

  • Automatic β€” invoked at the tail of the product flow (by /handoff, once a PRD reaches ready-for-rd).
  • Manual β€” invoked via /cto-review on any task that did not come through the flow (a one-off the CTO should still see).

Steps​

1. Resolve the source​

  • From the flow: a PRD at docs/prds/<slug>-<cu-id>.md (default to the current feature/branch's PRD).
  • Manual / ad-hoc: a free-text task description, a ClickUp task ID, or a GitHub Issue. There may be no PRD β€” gather what exists and mark missing handoff fields explicitly (do not invent them).

2. Resolve the destination list​

The target is the dedicated "CTO Review" ClickUp list. Resolve it by name at runtime via clickup_get_workspace_hierarchy (or clickup_search). Do not hardcode a list ID. If the "CTO Review" list does not exist, stop and tell the developer to create it (or confirm the correct list name) β€” never fall back to dumping the ticket in an arbitrary list.

3. Build the title β€” the convention​

[Feature name] informative title
  • Feature name β€” the short product name, in brackets, so the list scans cleanly (e.g. [WhatsApp OTP]).
  • informative title β€” a one-line, plain statement of what it is, enough to understand the scope without opening (e.g. Add WhatsApp as an OTP delivery channel for the consumer app).
  • Full example: [WhatsApp OTP] Add WhatsApp as an OTP delivery channel for the consumer app.

This is the working convention β€” if a feature needs a different shape, edit the title after creation. Keep the [Feature name] prefix regardless, so the list stays groupable.

4. Assemble the handoff package (ticket body)​

Carry everything the CTO needs to review without leaving the ticket. Pull from the PRD where it exists; for a missing field, write _(not provided)_ β€” never a placeholder value.

## Problem & outcome
<PRD Β§1–2 β€” the WHAT and WHY, no HOW>

## Scope
<in / out of scope, from the PRD>

## UI composition
<PRD Β§7.2 β€” components named from COMPONENTS.md (or Storybook + src/components
until design-system PR #326 merges); tokens referenced, never raw hex; design
reference link (Figma Dev Mode frame or Claude Design branch β€” code, not pixels)>

## Acceptance criteria
<PRD Β§8 β€” testable criteria>

## Handoff status
- PRD: <path> β€” status `ready-for-rd` (gatekeeper Mode A: pass/date) or `_(ad-hoc, no PRD)_`
- Design reference: <Figma frame URL / Claude Design branch> or `_(not provided)_`
- ClickUp parent: <CU-id from PRD `clickup_parent`> or `_(none)_`

## Links
- PRD doc Β· design reference Β· parent task Β· related GitHub Issues

5. Create the ticket​

  • Create the task in the resolved "CTO Review" list (clickup_create_task) with the title (step 3) and body (step 4).
  • Add the tag cto review (clickup_add_tag_to_task).
  • Link it to the PRD's clickup_parent when present (clickup_add_task_link), so the CTO-review ticket and the work parent are connected, not orphaned.

6. Report​

Return the created ticket URL and a one-line summary. If invoked from /handoff, report it as the final handoff step. If the destination list was missing or the ClickUp MCP was unreachable, say so plainly and do not claim a ticket was opened.

Boundaries​

  • Never fabricates handoff content. A missing PRD field is reported as not provided, not filled with a guess. A weak handoff surfaces in the ticket rather than being papered over.
  • Never hardcodes the list ID β€” resolves "CTO Review" by name each run.
  • Does not approve or move the ticket β€” opening it is the whole job; the CTO drives the review from there.

Cross-references​