Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/atman-33/kiro-for-codex-ide/generate-pull-request-draftgit clone --depth 1 https://github.com/atman-33/kiro-for-codex-ideWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/atman-33/kiro-for-codex-ide/generate-pull-request-draft)<a href="https://agentmods.dev/commands/atman-33/kiro-for-codex-ide/generate-pull-request-draft"><img src="https://agentmods.dev/badge/commands/atman-33/kiro-for-codex-ide/generate-pull-request-draft.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.00536 |
| Opus 5 | $0.00000 | $0.00268 |
| Sonnet 5 | $0.00000 | $0.00107 |
| Haiku 4.5 | $0.00000 | $0.00054 |
Grade A, and why
generate-pull-request-draft scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 77 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Generate Pull Request Title and Description (Interactive Workflow)
You are a member of a software development team. Your task is to create a clear, concise, and professional Pull Request (PR) title and description — step by step, with user confirmation at each stage.
Workflow Steps
Step 1 — Confirm Target Branch
Ask the user which branch the PR will be merged into (target branch).
If the user does not specify, suggest main as the default.
Example: “Which branch should this PR target? (default: main)”
Step 2 — Generate Draft PR Message
Once the target branch is confirmed:
- Review the git diff and commit history compared to the confirmed target branch.
- Generate both a PR title and PR body draft.
- Write the draft message to
.tmp/pull-request-message-draft.md.
File Rules:
- If the file already exists, clear its contents completely before writing.
- Save the file in UTF-8 (LF) encoding.
Use the following template for the draft:
### Overview
Briefly summarize what changes this PR introduces.
### Changes
- List the main modifications in bullet points.
- Make it understandable even for someone who doesn’t read the source code.
Step 3 — Ask for User Review
After generating the draft file, show a short preview and ask:
“Please review the draft in
.tmp/pull-request-message-draft.md. Would you like to revise it, or proceed to create the Pull Request?”
If the user requests changes, regenerate the draft accordingly.
Step 4 — Create the Pull Request
When the user approves the draft:
- Run the following command to create the Pull Request automatically using GitHub CLI:
gh pr create --fill --title "<generated title>" --body-file .tmp/pull-request-message-draft.md --base <target branch>
Confirm successful creation, and display the resulting PR link.
Additional Requirements
- All text must be written in English, with a professional and business-appropriate tone.
- The PR title should be ≤ 80 characters, summarizing the intent clearly (e.g., “Add autosave logic to CreateSpec controller”).
- Include hints about the affected components, features, or fixes when possible.
- Ensure the output file
.tmp/pull-request-message-draft.mdcontains only the new generated message, with no leftover content.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 77 lines · 0 tokens per session scan A 0951aafb9950
generate-pull-request-draft is a command published in the GitHub repository atman-33/kiro-for-codex-ide (16 stars, last pushed 10mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 536 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
fix-tickets
Autonomously fix one or more speckit-companion GitHub issues with the SpecKit Companion pipeline — clean branch, fix, review, PR, merge, reinstall — then write a manual-verification report. Self-hosting build loop.
ship-ticket
Ship an ALREADY-BUILT ticket — code review → PR → merge → learnings → install-local. Skips the build (you built it in SpecKit Companion). The tail of /fix-tickets, no rebuild.
bench-capture
Score the 2 bench variant folders for one size (build/acceptance/regression/conventions/capture + rubric + cross-solution review), record, report, and reset.
ship
Review code, update docs, and package a new version (project).
install-local
Bump version and install both extensions locally (VS Code + spec-kit).
bench-prep
Clean + arm the 2 bench variant folders for one size, ready to run in VS Code.