/submit-for-review does not reliably embed issue references in PR bodies

[sebastientaggart]

When /deploy builds the release PR, it parses Closes #N and Issue #N from the bodies of all PRs included in the release. In a v0.10.2 release with 18 merged PRs, only 3 had issue references in their bodies — leaving 13 qa-passed issues open after the release merged to main.

Root cause: /submit-for-review Step 3 ("Identify linked issue") relies on the agent inspecting the branch name or running gh pr view, but provides no deterministic mechanism to resolve the linked issue. When the agent can't confidently identify the issue, it proceeds without one and the PR body omits the Issue #N line entirely.

The branch-to-issue link does exist in GitHub (created by gh issue develop during /start), but the skill doesn't instruct the agent how to query it. There's no gh CLI shortcut for "which issue is this branch linked to?"

Expected behavior: Every PR created by /submit-for-review on a branch created by /start should include an Issue #N or Closes #N reference in the body, so that /deploy can collect them for the release PR's closing keywords.

Possible fixes:

1. Query the GitHub API for development branch linkages: gh api repos/{owner}/{repo}/branches/{branch} or search issues by linked branch name
2. Have /start write the issue number to a local file (e.g., .codecannon-issue) that /submit-for-review reads
3. Parse the gh issue develop branch metadata — GitHub stores the issue-branch association, it's just not easily surfaced via CLI

Option 2 is the most reliable and doesn't depend on GitHub API quirks.

[sebastientaggart]

Why option 2 (local file) is the most robust fix: GitHub's branch-to-issue linkage is stored server-side but isn't easily queryable — there's no gh issue list --linked-branch feature/foo command. API approaches require GraphQL queries against linkedBranches or iterating issues to find matches, which is fragile. A simple .codecannon-issue file written by /start and read by /submit-for-review is deterministic, works offline, and survives branch renames. It's the same pattern many CI tools use (e.g., .release-please-manifest.json).

[sebastientaggart]

Resuming work. Implementing Option C: embed issue number in branch name (feature/-), parse it in /submit-for-review to auto-include issue references in PR bodies.

[sebastientaggart]

Resolution

Feature branch names now include the issue number (e.g. feature/42-fix-login instead of feature/fix-login), so when a PR is created the issue reference is automatically extracted from the branch name and included in the PR body. This ensures /deploy can reliably collect all linked issues when building release PRs, preventing issues from being left open after a release.

See #141 for full technical details.