garrytan · yoseldvp · Mar 16, 2026 · Mar 16, 2026
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,5 +1,16 @@
 # Changelog
 
+## 0.4.4 — 2026-03-16
+
+### Added
+
+- **`/ship` now uses your repo's PR template.** If your repo has a `.github/PULL_REQUEST_TEMPLATE.md` (or any of the other standard locations), `/ship` reads it and uses it as the base structure for the PR body — filling in your sections, preserving your checkboxes and required fields, and appending ship-specific sections (eval results, Greptile review, etc.) only where the template doesn't already cover them. No template? Falls back to the existing default format.
+- **New `{{REPO_TEMPLATE_DETECT}}` placeholder for skill authors.** Drop it into any `.tmpl` file and get automatic detection of PR templates, issue templates, and bug report templates in the target repo. Checks all standard GitHub template locations. Any skill that creates PRs or issues can reuse this.
+
+### Changed
+
+- Removed hardcoded "Generated with Claude Code" signature from PR bodies — that's up to each repo's own PR template or CLAUDE.md to decide.
+
 ## 0.4.3 — 2026-03-16
 
 - **New `/document-release` skill.** Run it after `/ship` but before merging — it reads every doc file in your project, cross-references the diff, and updates README, ARCHITECTURE, CONTRIBUTING, CHANGELOG, and TODOS to match what you actually shipped. Risky changes get surfaced as questions; everything else is automatic.

diff --git a/VERSION b/VERSION
@@ -1 +1 @@
-0.4.3
+0.4.4
diff --git a/scripts/gen-skill-docs.ts b/scripts/gen-skill-docs.ts
@@ -479,13 +479,58 @@ Minimum 0 per category.
 10. **Use \`snapshot -C\` for tricky UIs.** Finds clickable divs that the accessibility tree misses.`;
 }
 
+function generateRepoTemplateDetect(): string {
+  return `## Repo Template Detection
+
+Before creating a PR, issue, or bug report via \`gh\`, check if the target repo provides GitHub templates:
+
+\`\`\`bash
+# PR templates (check all common locations)
+for f in .github/PULL_REQUEST_TEMPLATE.md .github/pull_request_template.md .github/PULL_REQUEST_TEMPLATE/default.md docs/pull_request_template.md PULL_REQUEST_TEMPLATE.md; do
+  [ -f "$f" ] && echo "PR_TEMPLATE: $f" && break
+done
+
+# Issue templates
+if [ -d ".github/ISSUE_TEMPLATE" ]; then
+  echo "ISSUE_TEMPLATES:"
+  ls .github/ISSUE_TEMPLATE/*.md .github/ISSUE_TEMPLATE/*.yml 2>/dev/null
+elif [ -f ".github/ISSUE_TEMPLATE.md" ]; then
+  echo "ISSUE_TEMPLATE: .github/ISSUE_TEMPLATE.md"
+fi
+\`\`\`
+
+**If a PR template is found:**
+
+1. Read the template file. It defines the repo's expected PR structure — section headings,
+   checklists, required fields, etc.
+2. Use the repo template as the **base structure** for the PR body. Fill in its sections
+   with the information you have (summary, test results, etc.).
+3. **Merge, don't replace.** If the skill needs sections the repo template doesn't have
+   (e.g., "Eval Results", "Greptile Review"), append them after the repo template's sections.
+   If the repo template has sections the skill doesn't populate (e.g., "Related Issues",
+   "Screenshots"), leave them with a sensible default or "N/A" — don't delete them.
+4. Preserve any checkboxes, required fields, or HTML comments from the repo template.
+   These often trigger CI checks or reviewer workflows.
+
+**If no PR template is found:** Use the skill's default PR body format (defined in the
+skill's own instructions).
+
+**For issues:** If the repo has issue templates (\`.github/ISSUE_TEMPLATE/\`), list the
+available templates and pick the best match for the issue type (bug report, feature
+request, etc.). Read the chosen template and fill in its fields. If no issue templates
+exist, use a sensible default format.
+
+---`;
+}
+
 const RESOLVERS: Record<string, () => string> = {
   COMMAND_REFERENCE: generateCommandReference,
   SNAPSHOT_FLAGS: generateSnapshotFlags,
   PREAMBLE: generatePreamble,
   BROWSE_SETUP: generateBrowseSetup,
   BASE_BRANCH_DETECT: generateBaseBranchDetect,
   QA_METHODOLOGY: generateQAMethodology,
+  REPO_TEMPLATE_DETECT: generateRepoTemplateDetect,
 };
 
 // ─── Template Processing ────────────────────────────────────

diff --git a/ship/SKILL.md b/ship/SKILL.md
@@ -444,9 +444,65 @@ git push -u origin <branch-name>
 
 ---
 
+## Step 7.5: Detect Repo PR Template
+
+## Repo Template Detection
+
+Before creating a PR, issue, or bug report via `gh`, check if the target repo provides GitHub templates:
+
+```bash
+# PR templates (check all common locations)
+for f in .github/PULL_REQUEST_TEMPLATE.md .github/pull_request_template.md .github/PULL_REQUEST_TEMPLATE/default.md docs/pull_request_template.md PULL_REQUEST_TEMPLATE.md; do
+  [ -f "$f" ] && echo "PR_TEMPLATE: $f" && break
+done
+
+# Issue templates
+if [ -d ".github/ISSUE_TEMPLATE" ]; then
+  echo "ISSUE_TEMPLATES:"
+  ls .github/ISSUE_TEMPLATE/*.md .github/ISSUE_TEMPLATE/*.yml 2>/dev/null
+elif [ -f ".github/ISSUE_TEMPLATE.md" ]; then
+  echo "ISSUE_TEMPLATE: .github/ISSUE_TEMPLATE.md"
+fi
+```
+
+**If a PR template is found:**
+
+1. Read the template file. It defines the repo's expected PR structure — section headings,
+   checklists, required fields, etc.
+2. Use the repo template as the **base structure** for the PR body. Fill in its sections
+   with the information you have (summary, test results, etc.).
+3. **Merge, don't replace.** If the skill needs sections the repo template doesn't have
+   (e.g., "Eval Results", "Greptile Review"), append them after the repo template's sections.
+   If the repo template has sections the skill doesn't populate (e.g., "Related Issues",
+   "Screenshots"), leave them with a sensible default or "N/A" — don't delete them.
+4. Preserve any checkboxes, required fields, or HTML comments from the repo template.
+   These often trigger CI checks or reviewer workflows.
+
+**If no PR template is found:** Use the skill's default PR body format (defined in the
+skill's own instructions).
+
+**For issues:** If the repo has issue templates (`.github/ISSUE_TEMPLATE/`), list the
+available templates and pick the best match for the issue type (bug report, feature
+request, etc.). Read the chosen template and fill in its fields. If no issue templates
+exist, use a sensible default format.
+
+---
+
 ## Step 8: Create PR
 
-Create a pull request using `gh`:
+Create a pull request using `gh`.
+
+**If a repo PR template was found in Step 7.5:** Read it and use its structure as the base
+for the PR body. Fill in its sections with the data gathered during the ship workflow. Then
+append any ship-specific sections that the repo template doesn't already cover:
+
+- **Pre-Landing Review** — findings from Step 3.5, or "No issues found."
+- **Eval Results** — if evals ran: suite names, pass/fail counts, cost dashboard. If skipped: "No prompt-related files changed — evals skipped."
+- **Greptile Review** — if comments found: bullet list with [FIXED] / [FALSE POSITIVE] / [ALREADY FIXED] tag. If no PR existed during Step 3.75: omit entirely.
+- **TODOS** — if items marked complete: bullet list with version. If TODOS.md doesn't exist and user skipped: omit.
+- **Test plan** — test pass/fail counts
+
+**If no repo PR template was found:** Use this default format:
 
 ```bash
 gh pr create --base <base> --title "<type>: <summary>" --body "$(cat <<'EOF'
@@ -473,8 +529,6 @@ gh pr create --base <base> --title "<type>: <summary>" --body "$(cat <<'EOF'
 ## Test plan
 - [x] All Rails tests pass (N runs, 0 failures)
 - [x] All Vitest tests pass (N tests)
-
-🤖 Generated with [Claude Code](https://claude.com/claude-code)
 EOF
 )"
 ```

diff --git a/ship/SKILL.md.tmpl b/ship/SKILL.md.tmpl
@@ -362,9 +362,25 @@ git push -u origin <branch-name>
 
 ---
 
+## Step 7.5: Detect Repo PR Template
+
+{{REPO_TEMPLATE_DETECT}}
+
 ## Step 8: Create PR
 
-Create a pull request using `gh`:
+Create a pull request using `gh`.
+
+**If a repo PR template was found in Step 7.5:** Read it and use its structure as the base
+for the PR body. Fill in its sections with the data gathered during the ship workflow. Then
+append any ship-specific sections that the repo template doesn't already cover:
+
+- **Pre-Landing Review** — findings from Step 3.5, or "No issues found."
+- **Eval Results** — if evals ran: suite names, pass/fail counts, cost dashboard. If skipped: "No prompt-related files changed — evals skipped."
+- **Greptile Review** — if comments found: bullet list with [FIXED] / [FALSE POSITIVE] / [ALREADY FIXED] tag. If no PR existed during Step 3.75: omit entirely.
+- **TODOS** — if items marked complete: bullet list with version. If TODOS.md doesn't exist and user skipped: omit.
+- **Test plan** — test pass/fail counts
+
+**If no repo PR template was found:** Use this default format:
 
 ```bash
 gh pr create --base <base> --title "<type>: <summary>" --body "$(cat <<'EOF'
@@ -391,8 +407,6 @@ gh pr create --base <base> --title "<type>: <summary>" --body "$(cat <<'EOF'
 ## Test plan
 - [x] All Rails tests pass (N runs, 0 failures)
 - [x] All Vitest tests pass (N tests)
-
-🤖 Generated with [Claude Code](https://claude.com/claude-code)
 EOF
 )"
 ```