Base

Plugin base in kkhys/codex-plugins. Commands read from the repo's manifest — yesterday.

Skills (27)

• babysitting-pr

  Watch a pull request until it is genuinely mergeable: long-poll CI, review threads and merge state through scripts/pr-watch.sh, fix branch-caused CI failures and actionable review comments, re-request Copilot review after every fix round until Copilot stops commenting. Use when a PR should be carrie

• cleaning-workspace

  Delete every local branch of the current repository except the protected ones — trunk branches, anything checked out in a worktree, names passed with --keep — after showing the list once and flagging work that exists nowhere else. Explicit workflow, invoked as $cleaning-workspace; never touches a wo

• creating-branch-name

  Create a git branch named type/description from the current changes. Use when asked for a branch, or when work sits on main or master and needs a branch before committing.

• creating-handoff

  Compact the current conversation into a handoff document — a file under ~/.agents/handoffs/, or appended to a Notion page — so a fresh session can continue the work. A transit document, not a spec or a plan; it carries only what the next session needs to resume.

• creating-pr

  Open a GitHub pull request with this user''s conventions — title "[base-branch] type: description", always --draft, always --assignee kkhys, a flat bullet body in the repository''s language. Use for any request to create or open a PR.

• creating-stacked-pr

  Decide whether a task should be a stack of dependent PRs — single PR is the default answer — design the layers at reviewable granularity, and build the stack with gh-stack under this user''s conventions ("[main] type: description" titles, draft, assignee kkhys). Use for any mention of stacked or dep

• diagnosing-bugs

  Six-phase discipline for a hard bug or performance regression — build a red-capable feedback loop, reproduce and minimise, rank hypotheses, instrument, fix behind a regression test, clean up. For a bug that resists a first look, not one whose cause the failing output already names.

• diagnosing-ci-failure

  Diagnose one failed CI run or the failing checks of a PR from a URL: pull the failed job logs, name the cause with the log excerpt, classify it as branch-caused or flaky, then fix it on the PR branch as a new commit or rerun the failed jobs. Use for a GitHub Actions run URL or a PR with failing chec

• digging

  Interrogate a plan, design, or technical decision one question at a time, in Japanese, until both sides hold the same picture of it. Asks and records only; never implements.

• drafting-message

  Draft a short Japanese message the user will post themselves — a Slack reply or share, a request to QA, design, support or another team, a Notion or PR comment — sized and worded for the named audience, shown in chat, and copied to the clipboard; never posts it. Use when the user wants text to send

• eli15

  Explain a topic the user names from zero as a one-page HTML picture explainer — drawn pictures, few plain words, pitched at a smart fifteen-year-old. Not for re-explaining an answer already on screen, which is explaining-like-doraemon.

• explaining-like-doraemon

  Re-explain a difficult answer as a Doraemon-Nobita dialogue in Japanese, then restate it in precise terms. Re-explains only what is already on screen; a topic explained from zero as a picture page is eli15.

• fixing-review-comments

  Address the unresolved review comments on a pull request end to end — read the threads, check each against the code, implement what holds, verify, commit the round, reply in every thread with the commit link. Use when asked to fix, handle, or respond to PR review feedback.

• formatting-commit

  Write git commit messages in Conventional Commits form with this user's scope and amend rules, and decide between a new commit and an amend. Use whenever changes are committed, including commits made inside another workflow.

• illustrating-pr

  Draw a pull request as one eli15 picture for an engineer reader — a self-contained HTML panel rendered with the local Chrome — and place it in the PR description''s "## In pictures" section, or a comment, with gh --attach. Explicit workflow, invoked as $illustrating-pr; writing the PR body itself is

• merging-renovate-prs

  Merge the open Renovate pull requests of a repository owned by kkhys, one at a time: squash on green CI, wait for the rebase Renovate does itself when a PR falls behind, diagnose and fix a check the bump broke, report what stays blocked. Refuses any repository whose owner is not kkhys and never touc

• posting-pr-review

  Post review findings to a GitHub pull request as a PENDING review through scripts/post-pr-review.sh — severity-tagged, one or two lines each, substantive findings only, attributed to Codex. Use whenever review comments are to be posted or submitted to a PR; never call the review API directly.

• publishing-pr

  Publish the current work end to end — branch, logical commits, draft pull request — by running creating-branch-name, splitting-commit, and creating-pr in sequence. Explicit workflow, invoked as $publishing-pr.

• reading-unresolved-pr-comments

  Fetch the current PR's unresolved review threads — thread IDs, outdated flags, line ranges, full comment history — through scripts/read-unresolved-pr-comments.sh and turn them into a fix plan. Use to see what reviewers asked for; the first step of fixing-review-comments. Reads only.

• recording-pr-qa

  Run a PR''s manual test in headless Chrome through playwright-cli, capture each case as a screenshot or a captioned video with an in-video console, and place the evidence with the case list in the PR description, in the repository''s template sections when it has them, or in the user''s pending revi

• recording-qase-qa

  Run a PR''s manual test against its Qase cases: map the change to the cases of the suites it touches, create the missing ones, record the non-automated ones through recording-pr-qa into the QA run with a clip per case, and turn the repeatable ones into a Playwright spec on a stacked PR. Explicit wor

• resolving-merge-conflicts

  Resolve an in-progress git merge, rebase, or cherry-pick conflict by intent: trace each side to its primary source (commit, PR, issue), preserve both intents per hunk, run the project''s own checks, and carry the operation to a finished commit. A PR into develop that GitHub reports as conflicting is

• resolving-pr-comments

  Resolve review threads on the current PR through scripts/resolve-pr-comments.sh — every unresolved thread after the user confirms, or an explicit list of thread IDs. Use when asked to resolve, close, or mark review threads as done.

• reviewing-pr

  Review a pull request, or a stacked series, and close with the fixed Japanese verdict block — approve or not, reproducible bugs with steps a human can run, findings without nits, regression and feature-flag scope, a manual test checklist. Use when handed a PR to review or asked whether it is approva

• splitting-commit

  Split uncommitted changes that mix several concerns into a sequence of focused commits a reviewer can follow and git bisect can act on. Not for a single-concern change, which goes straight to formatting-commit.

• writing-for-agents

  Levers for writing any document an agent consumes — a skill, an AGENTS.md, an agent definition, a reference reached by a pointer: context pointers, the two loads, information hierarchy, completion criteria, leading words, pruning. Use before creating or editing such a document, when a skill fires un

• writing-qase-cases

  Rules for what a Qase test case holds: only what lasts as long as the behaviour, variants as single, group or shared parameters, and the PR, the ticket, a feature flag and the environment kept in the run or the result instead. Use before creating or editing a Qase test case, through the API or a Qas

MCP servers (1)

• serena

  runs: uvx --from git+https://github.com/oraios/[email protected] serena start-mcp-server --project-from-cwd --context=codex

Similar plugins