Prescribe structured ticket body layout with Acceptance Criteria

.agents/skills/start/SKILL.md

@@ -93,7 +93,7 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor):
 ```bash
 gh issue create \
   --title "<standalone full sentence — must make sense with no context>" \
-  --body "<human-readable explanation: what the problem is, why it matters, general approach — written for a non-developer, no code or file paths>" \
+  --body "<structured markdown body — see sections below>" \
   --assignee @me \
   [--label "<resolved labels>"] \
   [--milestone "<resolved milestone>"]
@@ -103,6 +103,25 @@ Resolve labels and milestone using the resolution steps in the Parsing section a
 - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
 - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
 
+**Body structure (required sections, in this order):**
+
+```markdown
+## Problem to Fix
+<what is broken or missing, written for a non-developer — no code or file paths>
+
+## Why it Matters
+<the impact or motivation — who is affected and how>
+
+## General Approach
+<high-level direction for the fix, in plain language>
+
+## Acceptance Criteria
+- <specific, verifiable outcome>
+- <another outcome>
+```
+
+All four sections are required. Write for a non-developer audience — no code, no file paths. Acceptance Criteria must be concrete and verifiable (not vague goals).
+
 **Title rules:**
 - ✅ `Fix 'Contact Us' footer link pointing to 404 instead of /contact-us`
 - ❌ `Fix broken link`
@@ -225,4 +244,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit <number> --remove-assignee @me`.
 - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`.
 - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation.
-<!-- generated by CodeCannon/sync.sh | skill: start | adapter: codex | hash: 3dd95db6 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: codex | hash: c10aad5a | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

.claude/commands/start.md

@@ -88,7 +88,7 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor):
 ```bash
 gh issue create \
   --title "<standalone full sentence — must make sense with no context>" \
-  --body "<human-readable explanation: what the problem is, why it matters, general approach — written for a non-developer, no code or file paths>" \
+  --body "<structured markdown body — see sections below>" \
   --assignee @me \
   [--label "<resolved labels>"] \
   [--milestone "<resolved milestone>"]
@@ -98,6 +98,25 @@ Resolve labels and milestone using the resolution steps in the Parsing section a
 - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
 - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
 
+**Body structure (required sections, in this order):**
+
+```markdown
+## Problem to Fix
+<what is broken or missing, written for a non-developer — no code or file paths>
+
+## Why it Matters
+<the impact or motivation — who is affected and how>
+
+## General Approach
+<high-level direction for the fix, in plain language>
+
+## Acceptance Criteria
+- <specific, verifiable outcome>
+- <another outcome>
+```
+
+All four sections are required. Write for a non-developer audience — no code, no file paths. Acceptance Criteria must be concrete and verifiable (not vague goals).
+
 **Title rules:**
 - ✅ `Fix 'Contact Us' footer link pointing to 404 instead of /contact-us`
 - ❌ `Fix broken link`
@@ -220,4 +239,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit <number> --remove-assignee @me`.
 - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`.
 - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation.
-<!-- generated by CodeCannon/sync.sh | skill: start | adapter: claude | hash: 2448695d | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: claude | hash: c3649e3f | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

.cursor/rules/start.mdc

@@ -94,7 +94,7 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor):
 ```bash
 gh issue create \
   --title "<standalone full sentence — must make sense with no context>" \
-  --body "<human-readable explanation: what the problem is, why it matters, general approach — written for a non-developer, no code or file paths>" \
+  --body "<structured markdown body — see sections below>" \
   --assignee @me \
   [--label "<resolved labels>"] \
   [--milestone "<resolved milestone>"]
@@ -104,6 +104,25 @@ Resolve labels and milestone using the resolution steps in the Parsing section a
 - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
 - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
 
+**Body structure (required sections, in this order):**
+
+```markdown
+## Problem to Fix
+<what is broken or missing, written for a non-developer — no code or file paths>
+
+## Why it Matters
+<the impact or motivation — who is affected and how>
+
+## General Approach
+<high-level direction for the fix, in plain language>
+
+## Acceptance Criteria
+- <specific, verifiable outcome>
+- <another outcome>
+```
+
+All four sections are required. Write for a non-developer audience — no code, no file paths. Acceptance Criteria must be concrete and verifiable (not vague goals).
+
 **Title rules:**
 - ✅ `Fix 'Contact Us' footer link pointing to 404 instead of /contact-us`
 - ❌ `Fix broken link`
@@ -226,4 +245,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit <number> --remove-assignee @me`.
 - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`.
 - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation.
-<!-- generated by CodeCannon/sync.sh | skill: start | adapter: cursor | hash: f450dbf9 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: cursor | hash: 7481a231 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

.gemini/skills/start/SKILL.md

@@ -93,7 +93,7 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor):
 ```bash
 gh issue create \
   --title "<standalone full sentence — must make sense with no context>" \
-  --body "<human-readable explanation: what the problem is, why it matters, general approach — written for a non-developer, no code or file paths>" \
+  --body "<structured markdown body — see sections below>" \
   --assignee @me \
   [--label "<resolved labels>"] \
   [--milestone "<resolved milestone>"]
@@ -103,6 +103,25 @@ Resolve labels and milestone using the resolution steps in the Parsing section a
 - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
 - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
 
+**Body structure (required sections, in this order):**
+
+```markdown
+## Problem to Fix
+<what is broken or missing, written for a non-developer — no code or file paths>
+
+## Why it Matters
+<the impact or motivation — who is affected and how>
+
+## General Approach
+<high-level direction for the fix, in plain language>
+
+## Acceptance Criteria
+- <specific, verifiable outcome>
+- <another outcome>
+```
+
+All four sections are required. Write for a non-developer audience — no code, no file paths. Acceptance Criteria must be concrete and verifiable (not vague goals).
+
 **Title rules:**
 - ✅ `Fix 'Contact Us' footer link pointing to 404 instead of /contact-us`
 - ❌ `Fix broken link`
@@ -225,4 +244,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit <number> --remove-assignee @me`.
 - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`.
 - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation.
-<!-- generated by CodeCannon/sync.sh | skill: start | adapter: gemini | hash: f28782f5 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: gemini | hash: d632050d | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

skills/start.md

@@ -136,7 +136,7 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor):
 ```bash
 gh issue create \
   --title "<standalone full sentence — must make sense with no context>" \
-  --body "<human-readable explanation: what the problem is, why it matters, general approach — written for a non-developer, no code or file paths>" \
+  --body "<structured markdown body — see sections below>" \
   --assignee @me \
   [--label "<resolved labels>"] \
   [--milestone "<resolved milestone>"]
@@ -146,6 +146,25 @@ Resolve labels and milestone using the resolution steps in the Parsing section a
 - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
 - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
 
+**Body structure (required sections, in this order):**
+
+```markdown
+## Problem to Fix
+<what is broken or missing, written for a non-developer — no code or file paths>
+
+## Why it Matters
+<the impact or motivation — who is affected and how>
+
+## General Approach
+<high-level direction for the fix, in plain language>
+
+## Acceptance Criteria
+- <specific, verifiable outcome>
+- <another outcome>
+```
+
+All four sections are required. Write for a non-developer audience — no code, no file paths. Acceptance Criteria must be concrete and verifiable (not vague goals).
+
 **Title rules:**
 - ✅ `Fix 'Contact Us' footer link pointing to 404 instead of /contact-us`
 - ❌ `Fix broken link`