Spec-driven delivery pipeline: grill a topic into ratified decisions, write and validate a spec against it, split the spec into dependency-ordered tasks, then implement them in isolated worktrees with batched validation.
5 skills · 2 commands · 3 agents
Unified code review that fans out parallel scanners over a change — one per active lens, up to eleven per run — and merges them into one per-file report. Eleven lenses: comment quality, four quality/craft lenses (readability & tests, naming & module, objects & patterns, simplicity & types), an always-on correctness lens (wrong conditions, unhandled cases, off-by-one, swallowed errors, races, broken call contracts), an always-on narrow security lens (secrets, injection, access checks, boundary validation, insecure settings, IaC exposure, access widening, plus access policies and CI workflows), an always-on coherence lens (docs, contracts, migrations, config and sibling listings that disagree with the code or each other, code breaking a rule an accepted ADR or CONTEXT.md states), an always-on assumptions lens (code relying on library, runtime, CI or platform behaviour the installed source or the locked version contradicts, test doubles the real dependency would not match), a performance lens for executable source (N+1, unbounded fetch, blocking-in-async, wasted renders, missing indexes), and a spec lens via --spec <path> or a spec file the diff carries. Explicit rules in a root CODING_STANDARDS.md (plus a gitignored .local.md overlay) generate standards findings. The standalone comment-review and quality-review skills stay invocable for a single-lens pass. Reviews the current branch diff by default (or explicit paths / --base, or a GitHub PR with --pr). Quality findings are tagged family · rule · severity; comment verdicts are R1–R12 · KEEP/REMOVE/REWRITE/MOVE/ADD, shown side by side and applied through a single risk-cut menu. Successor to the comment-review and quality-review plugins.
5 skills · 1 command · 1 agent
Small everyday development skills: diagnose and fix failed CI pipelines, shepherd a pull request until CI is green and review is resolved, check a dependency upgrade against the codebase, and push a branch as a pull request filled from the repository's template and labelled with its risk, assessed by TypeSafe Jev, Gemini Decision or both.
4 skills
Deprecated — use fd3. End-to-end feature delivery: requirements gathering, editing, status tracking, and implementation orchestration with parallel subagents
4 commands
Proof that a pull request's change works: prepare-proof judges which proof a branch needs, with signals from TypeSafe Jev or Gemini Decision when a key is set, then produces each kind, a narrated walkthrough video with playwright-recast, screenshots at the project's breakpoints, and masked terminal or API transcripts, and hands it to pr-open through the branch's proof manifest.
4 skills