Agent skill

Create PR

by moeru-ai in moeru-ai/airi

Prepare and create an AIRI pull request with verifiable change context, architecture evidence, and required visual evidence.

MITAuto-check passedDevelopment

Install Create PR

skills CLI
$ npx skills add moeru-ai/airi --skill create-pr -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install moeru-ai/airi create-pr --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/moeru-ai/airi.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/create-pr .claude/skills/create-pr && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
create-pr
GitHub stars
50k
Token cost
~2.3k tokens
SKILL.md length
1,224 words
Files
3 (incl. references)
Skills in repo
24
Repo updated
First seen
Licence
MIT

At a glance

Prepare and create an AIRI pull request with verifiable change context, architecture evidence, and required visual evidence.

  • Works in 12 steps: Inspect the repository instructions,… → Compute the merge base. Record the exact… → Detect stacked work. Separate inherited… → …
  • Codex must open
  • SKILL.md covers Workflow, Context Evidence, PR Body Contract and Behavior Evidence Workflow, plus 3 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Create PR is an agent skill from moeru-ai/airi. Prepare and create an AIRI pull request with verifiable change context, architecture evidence, and required visual evidence. Use when Codex must open, create, publish, or prepare a PR from the current branch.

Its SKILL.md is about 2.3k tokens, which your agent loads only when the skill is triggered. The skill folder holds 4 other files, including reference files (for example `agents/openai.yaml` and `references/pr-body.md`).

It sits in Development, covering Pull requests. The repository describes itself as: 💖🧸 Self hosted, you-owned Grok Companion, a container of souls of waifu, cyber livings to bring them into our worlds, wishing to achieve Neuro-sama's altitude. Capable of… The licence is MIT.

When your agent uses it

  • Codex must open
  • Prepare a PR from the current branch

Example prompts

  • “/create-pr”

Workflow steps

12 steps, taken from the first numbered list in SKILL.md.

  1. Inspect the repository instructions, status, branch, remotes, and target branch.
  2. Compute the merge base. Record the exact base...head comparison that the PR will publish.
  3. Detect stacked work. Separate inherited changes from this PR's own changes.
  4. Review the complete diff. Trace changed files to their entry points, callers, state owners, persistence, and external boundaries.
  5. Classify the PR as a feature, fix, refactor, maintenance change, or a combination. Select context evidence that helps reviewers understand…
  6. Run checks that match the changed surfaces. Satisfy the repository's required final checks.
  7. If the diff changes user-visible UI, follow the visual-evidence workflow below.
  8. Read the PR body template. Compose the body from verified code and runtime evidence.
  9. Publish the intended commits through the available GitHub or gh workflow.
  10. Create the PR. Then open it and verify the title, base, head, body, diagrams, tables, and image Markdown.
  11. Get the PR review threads, comments, and check status. Fix each confirmed error and run focused checks.
  12. Push each correction. Reply with evidence and resolve the applicable thread.

What it can do on your machine

Read from SKILL.md and the folder at commit 45b8670. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Create PR loads about 2.3k tokens when it runs, and up to ~3.6k if it reads all its reference files. Until then it costs about 55 tokens; SKILL.md has 1,224 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~55
When it runs · the whole SKILL.md, loaded when a task matches
~2.3k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~3.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from moeru-ai/airi at commit 45b8670, republished under its MIT licence (© moeru-ai). 1,224 words, ~2,263 tokens.

Download SKILL.mdSave it as .claude/skills/create-pr/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
create-pr
description
Prepare and create an AIRI pull request with verifiable change context, architecture evidence, and required visual evidence. Use when Codex must open, create, publish, or prepare a PR from the current branch.

Create Pull Request

Create a reviewable PR from the exact commits intended for publication. The PR body must explain the changed system, not only list changed files.

Workflow

  1. Inspect the repository instructions, status, branch, remotes, and target branch.
  2. Compute the merge base. Record the exact base...head comparison that the PR will publish.
  3. Detect stacked work. Separate inherited changes from this PR's own changes.
  4. Review the complete diff. Trace changed files to their entry points, callers, state owners, persistence, and external boundaries.
  5. Classify the PR as a feature, fix, refactor, maintenance change, or a combination. Select context evidence that helps reviewers understand this change.
  6. Run checks that match the changed surfaces. Satisfy the repository's required final checks.
  7. If the diff changes user-visible UI, follow the visual-evidence workflow below.
  8. Read the PR body template. Compose the body from verified code and runtime evidence.
  9. Publish the intended commits through the available GitHub or gh workflow.
  10. Create the PR. Then open it and verify the title, base, head, body, diagrams, tables, and image Markdown.
  11. Get the PR review threads, comments, and check status. Fix each confirmed error and run focused checks.
  12. Push each correction. Reply with evidence and resolve the applicable thread.

Context Evidence

Build a small context brief before you write the PR body. Keep the analysis read-only until the normal publication step.

  • Record the repository, target branch, head branch, merge base, and inspected commit range.
  • For a stacked PR, identify the parent PR or branch. Do not describe inherited changes as this PR's own changes.
  • Separate runtime code from generated files, lockfiles, snapshots, and migrations.
  • Trace the changed files to real module boundaries. Include entry points, composition roots, protocols, domain services, persistence, adapters, and callers when applicable.
  • Support architecture claims with file paths or symbols. Mark an unproven business intent as an assumption or an open question.
  • Do not expose tokens, secrets, full user records, or webhook payloads.

PR Body Contract

Use the structure in the PR body template as a decision guide. Match the detail to the scope, risk, and review cost.

  • Every PR needs a concise ## Summary and ## Verification section.
  • Add ## Change map when the diff changes several modules, responsibilities, or ownership boundaries.
  • Add ## Architecture and behavior when a diagram explains the change faster or more accurately than prose.
  • Add ## Boundaries and risks when the change has meaningful failure modes, invariants, migrations, or external effects.
  • Keep a small and local PR body small. Do not add a table or diagram only to satisfy a template.

When a change map is useful, prefer this table:

ModuleBeforeAfterDescription
<module or boundary><previous responsibility or behavior><new responsibility or behavior><reason and effect>

Use module or domain names in the first column. Do not use a raw file list as the module map. Prose is sufficient for a single local module.

Behavior Evidence Workflow

Apply this workflow when the diff changes runtime behavior. A small wording, styling, or local cleanup change does not need a behavior diagram.

  1. List the changed behavior scenarios with a stable ID and short title. Include affected state transitions, async ordering, retries, cancellation, event routing, persistence, cleanup, and failure or recovery paths.
  2. For each scenario, select the smallest evidence form that makes the change reviewable: prose for a local path, a module flow for changed ownership or dependencies, a sequence diagram for ordering, or a state diagram for changed transitions or terminal states.
  3. For a fix that changes a flow or state model, provide comparable Before and After diagrams. For a feature, show the resulting flow or state model and explain any replaced behavior.
  4. Cover every listed scenario in the PR body or name it as unverified. Do not silently omit a changed path because a diagram seems optional.
  5. Inspect the evidence against the diff. Keep node names and abstraction level consistent across a Before and After pair.

When a scenario changes state, show the states, triggering events or commands, and terminal or recovery states that the diff affects. When it changes ordering, show the participants and the order of calls, events, retries, or cleanup. Name correlation and idempotency keys when they isolate concurrent work.

Keep diagrams tied to code. Label arrows with calls, events, commands, or data. Identify domain-rule and mutable-state owners. Show external systems, IPC, queues, databases, caches, and configuration when they affect the behavior. Match each alt branch to a code branch. Mark inferred paths as assumptions or open questions.

Show full SKILL.md (485 more words)Show less

Boundary and Verification Mapping

Select risks that match the diff. Start with inputs and side effects. Then examine failure, retry, duplicate delivery, concurrency, ordering, authorization, cleanup, migration, and rollback. Reuse the behavior scenario IDs when they connect an invariant to its evidence.

Map each high-risk invariant to existing tests, new tests, CI checks, or an unverified runtime condition. A green CI result proves only that its configured checks passed.

Use a table when the PR has several meaningful edge cases or invariants:

Invariant or boundaryFailure modeProtectionEvidence or gap
<required behavior><how it can fail><code or design guard><test, runtime evidence, or unverified gap>

Distinguish verified facts, assumptions, and unverified conditions. Do not write "safe," "fixed," or "backward compatible" without evidence.

Visual Evidence Workflow

  1. Trace the diff to every affected page, window, dialog, route, responsive state, theme, and locale. Shared primitives and global styles can require several consumers, not one representative page.

  2. Record a stable ID and human-readable title for each state. Prefer existing product-owned Vishot scenarios, Histoire stories, routes, and nearby tests.

  3. Use the recorded merge base. Create a detached temporary worktree for that commit. Never switch or overwrite the contributor's active worktree.

  4. Use $use-vishot to capture the same scenario from the merge base and proposed HEAD. It delegates by runtime:

    • $use-vishot-with-electron for Electron windows.
    • $use-vishot-with-web for browser routes.
    • $use-vishot-with-capacitor for Stage Pocket or another Capacitor app.
  5. Use identical scenario definitions, viewports, locale, theme, fixture data, and readiness conditions for both revisions.

  6. Construct explicit Vishot output directories using the repository-owned .vishot/[branch/][group/] convention. Omit the branch segment for the default branch and use a filesystem-safe segment for other branches. Keep capture group and name identical across revisions.

  7. Inspect every image. Reject blank, loading, error, permission, onboarding, or unstable captures unless that is the documented state.

  8. Pair results by stable ID and retain this handoff record:

    text
    id: settings-connection
    title: Settings / Connection
    runtime: web
    viewport: 1440x900
    before: /absolute/repo/.vishot/settings/settings-connection.png
    after: /absolute/repo/.vishot/feat-settings/settings/settings-connection.png

    Use before: absent for a new state and after: removed for a deleted state. A capture failure is blocking. Record its reason instead of silently omitting the state.

  9. Upload every local image as a GitHub user asset by invoking $upload-github-attachment while composing the PR.

  10. Put all pairs under ## Visual changes. Put an image row before its component or page name row:

markdown
| Before | After |
|---|---|
| ![](before-user-asset-url) | ![](after-user-asset-url) |
| Settings / Connection | Settings / Connection |
  1. Verify that every user-asset URL matches the intended capture. Follow $upload-github-attachment for upload success criteria. Do not add GET/HEAD probes or block on anonymous 404 responses. Remove temporary worktrees only after upload succeeds. Clear ignored .vishot captures when they are no longer useful locally.

Visual Evidence Contract

Treat Vishot output as ephemeral handoff data. GitHub owns the uploaded copy. The repository must remain free of tracked PR-only images.

If GitHub asset upload is unavailable, stop before you create an incomplete UI PR. Report the local image paths that the PR needs.

© moeru-ai, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 2 other files (references) in .agents/skills/create-pr of moeru-ai/airi.

  • SKILL.md
  • agents/openai.yaml
  • references/pr-body.md

Open the folder on GitHubat commit 45b8670

Compare with similar skills

Create PR next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Create PR compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Create PR this skillmoeru-ai/airi50k—~2.3kAutomated safety check: PassMIT
Finishing a Development Branchobra/superpowers296k5 repos~1.9kAutomated safety check: PassMIT
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Check PRonyx-dot-app/onyx32k2 repos~2.3kAutomated safety check: PassMIT
Understand Diff AnalysisEgonex-AI/Understand-Anything86k1 repos~1.4kAutomated safety check: PassMIT
PR Design DocOpenHands/OpenHands90k—~2.4kAutomated safety check: PassMIT

Similar skills

  • Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.

    296k GitHub starsUsed in 5 repos~1.9k tokens
    DevelopmentAuto-check passed
  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed
  • Check PR

    onyx-dot-app/onyx

    Checks a GitHub, GitLab, or Perforce (p4) pull request (or merge request, or shelved changelist) for unresolved review comments, failing status checks, and incomplete PR descriptions.

    32k GitHub starsUsed in 2 repos~2.3k tokens
    DevelopmentAuto-check passed
  • Understand Diff Analysis

    Egonex-AI/Understand-Anything

    Reads your git changes or a pull request against a prebuilt knowledge graph of the project to explain what changed, which components are affected and what is risky.

    86k GitHub starsUsed in 1 repo~1.4k tokens
    DevelopmentAuto-check passed
  • PR Design Doc

    OpenHands/OpenHands

    For a non-trivial pull request, write a self-contained HTML design doc under the temporary .pr/ directory and link a visibility-appropriate preview in the PR description, so maintainers grasp the…

    90k GitHub stars~2.4k tokensUpdated today
    DevelopmentAuto-check passed
  • WooCommerce Code Review

    woocommerce/woocommerce

    Reviews WooCommerce code changes against the project's standards, flagging backend PHP architecture, naming, documentation, data integrity and testing violations.

    11k GitHub starsUsed in 3 repos~1.1k tokens
    DevelopmentAuto-check passed

More from moeru-ai/airi

All 24 skills in this repo
  • Simple English

    moeru-ai/airi

    Write or rewrite technical text with the rules of ASD-STE100 Simplified Technical English so it is clear, unambiguous, and free of AI slop.

    50k GitHub starsUsed in 2 repos~4.6k tokens
    Auto-check passed
  • Review pending AIRI translations on Crowdin in a batch, then sync them into the repository.

    50k GitHub stars~1.5k tokensUpdated today
    Auto-check passed
  • Upload a local image or file to GitHub's user-attachments storage and return a URL suitable for issue, pull request, discussion, or comment Markdown.

    50k GitHub stars~554 tokensUpdated today
    Auto-check passed
  • Test AIRI display-model imports with agent-browser across stage-tamagotchi Electron, stage-web, and stage-pocket mobile web layouts.

    50k GitHub stars~1.1k tokensUpdated today
    Auto-check passed
  • A skill your agent uses when Codex needs to inspect, debug, or automate an Electron app through agent-browser and Chrome DevTools Protocol, especially when the app has multiple BrowserWindow…

    50k GitHub stars~3.1k tokensUpdated today
    Auto-check passed
  • Analyze Io Traces

    moeru-ai/airi

    Read and analyze AIRI IO traces that Tamagotchi saved to local files.

    50k GitHub stars~542 tokensUpdated today
    Auto-check passed

Categories

Questions about Create PR

What does Create PR do?

Prepare and create an AIRI pull request with verifiable change context, architecture evidence, and required visual evidence. Create PR is an agent skill from moeru-ai/airi. Prepare and create an AIRI pull request with verifiable change context, architecture evidence, and required visual evidence.

When should I use Create PR?

Create PR fits situations like: Codex must open; prepare a PR from the current branch.

How do I install Create PR in Claude Code?

Run `npx skills add moeru-ai/airi --skill create-pr -a claude-code`. Or copy the skill folder (.agents/skills/create-pr in moeru-ai/airi) into .claude/skills/create-pr in your project. Claude Code loads it when a task matches its description.

How do I install Create PR in Codex?

Run `npx skills add moeru-ai/airi --skill create-pr -a codex`. Or copy the skill folder (.agents/skills/create-pr in moeru-ai/airi) into .agents/skills/create-pr in your project. Codex loads it when a task matches its description.

Can I use Create PR in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add moeru-ai/airi --skill create-pr -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/create-pr, .gemini/skills/create-pr, .github/skills/create-pr and .opencode/skills/create-pr in your project.

What does Create PR need to run?

SKILL.md names no scripts, command-line tools or credentials: Create PR is instructions for the agent only.

Does Create PR access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Create PR safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Create PR use?

Create PR is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Create PR use?

About 2.3k tokens (SKILL.md is roughly 9.1k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.3k tokens, read only when the agent opens those files.

What are the alternatives to Create PR?

Skills that share tags, products or a category with Create PR: Finishing a Development Branch (obra/superpowers, 296k stars), PR Babysitter (openinterpreter/openinterpreter, 69k stars), Check PR (onyx-dot-app/onyx, 32k stars) and Understand Diff Analysis (Egonex-AI/Understand-Anything, 86k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Create PR?

moeru-ai (a GitHub organization) maintains it in moeru-ai/airi, which has 50,142 GitHub stars. The repository holds 24 skills in this directory. The repository was last updated on October 8, 2026.

Source: moeru-ai/airi on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.