code-factory

The Delivery Lead persona — owns HOW the team delivers and owns the rituals. Activate when the user has a team call to prepare or run (planning, refinement, standup, retro, review), asks what ritual or process fits, wants iterations or cadence set up, asks "what are we doing on this call", wonders how to get from backlog to built, or when delivery feels stuck or chaotic. A facilitator: it structures conversations where the TEAM supplies the content; it teaches what each ritual is when asked; it never mutates the board without an explicit go.

The Navigator persona — the guide over the whole Code Factory. Activate FIRST on any big or multi-part organizational prompt ("we need to organize this", "here are the repos, set up delivery", a pasted brief plus "where do we start"), when the user asks how to use these skills, what a term or ritual means, what state the work is in, or what the next step is. It reads the board, the repo, and the clock, then answers "here's where you are, here are the possible next moves" — it talks and routes; it NEVER executes work or mutates anything.

The Product Manager persona — owns WHAT gets built and in what order, and owns the board's contents. Activate when the user brings raw work to organize (a brief, a pile of tasks, "we need to sort this out"), asks what to build next, wants the backlog groomed, triaged, or prioritized, needs epics or a roadmap, or mentions tickets piling up. A conversation-first role: it proposes and asks; it never acts on the board without an explicit go.

How and when to query the repo's knowledge graph — find symbols, trace call chains, compute blast radius, map architecture. Use before grep for any structural code question — who calls this, what does X depend on, what breaks if this changes, what's the shape of this codebase.

Configure a repo for Code Factory — issue tracker, triage labels, domain docs, the company GitHub Project board, and the codebase-memory index. Run once per repo before any other Code Factory skill.

Establish what the team can actually take on — measured pace minus known absences and interrupt load, per person WIP checked, the number planning is allowed to spend.

Sweep the active work for dependencies and risks — blocking chains mapped, single points of failure named, each real risk given an owner and a trigger, theatre avoided.

Size a set of tickets — relative sizing against reference items the team has actually shipped, disagreement surfaced before numbers converge, epics detected and sent to be split.

Close an iteration facing the stakeholders — demo what shipped against the goal, state what didn't and why, and collect the feedback that reorders the backlog.

Force-rank the backlog with the user — the right framework applied, ties broken, the "not now" list made explicit, the board reordered to match.

Build or update the roadmap — epics on a Now/Next/Later horizon on the board, dated only as far as honesty allows, with the narrative stakeholders can repeat.

Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker — edges as text in one file per ticket locally, or native blocking links on a real tracker.

Operate the company delivery board (GitHub Project) — add items, move status, assign iterations, build epics, query the backlog. Use whenever a skill or agent needs to read or write the board, or the user mentions the board, backlog, epics, or iterations.

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

Whole-repo audit for over-engineering. Like lazy-review, but scans the entire codebase instead of a diff: a ranked list of what to delete, simplify, or replace with stdlib/native equivalents. Use when the user says "audit this codebase", "audit for over-engineering", "what can I delete from this repo", "find bloat", "lazy-audit", or "/lazy-audit". One-shot report, does not apply fixes.

Harvest every `lazy:` comment in the codebase into a debt ledger, so the deliberate shortcuts and deferrals lazy leaves behind get tracked instead of rotting into "later means never". Use when the user says "lazy debt", "/lazy-debt", "what did lazy defer", "list the shortcuts", "lazy ledger", or "what did we mark to do later". One-shot report, changes nothing.

Show lazy's measured impact as a compact scoreboard: less code, less cost, more speed, from the benchmark medians. One-shot display, not a persistent mode, and not a per-repo number. Trigger: /lazy-gain, "lazy gain", "what does lazy save", "show lazy impact", "lazy scoreboard".

Quick-reference card for all lazy modes, skills, and commands. One-shot display, not a persistent mode. Trigger: /lazy-help, "lazy help", "what lazy commands", "how do I use lazy".

Code review focused exclusively on over-engineering. Finds what to delete: reinvented standard library, unneeded dependencies, speculative abstractions, dead flexibility. One line per finding: location, what to cut, what replaces it. Use when the user says "review for over-engineering", "what can we delete", "is this over-engineered", "simplify review", or invokes /lazy-review. Complements correctness-focused review, this one only hunts complexity.

Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY coding task: writing, adding, refactoring, fixing, reviewing, or designing code, and choosing libraries or dependencies. Also use whenever the user says "lazy", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT use for non-coding requests (general knowledge, prose, translation, summaries, recipes).

Open an iteration — set the goal, pull prioritized work in against capacity, and leave the board reflecting the plan.

Groom the top of the backlog until enough items are Ready — labelled, sized, unblocked, epic-assigned, and implementable without a follow-up question.

Run a retrospective — review last time's actions, gather what went well/badly from data and the team, and leave 1–3 owned, dated improvement actions.

The full Code Factory review — deterministic pre-pass (fallow + codebase-memory blast radius), toggleable dimension sub-agents (Standards, Spec, Correctness, Tests, Laziness, Boundaries), a graded verdict against review.schema.json, and optional auto-fix. Use for reviewing a branch, PR, or diff with the rig; for a quick two-axis pass use code-review instead.

Read the board and report the day's truth — what moved, what's in flight, what's blocked — in one screen.

Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.

Move issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.

Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.