prod-release-builder

Product Release Builder — ClickUp

You build a Production release in ClickUp for the Auro engineering ecosystem. End-to-end: gather inputs, discover and confirm candidates, create the release task, link them, generate the engineering Description and Deploy Notes, and post a customer-facing release notes draft as a comment for the CS team.

Supporting files (read at start of named phase):

• CLICKUP-REFERENCE.md (Phase 2) — list IDs, custom field IDs, status names, version logic, drift warning, comments-plain-text constraint.
• DESCRIPTION-PATTERNS.md (Phase 6) — engineering theme grouping, scaffold, deploy notes, vague-name flagging.
• CUSTOMER-NOTES-PATTERNS.md (Phase 7) — customer-facing classification, plain-text format, scaffold, maintenance fallback.

---

PHASE 1 — Gather inputs

Always ask Question 1 — even if you think you know from memory or context. The deploy date is critical and cannot be assumed.

Step 1 — Ask the user

Ask Q1 in chat (it's a date, not a button choice), then call ask_user_input_v0 with Q2 and Q3.

• Q1 (chat) — Target deploy date (required, format YYYY-MM-DD)
• Q2 (button) — Release type — single_select: Major / Minor / Patch / Hotfix. Default Patch.
• Q3 (button) — Project — single_select: Auro / Argonaut. Default Auro.

If the user provided a version override in their initial message (e.g. "cut v2.1.0 for May 12"), capture it and skip auto-increment in Phase 4.

---

PHASE 2 — Discover candidate tasks

Read CLICKUP-REFERENCE.md now.

Step 1 — Discover Sprint lists dynamically

Call clickup_get_workspace_hierarchy scoped to the Engineering Sprints folder ID (in reference). Extract every list ID inside. Do not hardcode Sprint 1–5; use what's discovered.

Step 2 — Query Done tasks per Sprint list

For each Sprint list, call clickup_filter_tasks with statuses: ["done"], subtasks: true, include_closed: false. Aggregate the unique tasks across all Sprint lists.

Step 3 — Filter by Release field

For each task, check the Release relationship custom field. Keep only tasks where Release is empty. Tasks already linked to any release are excluded.

Step 4 — Filter by home list (project boundary)

Filter candidate tasks to those where task.list.id matches the Phase 1 project's home list (see CLICKUP-REFERENCE.md → Project → home list mapping). Sprint lists display tasks but every task is homed in exactly one engineering list.

Project boundary rule: projects never cross-combine. Auro releases pull only Auro 2.0 tasks; Argonaut releases pull only Argonaut 2.0. Apply this filter even in single-project usage — it's the defence against an Argonaut task accidentally appearing in an Auro release later.

Step 5 — Empty-result handling (mandatory)

If no candidates found, tell the user explicitly: "No Done tasks without a Release found in any active sprint. Want to proceed with an empty release, or abort?" Wait for choice. Never proceed silently.

---

PHASE 3 — Confirm with the user

Show the candidate list as a table: task ID (linked), title, sprint name, assignee.

Ask: "I found N candidate tasks ready for this release. Proceed with all, exclude specific tasks, or abort?"

Hard gate — do not proceed without explicit confirmation. If the user says "exclude X, Y, Z", remove those task IDs from the candidate list and confirm the revised list. If they abort, report "Aborted — no changes made" and stop.

---

PHASE 4 — Auto-version and create release task

Step 1 — Determine version

If user provided a version override in Phase 1, use it. Otherwise auto-increment per CLICKUP-REFERENCE.md → Version increment logic.

If parsing the previous version fails, ask the user to specify the version explicitly. Do not guess.

Step 2 — Create the release task (two-step pattern)

Two-step is more reliable than a bundled single call (lessons learned from prod-feedback-to-clickup).

2a: clickup_create_task with only list_id (Releases), name ([Project] vX.Y.Z — YYYY-MM-DD), description ("Creating..."), status ("Planned").

2b: clickup_update_task on the new task ID with markdown_description (scaffolded; full rewrite in Phase 6) and custom_fields: AURO DEPARTMENT = ENGINEERING; Project (if field exists); Release Type; Target Deploy Date; Release Manager = current user (resolve via clickup_resolve_assignees with "me").

Step 3 — Verify

Call clickup_get_task (detail_level: summary) to confirm fields landed. If any are empty unexpectedly, retry the update once. If still failing, surface to user with what's missing.

---

PHASE 5 — Link tasks

For each confirmed candidate, call clickup_update_task with the Release relationship field set to { "add": ["<release_task_id>"] }.

Track failures. Retry once on failure — transient ClickUp API errors are common (we've seen them in this skill's predecessor work). If still failing after retry, surface the failed task IDs to the user and ask whether to continue with description generation or abort.

Never silently drop a link — the user must know what was/wasn't linked.

---

PHASE 6 — Generate description and deploy notes

Read DESCRIPTION-PATTERNS.md now.

Step 1 — Decide whether to fetch task details

Most task names are descriptive enough on their own. Only call clickup_get_task for a task if the name is vague (e.g. "Frontend bugs", "Misc") or theme classification is genuinely ambiguous. Avoids fetching every task — keeps tool calls proportional.

Step 2 — Group tasks by theme

Apply the theme grouping rules in DESCRIPTION-PATTERNS.md. Assign each task to one theme. Don't force tasks into themes that don't fit — if a task is genuinely a one-off, it goes in the "Bug Fixes" or "Other" bucket.

Step 3 — Write the description and deploy notes

Use the structure in DESCRIPTION-PATTERNS.md: Scope / Highlights (themed) / Sign-off Gates / Lifecycle / Rollback. Write Deploy Notes as a one-line summary.

Step 4 — Update the release task

Call clickup_update_task with the final markdown_description and Deploy Notes custom field.

Step 5 — Flag vague names

In the Phase 8 close-out response, list any task names you flagged as vague — the user may want to expand those manually.

---

PHASE 7 — Generate and post Customer Release Notes

Read CUSTOMER-NOTES-PATTERNS.md now.

Step 1 — Classify each linked task

Classify as customer-facing or internal per the rules in patterns file. Default: generous inclusion — include unless clearly internal. Better Alina trims one bullet than misses a feature. If genuinely ambiguous, include + flag [review] in Phase 8.

Step 2 — Empty-customer-impact case

If zero or one customer-facing tasks survive classification, skip Steps 3–4. Post the maintenance fallback comment from the patterns file instead. Silence is ambiguous; an explicit "nothing customer-facing this round" note is clearer.

Step 3 — Group by area

Use the area-of-platform headers from the patterns file (e.g. FASTER, MORE FLEXIBLE DATA TABLES). Headers describe user benefit, not engineering area. Lead with the section that has biggest user impact.

Step 4 — Write the customer notes (PLAIN TEXT)

ClickUp comments do not support markdown. Use plain-text formatting per the patterns file: ALL CAPS headers, hyphen bullets, blank-line spacing, em-dash separator. No **bold**, *italic*, or --- rules — they render literally.

Write in customer-benefit voice ("you can now..."). Avoid jargon (URQL, CASL, etc.) — translate to user-visible impact.

Step 5 — Post as a comment

Call clickup_create_task_comment with the release task ID, the plain-text customer notes as comment_text, notify_all: false, no assignee. Verify the returned comment_id. Retry once on failure; surface in Phase 8 if still failing.

---

PHASE 8 — Confirm and close out

Report:

1. Release task name and URL
2. Count of linked tasks
3. Engineering themes found (bullet list)
4. Customer-facing tasks count + customer notes status (posted as comment, or maintenance fallback used)
5. Any tasks flagged [review] for Alina (ambiguous classification)
6. Any flagged vague task names from engineering description
7. Any link failures from Phase 5 or comment-post failures from Phase 7

Offer one follow-up: "Want me to draft an intro message for Travis/Angus, ping Alina about the customer notes, or move the release status to In Progress?"

---

Quality checklist (verify before finishing)

• Q1 (target deploy date) explicitly asked and received
• Sprint lists discovered dynamically (no hardcoded IDs)
• User confirmation received before any task linking
• Release task created with title format [Project] vX.Y.Z — YYYY-MM-DD
• All confirmed candidate tasks have Release field updated (or failures surfaced)
• Engineering description includes Scope / Highlights / Sign-off Gates / Lifecycle / Rollback
• Deploy Notes one-line summary populated
• Customer Release Notes posted as a comment (plain-text, no markdown) — OR maintenance fallback comment posted if no customer-facing tasks
• Vague task names flagged for user review
• Tasks with ambiguous customer-facing classification flagged [review] for Alina
• Empty-candidate case handled with explicit user choice