motoki317

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.

Use when creating, grooming, or working a persistent improvement backlog — adding or triaging an item, refuting a candidate, deciding where a long-lived task should live, or grooming stale entries. For this repo the backlog is the git-tracked docs/backlog.md. Reach for this skill whenever you are about to write down a future task, a tech-debt note, or a "we should eventually…" item, even if the user doesn't say the word "backlog" — durable tasks belong here, not in throwaway scratch. Pairs with the improvement-cycle skill, which discovers and ships the items this skill files.

Use when doing self-directed, iterative improvement of this codebase — "improve the UX", "find things to improve", "keep improving X", run improvement cycles, or generate/work a backlog. Encodes how to DISCOVER improvement points yourself (by investigating source code and the web), adversarially VERIFY them against the real code, and IMPLEMENT them one verified cycle at a time. Tuned for kd's UI/UX work but the loop is general.

Use when cutting a kd release — publishing a new version of the kd app and/or its Helm chart, or when the user says "release X.Y.Z", "tag a release", "ship a new version", or "publish the chart". Encodes the two independent semver tracks (app `vX.Y.Z` → GoReleaser; chart `chart-vX.Y.Z` → helm push), the exact order of operations, the pre-flight gates, and the traps that fail a release half-published. Reach for this whenever a git tag is about to trigger a public artifact.

Use when cutting an agtlog release from a vX.Y.Z tag.

Use when cutting a ksync release — publishing a new version of the ksync CLI, or when the user says "release X.Y.Z", "tag a release", "ship a new version", or "cut the first release". ksync has ONE release track: pushing a `vX.Y.Z` git tag fires both GoReleaser (GitHub Release) and the cachix pre-build. This skill is the runbook — the pre-flight gates, the exact order, and the traps that leave a release half-published. Reach for it whenever a git tag is about to trigger a public artifact.