farzanmrz

User-invoked pass that re-derives a project's Claude-native instruction layout — a surface AGENTS.md plus path-scoped .claude/rules/ — as a projection of the installed skill set and the actual codebase. Enumerates every available skill, maps which applies to which path (wiring unwired-but-needed ones, dropping inapplicable ones), grounds every claim against the code, discloses only non-code-recoverable info per path, and drops the inert references/ layer. Read-only toward user-owned notes (roadmaps, scratchpads) — it reports promotion candidates, never rewrites them. Invoke as /meta-dev:revise-agents-md.

Bootstrap a project's instruction files from scratch — a surface AGENTS.md plus path-scoped .claude/rules/ derived from the installed skills and the actual code. Use when the user asks to set up CLAUDE.md/AGENTS.md, bootstrap instruction files or project memory, or initialize the layout for a repo that has none. Not for editing an existing layout's content (update-instructions), tightening one already in place (improve-instructions), or re-deriving the whole layout of a repo that already has one (revise-agents-md).

Raise the quality of a project's instruction files (CLAUDE.md, AGENTS.md, references) WITHOUT changing what they commit to. Use when the user asks to clean up, debloat, or tighten CLAUDE.md or AGENTS.md, audit instruction files, or says their constitution is bloated, messy, or hard to read. Fact or guard changes belong to update-instructions; first-time bootstrap belongs to setup-instructions.

Raise an existing skill's quality against a measurable criterion WITHOUT changing its intended behavior. Use when the user asks to debloat, tighten, shorten, or clean up a skill, fix its formatting or wording, rewrite a description already diagnosed as under-triggering (diagnosing why belongs to review-skill), or run the automated description-optimization loop. Behavior changes belong to update-skill; skills over their size budget belong to restructure-skill.

Reorganize skill architecture — split one skill into several, merge overlapping skills, or move content between SKILL.md, references, and scripts. Use when a skill exceeds its size budgets, when skills overlap or their descriptions collide, when content sits at the wrong loading level, or when the user asks to split, merge, rename, or reorganize skills. Content edits within one healthy skill belong to update-skill or improve-skill.

Read-only audit of a project's instruction files (AGENTS.md, CLAUDE.md, .claude/rules) — never edits them. Use to review, check, audit, or diagnose instruction files, verify every documented claim against the actual codebase, find stale or wrong facts, spot cross-file contradictions or bloat, or get a quality report before deciding what to change. Not for applying fixes (update-instructions / improve-instructions) or first-time bootstrap (setup-instructions).

Entry point and router for ALL work on Agent Skills. Use whenever the user wants anything done to a skill — make, build, edit, extend, tighten, reorganize, audit, or remove one — especially when the operation is unclear, mixed, or spans several, or when the user invokes skill-creation by name.

Change a project's instruction-file content — AGENTS.md, CLAUDE.md, and .claude/rules/ — and re-scope a rule when its area outgrows it. Use for "add/change X in AGENTS.md", "update a rule's skills or facts", "the stack table is out of date", "split the app rule". Not for quality-only cleanup with unchanged facts (improve-instructions), a fresh repo with no layout yet (setup-instructions), or a full re-derivation of the whole layout (revise-agents-md).

Explicitly invoked deterministic status report for the Oparax outreach record store. Never invoke implicitly.

Explicitly invoked Oparax workflow for logging X-contacted reporters into the fixed LeanSpark experiment. Never invoke implicitly.

Explicitly invoked Oparax workflow for checking new queued X accounts once to determine whether they can receive DMs. Never invoke implicitly and never use for unavailable-account rechecks.

Explicitly invoked Oparax workflow for sending already-prepared X DMs sequentially until the queue ends or X refuses a send. Never invoke implicitly.

Explicitly invoked Oparax workflow for rechecking every previously unavailable X account and resolving it as available or invalid. Never invoke implicitly and never use for new-contact checks.

Phase 2 of the feature flow, standalone: implement the approved plan from the ft/N issue (or a directly-stated small build) with parallel implementers, a fast per-task typecheck gate, and deep review reserved for the foundational task. Use when the user says /feature-build, "build the plan", "implement the tasks", or "just build X" mid-flight on a feature branch.

The end-to-end feature flow: plan → build → QC → triage+ship, run as one guided sequence. Use when the user wants a full slice built from idea to shipped commit. For a single phase, use the granular skills directly: /feature-plan, /feature-build, /feature-qc, /feature-ship (or /simplify, /code-review, /feature-lint for individual QC passes).

Phase 1 of the feature flow, standalone: the plan gate (the plan is the spec). Use when the user says /feature-plan, "plan this feature", "spec this out", or wants a plan gate without committing to the full flow. Not for building — that is /feature-build.

Resolve residual Biome lint findings on a feature branch's changed files — the rules `biome check --write` can't safely auto-fix. Invoked by /feature-qc as its final pass; also runnable standalone on a branch (/feature-lint). NOT for a one-off lint of a single file — run `pnpm lint:fix` directly for that.

Phase 1 of the feature flow, standalone: the plan gate (the plan is the spec). Use when the user says /feature-plan, "plan this feature", "spec this out", or wants a plan gate without committing to the full flow. Not for building — that is /feature-build.

Phase 3 of the feature flow, standalone: the full QC battery over the current feature branch. Use when the user says /feature-qc, "run QC", "quality pass", or wants the branch proven buildable+bootable mid-flight. For just one pass, use /simplify, /code-review, or /feature-lint directly instead.

Phases 4–5 of the feature flow, standalone: the triage + ship gates. Use when the user says /feature-ship, "ship it", "close the slice", or brings manual-test findings on a finished branch.

The end-to-end feature flow: plan → build → QC → triage+ship, run as one guided sequence. Use when the user wants a full slice built from idea to shipped commit. For a single phase, use the granular skills directly: /feature-plan, /feature-build, /feature-qc, /feature-ship (or /simplify, /code-review, /feature-lint for individual QC passes).

Phase 2 of the feature flow, standalone: implement the approved plan from the ft/N issue (or a directly-stated small build) with parallel implementers, a fast per-task typecheck gate, and deep review reserved for the foundational task. Use when the user says /feature-build, "build the plan", "implement the tasks", or "just build X" mid-flight on a feature branch.