ccc-file-pr git:20261027.a49bba2A

Immutable. This exact content never changes and is served at /api/v1/blob/acf4a34e1e87950c.

---
name: ccc-file-pr
description: "File a concise draft pull request with a clear title, a problem-first description, and the local test results. Use when the user asks to file, open, or create a PR."
allowed-tools:
  - Read
  - Bash(gh pr list *)
  - Bash(gh pr view *)
  - Bash(git diff *)
  - Bash(git log *)
  - Bash(git status *)
  - AskUserQuestion
argument-hint: "[base-branch]"
disable-model-invocation: true
---

# /ccc-file-pr — File a concise PR

**CC Commander** · /ccc-file-pr · a draft PR with a human title, a problem-first description and recorded local proof.

> Adapted from [t3dotgg/tstack](https://github.com/t3dotgg/tstack) `skills/file-pr/SKILL.md` at `92e38e2cf677a84a142e8df296861c588542135c`. MIT, Copyright (c) 2026 Theo Browne; see `LICENSE.txt`. Changes for CC Commander are marked "CCC safety:".

The user's selected model is preserved. Codex: ask the picker below as a plain-text question or request_user_input.

## When to use / when not to

- Use when the user asks to file, open, or create a pull request for the current branch.
- Not for reviewing a branch (`/ccc-review`) or diagnosing red CI (`/ccc-ci`).

## What happens

1. **Check for an existing PR and the base.**
   ```bash
   git status --short --branch
   gh pr list --head "$(git branch --show-current)" --json number,url,state,isDraft
   ```
   If a PR exists, report it and stop unless the user wants an update.
2. **Review the diff locally** against the base branch (usually `origin/main`) so the contents match the goal:
   ```bash
   git fetch origin && git diff origin/<base>...HEAD --stat && git log origin/<base>..HEAD --oneline
   ```
3. **Run the local gate on this exact head.** Run the repository's full test suite and lint (find the commands in CLAUDE.md, AGENTS.md, package scripts or the Makefile). Record the exact commands and their results. CCC safety: push only after both are green on this head; never `--no-verify`, never skip a hook. A failure is fixed, not skipped.
4. **Write the title.** PR titles usually become commit messages, so follow the repository's conventions (read recently merged PRs and `git log`). Prefer a concise, human-readable title that says why the change matters:

   BAD

   > ❌ perf(server): negotiate permessage-deflate on the websocket

   GOOD

   > ✅ perf(server): cut websocket frame size by 70%+ with gzipping

5. **Write the description.** Open with a simple explanation of the problem based on the user's original prompt, then briefly explain the solution. Do not lead with an implementation inventory:

   BAD

   > ❌ Removed implicit workspace carry-over from every "new thread" entry point (cmd+n / cmd+shift+o, sidebar v1/v2 buttons, command palette). New threads inherit only the project from context; branch, worktree, and env mode always come from the configured defaults. Deleted buildContextualThreadOptions, startNewThreadInProjectFromContext, and the v1 sidebar's seed-context machinery.

   GOOD

   > ✅ My "new worktree" default was ignored when starting new threads on existing worktrees. Super unintuitive. Now your preferences always apply.

   CCC safety: add a "Local checks" section listing the exact suite and lint commands and their result (pass/fail, counts) on this head sha.
6. **Attribute.** End the description with `Created with <model> in <harness>.` using the model name the harness reports, and include subagent models that wrote part of the change. If model identity is unavailable, name the harness without guessing a model.
7. **Secrets check.** Before submission, check the title, description, quotes and attachments for secrets and private details.
8. **Create as draft.** CCC safety: upstream opens a ready PR so review bots run; here the PR is a draft until the local gate is green on the head.
   ```bash
   git push -u origin HEAD
   gh pr create --draft --base <base> --title "<title>" --body-file <file>
   ```
   If `gh pr create` fails because the GraphQL rate limit is used up, use REST: `gh api repos/<owner>/<repo>/pulls -f title=... -f head=... -f base=... -F draft=true -F body=@<file>`.
9. **Mark ready** (`gh pr ready <n>`) only when the gate is green on the head and the user asked for it or granted a full-send. Draft PRs may skip review bots; say so when reporting.
10. If the user also asked to babysit it, Read [ccc-babysit-pr](../ccc-babysit-pr/SKILL.md) and follow its steps. If a PR comment is needed, Read [ccc-pr-comments](../ccc-pr-comments/SKILL.md) and follow its steps.

## Decision points

After the draft exists and the gate is green (AskUserQuestion, 2–3 options):
- 🟢 Keep as draft: you mark it ready later
- Mark ready for review: review bots start; use only after the gate is green
- Also monitor it: continue with the babysit steps

## Done when

- `gh pr view <n> --json url,isDraft,headRefOid` was read after creation and reported: URL, draft state, head sha.
- The description lists the local suite and lint commands and their results for that sha.

## Guardrails

- Pushing and creating a PR each need the user's request in this conversation.
- Never rewrite pushed history, never `--no-verify`, never skip hooks or secret scanning.
- No follow-up PR comment unless it serves the user's request.
- Never include secrets or private details in any PR text.

## See also

- `/ccc-review` — branch review before filing
- `/ccc-ci` — diagnose red CI
- `/ccc-qa` — full pre-ship test pass

---

> ⚙️ **Fable contract:** plan before build · verifier ≠ worker · prove before alarm · loops need gates · leave durable state — `rules/fable-method.md`