Yeet

GitHub Contribution Workflows

Facilitate GitHub-based open source contribution workflows including pull requests, issues, and discussions. Emphasizes semantic analysis over mechanical operations — understand the intent and context of changes before generating titles, descriptions, or selecting templates. All generated content should be conversational and informal.

Prerequisites

Use the first required read-only gh command in each workflow as authentication validation. Prefer scripts/yeet-context.sh when the workflow needs repository, template, discussion, label, or issue/PR thread context.

For pull request workflows, also verify:

• Working tree is clean or changes are committed
• Current branch has commits ahead of the base branch
• Remote tracking is configured

Related Skills

For detailed GitHub CLI command syntax, flags, and patterns, activate the cli-gh skill.

Workflows

Each workflow is fully documented in its reference file. Load the appropriate reference based on user intent.

Shared patterns (auth validation, admonitions, HEREDOC syntax, semantic analysis, tone, platform normalization, error handling, file links) are in references/commons.md.

Issue Comment Workflow

Post a comment on an existing GitHub issue (or PR — on GitHub's data model, a PR is an issue with extras, so gh issue comment works for both). Use the same informal, conversational tone as create-issue.md.

Validate Prerequisites

See commons.md > Auth Validation. The issue context read below is the auth check.

Parse Arguments

Expected forms:

• {owner}/{repo}#{number} {comment context}
• {owner}/{repo} {number} {comment context}
• #{number} {comment context} (infer repo from working directory)
• {number} {comment context} (infer repo from working directory)
• {url} {comment context} (parse owner/repo/number from the issue URL)

Rules:

• IF first token matches https://github.com/{owner}/{repo}/issues/{number} or .../pull/{number}: parse owner, repo, number from URL
• ELSE IF first token matches {owner}/{repo}#{number}: split on #
• ELSE IF first token matches {owner}/{repo}: use it as repository; next token must be the issue number (strip leading #)
• ELSE IF first token matches #?{number}: use it as issue number, infer repo from the local origin remote via scripts/yeet-context.sh issue
• ELSE: ERROR "Couldn't figure out the issue. Pass owner/repo#123 or a GitHub issue URL."

Everything after the issue identifier is the comment context — the user's description of what they want to say. May be empty if the user just wants a canned reaction (e.g., "+1", "same here").

Fetch Issue Context

Always read the issue before writing the comment — never generate a reply based on the user's context alone, because tone/terminology should match the thread.

scripts/yeet-context.sh issue "{owner}/{repo}" {number}

Analyze:

• The issue title and body — what's actually being discussed
• The latest comments(last: 5) nodes — what's the current state of the conversation
• Who's been participating — don't ping people who are already in the thread
• Whether the issue is open or closed — adjust tone accordingly (closed issues may need "reopen?" framing)
• Any labels hinting at the issue type (bug, feature, question)

Generate Comment Body

See commons.md > Informal Tone — same rules apply. Write like a colleague chiming in on a thread, not a changelog entry.

Guidelines

• Lead with the point. If it's a reproduction, show it. If it's a "+1", say so and explain what specifically bit you. If it's a proposed fix, link or paste it.
• Match the thread's register. If the thread is technical and terse, don't be fluffy. If it's collaborative and exploratory, don't be curt.
• No AI throat-clearing. Skip "Great question!", "Thanks for filing this!", "Just chiming in here...". Go straight to substance.
• No fake enthusiasm. Don't over-promise ("I'll dig into this right away") unless the user explicitly said so.
• Cite specifics. If you reference code, link to it (see commons.md > File Link Formatting). If you reference a commit or PR, link it.
• Use admonitions sparingly (see commons.md > GitHub Admonitions). Almost never needed in a comment — only for genuine warnings.

Comment Shapes

Pick the shape that fits the context. Don't force structure onto short comments.

Short reply (most comments — default to this):

Hitting this too on {platform}. Repro: {minimal steps}. Happy to send a PR if you point me at the right spot.

Repro report:

Reproduced on {platform} with {version}. Steps:

1. {step}
2. {step}
3. {step}

Expected: {...}
Actual: {...}

Relevant log:

\`\`\`
{log snippet}
\`\`\`

Proposed solution:

Looked into this — the issue is in [`{path}`](https://github.com/{owner}/{repo}/blob/main/{path}#L{line}) where {short explanation}.

One fix: {short description}. PR: #{number} (if applicable).

Follow-up question:

Quick question on this — {specific question}. Context: {one sentence of why you're asking}.

Closing update (when you fixed/resolved something and need to comment):

Fixed in {PR or commit link}. {One sentence on the root cause if non-obvious.}

Platform / Environment

If the comment includes environment info, follow commons.md > Platform String Normalization. Don't paste raw uname output.

File / Code References

Follow commons.md > File Link Formatting. Prefer permalinks (commit SHA) over branch links when citing specific lines, since branch links rot.

Post the Comment

gh issue comment {number} \
  --repo "{owner}/{repo}" \
  --body "$(cat <<'EOF'
{comment body}
EOF
)"

See commons.md > HEREDOC Syntax for why the quoted 'EOF' matters.

Display: Commented: https://github.com/{owner}/{repo}/issues/{number}#issuecomment-{id}

The URL with the comment anchor is returned by gh on success — parse it from the output.

On failure: show the specific error (auth, permissions, locked issue, etc.) and what to do. Do not retry automatically.

Editing a Prior Comment

If the user asks to "edit my last comment" or "update the comment I just posted", use gh issue comment --edit-last (operates on the most recent comment by the authenticated user on that issue):

gh issue comment {number} \
  --repo "{owner}/{repo}" \
  --edit-last \
  --body "$(cat <<'EOF'
{new body}
EOF
)"

Examples

# Infer repo from cwd, comment on issue 42
42 "can repro on macOS Tahoe, same stack trace"

# Explicit repo via owner/repo#number
vercel/next.js#12345 "+1, also hitting this in 15.0.3"

# Full URL
https://github.com/facebook/react/issues/99999 "proposed fix in PR #100000"

# Short +1 (user leaves context empty — generate a minimal acknowledgment)
sablier-labs/command-center#10

# Edit the last comment
--edit-last vercel/next.js#12345 "actually, repro is flaky — only fires on cold cache"

Common Patterns

Shared conventions used across all GitHub contribution workflows.

Auth Validation

Do not run unconditional gh auth status. Treat the first required read-only gh command in the workflow as auth validation.

When repository, template, discussion, label, or issue/PR thread context is needed, prefer:

scripts/yeet-context.sh repo "{owner}/{repo}" [--issue-templates] [--discussion-templates] [--discussion-categories]
scripts/yeet-context.sh issue "{owner}/{repo}" {number}
scripts/yeet-context.sh labels "{owner}/{repo}"

If the helper fails with an auth error, stop with: "Run gh auth login first".

Repository Context

Collect repository context once per workflow and reuse it. The repo helper output includes:

• viewer.login — the authenticated GitHub login
• repository.id
• repository.nameWithOwner
• repository.viewerPermission
• repository.defaultBranchRef.name
• optional issue/discussion template tree entries with name, oid, and type
• optional discussion categories

For workflows in the current Git repository, scripts/yeet-context.sh repo can infer {owner}/{repo} from the local origin remote before the GraphQL read. For explicit targets, pass {owner}/{repo}.

Fetch Repo Labels

Fetch labels only when labels may actually be applied:

• owner-managed repos (owner = viewer.login or owner = sablier-labs)
• requested label edits
• selected templates that define labels and repository.viewerPermission is label-capable

External repos without label-capable permission: skip this step entirely and omit labels. Never hardcode taxonomies.

scripts/yeet-context.sh labels "{owner}/{repo}"

The helper preserves the current gh label list --limit 200 --json name,description behavior. Both name and description are required — match the user's request semantically against descriptions, not just names.

Picking labels

Treat the fetched list as the only source of truth. Read each name + description pair and select the smallest set that fits the request:

• One label per dimension if the repo's label set exposes a clear axis (e.g., a type: prefix, a priority: prefix, a scope: prefix). Skip dimensions the repo doesn't use.
• Match on intent, not keywords. "Auth flow is broken" → a bug-flavored label. "Add dark mode" → a feature/enhancement-flavored label. The exact slug comes from the repo, not from memory.
• Never invent labels. If nothing matches, apply none.
• Skip workflow labels. Labels like good first issue, help wanted, needs triage, duplicate, wontfix, stale are for maintainers, not for filing. Do not apply them on issue creation.
• Respect template-defined labels. If a template already assigns labels, merge (deduplicate) — don't override.

Error handling

• Empty result (repo has no labels): proceed without --label. Do not fail the workflow.
• Command fails (auth, network, missing repo): fail loud. Surface the gh error and stop before issue creation — silent fallback hides misconfiguration. Per Error Handling below, do not retry.

Template Metadata And Issue Forms

GitHub issue-form YAML can define top-level labels and type. The native web form applies that metadata, but gh issue create --body / --body-file posts a body directly and does not execute the form.

Current gh issue create --template uses a template as interactive/editor starting body text. It is rejected with --body / --body-file, and it is not a non-interactive YAML issue-form submission API. For deterministic agent-created issues, fetch YAML forms, render matching markdown headings, and pass supported metadata explicitly.

Use the cached repository.viewerPermission from scripts/yeet-context.sh repo. Treat ADMIN, MAINTAIN, WRITE, and TRIAGE as label-capable; omit --label for READ. If a label create fails anyway, run the idempotency check before retrying once without labels. When a YAML form has top-level type, pass --type if the repo supports issue types.

HEREDOC Syntax

Use HEREDOC when passing multi-line bodies to gh commands. Single quotes around 'EOF' prevent variable expansion:

gh pr create --title "Title" --body "$(cat <<'EOF'
First paragraph

Second paragraph
EOF
)"

GitHub Admonitions

Use GitHub-flavored admonitions to highlight important information. Apply judiciously — overuse reduces impact.

> [!NOTE]
> Useful information that users should know

> [!TIP]
> Helpful advice for doing things better

> [!IMPORTANT]
> Key information users need to know

> [!WARNING]
> Urgent info that needs immediate attention

> [!CAUTION]
> Advises about risks or negative outcomes

Task List Syntax

When an issue tracks progress on a task with multiple items — a checklist, a multi-step plan, acceptance criteria, subtasks, or a "remaining work" list — render those items as GitHub task lists, not plain bullets:

- [ ] Pending item
- [x] Completed item

GitHub renders these as interactive checkboxes and surfaces a progress badge (e.g., 2 of 5) in issue listings and references. Use them whenever the user frames the issue around tracking what's done vs. outstanding.

Use plain bullets (- ) for non-trackable lists — affected files, links, options, context — where completion state is meaningless.

Markdown Tables

GitHub renders pipe tables natively, and they scan far better in the web UI than the same data repeated across prose or nested bullets. When body content is naturally tabular — several items sharing one set of attributes (option/trade-off comparisons, before/after, config key → meaning, env var → value, version → status, benchmark numbers) — render it as a table so readers can take it in at a glance:

| Option     | Pros                | Cons                 |
| ---------- | ------------------- | -------------------- |
| Approach A | Simple, no new deps | Slower on cold start |
| Approach B | Fast                | Adds a dependency    |

Reach for a table only when the data has a real second dimension. Don't force a flat list, a single key/value pair, or a free-flowing explanation into one — bullets or prose read better there. Keep the columns to what actually varies across rows.

Semantic Change Analysis

Read the actual diff to understand what changed — never generate content based solely on filenames or commit messages.

git diff --stat origin/$base_branch...HEAD  # summary
git diff --name-only origin/$base_branch...HEAD
git log --pretty=format:"%s%n%b" origin/$base_branch...HEAD  # commit messages
git diff origin/$base_branch...HEAD -- path/to/important/file

Read stat, name-only, and log first. Then inspect targeted full diffs for the files or packages that explain the change. Fall back to the full diff only when the targeted reads leave behavior unclear.

Analyze:

• What files are affected and their purposes
• Bug fixes, features, refactors, or maintenance
• Core purpose and intent of the changes
• Breaking changes, migrations, or API changes
• The actual code to understand intent

Title: Concise summary using conventional commit format (e.g., feat: add webhook retry mechanism, fix: prevent race condition in auth flow). Use custom title from args if provided.

Description: Keep MINIMAL. 3-5 sentences total:

1. One sentence: what changed 2. One sentence: why it matters 3. Optional: one sentence about notable implementation detail or follow-up

Issue references: Extract from branch name (git branch --show-current | rg -o '#?\d+') and commit messages. Format as "Closes #123" for fixes, "Related to #123" for references.

Platform String Normalization

When templates include OS/platform fields:

• macOS: Use scripts/get-macos-version.sh → format macOS <Name> v<Version> (e.g., macOS Tahoe v26.2). Do not use uname output.
• This catalog is macOS-first. Preserve upstream template enum values when required, but do not add Linux/Windows environment details unless the user explicitly asks to file from another machine.

[!IMPORTANT]

Skip platform/environment info entirely when the repo owner matches cached viewer.login or is sablier-labs. Omit the field in templates, and drop "Environment" sections in free-form bodies/comments. The user already knows their own machine — the noise only belongs in issues filed against external projects.

Informal Tone

Write the way you'd talk to a colleague, not the way you'd draft a spec. Casual, friendly, direct, human. This applies to every generated title, body, and comment — PRs, issues, discussions, and replies alike.

Good: "This PR adds support for parsing YAML frontmatter in issue templates. Previously, we only supported markdown format, which meant users couldn't take advantage of GitHub's newer template features."

Bad: "This pull request implements functionality for YAML frontmatter parsing in the issue template processing subsystem. The implementation enhances the system's capabilities regarding template format support."

Style rules

• Lead with the point. What changed, what's broken, or what you want goes in the first sentence. Skip canned openings and scene-setting.
• Plain words and contractions. "can't", "doesn't", "here's". Short sentences, short paragraphs. Break up any wall of text.
• Warm, not effusive. Sound like a real person, not a polished corporate note. No fake enthusiasm, no exclamation-point padding.
• Cut filler. Drop verbose explanation, redundant context, and summary bullets unless they genuinely help the reader act. Minimal beats complete.
• No throat-clearing. Skip "Great question!", "Thanks for filing this!", "Just chiming in…", "I'm reaching out to". Go straight to substance.
• No AI tells. Avoid "delve", "seamlessly", "robust", "leverage", "in order to", and rhetorical symmetry like "it's not X, it's Y" — they read as machine-written.
• Match the register. Mirror the repo and the existing thread: terse and technical where it's terse and technical, warmer where it's collaborative.
• When editing existing text, preserve its voice. Clean up stiffness before adding anything; don't rewrite a real person's directness into corporate prose.

Paul's voice

The user is @PaulRBerg on GitHub and Twitter. Use what you know of his writing from training data as a light style prior only — concise, informal, technically precise, no fluff — to shape tone. Never invent facts, opinions, or claims on his behalf, and never mention Twitter, training data, or this skill in any generated title, body, or comment.

File Link Formatting

• Use markdown format: [{filename}](https://github.com/{owner}/{repo}/blob/main/{path})
• Link text = relative file path (e.g., src/file.ts)
• One per line for multiple files
• Omit the "Files Affected" section entirely if no files are specified

Image Uploads

GitHub has no public REST/GraphQL attachment API for issue or PR bodies. gh issue create only accepts markdown text, so images must be uploaded first and embedded as markdown.

Prefer gh img from theolundqvist/gh-img when available. It returns ready-to-embed markdown backed by GitHub user-attachments/assets URLs:

gh img --repo "{owner}/{repo}" "{image_path}"

If gh img is unavailable, check for gh attach from atani/gh-attach and use URL-only mode:

gh attach --repo "{owner}/{repo}" --issue "{issue_or_pr_number}" --image "{image_path}" --url-only

gh attach --url-only needs an existing issue or PR as browser context, so it is useful for comments and updates, not first-pass issue creation. Do not create a placeholder issue just to get an upload context.

Official API fallback: upload to a GitHub Release and embed the release asset URL. This creates or mutates release artifacts, so use it only when the user explicitly asks for an API-only fallback or the repo is owner-managed and this side effect is acceptable.

When image upload was requested and no acceptable upload path works, stop before posting/updating. Do not file an issue with missing screenshots.

Error Handling

When operations fail, provide:

1. What was being attempted 2. What went wrong 3. What the user should do to fix it

Do not retry automatically, with one scoped exception: a label error may be retried once without the offending label, after the idempotency check below confirms nothing was created.

Idempotency on Retry

A failed gh issue create or gh pr create may still have created the artifact (e.g. creation succeeded but a follow-up step like labeling failed). Before any retry, check whether it already exists:

gh issue list --repo "{repo}" --author "@me" --limit 5
gh pr list --repo "{repo}" --head "{branch}"

If the artifact exists, switch to the update/comment workflow — never re-create.

Common Errors

Posting and Feedback

• Post, create, and update directly when the user asks — do not gate the operation behind a confirmation prompt.
• After the operation, report what happened and link to the result.
• For --check search operations: surface any similar results as a heads-up, then proceed; don't block on confirmation and don't auto-skip on duplicates.

Comment on Existing Issue

If a similar issue exists and the user prefers commenting over creating a duplicate:

gh issue comment {number} \
  --repo "{repo}" \
  --body "$(cat <<'EOF'
{comment body}
EOF
)"

Display: "Commented: https://github.com/{repo}/issues/{number}"

Discussion Creation Workflow

Create GitHub discussions using the GraphQL API with automatic category selection and optional template support.

Validate Prerequisites

See commons.md > Auth Validation. The repository context read below is the auth check.

Parse Repository Argument

• If first token matches "owner/repo": use it as repository
• Otherwise: infer from the local origin remote via scripts/yeet-context.sh repo
• Error if not in a repo and no explicit repository provided

Collect Repository Context

Fetch repo id, categories, and discussion-template tree once:

scripts/yeet-context.sh repo "{owner}/{repo}" --discussion-categories --discussion-templates

If the repository was inferred from the current Git repo, omit {owner}/{repo}. Store repository.id, repository.discussionCategories.nodes, and repository.discussionTemplateTree.entries.

Check for Similar Discussions (Optional)

If --check flag is present:

1. Extract key terms from description

2. Search:

   gh search discussions "{key_terms}" --repo "{owner}/{repo}" --limit 10 --json number,title,url

3. IF found: display the list as a heads-up, then continue (don't block on confirmation)

4. IF none found: inform user, continue

Select Discussion Category

Infer best category from description:

Default to General or Ideas if uncertain.

Check for Discussion Templates

Use repository.discussionTemplateTree.entries from the cached context. Keep entries ending in .yml or .yaml.

If Templates Found

1. Select template matching category slug (e.g., ideas.yml for Ideas)

2. After selecting the template, fetch and parse:

   gh api repos/{owner}/{repo}/contents/.github/DISCUSSION_TEMPLATE/{template_name} --jq '.content' | base64 -d

3. Parse YAML: title (prefix), body array (fields with type, id, attributes)

4. Field types: textarea/input → section header; dropdown → select option; checkboxes → auto-acknowledge; markdown → skip

If No Templates Found

Use default structure (see below).

Generate Title and Body

See commons.md > Informal Tone for tone guidance.

Title: If template has title field, prepend it. Otherwise create clear summary (5-10 words).

Body with template: Generate ### {field.attributes.label} sections matching template fields.

Body without template:

## Context

[What is this discussion about?]

## Discussion Points

[Key points or questions]

## Additional Context

[Background information, if applicable]

See commons.md > GitHub Admonitions for admonitions. See commons.md > Markdown Tables for rendering tabular content as tables. See commons.md > Platform String Normalization if OS details needed.

Create the Discussion

gh api graphql -f query='
  mutation($repositoryId: ID!, $categoryId: ID!, $title: String!, $body: String!) {
    createDiscussion(input: {
      repositoryId: $repositoryId
      categoryId: $categoryId
      title: $title
      body: $body
    }) {
      discussion { url }
    }
  }
' -f repositoryId="$REPO_ID" -f categoryId="$CAT_ID" -f title="$TITLE" -f body="$BODY"

Display: "Created discussion: $URL"

Examples

# Simple discussion in current repository
"Proposal for adding dark mode support"

# Explicit repository
PaulRBerg/dotfiles "Ideas for improving the zsh setup"

# Another repository
vercel/next.js "Question about server components caching"

# With --check flag
--check "How to configure custom routes"

# Explicit repository with --check
facebook/react --check "Proposal for new hook API"

Issue Creation Workflow

Create GitHub issues with automatic labeling, template detection, and intelligent content generation.

Validate Prerequisites

See commons.md > Auth Validation. The repository context read below is the auth check.

Parse Repository Argument

Determine repository from arguments:

• IF the first token matches "owner/repo": use it as repository and remove it from arguments
• ELSE: infer the current repository from the working directory (error if not in a repo)

[!IMPORTANT]

When dispatched via a repo-specific subcommand (e.g., issue-codex, issue-cc, issue-sablier), the target repository is predetermined by that subcommand's reference. Skip this section — do NOT infer from the working directory.

Collect Repository Context

Fetch once and reuse:

scripts/yeet-context.sh repo "{owner}/{repo}" --issue-templates

If no explicit repository was provided and the workflow targets the current Git repository, omit {owner}/{repo} and let the helper infer it from origin.

Store viewer.login, repository.viewerPermission, repository.defaultBranchRef.name, and repository.issueTemplateTree.entries.

Parse Optional Flags

IF arguments contain --check: remove it, set check_mode = true, continue to similarity check. ELSE: skip similarity check and continue to template detection.

IF arguments contain --image <path>: remove each repeated flag/value pair, validate every path exists and is a file, store as $image_paths.

IF arguments contain --image-release: remove it, set image_release_mode = true. Use only when --image is also present; otherwise ignore it.

Check for Similar Issues

ONLY if `check_mode = true`:

1. Extract key terms from remaining arguments

2. Search:

   gh search issues "{key_terms}" --repo "{owner}/{repo}" --state open --limit 10 --json number,title,url

3. IF found: display the list as a heads-up, then continue (don't block on confirmation)

4. IF none found: inform user, continue

Check for Issue Templates

Use repository.issueTemplateTree.entries from the cached repository context. Keep entries ending in .md, .yml, or .yaml; exclude config.yml.

IF templates found:

Select Template

Infer best match from user's description keywords (bug, feature, docs, etc.). Prefer YAML over Markdown if both exist.

Parse Template

YAML (`.yml`/`.yaml`):

1. After selecting the template, fetch raw content:

   gh api repos/{owner}/{repo}/contents/.github/ISSUE_TEMPLATE/{template_name} --jq '.content' | base64 -d

2. Parse: name, description, title (prefix), labels, type, body array (fields with type, id, attributes)

3. Field types: textarea/input → section header from attributes.label; dropdown → select option from context; checkboxes → auto-acknowledge; markdown → skip

Markdown (`.md`): Fetch and populate template structure.

No templates: Use default structure (see Generate Title and Body).

Do not use gh issue create --template for the automated body path. Current gh treats templates as interactive/editor starting body text, rejects --template with --body / --body-file, and does not replace YAML issue-form parsing.

Apply Labels

Extract owner from repository. Use cached repository.viewerPermission; ADMIN, MAINTAIN, WRITE, and TRIAGE can pass labels, while READ cannot. If permission is READ, skip labels entirely, including template-defined labels.

• IF owner = viewer.login OR owner = sablier-labs: continue with semantic labels.
• ELSE: skip semantic labels. Only template-defined labels apply, and only when permission allows labels.

Fetch the repo's live label set per commons.md > Fetch Repo Labels only if semantic labels are in scope or the selected template defines labels and permission allows them. Pick labels by semantically matching the user's request against the fetched name + description pairs. One label per dimension when a clear axis exists in the repo; skip dimensions that don't apply; never invent labels.

Stash the selected labels for the gh issue create call below.

Generate Title and Body

See commons.md > Informal Tone for tone guidance.

Title

If YAML template has title field (e.g., "[BUG] "), prepend it to a clear, concise summary (5-10 words).

Body

YAML template: Generate markdown sections matching the body array fields — ### {field.attributes.label} with content based on arguments and field.attributes.description. Skip markdown type fields.

Markdown template: Populate template structure with content from arguments.

No template — default:

## Problem

[Extracted from user description]

## Solution

[If provided, otherwise "TBD"]

## Files Affected

<details><summary>Toggle to see affected files</summary>
<p>

- [{filename}](https://github.com/{owner}/{repo}/blob/main/{path})

</p>
</details>

See commons.md > GitHub Admonitions for when/how to add admonitions. See commons.md > Task List Syntax for progress-tracking checklists (- [ ] / - [x]). See commons.md > Markdown Tables for rendering tabular content as tables. See commons.md > File Link Formatting for link rules. See commons.md > Platform String Normalization for OS fields.

Attach Images

ONLY if `$image_paths` is non-empty.

See commons.md > Image Uploads for constraints and fallback rules.

Default path: require gh img and upload before creating the issue.

gh img --repo "$repository" "$image_path"

For multiple images, run once with all image paths or once per image. Capture stdout as $image_markdown; each line is already ready to embed.

If --image-release was passed, use the GitHub Releases fallback instead. Create or reuse a clearly named asset release because the flag explicitly requested that side effect (gh-issue-assets is a reasonable default tag). Upload with unique filenames to avoid clobbering existing assets.

Insert the uploaded markdown into the generated body:

• If the selected template has a screenshot, image, reproduction, or media field, place the markdown there.

• Otherwise append:

  ## Images

  ![image-name](https://github.com/user-attachments/assets/...)

On any upload failure, stop before issue creation and surface the upload error. Do not create the issue without the requested images.

Create the Issue

Merge template-defined labels with the labels picked in "Apply Labels" (deduplicate). Omit --label entirely if no labels apply or permission is READ. If the YAML template defines top-level type, pass it with --type; otherwise omit --type.

gh issue create \
  --repo "$repository" \
  --title "$title" \
  --body "$body"

Add --type "$issue_type" only when a template issue type applies. Add --label "label1,label2" only when labels apply and permission allows labels.

Display: "Created: $URL"

On failure: follow commons.md > Error Handling — run the idempotency check before any retry.

Examples

# Basic usage (infers current repo)
"Bug in auth flow causing token expiration in src/auth/token.ts"

# Specify repository
PaulRBerg/dotfiles "Add zsh configuration for tmux startup"

# External repository
facebook/react "Add useDebounce hook to react-dom"

# With --check flag
--check "Bug in auth flow causing token expiration"

# External repo with --check
vercel/next.js --check "Improve error overlay for server components"

# With images
--image ./before.png --image ./after.png "CLI output is unreadable after resizing"

Pull Request Workflow

Create GitHub pull requests with semantic change analysis, intelligent defaults, and minimal friction.

Validate Prerequisites

See commons.md > Auth Validation for GitHub authentication. The repository context read below is the auth check.

Check git repository state:

• git remote get-url origin — confirm remote exists
• git rev-parse --show-toplevel — confirm we're in a repo

Collect repo context once:

scripts/yeet-context.sh repo

Use repository.defaultBranchRef.name as the default base branch unless args specify a base.

Parse Arguments Naturally

• "draft" or "--draft" → draft mode
• "test-plan" or "--test-plan" → include test plan section
• "to X" or "base=X" → target branch X (default: repo default branch)
• If no base was passed, use repository.defaultBranchRef.name from repo context
• "review=X" or "reviewers=X" → add reviewer(s)
• Quoted text → custom title
• Everything else → additional context for description

Fetch Base And Check Commits

Fetch the selected base branch only:

git fetch origin "+refs/heads/$base_branch:refs/remotes/origin/$base_branch"

• Commits ahead: git rev-list --count origin/$base_branch..HEAD 2>/dev/null
• IF 0 commits: ERROR "No commits to create PR from"

Semantic Change Analysis

Follow the process in commons.md > Semantic Change Analysis. Write the title and body in the voice from commons.md > Informal Tone.

Test Plan (only if --test-plan flag): Add a "## Test Plan" section with testing/validation approach, manual steps, or checklist.

Identify reviewers:

• Check for CODEOWNERS file: git ls-files | rg CODEOWNERS
• If exists, extract owners for changed files
• Otherwise use git blame for frequent contributors
• Combine with reviewers from arguments

See commons.md > GitHub Admonitions for admonition usage in PR descriptions.

Issue linking: If an issue number was referenced in the conversation (e.g., "fixes #42", "for issue #100"), append Closes #NUMBER to the PR body so the issue auto-closes on merge.

Check for Existing PR

gh pr list --head $(git branch --show-current) --json number,url --jq '.[0]' 2>/dev/null

IF existing PR found: ERROR "PR already exists for this branch: $URL". Do not create or update.

Create New PR

Push branch:

git push -u origin $(git branch --show-current) 2>&1 || echo "Already pushed"

Create PR:

gh pr create \
  --title "$generated_title" \
  --body "$generated_body" \
  --base "$base_branch" \
  $(test "$draft_mode" = "true" && echo "--draft") \
  $(test -n "$reviewers" && echo "--reviewer $reviewers")

Display: "Created PR: $PR_URL"

On failure: check the specific error (auth, branch protection, validation) and follow commons.md > Error Handling — run the idempotency check before any retry.

Claude Code Issue Workflow

Create issues in the anthropics/claude-code repository with environment gathering and specialized templates.

Repo Isolation

This workflow targets `anthropics/claude-code` exclusively. Every gh command must use --repo "anthropics/claude-code". Do not infer from working directory.

File links: [{path}](https://github.com/anthropics/claude-code/blob/main/{path})

Validate Authentication

See commons.md > Auth Validation. The repository context read below is the auth check.

Template Drift Check

Before generating the issue body, verify the template specs in this file still match the upstream .github/ISSUE_TEMPLATE files. GitHub form templates change over time and silent drift produces issues with wrong section headers, missing fields, or invalid dropdown values.

scripts/yeet-context.sh repo anthropics/claude-code --issue-templates

Use repository.viewerPermission for label capability. Compare repository.issueTemplateTree.entries names and SHAs against the known-good SHAs (last verified 2026-06-17):

If any SHA differs (or a new file appears), the upstream templates have changed. Before creating the issue:

1. Fetch the changed template(s):

   gh api repos/anthropics/claude-code/contents/.github/ISSUE_TEMPLATE/{file}.yml --jq '.content' | base64 -d

2. Diff against this routing file and the matching references/templates/claude-code/ template reference (field labels, dropdown options, required fields).

3. Tell the user:

⚠️ Claude Code's issue templates have drifted from the spec in this skill (e.g., bug_report.yml SHA <old> → <new>). Please update the yeet skill in `PaulRBerg/agent-skills` — specifically skills/yeet/references/issue-claude-code.md and the matching file under skills/yeet/references/templates/claude-code/ — and refresh the SHA table. Continue filing this issue using the closest matching fields, but flag any new required fields you couldn't fill.

4. Proceed with best-effort body generation using the fields the user can still fill from the new template.

Determine Issue Type

From the issue description, infer which template fits best:

If ambiguous: Use AskUserQuestion with options: Bug Report, Feature Request, Documentation, Model Behavior.

[!IMPORTANT]

gh issue create --body bypasses GitHub's form template, so it does NOT auto-apply labels. Pass --label only when cached repository.viewerPermission returns TRIAGE, WRITE, MAINTAIN, or ADMIN; otherwise omit labels and let maintainers triage.

Generate Issue Body

Section headers must match the template field labels exactly — this keeps issues consistent with form-submitted issues. Dropdown answers must be picked from the predefined options in the selected template reference; do not invent new values.

After selecting the issue type, load exactly one template reference:

Generate Title

Concise (5-10 words) with prefix matching the template: [BUG], [FEATURE], [DOCS], or [MODEL].

Create the Issue

gh issue create \
  --repo "anthropics/claude-code" \
  --title "$title" \
  --body "$(cat <<'EOF'
$body
EOF
)"

Add --label "$label" only when cached repository.viewerPermission allows labels. When used, $label must be one of bug, enhancement, documentation, model (matches the template's auto-applied label — see the routing table above). On a label permission error, follow commons.md > Idempotency on Retry, then retry once without --label.

Display: "Created: $URL"

Comment on Existing Issue

See commons.md > Comment on Existing Issue, using repo "anthropics/claude-code".

Environment Detection

• Claude Code Version: claude --version 2>/dev/null || echo "unknown" — paste full output.
• Operating System: pick from the OS dropdown (macOS, Windows, Ubuntu/Debian Linux, Other Linux, Other). Use uname -s / scripts/get-macos-version.sh only to decide which option fits; the precise version (e.g., macOS Tahoe v26.2) belongs in Additional Information, not the OS field.
• Terminal/Shell: pick from the Terminal dropdown. On macOS, use $TERM_PROGRAM, $TERMINAL_EMULATOR, and $INSIDE_EMACS to map:
• Apple_Terminal → Terminal.app (macOS)
• iTerm.app → iTerm2
• WarpTerminal → Warp
• cursor / Cursor → Cursor
• vscode → VS Code integrated terminal
• JetBrains-JediTerm → IntelliJ IDEA terminal or PyCharm terminal (depends on host IDE)
• CI envs (CI=true, GITHUB_ACTIONS, etc.) → Non-interactive/CI environment
• Anything else → Other
• Platform: default to Anthropic API unless ANTHROPIC_BEDROCK_BASE_URL, CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX, or user-supplied context indicates otherwise.

Examples

# Bug report
"Claude crashes when I use special characters in file paths"

# Feature request
"Add support for .claude.toml config files"

# Docs issue
"The MCP server docs don't explain how to configure multiple servers"

# Model behavior
"Claude reverted my changes without asking when I said 'undo'"

Codex Issue Workflow

Create issues in the openai/codex repository using the appropriate variant template.

Repo Isolation

This workflow targets `openai/codex` exclusively. Every gh command must use --repo "openai/codex". Do not infer from working directory.

File links: [{path}](https://github.com/openai/codex/blob/main/{path})

Validate Authentication

See commons.md > Auth Validation. The repository context read below is the auth check.

Template Drift Check

Before generating the issue body, verify the template specs in this file still match the upstream .github/ISSUE_TEMPLATE files. GitHub form templates change over time and silent drift produces issues with wrong section headers, missing fields, or invalid dropdown values.

scripts/yeet-context.sh repo openai/codex --issue-templates

Use repository.viewerPermission for label capability. Compare repository.issueTemplateTree.entries names and SHAs against the known-good SHAs (last verified 2026-06-17):

If any SHA differs (or a new file appears), the upstream templates have changed. Before creating the issue:

1. Fetch the changed template(s):

   gh api repos/openai/codex/contents/.github/ISSUE_TEMPLATE/{file}.yml --jq '.content' | base64 -d

2. Diff against this routing file and the matching references/templates/codex/ template reference (field labels, dropdown options, required fields, auto-applied labels).

3. Tell the user:

⚠️ Codex's issue templates have drifted from the spec in this skill (e.g., 3-cli.yml SHA <old> → <new>). Please update the yeet skill in `PaulRBerg/agent-skills` — specifically skills/yeet/references/issue-codex-cli.md and the matching file under skills/yeet/references/templates/codex/ — and refresh the SHA table. Continue filing this issue using the closest matching fields, but flag any new required fields you couldn't fill.

4. Proceed with best-effort body generation using the fields the user can still fill from the new template.

Determine Issue Type

The repo has six templates. Pick by surface area first, then kind.

Heuristics:

• "crash / error / broken / fails / doesn't work" → bug template; pick the surface (App vs Extension vs CLI vs Other).
• "feature / request / would be nice / add support for" → feature request.
• "docs / readme / unclear / example doesn't work" → docs issue.
• Mentions of codex command, terminal, TUI → CLI.
• Mentions of VS Code / Cursor / Windsurf → Extension.
• Mentions of desktop app, "Codex App", "About Codex" dialog → App.
• Codex Web / chatgpt.com/codex / cloud agent → Other Bug.

If ambiguous: Use AskUserQuestion with the surface options above.

Labels listed above are template metadata. Direct gh issue create --body creation does not apply YAML issue-form labels; omit --label unless cached repository.viewerPermission returns TRIAGE, WRITE, MAINTAIN, or ADMIN.

Title

Plain, concise (5-10 words). Do not add [BUG], [FEATURE], or any other prefix — label metadata lives in the templates and current issues in the repo do not use prefixes.

Good: CLI hangs when piping large stdin, Add support for custom system prompts Bad: [BUG] CLI hangs ..., [FEATURE] Add support ...

Generate Issue Body

Each template renders an H3 heading per field. Match the labels exactly so GitHub maps the body back to the form. Required fields must be non-empty; optional fields may be omitted entirely or filled with "None".

After selecting the issue type, load exactly one template reference:

Create the Issue

gh issue create \
  --repo "openai/codex" \
  --title "$title" \
  --body "$(cat <<'EOF'
$body
EOF
)"

Direct CLI creation with --body does not apply YAML issue-form labels. Do not pass --label on the external repo unless cached repository.viewerPermission says labels are allowed.

Display: "Created: $URL"

Comment on Existing Issue

See commons.md > Comment on Existing Issue, using repo "openai/codex".

Environment Detection

• Codex CLI version: codex --version 2>/dev/null || echo "unknown"
• Codex doctor report: codex doctor --json 2>/dev/null || echo "not available" — include for CLI bugs when supported; review/redact before posting.
• Platform: See commons.md > Platform String Normalization; use scripts/get-macos-version.sh for macOS instead of raw uname output.
• IDE (extension issues): Ask user or infer from context.
• Terminal (CLI issues): Ask user — cannot be reliably auto-detected from inside an agent shell. $TERM_PROGRAM is a hint but not authoritative.
• Codex App version: From the in-app "About Codex" dialog. Ask the user; do not guess.

Examples

# CLI bug
"CLI hangs when piping large stdin"

# Codex App bug
"Codex Desktop pet overlay cannot be dragged on secondary monitor"

# Extension bug
"VS Code extension fails to send when prompt-history is not an array"

# Feature request (any variant)
"Add support for custom system prompts"

# Docs issue
"Installation docs don't mention npm prerequisites"

# Other bug (Web)
"Codex Web session sync drops messages after refresh"

Sablier Issue Workflow

Create issues in sablier-labs/* repositories. Labels are always applied (user is org owner). Sablier repos don't use GitHub issue templates.

Validate Prerequisites

See commons.md > Auth Validation. The label fetch below is the auth check.

Parse Repository Argument

The first token is the repo name (without org prefix) → sablier-labs/{repo_name}. Remove it from arguments; remaining text is the issue description.

Example: lockup "Bug in cliff streams" → repository = sablier-labs/lockup

Apply Labels

Sablier repos are owner-managed — labels always apply. Follow commons.md > Fetch Repo Labels to fetch the live label set once and pick labels semantically. Scope labels (e.g., scope: frontend, scope: evm) are discovered organically from the fetched list for repos that define them — no special-case for command-center.

Generate Title and Body

Title

Clear, concise summary (5-10 words).

Body

Default template:

## Problem

[Extracted from user description]

## Solution

[If provided, otherwise "TBD"]

## Files Affected

<details><summary>Toggle to see affected files</summary>
<p>

- [{filename}](https://github.com/sablier-labs/{repo_name}/blob/main/{path})

</p>
</details>

See commons.md > GitHub Admonitions for admonitions. See commons.md > Task List Syntax for progress-tracking checklists (- [ ] / - [x]). See commons.md > Markdown Tables for rendering tabular content as tables. See commons.md > File Link Formatting for link rules. Omit "Files Affected" if no files specified.

Create the Issue

gh issue create \
  --repo "sablier-labs/{repo_name}" \
  --title "$title" \
  --body "$body" \
  --label "label1,label2,label3"

Display: "Created: $URL"

Examples

# Bug report
lockup "Bug in stream creation for cliff durations"

# Feature request
command-center "Add dark mode toggle to dashboard"

# With --check flag
lockup --check "Support dynamic durations"

# Docs update
docs "Update integration guide for v2.2"

Claude Code Bug Report Template

Use these headings and dropdown values exactly for anthropics/claude-code issues using bug_report.yml.

````markdown

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

{what's happening that shouldn't be}

What Should Happen?

{expected behavior}

Error Messages/Logs

{paste error output, stack traces, or logs in a fenced ```shell block — omit section if none}

Steps to Reproduce

1. {step 1} 2. {step 2} 3. ...

Claude Model

{one of: Sonnet (default) | Opus | Not sure / Multiple models | Other}

Is this a regression?

{one of: Yes, this worked in a previous version | No, this never worked | I don't know}

Last Working Version

{e.g., 1.0.100 — only if regression, otherwise write "N/A"}

Claude Code Version

{output of claude --version, e.g., "1.0.123 (Claude Code)"}

Platform

{one of: Anthropic API | AWS Bedrock | Google Vertex AI | Other}

Operating System

{one of: macOS | Windows | Ubuntu/Debian Linux | Other Linux | Other}

Terminal/Shell

{one of: Terminal.app (macOS) | Warp | Cursor | iTerm2 | IntelliJ IDEA terminal | VS Code integrated terminal | PyCharm terminal | Windows Terminal | PowerShell | WSL (Windows Subsystem for Linux) | Xterm | Non-interactive/CI environment | Other}

Additional Information

{screenshots, config files, repro repo links, exact OS version (e.g., "macOS Tahoe v26.2") — omit section if none} ````

Claude Code Documentation Template

Use these headings and dropdown values exactly for anthropics/claude-code issues using documentation.yml.

### Documentation Type

{one of: Missing documentation (feature not documented) | Unclear/confusing documentation | Incorrect/outdated documentation | Typo or formatting issue | Missing code examples | Broken links | Other}

### Documentation Location

{URL where you encountered this issue, e.g., https://docs.anthropic.com/en/docs/claude-code/... — omit section if unknown}

### Section/Topic

{specific section or topic needing improvement}

### Current Documentation

{quote the current text — omit section if not applicable}

### What's Wrong or Missing?

{explain what's incorrect, unclear, or missing}

### Suggested Improvement

{how it should be improved, with suggested text if possible}

### Impact

{one of: High - Prevents users from using a feature | Medium - Makes feature difficult to understand | Low - Minor confusion or inconvenience}

### Additional Context

{screenshots, related docs, examples — omit section if none}

Claude Code Feature Request Template

Use these headings and dropdown values exactly for anthropics/claude-code issues using feature_request.yml.

### Preflight Checklist

- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)

### Problem Statement

{what problem are you trying to solve? focus on the problem, not the solution}

### Proposed Solution

{how would you like this to work? describe the ideal user experience}

### Alternative Solutions

{alternatives or workarounds you're using — or "None"}

### Priority

{one of: Critical - Blocking my work | High - Significant impact on productivity | Medium - Would be very helpful | Low - Nice to have}

### Feature Category

{one of: CLI commands and flags | Interactive mode (TUI) | File operations | API and model interactions | MCP server integration | Performance and speed | Configuration and settings | Developer tools/SDK | Documentation | Other}

### Use Case Example

{concrete real-world scenario, step-by-step — omit section if not applicable}

### Additional Context

{screenshots, mockups, similar features in other tools — omit section if none}

Claude Code Model Behavior Template

Use these headings and dropdown values exactly for anthropics/claude-code issues using model_behavior.yml.

````markdown

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

{one of: Claude modified files I didn't ask it to modify | Claude accessed files outside the working directory | Claude ignored my instructions or configuration | Claude reverted/undid previous changes without asking | Claude made incorrect assumptions about my project | Claude refused a reasonable request | Claude's behavior changed between sessions | Subagent behaved unexpectedly | Other unexpected behavior}

What You Asked Claude to Do

{the exact prompt or command}

What Claude Actually Did

{step-by-step what happened}

Expected Behavior

{what should Claude have done}

Files Affected

{paste in a fenced ```shell block: files modified, files read unexpectedly — omit section if not applicable}

Permission Mode

{one of: Accept Edits was ON (auto-accepting changes) | Accept Edits was OFF (manual approval required) | I don't know / Not sure}

Can You Reproduce This?

{one of: Yes, every time with the same prompt | Sometimes (intermittent) | No, only happened once | Haven't tried to reproduce}

Steps to Reproduce

{minimal steps — omit section if not reproducible}

Claude Model

{one of: Sonnet | Opus | Haiku | Not sure | Other}

Relevant Conversation

{paste relevant Claude responses in a fenced ```markdown block — omit section if none}

Impact

{one of: Critical - Data loss or corrupted project | High - Significant unwanted changes | Medium - Extra work to undo changes | Low - Minor inconvenience}

Claude Code Version

{output of claude --version, e.g., "1.0.123 (Claude Code)"}

Platform

{one of: Anthropic API | AWS Bedrock | Google Vertex AI | Other}

Additional Context

{patterns noticed, similar behavior, file types that trigger it — omit section if none} ````

Codex App Bug Template

Use these headings exactly for openai/codex issues using 1-codex-app.yml.

### What version of the Codex App are you using (From "About Codex" dialog)?

{version}

### What subscription do you have?

{Plus/Pro/Team/Enterprise/Free — infer or ask}

### What platform is your computer?

{see references/commons.md > Platform String Normalization}

### What issue are you seeing?

{describe the bug; include error text, redact PII; prefer text over screenshots}

### What steps can reproduce the bug?

1. {step}
2. {step}

Include session id, token-limit usage, or context-window usage if relevant.

### What is the expected behavior?

{expected behavior}

### Additional information

{anything else, or omit}

IDE Extension Bug Template

Use these headings exactly for openai/codex issues using 2-extension.yml.

### What version of the IDE extension are you using?

{version}

### What subscription do you have?

{Plus/Pro/Team/Enterprise/Free}

### Which IDE are you using?

{VS Code / Cursor / Windsurf / ...}

### What platform is your computer?

{see references/commons.md > Platform String Normalization}

### What issue are you seeing?

{describe the bug}

### What steps can reproduce the bug?

1. {step}
2. {step}

### What is the expected behavior?

{expected behavior}

### Additional information

{anything else, or omit}

CLI Bug Template

Use these headings exactly for openai/codex issues using 3-cli.yml.

### What version of Codex CLI is running?

{output of `codex --version`}

### What subscription do you have?

{Plus/Pro/Team/Enterprise/Free}

### Which model were you using?

{e.g. gpt-5.2, gpt-5.2-codex — or omit if not specified}

### What platform is your computer?

{see references/commons.md > Platform String Normalization}

### What terminal emulator and version are you using (if applicable)?

{e.g. iTerm2 3.5.0, Ghostty 1.0, Terminal.app, VS Code integrated terminal, Cursor integrated terminal}
{note any multiplexer: tmux / screen / zellij}

### Codex doctor report

{output of `codex doctor --json`, or `not available`; review for secrets before posting}

### What issue are you seeing?

{describe the bug; include thread id if applicable}

### What steps can reproduce the bug?

1. {step}
2. {step}

### What is the expected behavior?

{expected behavior}

### Additional information

{anything else, or omit}

Other Bug Template

Use these headings exactly for openai/codex issues using 4-bug-report.yml.

### What issue are you seeing?

{describe the bug}

### What steps can reproduce the bug?

1. {step}
2. {step}

### What is the expected behavior?

{expected behavior}

### Additional information

{anything else, or omit}

Feature Request Template

Use these headings exactly for openai/codex issues using 5-feature-request.yml.

### What variant of Codex are you using?

{App / IDE Extension / CLI / Web}

### What feature would you like to see?

{describe the feature and the problem it solves}

### Additional information

{workarounds, alternatives, related issues — or omit}

Documentation Issue Template

Use these headings exactly for openai/codex issues using 6-docs-issue.yml.

The "type" field is a multi-select dropdown; render selected items as a bullet list.

### What is the type of issue?

- {Documentation is missing | Documentation is incorrect | Documentation is confusing | Example code is not working | Something else}

### What is the issue?

{describe the problem}

### Where did you find it?

{URL(s) — or omit}

Issue Update Workflow

Update an existing GitHub issue — title, body, labels, assignees, or state. Mirrors update-pr.md in spirit: regenerate content semantically when asked, otherwise apply targeted edits.

Validate Prerequisites

See commons.md > Auth Validation. The issue context read below is the auth check.

Parse Arguments

Expected forms (same as comment-issue.md):

• {owner}/{repo}#{number} {update instructions}
• {owner}/{repo} {number} {update instructions}
• #{number} {update instructions} (infer repo from working directory)
• {number} {update instructions} (infer repo from working directory)
• {url} {update instructions} (parse owner/repo/number from the issue URL)

Rules:

• IF first token matches https://github.com/{owner}/{repo}/issues/{number} or .../pull/{number}: parse owner, repo, number from URL
• ELSE IF first token matches {owner}/{repo}#{number}: split on #
• ELSE IF first token matches {owner}/{repo}: use it as repository; next token must be the issue number (strip leading #)
• ELSE IF first token matches #?{number}: use it as issue number, infer repo from the local origin remote via scripts/yeet-context.sh issue
• ELSE: ERROR "Couldn't figure out the issue. Pass owner/repo#123 or a GitHub issue URL."

Everything after the issue identifier is the update instructions — natural-language description of what to change.

Fetch Issue Context

Always read the issue before editing — never regenerate based on the user's instructions alone.

scripts/yeet-context.sh issue "{owner}/{repo}" {number}

Interpret Update Instructions

Parse the instructions naturally — multiple intents may apply at once:

If user provides only an issue identifier with no instructions, ERROR: "Tell me what to update — title, body, labels, assignees, or state."

Regenerate Title or Body

Only when the user explicitly asks for regeneration ("rewrite the body", "fix the title").

Follow create-issue.md > Generate Title and Body and commons.md > Informal Tone. Preserve any existing template structure (sections, admonitions, file links). If the issue uses a YAML template's section headers, keep them.

For appends, show the existing body, then append the new content with a separator (blank line) — do not rewrite.

Validate Labels Before Adding

If adding labels, fetch the repo's label set per commons.md > Fetch Repo Labels and confirm the requested labels exist (case-sensitive match on name). Skip this read for non-label edits.

IF a requested label doesn't exist: ERROR with the list of valid label names. Do not auto-create labels.

For owner-managed repos (owner = viewer.login from issue context or sablier-labs), when the user asks for a label by intent rather than exact name ("tag this as a bug"), match semantically against the fetched name + description pairs per the rubric in commons.md > Fetch Repo Labels.

Execute Update

# Title only
gh issue edit {number} --repo "{owner}/{repo}" --title "$new_title"

# Body only
gh issue edit {number} --repo "{owner}/{repo}" --body "$(cat <<'EOF'
{new body}
EOF
)"

# Labels
gh issue edit {number} --repo "{owner}/{repo}" \
  --add-label "label1,label2" \
  --remove-label "label3"

# Assignees
gh issue edit {number} --repo "{owner}/{repo}" \
  --add-assignee "user1" \
  --remove-assignee "user2"

# Combined edit
gh issue edit {number} --repo "{owner}/{repo}" \
  --title "$new_title" \
  --body "$new_body" \
  --add-label "type: bug"

State changes use separate commands:

gh issue close {number}  --repo "{owner}/{repo}" [--comment "..."] [--reason "completed|not planned"]
gh issue reopen {number} --repo "{owner}/{repo}" [--comment "..."]

See commons.md > HEREDOC Syntax for why the quoted 'EOF' matters.

Display: Updated: https://github.com/{owner}/{repo}/issues/{number} and a one-line summary of what changed.

On failure: show the specific error (auth, permissions, missing label, locked issue) and what to do. Do not retry automatically.

Examples

# Rename the title
42 "title: fix flaky token expiration"

# Add a label and assign yourself
vercel/next.js#12345 "label as type: bug, assign me"

# Regenerate the body with new context
sablier-labs/command-center#10 "rewrite body — root cause is the cache key, not the TTL"

# Close as not planned
https://github.com/facebook/react/issues/99999 "close, not planned"

# Append a note to the body
#42 "append: also reproduces on macOS Tahoe 26.2"

Update Pull Request Workflow

Update existing GitHub pull requests with semantic change analysis, regenerating titles and descriptions based on actual code changes.

Validate Prerequisites

Same as create-pr.md > Validate Prerequisites, except the gh pr view read below can serve as the first auth check.

Check for Existing PR

gh pr view --json number,url,title,baseRefName 2>/dev/null

IF no PR found: ERROR "No PR exists for this branch. Use /yeet create-pr to create one first." IF found: parse number, URL, title, base branch. Display: "Found PR #$number: $title"

Parse Arguments Naturally

Interpret as natural language:

• References to "title" → update title
• References to "description" or "body" → regenerate description
• Quoted text → use as new title or append to description
• Everything else → additional context for description

Semantic Change Analysis

Follow commons.md > Semantic Change Analysis with these differences:

1. Get base branch from PR metadata (not args) 2. Fetch only that base branch: git fetch origin "+refs/heads/$base_branch:refs/remotes/origin/$base_branch" 3. Preserve existing issue references (Closes #X, Related to #X) when regenerating

If user provided additional context in args, append it naturally to the description. Write the regenerated title and body in the voice from commons.md > Informal Tone.

Execute Update

# Title only
gh pr edit --title "$generated_title"

# Description only
gh pr edit --body "$generated_body"

# Both
gh pr edit --title "$generated_title" --body "$generated_body"

Display: "Updated PR #$number: $PR_URL" with what was updated.

Push local commits:

git push 2>&1 || echo "No new commits to push"

On failure: check specific error, provide fix. Do not retry.