smorinlabs

Resolve a repo name to its local path(s) and identity facts — origin, default branch, checkout-vs-worktree kind, branch, dirty state, build tooling — with one fast config-bounded command instead of exploring the filesystem. Fire whenever a repo is referenced by bare name and its location isn't already established in this session — BEFORE running ls/find/glob over home or code directories to locate a repo, BEFORE gh repo view/list to identify an origin or enumerate org repos, and for "where is <repo>", "what repos do I have", "which org owns X", "is this a worktree", "what's the exact name to clone". Covers local multi-root scan plus a gh REST-first remote org fallback from user config. Not for searching file contents inside an already-located repo, and not for cloning or mutating anything — it only finds and describes.

Drive an open GitHub PR to merge by resolving every review thread. Waits (bounded) for AI reviewer bots (Claude, Codex, Greptile, Copilot) to comment, then triages each thread — validate the claim, verify by running code where possible, fix valid findings and push, refute invalid ones with a reasoned reply — every thread resolved either way. Cycles as fixes trigger new reviews, checks the PR title against repo conventions (CLAUDE.md, else Conventional Commits), then ends per mode: --auto (merge, no questions), --confirm (final gate; default), --ready (prep only); --deep adds an opt-in deep review. Quota-safe polling throughout (rate-limit preflight, 20s+ floor, bounded monitors). Use when the user says "merge this PR", "get PR #N merged", "resolve the PR comments", "address review feedback and merge", "close out this PR", "babysit the PR". Never closes a PR without merging; does not write the initial review (/code-review does) or fix failing CI (that is ci-audit).

Render actions only the READER can or will perform as a delineated, self-contained task block — a bounded frame (rail + rules) carrying what it completes, steps numbered with a stable tag, grouped by surface (terminal, browser, desktop/system UI, phone, physical world), each step titled by its outcome with the literal command or UI path below it and a ✓ verification line, closing with the immediate next move. Scales down to one line for a single step and up with a map and stop points for long sequences; re-renders in-flight processes across turns as a scoreboard; states errors as cause and fix. Fire on request — "format the manual steps", "what do I need to do by hand", "what's left for me" — and when composing any handoff with agent-impossible actions, manual verification, or work the user claimed. Decisions are not steps — anything needing the user's judgment is asked (question-walkthrough) before instructing. Canonical spec behind an always-on digest kept in global instructions.

Walk a pile of open questions or undecided to-dos one at a time via the AskUserQuestion tool — smartest question first, just-enough context per item, and after EVERY answer re-evaluate the remaining pile (drop what became moot, reorder what changed, surface implied follow-ups). Sources it handles — mine open questions from the current conversation, read them from a document the user points at (PRD, design doc, notes), take a list given inline, or pull undecided items from task systems (tasks, PROJECTS.md). Decisions are recorded back at their source. Use when the user says "go through these one by one", "walk me through the open questions", "there's a bunch of to-dos, help me decide", "triage these decisions with me", or a doc/plan is blocked on several unanswered questions. Not for scoping a project idea (project-refine), not for batch shareable decision pages (html-codesign — offer it if they'd rather review async), and context style defers to the explain skill's anatomy.

Bootstraps the project-harness bundle by establishing its five skills, running a four-step idempotent setup on first use per repo, and routing project-state edits through the right sibling skill.

Explain anything in a concrete-anchored style — succinct, just-enough context, always grounded in a real example. Use when the user invokes /explain, or asks in their own words: "explain X", "give me a before and after", "add more context on <finding/step/option>", "show examples of the options so I can decide", "what does this change get us", "what's the bigger picture here", "give me step by step instructions". A bare "explain" right after an explanation means "not enough to act on yet": diagnose the gap (bigger picture, clearer language, or a sharper example) and usually rewrite, not append; an argument steers the focus; a dissimilar target restarts fresh. Modes (inferred from the target; explicit argument wins): default, options (example per option + recommendation), deeper, steps (operator instructions). Not for manual testing steps (manual-test-guide) or whole-session recaps.

Whenever the user asks Claude to generate or restyle HTML — a page, artifact, mockup, dashboard, doc, status page, landing page, release-notes page, HTML email, or styled snippet — offer a small catalog of visual themes and apply the chosen one to all subsequent HTML in the session. v1 catalog: birchline (warm editorial), technical-minimal (docs-site neutral), high-contrast-dark (dashboard/terminal). Each theme is a self-contained folder of tokens, components, anti-patterns, and a worked example; only the chosen theme's files are read (progressive disclosure). The choice persists in session memory and can be saved per-project to `.claude/use-html-theme.local.md`. Overrides via natural language and `[theme: <name>]` / `[notheme]` inline flags; ask to preview or compare the themes to get a side-by-side catalog page. Do NOT activate for markdown, JSON, prose, or non-HTML code, or when the user said `[notheme]` or asked for no theme.

Build an interactive "codesign" decision page as a single self-contained HTML file: the reader toggles choices (pick-one or pick-any sections), adds notes, and exports the decision as Markdown and JSON with stable IDs (sec-01, ch-01-a) so picks can be quoted in chat and iterated — "keep ch-01-a, swap ch-02-b" yields a diffable v2. Use whenever the user wants to choose between options and capture the decision: design directions, plan A vs plan B, prioritization passes, "pick from these" reviews, option pages a stakeholder reviews async and sends back. Trigger phrases: codesign, co-design, decision page, pick from these, which should we, compare the options, choose and export, design directions, prioritize these. Pairs with use-html-theme — the active theme styles the page; without one it falls back to a built-in neutral style. NOT for signing macOS/iOS apps or binaries (Apple's codesign tool).

Operate the Doxa Research CLI for approved research execution. Use only when the user explicitly says "use Doxa" or "Doxa Research", asks to run, resume, check, or cancel a Doxa job, or an established plan has already selected Doxa to execute `.prompt.md` files. Handles preflight, provider/mode selection, paid-run confirmation, background monitoring, and output/provenance capture. Do not trigger for generic deep-research or research-planning requests; guided-research owns framing and lineage, while this skill owns Doxa execution.

Process a known bug ID from a structured bug review into a revalidated fix plan and implementation path, including fix-worthiness, multiple-choice user decisions, architectural/common-pattern analysis, consistency and naming review, TDD regression tests, maintainability improvements, verification, tracker updates, and commit reporting. Use when Codex is given a specific bug ID and asked whether or how to fix it, or asked to proceed from a reviewed bug into a fix.

Structured multi-method process for reviewing code changes for bugs and maintainability risks, including test-suite evaluation, feature-specific probes, design-doc scope review, precise bug scope language, wrapper-aware validation, candidate validation with evidence, contract conflict handling, one-by-one user approval, regression tests, verified fixes, and bug-to-commit reporting. Use when Codex is asked to check for bugs, review recent work, review a component or project scope, validate suspected defects, or proceed from a bug review into fixes.

Use when bootstrapping a new Python repo, project, CLI, package, script, or uv project from py-launch-blueprint. Ask whether the user wants the opinionated template bootstrap or a minimal setup before running commands.

Guide for using uv, the Python package and project manager. Use this when working with Python projects, scripts, packages, or tools.

Run template-press against a target repo — dry-run preview, identity validation, apply, verify, receipt. Use when the user says "press <repo>", "rebrand <repo> with template-press", "run the press on <path>", or "point template-press at <target>".

Run the R1/R2/R3 rebrand acceptance matrix to answer "did we break the press?". Use when the user asks to "run the matrix", "verify the press still works", "run the rebrand acceptance tests", or after any change to src/template_press/rebrand/.

Apply the org's CLI Design Standard (cli-design-standard.md in this repo) to any CLI work, scaled by tier (minimal / standard / publishable) and feature applicability. Four modes — plan (greenfield interview → noun-verb vs small-CLI profile, tier, interface spec), check (mid-build lookups — "what exit code / flag / config path does the standard say"), review (design review of a CLI spec or plan; findings cite rule IDs), audit (conformance sweep of an existing CLI with live execution checks; emits findings, a CONFORMANCE.md waiver note, optional CI fixtures). Fires whenever a CLI is being created, designed, extended, reviewed, or audited — "new CLI", "build a CLI", "add a subcommand", "review this CLI design", "is this CLI conformant", "audit this CLI", "CLI standards". Not for generic non-CLI architecture review (factor-architect), generic quality sweeps (factor-scan), external CLI-practice research (guided-research), or package-name availability (claim-package-name-skill).

Pointer to difftree's install/setup skill, which lives in the companion difftree-action repo. Fires when someone in the difftree repo says "install difftree", "set up difftree", "add difftree to my CI", "add PR diff-tree comments", or "set up difftree-action". It does not install or configure anything itself — it routes to the canonical difftree-action-setup skill at github.com/smorinlabs/difftree-action (which installs the CLI and scaffolds the PR workflow) and points at this repo's README for a plain local `cargo install difftree`.

Install the difftree CLI and/or add difftree PR diff-tree comments to a repository. Use when the user says "install difftree", "set up difftree", "add difftree to my repo", "add PR diff-tree comments", "set up difftree-action", or wants difftree running locally or in CI. Installs the difftree CLI (prebuilt binary, `cargo install difftree`, or from source) and scaffolds a `.github/workflows/pr-diff-tree.yml` that runs smorinlabs/difftree-action from this repo's canonical examples/pr-diff-tree.yml, then commits or opens a PR. This is the difftree-action repo's own setup skill; the difftree CLI repo ships a lightweight pointer to it.

Use this skill WHENEVER the user wants to create a new repo, project, package, CLI, script, or UV project that involves Python. Trigger on phrasings that include the word "repo" (e.g., "create a Python repo", "make a new repo for this CLI", "spin up a fresh python repo", "new GitHub repo for a Python tool"), the word "project" (e.g., "create a new Python project", "start a fresh Python project"), or the words "CLI" / "package" / "script" (e.g., "create a Python CLI", "scaffold a Python package"). This skill is the project's bootstrap workflow — it uses `gh repo create --template` against py-launch-blueprint, then the init rebrand (`init/init.py`), then prompts about post-init. The skill ASKS THE USER FIRST whether they want this opinionated bootstrap or prefer a minimal setup, so it's safe to over-trigger — if the user declines, the skill exits cleanly. ALWAYS prefer this skill over running `gh repo create` or `uv init` manually for ANY Python repo/project creation intent. Common triggers: "create a new Pytho