ohyesgocool
UserLoop engineering for AI coding agents: plan → build → MR → independent AI review → fix → re-review until clean, with a merge gate and a self-learning blind-spot ledger. Agent Skills format, Claude Code native, MIT.
Categories
Indexed Skills (9)
address-review
Triage external code-review feedback on a merge request and resolve it end-to-end, automatically: decide which comments are valid against the actual diff (line by line), explain why each valid one was missed during coding, defend the correct decisions reviewers got wrong, then implement the fixes, push, and reply to every comment thread — all in one pass, without stopping to ask. Built for the loop where an AI coding agent writes the code, you raise an MR, and reviewer agents comment with less project context than the author has. Invoking the skill is the go-ahead for the whole loop (triage → implement → push → reply); the only hard stop is a red build. Valid comments get marked done on the MR, invalid ones explained. Use when: addressing MR/PR review comments, "address the review", "incorporate review feedback", triaging reviewer-bot comments, deciding which review comments are worth acting on.
build-feature
Execute a feature plan phase by phase, as a disciplined coding agent: branch fresh from main (always — pull latest, never branch off a stale branch), read the plan fully line by line, re-ground every phase in the current code before writing, then build with clean-code discipline — SOLID, DRY, reuse-first (more code = more maintenance surface), async/concurrent by default with a synchronization ledger for every spot that must be sequential, a hack ledger so nothing sneaky ships unflagged, and sound database design (constraints, indexes, transactions, migration discipline). Type-check + tests gate every phase; commits are granular (one per logical change); every finished plan ends with the branch pushed and an MR/PR raised whose description always has four sections — Problem / Solution / Technical details / Review notes. Two hard stops only: an architectural concern (ask the user, with a recommendation) and a red build. Everything else runs continuously through all phases, MR/PR included. Use when: implementing
land
Post-merge landing: take merged MR(s) to verified-in-production by executing the project's landing runbook — watch the main pipeline(s) to green, apply or hand off migrations, deploy in the runbook's order, then canary-verify (health checks, smoke checks) before declaring shipped. Runbook-driven: reads docs/landing.md; on first run it drafts one by inspecting the repo (CI config, migrations, health endpoints) and confirms it with you. Every step is tagged [agent] (executed directly) or [human] (prod-locked — handed to you as exact commands and waited on, never assumed). Hard stops: red pipeline, failed migration, failed canary, unconfirmed human step. Never auto-rolls-back; prepares the revert and asks. Use when: "land this", "deploy the merge", after /ship-feature merges, "take it to prod", running post-merge follow-ups (migrations, deploy order, canary).
mr-review
Get independent external-AI reviews on a merge request and post them as MR comments: sends the MR title, description, and diff to each configured external reviewer — OpenAI GPT (correctness-first implementation brief) and xAI Grok (code-quality review: DRY, cohesion, naming, testability) — and posts each reviewer's brief as a separate MR discussion. The point is independence: the reviewers are DIFFERENT models from the one that wrote the code, so they don't share its blind spots. Review-only — never modifies code, never approves, never merges. Feeds /address-review, which triages and resolves the posted comments. Requires OPENAI_API_KEY and/or XAI_API_KEY in the environment (see Configuration). Use when: "review this MR", "run the AI review", "get an external review", right after /build-feature raises an MR, or re-reviewing after fixes were pushed.
plan-feature
Product-owner + architect planning agent: take a rough brief (a few paragraphs on what to build), study the actual codebase first, frame the feature by what the USER achieves, challenge the brief and ask only the clarifying questions that genuinely block planning (with a recommendation each), audit every proposed UI element against "less is more", verify the design is buildable against real code (file:line), then produce a phased, executable plan — summary of what changes, summary of how, then small technically-elaborate phases a coding agent can pick up and run without extra context. The plan is saved as a markdown file for handoff. One deliberate pause: the clarifying-questions gate. Everything else runs end-to-end. Use when: planning a new feature, "plan this", "create a plan for", "how should we build X", turning a product idea into an implementation plan, before starting any multi-phase build.
resolve-conflicts
Integrate a moved target branch into a feature branch and resolve the conflicts — safely enough to run unattended. Merges the target in rather than rebasing, so the MR's existing review threads stay anchored and nothing needs a force-push. Classifies every conflicted file before touching it: lockfiles and generated artifacts are regenerated rather than hand-merged, migrations are renumbered rather than merged, additive lists are unioned, and logic conflicts are resolved by reading both sides' intent — never by picking a side. Then it proves the integration: no surviving markers, every hunk the target contributed still present in HEAD (the "took ours wholesale" check), full gates green, and the feature re-verified. Hard stops are the point: same-migration edits, unresolvable lockfiles, binaries, delete/rename conflicts, oversized conflict sets, and genuine guesswork all stop with the tree exactly as it was and a rollback anchor printed. Use when: an MR shows conflicts with its target, "resolve the conflicts",
ship-feature
The full loop, one command — from a Jira ticket key or a feature brief. Give it PROJ-123 and it reads the whole ticket (/ticket-intake), plans (/plan-feature), builds and raises the MR (/build-feature), gets independent external-AI reviews (/mr-review), triages and fixes the findings (/address-review), re-reviews until clean, resolves any conflicts with the target (/resolve-conflicts), merges, and writes the outcome back to the ticket (/ticket-report) — moving it to Done only when every requirement was actually delivered. Point it at a ticket whose MR is already open and it skips straight to auditing that MR: unresolved comments get addressed, a clean one gets merged. Safeguards: max review rounds (default 3), no-progress detection, honest convergence, and a four-part definition of a green pipeline. Ticket runs are autonomous by default, which removes the human from the waiting, never from the deciding — every hard stop still fires, it just hands off with evidence instead of blocking on a prompt. Use when: "s
ticket-intake
Read a Jira issue whole — description, acceptance criteria, every comment, subtasks, links, labels, status and available transitions — and turn it into a brief plus a numbered requirements list the rest of the loop is accountable to. Reconciles comments against the description chronologically, so a comment that changed the scope wins and the superseded requirement is shown struck through rather than silently dropped. Every requirement carries a verbatim quote and its source; every piece of ticket text that produced no requirement is listed in a mandatory residue block, because a requirement that was never extracted can never be reported as missing. Strictly read-only against Jira: it never comments, never transitions, never edits. Jira access is the Atlassian MCP server or nothing — if the tools aren't bound it stops with the setup command rather than guessing what the ticket said. Use when: starting work from a Jira ticket, "what does PROJ-123 actually ask for", auditing an MR against its ticket, or as Stage
ticket-report
Close the loop on a Jira ticket: post exactly one comment saying what was planned, what was built per requirement with evidence, and — the section that matters — what the ticket asked for that was NOT built and why; then move the ticket to the status the evidence supports. Partial coverage never lands in Done, ever: a ticket marked Done with unbuilt requirements removes the one signal a human needs. Transitions are discovered from the live workflow rather than assumed, rejected when they need fields nobody can legitimately fill, and skipped silently when the issue is already there. Both writes are idempotent — a resumed or re-run loop reports "already reported" instead of spamming the ticket. Runs in audit mode against an MR it didn't build, evidencing each requirement against the real diff. Use when: a ticket's MR has merged, "update the Jira ticket", closing out PROJ-123, or as the final stage of /ship-feature PROJ-123.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.