dotfiles

Run a PR's full review-fix cycle — wait for review and CI, fix failures, evaluate and reply to comments, then commit and push. Use whenever a PR was just opened or updated — the post-Ship phase of the Orchestrator loop.

Push the current branch and create a pull request with a title and description derived from the commit history. Use when the user asks to open a PR — the Ship step of the Orchestrator loop, always user-triggered.

Delegate a task's implementation wholesale to OpenAI Codex (`codex-run work`) — the whole requirements document in one long autonomous run — keeping policy, orchestration, and acceptance in the main loop. Use at the Implement step of the Orchestrator loop, for any multi-part build.

Cross-model second opinion from OpenAI Codex — `codex-run advise --context` reviews the current session, or pipe a brief. Triggers on "ask codex", "codex review", "second opinion", or the "Cross-model review" rules.

Define requirements before implementation — clarify constraints and design policy, then write a requirements spec and task breakdown for the Implementer to a gitignored plan file. Use at the Plan step of the Orchestrator loop, or whenever a request's scope needs pinning down before building. Never implements; the plan file is its only write.

Root-cause investigation — enumerate competing hypotheses, verify each with evidence, suggest a fix but never apply it. Use when an error, failing test, or anomaly needs diagnosing before any fix is written; implementation hands off to the Implementer.

Create, improve, and evaluate skills. Use when the user wants to create a skill from scratch, edit or optimize an existing one, run evals or benchmarks on it, or optimize its description for better triggering accuracy.

Multi-viewpoint quality review (ISO/IEC 25010) of a change or plan, run by parallel agents. Use after implementing a change, to pressure-test a plan, or when the user asks for feedback, a quality check, or a critique of recent work.

QA-test a feature by exercising the running software with adversarial scenarios. Use after implementing or changing a feature, or when the user asks for QA, to "try to break" something, hunt for defects, or verify behaviour against spec.

Regroup the unshipped commits — a feature branch, or unpushed work on the default branch — into clean, reviewer-readable logical units, then rebase and push where authorized. Use when history shows trial-and-error (fix-ups, reverts, WIP commits) worth tidying — the Implementer loop's Tidy step; the address skill invokes it to publish review fixes.

Answer questions about the project with file:line evidence from code and docs — read-only, never modifies files. Use when the user asks how or why something works, or weighs a "should we" question that needs an investigated answer rather than a change.

日本語の技術文書・書籍原稿の文章規範（整形、段落と論証の構成、論証の厳密さ、読み手の負荷、視点と語り、演出の抑制、LLM 口調の禁止、冗長の排除）。日本語で章・草稿・記事・解説文を書くとき、または推敲・リライトするときに使用する。

Guide Test-Driven Development using Kent Beck's Red-Green-Refactor cycle. Use when writing tests, implementing features via TDD, or following plan.md test instructions.

Prepare a contribution to an upstream OSS repo — review the diff and tests against its contribution guide and draft compliant PR metadata. Use before submitting a PR to an external repository. Read-only; never opens the PR.

Browser automation CLI for AI agents — navigate, fill forms, click, screenshot, extract data, and test web apps via CDP. Use for any browser or web-UI task, exploratory QA, and automating Electron desktop apps (VS Code, Slack, Discord, …) or cloud browsers (Vercel Sandbox, AWS AgentCore).

Stage meaningful diffs and create commits with WHY-focused messages. Use when committing changes.

Analyze an open decision through the lenses that best expose its blind spots (feasibility, risk, impact, alternatives, cost, …), run in parallel, then synthesize a recommendation with explicit trade-offs. Use *before* deciding — when the user weighs options, compares approaches, assesses feasibility/risk/impact, or thinks a problem through. Not for reviewing an existing change (feedback) or exercising running software (qa-review).