ulpi-io

Propagate ONE validated learning about SKILL design or quality from this session into the central skill-learnings file — extract the smallest useful pattern or anti-pattern, categorize it (Structural Patterns / Content Patterns / Anti-Patterns / Skill-Specific), and add it once without touching any actual skill file. User-only maintenance workflow that mutates durable skill-authoring guidance: it grounds the rule in what THIS session revealed, never invents, checks for duplicates, and confirms category and wording before writing. Use to capture a skill-authoring rule so future skill work inherits it.

Propagate ONE validated learning about Claude Code behavior from this session into the project's CLAUDE.md — the MAIN-AGENT memory Claude loads every session, not agent or skill files. Extract the smallest useful workflow/scope/session rule, place it in the correct section (Workflow Rules / Session Management / Scope Control / Behavioral Patterns), and preserve the surrounding structure. User-only maintenance workflow that mutates durable project memory: it grounds the rule in what THIS session revealed, never invents, checks for duplicates, and confirms wording and placement before writing. Use to make a Claude-behavior rule persist into future sessions.

Propagate ONE validated learning from this session into durable AGENT guidance — extract the smallest useful rule, classify its scope (Global / Claude Code Only / Agent-Specific), store it once in the central agent-learnings file, and sync the regenerated `## Learnings` section into every live agent definition across the CLI trees present. User-only maintenance workflow that mutates durable agent prompts: it grounds the rule in what THIS session actually revealed, never invents, confirms scope and wording first, and keeps "Claude Code Only" learnings out of subagent prompts. Use to record an agent-behavior rule so future agents inherit it.

Route the start of substantive work to the right execution path — a lightweight INTERNAL intake pass, not a user-facing command and not a universal constitution. Answers four questions fast: does a more specific skill own this, is specialized agent delegation warranted, what is the minimum context needed to avoid a blind edit, and does the work need DAG planning or can it proceed directly — then states the chosen path in one concise update. Invokes the matching skill instead of merely naming it, gathers only the minimum context (no full capability inventory unless asked), and hands real planning to `plan-to-task-list-with-dag` rather than becoming a planner itself. Use internally at task start when no more specific skill has already matched.

Take one feature request from prompt to reviewed, audited delivery in a SINGLE autonomous pass — one runnable Workflow that plans, reviews the plan, builds task by task, cross-reviews the build, and optionally runs a launch audit, then RETURNS the verified findings rather than looping (the user decides any fix round; a Workflow can't ask mid-run, and an autonomous fix-loop is what caused multi-hour grinds). It chains the existing skills — plan-to-task-list-with-dag (a specialist agent per task) → plan-founder-review → a specialist engineer/reviewer build across the DAG → a full claude ∥ codex/kiro cross-review → go-live-audit — and FOLLOWS the graph strictly: every task declares its dependencies, layers must be a topological order, plan review blocks a mis-ordered graph, and a task NEVER builds before its dependencies integrate (no building on a broken base). Per-task review is SLICE-SCOPED (judges only that task's own change against its acceptance criteria, attributing whole-codebase end-state gaps to the task that owns them) so the build isn't drowned in false blocks, and impl review is the end-state gate. Gates FAIL CLOSED — a reviewer that didn't actually run is never counted clean, and a died codex/kiro reviewer falls back to a native review, never a fabricated block. Durable and resumable: each run writes a live status file (overall + per-phase + per-task) with a journal reader for status/stop/resume, and resume rebuilds integration state from GIT ground truth so an interrupted run never loses or re-loses already-landed tasks. Code writing and each review independently pick native / codex / kiro (reviews can skip; writer and reviewer can differ), so the user controls quality vs token cost.

Manage local service credentials WITHOUT ever exposing their values — the `secrets` CLI adds, rotates, lists, enables, disables, and inspects encrypted integrations (including MCP/agent tooling) through interactive entry, reporting only service names and enablement status. Hard invariant: secret material never enters arguments, logs, or output and `--reveal` is never used — the reporting surface is the service, not the value. Use only on explicit request to wire or inspect credentials.

Write and change Rust the way THIS workspace already does it, NOT by generic defaults — a systems-programming reference carrying the real crate boundaries, error model, and conventions for storage engines, binary formats, Arrow/DataFusion, search and vector indexing, async concurrency, testing, and unsafe discipline, so a change lands idiomatic and review-ready instead of merely compiling. Use when a task touches this workspace's Rust crates and should follow its systems-level conventions rather than boilerplate.

Diagnose and fix 3+ genuinely INDEPENDENT failures concurrently on Claude Code's real parallel agent runtime — without splitting one root cause into conflicting investigations. Proves the failures don't share a root cause (same dependency/config/migration/deploy across traces) before launching, matches each lane to the best specialized agent, briefs it with real evidence (failing output, stack traces, test names), launches all lanes in one message with background execution and worktree isolation, then reruns each original failure and conflict-checks the fixes. Refuses to parallelize fewer than 3 lanes or symptoms that may share a cause, consolidates lanes that converge on one root cause instead of claiming independent wins, and reports partial success honestly. Use when the user gives 3+ clearly independent failures to fix in parallel.

Run 3+ genuinely INDEPENDENT build tasks concurrently on Claude Code's real parallel agent runtime — throughput without file conflicts or fake orchestration. Proves independence (disjoint write scope, no dependency edges) before launching, matches each lane to the best specialized agent, writes a complete self-contained brief per fresh agent, launches them all in one message with background execution and worktree isolation, then conflict-checks and reviews each finished lane before treating it as merged. Refuses to parallelize fewer than 3 lanes or lanes that share write scope or dependencies, never assumes fresh agents inherit context, and reports partial success per lane rather than a blurred merged summary. Use when an approved plan or the user gives 3+ independent build lanes.

Deep-audit ONE Rust crate end to end — read every file, don't sample: enumerate and read the whole crate, run its `cargo test`, check the existing `.ulpi/issues/<crate>.md` to avoid duplicates, then write or append evidence-backed findings (correctness, panic, validation, race, data-corruption, coverage gaps) each with severity and exact file:line — runs as a forked analysis workflow with its own reasoning budget, isolated from the main flow. Only valid if it actually read the entire crate; grounds every finding in real file:line evidence, labels uncertain claims INFERENCE, and never invents issues from intuition or writes outside this repository's issue file. Use when the user asks for a deep review of a single Rust crate.

Read a feature branch's merge-readiness from its actual git data — measured metrics, not vibes: collect raw git output for the branch vs base, compute branch-health metrics (size class, test ratio, focus, drift, sessions, hotspots), scan the diff for pre-PR artifacts (secrets, `.only`, conflict markers, debug lines, TODOs), then render a GREEN / YELLOW / RED verdict with per-signal recommendations — runs as a forked analysis workflow with its own reasoning budget, isolated from the main flow. Every metric is derived from concrete git data, never estimated; the verdict follows the documented signal thresholds and never reports GREEN while a blocking finding stands; read-only apart from the optional JSON snapshot, never touching code or git state. Use when the user asks for branch health, pre-PR analysis, or `/pr-retro`.

Turn a request into a SCHEDULABLE task DAG — atomic tasks with real dependencies, not planning prose: challenge scope and pick a planning mode with the user first, explore the real repo so no path is invented, then decompose into atomic TASK-NNN entries — each with a ≤3-file write scope, 2-3 testable acceptance criteria, a slice-scoped validate command, explicit dependencies, and an assigned agent — emitted as one canonical object into matching `.ulpi/plans/<name>.md` and `.json`. Every named path comes from observed repo state, the dependency graph stays acyclic, and JSON is the source of truth the markdown is rendered from — no phantom files, no circular edges, no task that hides side effects it never provisions. Use when the user asks to plan, decompose, or break work into execution-ready tasks.

Gate an implementation plan BEFORE agents execute it — catch phantom paths and false reuse, not typos: read the full plan markdown and its companion JSON, reality-check every file path and reuse claim against the actual repo, challenge scope, architecture, the dependency graph, and risk and test coverage, then score each section and render an APPROVE / REVISE / REJECT verdict — runs as a forked review workflow with its own reasoning budget, isolated from the main execution flow. The verdict follows only from evidence-backed findings: never rubber-stamps a non-trivial plan and never invents findings, but a genuinely clean section is allowed to pass; read-only, never edits the plan. Use when the user asks to review or gate a plan before execution.

Convert a local skill into a Claude Code optimized shape — an AUDIT-then-rewrite that ties every change to real Claude skill-runtime behavior, treating FRONTMATTER as the highest-leverage routing surface. Inventories the skill, checks it against the runtime reference (Claude routes and budgets skills from metadata first), writes a per-skill DAG rewrite plan with source-backed guardrails, and — only when asked — rewrites frontmatter, body, and references for cheaper routing and safer execution. Defaults to PLAN mode, never a blind rewrite, uses skill-native frontmatter only, and preserves structural content (routing tables, guardrail rules) rather than stripping it as bulk. Use to migrate or restructure a SKILL.md for Claude's skill runtime.

Convert a local AGENT.md into a Claude Code optimized agent — an AUDIT-then-rewrite that ties every change to real Claude agent-runtime behavior, not taste. Inventories the agent, checks it against the runtime reference (the whole body becomes the system prompt; role identity stays, procedure moves to skills), writes a per-agent DAG rewrite plan with source-backed guardrails, and — only when asked — rewrites the frontmatter and prompt body thinner and more role-specific. Defaults to PLAN mode, never a blind rewrite, uses agent-native frontmatter only, and grounds each decision in the runtime source rather than inventing conventions. Use to migrate or thin an AGENT.md for Claude's agent runtime.

Write Node.js and Bun backend code the way THIS project already does it, not by generic defaults — a TypeScript-first reference that detects the runtime and carries the real conventions for HTTP servers, Zod boundary validation, typed error handling, pino logging, database access, auth, BullMQ queues, caching, async and graceful-shutdown patterns, security, CLI tooling, testing, and observability, so a change lands idiomatic and review-ready instead of merely running. Use when a task touches this project's Node.js or Bun backend and should follow its conventions rather than generic defaults.

Build or review a Next.js App Router surface against the project's installed framework version and established architecture. Covers pages, layouts, async request APIs, server and browser API clients, authentication, client concurrency, Route Handlers, metadata, i18n, accessibility, machine-readable content, and layered testing. Use when a task touches Next.js and must preserve project-specific decisions such as the resolved framework version, backend session protocol, canonical domain, and locked visual theme.

Build NestJS the way THIS project's module architecture already does it, not by framework defaults — a reference carrying the real module boundaries and dependency-injection discipline behind thin controllers, class-validator DTOs, TypeORM/Prisma data access, guards, interceptors, pipes, exception filters, BullMQ queues, WebSockets, microservices, OpenAPI, and testing, so a change lands idiomatic and review-ready instead of bypassing the framework. Use when a task touches this project's NestJS modules and should follow its DI-driven architecture rather than framework defaults.

Refresh a Cargo WORKSPACE or package monorepo's durable AI context — a self-contained `CLAUDE.md` per member that Claude lazy-loads, plus a thin project-wide root, so a change in any member has local guidance without bloating the root. Discovers each member's real reachable surface, key files, wiring, and inter-member dependencies, then keeps the root project-wide. User-only maintenance workflow that mutates durable memory across many members: it documents the ACTUAL exported/reachable surface (not raw `pub`/`export` counts), grounds every claim in code, and preserves locked root decisions. Use to refresh workspace-local context after refactors, member additions, or export changes.

Refresh a SINGLE app's durable AI context — a thin `CLAUDE.md` router over discovered reference docs so future sessions start knowing the repo without paying for stale guesswork. Detects the framework shape, discovers the real routes, exports, flows, and subsystems from code, rewrites the imported references, then keeps `CLAUDE.md` compact and always-loaded. User-only maintenance workflow that mutates durable project memory: every claim is GROUNDED in the real codebase, never invented, and human-authored rules are preserved rather than overwritten. Use to initialize or refresh one app's context map after meaningful changes.

Put local dev surfaces behind trusted HTTPS `.test` domains — real certs and DNS, not localhost:port — with the `lokei` CLI: framework-aware `run`, public tunnels via `share`/`--expose`, `docker up` and `.test.yaml` multi-service orchestration, and `doctor`/`routes`/`logs` diagnostics, backed by a one-time setup that mints and trusts a local CA and wires `.test` DNS and port forwarding. Never auto-runs setup, service-install, or uninstall — those wait for approval. Use for local HTTPS, named domains, tunnel sharing, or lokei diagnosis.

Prepare and run a product launch on X (formerly Twitter) end to end — the external link goes in a REPLY, not the main tweet, so reach isn't penalized. Grounds in the real product, then writes a paste-ready package to `.ulpi/launch/x/`: `POST.md` (the launch **thread** — a scroll-stopping hook tweet, the thread body, native media, and the product link in a reply), `PLAN.md` (timing, the **golden-hour** engagement runbook, cross-promotion, and the post-launch plan), and `CHECKLIST.md` (a blocking pre-flight gate). The X runner of the launch-* family: it owns X mechanics, format rules, and the gate, and composes the shared `launch-copy` (thread copy), `launch-outreach` (team amplification, mode `x`), and `launch-analytics` (UTM + conversion tracking), degrading to built-in fallbacks if a companion isn't installed. Reads the shared `.ulpi/launch/positioning.md`. Engagement asks to your own audience are fine (no vote-ring rules), but it avoids what X penalizes — a link in the main tweet, engagement-bait, and bought engagement. Use when the user wants an X launch thread written and launch day planned.

Prepare and run a Product Hunt launch end to end — COMPLIANT promotion ONLY: never vote manipulation, rings, bought/incentivized votes, or "please upvote". Grounds every word in the real product, then writes a complete, paste-ready package to `.ulpi/launch/product-hunt/`: `LISTING.md` (every PH field — tagline options ≤ the current limit, description, topics, a gallery shot-list, demo-video outline, the maker's first comment), `PLAN.md` (a T-minus countdown + an hour-by-hour Pacific-time launch-day runbook + the post-launch plan), `OUTREACH.md` (segmented supporter outreach + social posts), and `CHECKLIST.md` (a blocking pre-flight gate). The PH orchestrator of the launch-* family: it owns field specs, policy, and the day-of runbook, and composes the shared `launch-copy` (listing), `launch-outreach` (mode `product-hunt`), and `launch-analytics` (UTM + conversion tracking), degrading to built-in fallbacks if a companion isn't installed. Reads the shared `.ulpi/launch/positioning.md`. Treats Product Hunt as a credibility amplifier, not primary acquisition, and sets realistic expectations. Use when the user wants a full Product Hunt launch prepared and run.

Build and notify a launch's supporter audience with paste-ready, platform-COMPLIANT outreach — the messages you send to PEOPLE, never the on-listing copy. Recruits an audience before launch, segments it (team · friends · users/waitlist · communities · public followers), and notifies it in timed waves on the day. Drafts the teaser DMs, waitlist and launch-day emails, community heads-ups, 1:1 DMs, and X/LinkedIn amplification posts, and writes them to `.ulpi/launch/<channel>/OUTREACH.md`. Parameterized by a per-platform COMPLIANCE MODE the caller passes (Product Hunt: supporter waves allowed, ask for feedback not upvotes; Hacker News: NO vote mobilization at all); grounds every message in `.ulpi/launch/positioning.md` and NEVER solicits/incentivizes votes or mass-spams. Shared audience block of the launch-* family, invoked by the per-platform runners (`launch-product-hunt`, `launch-hacker-news`, `launch-x`, `launch-linkedin`) or run standalone. Use when a launch needs who-to-tell and what-to-say, compliant to each platform's rules.

Prepare and run a product/company launch on LinkedIn end to end — the launch link goes in the FIRST COMMENT, not the post body, and you never edit the post right after publishing. Grounds in the real product, then writes a paste-ready package to `.ulpi/launch/linkedin/`: `POST.md` (the launch **post** — a strong hook in the first ~2 lines before the "…see more" cut, a skimmable body, the reach-earning format, hashtags, and the product link as the **first comment**), `PLAN.md` (timing, the **golden-hour** engagement runbook, team amplification, and the post-launch plan), and `CHECKLIST.md` (a blocking pre-flight gate). The LinkedIn runner of the launch-* family: it owns LinkedIn mechanics, format rules, and the gate, and composes the shared `launch-copy` (post copy), `launch-outreach` (team amplification, mode `linkedin`), and `launch-analytics` (UTM + conversion tracking), degrading to built-in fallbacks if a companion isn't installed. Reads the shared `.ulpi/launch/positioning.md`. Engagement asks to your network and team are fine (no vote-ring rules), but it avoids what LinkedIn penalizes — a link-preview card in the body, engagement-bait, pods, and an early edit. Use when the user wants a LinkedIn launch post written and launch day planned.

Prepare and run a Hacker News "Show HN" launch end to end — HN is STRICTER than every other channel: it **forbids all vote mobilization** (no supporter waves, no asking anyone to upvote, ever). Grounds in the real product (real stack, honest limits), then writes a small, paste-ready package to `.ulpi/launch/hacker-news/`: `POST.md` (the standard `Show HN: <thing> – <plain description>` title + the URL + the founder's technical, no-hype first comment), `PLAN.md` (US-Eastern timing, the first-1–2-hours plan, a thread-engagement plan with prepared answers to hard questions, and the post-launch / second-chance plan), and `CHECKLIST.md` (a blocking readiness gate). The HN runner of the launch-* family: it owns Show HN rules, HN policy, the thread runbook, and the gate, and composes the shared `launch-copy` (title + first comment) and `launch-analytics` (UTM + conversion tracking), degrading to built-in fallbacks if a companion isn't installed. Rewards technical honesty and a present, non-defensive founder; punishes hype and signup-walled products. Use when the user wants to post a Show HN or plan an HN launch.

Draft the copy a launch needs, in multiple angles, all bound to the REAL product — never generic placeholders. Produces taglines/headlines, one-liners, short and long descriptions, and the launch post / first comment in feature-led, benefit-led, comparison, and audience-led versions with one recommended each. Reads and reuses `.ulpi/launch/positioning.md` (the platform-agnostic product brief) so the product is described once and reused everywhere; grounds via the `browse` skill + repo when it's absent. Honors the caller's **asset profile** — hard character limits, voice, and compliance rules — to the letter. Shared copy block of the launch-* family, feeding the per-platform runners' posts (`launch-product-hunt` listing, `launch-hacker-news` Show HN, `launch-x` / `launch-linkedin` threads) or run standalone; writes to `.ulpi/launch/<channel>/copy.md` or hands drafts back. Use when a launch needs on-brand, within-limit copy grounded in one real product.

Instrument a launch so the traffic spike is ATTRIBUTABLE, not a vanity number — one consistent UTM scheme on every launch link, the conversion funnel (visit → signup → activation) wired into GA4 or the project's existing analytics, and a validate + read-out step. Writes the UTM map + event plan to `.ulpi/launch/<channel>/analytics.md`, parameterized by launch source (e.g. producthunt, hackernews) so each link and report is correctly attributed. Shared measurement block of the launch-* family — invoked by the per-platform runners (`launch-product-hunt`, `launch-hacker-news`, `launch-x`, `launch-linkedin`) to close the loop, or run standalone. Measures durable outcomes (signups, activation), extends the real stack, and NEVER puts PII in links or events. Use when a launch needs UTMs on every link and signup tracking, not just an upvote count.

Build Filament admin panels on the v5 API surface THIS project targets, not deprecated v3 patterns — a reference carrying the current namespaces and conventions for Resources, forms, tables, actions, filters, relation managers, widgets, infolists, panels, and testing, with business logic kept in application Actions, so a change lands idiomatic and review-ready instead of tripping over renamed APIs. Use when a task touches this project's Filament admin panels and should target the v5 surface rather than deprecated patterns.

Write and change Laravel the way THIS project already does it, with Laravel 13 as the recommended baseline for new applications and explicit compatibility handling for existing versions. Carries the real controller/Action/Resource boundaries and conventions for thin controllers, Form Request validation, strict Eloquent, API Resources, Horizon queues, caching, auth, observability, and the Laravel AI/Boost/MCP stack. Use when a task touches this project's Laravel code and should follow its backend conventions rather than generic or outdated framework defaults.

Get an INDEPENDENT second opinion from the Kiro CLI run strictly READ-ONLY — a separate reviewer runtime over the real diff, with no write access to the repo. Reads the real diff (branch, a commit, or uncommitted) to build a focused prompt, optionally injects the stack's convention skills (`--skill`, since kiro can't load them itself), then launches kiro via the bundled helper with trust scoped to `fs_read,execute_bash` so it can grep/git to verify findings but never edit. Never uses `--trust-all-tools` (the auto-mode classifier dead-ends read-only tasks on it) or hand-rolls the prompt through the shell; keeps secrets out, treats findings as candidates to verify, and reports an explicit clean result. Use only on explicit user intent or when a user-invoked workflow composes it as the kiro reviewer.

Delegate an implementation task to the Kiro CLI and report exactly what it changed — verified against a git baseline, never on kiro's SELF-REPORT. Gathers the context a fresh agent needs, rephrases the request into a self-contained, injection-safe prompt with XML boundary tags, injects the task's kiro convention skills (`--skill`), launches kiro via the bundled helper with trust scoped to the mode (`implement` = least-privilege write, `review` = read-only), then diffs the working tree against a pre-run baseline. Never auto-installs kiro or pipes a remote installer to a shell, never passes raw user input through the shell or defaults to `--trust-all-tools`, and reports partial completion and errors honestly rather than trusting kiro's own summary. Use only when the user explicitly asks to delegate implementation to kiro.

Author and run a project-TAILORED pre-launch audit as a bounded multi-agent workflow — a real launch verdict, not a checklist skim: fill the bundled workflow template from the repo's real stack and hard rules, then run Gates (typecheck / test / lint / build in parallel) → Find (one read-only finder per applicable audit dimension) → Dedup (merge shared-root-cause findings) → Verify (adversarial agents try to refute every finding; blockers get a code lens plus a spec lens) → Critic (name uncovered areas, spawn follow-up finders) → a GO / NO-GO / GO-WITH-FIXES report, all fanned out under a MAX_PARALLEL cap. Finders and verifiers stay read-only — the skill audits and reports, never fixes; a gate that didn't actually run is treated as a blocker, never counted clean; secret values are redacted to type and location. Confirms scope and warns about the agent count (typically 40-80) before running.

Run merges and conflict resolution inside a dedicated git worktree so the MAIN tree is never touched — isolation is the whole point. Lists existing worktrees and current context first, creates or reuses the right isolated workspace, tags a backup and performs the merge/rebase/ cherry-pick there, validates the result, then closes the lifecycle with `git worktree remove` + `prune` and verifies the main tree stayed clean. Uses `git worktree remove` (never `rm -rf`) for normal cleanup, never auto-deletes non-ephemeral branches, and requires explicit confirmation before force-removing a dirty worktree. Use only when the user explicitly wants merge work done in an isolated worktree.

Run a git merge, PR merge, conflict resolution, or rollback safely — readiness-checked and BACKED UP before anything touches shared history. Assesses branch/CI/review state and conflict risk, tags a backup point before non-trivial merges, resolves conflicts without dropping either side (regenerating lockfiles, not hand-editing), validates the result, then cleans up or rolls back — routing to the worktree specialist when isolated execution is safer. Never claims success with unresolved conflicts or failing validation, prefers `git revert` over `reset` on shared branches, and requires explicit confirmation before destructive rollback, force-push, or branch deletion. Use only when the user explicitly asks to merge, resolve conflicts, or roll back.

Produce a distinctive, LOCKED design language plus an implementation-ready UX/UI spec, written to `.ulpi/design/`: a per-brief visual identity (palette, type, signature), the design system to build on, user flows and states, component briefs, and accessibility constraints. Commits to a bold aesthetic direction, bans AI-slop by name, and locks the identity so every screen and future session stays consistent. Can visit inspiration links with the browse skill to extract real design DNA. Ends with a build handoff that a delegated engineering agent implements — a DESIGN-SPEC skill that produces the spec, never production UI code. Use for new features, redesigns, or design-system work where the build should follow a locked spec.

Hunt REAL bugs and security holes in the current branch diff — verified, not a raw model dump: map each changed file's attack and defect surface, run the security-and-logic checklist against it, then verify every candidate against surrounding code, callers, and existing mitigations — runs as a forked review workflow with its own reasoning budget, isolated from the main flow. Reports only findings that survive the false-positive check, severity-ranked with file:line evidence and a fix direction, and states an explicit clean result when nothing real is found; stays read-only and never edits code. Use when the user asks to find bugs, review changes, or audit branch risk.

Discover, install, and manage AI agents across 43+ coding CLIs and IDEs from ONE source — auto-translated to each client's native format, not hand-ported — with the `agentshq` CLI: `find`, `add`, `list`, `remove`, `check`/`update`, and `init` scaffolding, scoped by `-g` (global) and `--ide` targets. Explicit-user-only and precise: it never installs, removes, or updates agents the user didn't ask for. Use to find agents or manage an existing agent catalog.

Write and change container infrastructure the way THIS project already builds and ships it, not by generic defaults — a Docker reference carrying the real conventions for Dockerfiles, multi-stage builds, Compose services, networking, volumes, health checks, registries, BuildKit, security hardening, CI/CD integration, and debugging. Holds the invariants that keep images small and safe: multi-stage builds, non-root runtime, pinned base images, no baked secrets, a mandatory .dockerignore, and frozen lockfiles — so an image lands small, secure, reproducible, and review-ready instead of merely building. Use when a task touches container configuration, images, or deployment infrastructure.

Move a bulky inline test block out of its source file WITHOUT weakening it — same coverage, same private access: read the source and its inline tests, pick the smallest safe extraction boundary (an adjacent `#[cfg(test)] mod`, not a top-level `tests/`, when private access matters), move tests and their helpers with names and attributes intact plus the minimal module wiring, then run the narrowest relevant tests. Preserves the original visibility model and touches production code only as far as wiring requires — never silently downgrades private unit tests into weaker public-API integration tests. Use when the user asks to split large inline tests out of a source file.

Open a GitHub pull request that matches what the branch ACTUALLY changed — validated against the real base, not the branch name or an optimistic summary. Reads the full diff against the true base branch, blocks on protected-branch/empty-branch/conflict-marker states, invokes `commit` first if the tree is dirty, classifies type/scope/breaking-changes from the diff, runs the narrowest relevant checks, pushes the branch, then creates the PR with `gh` and verifies its number, URL, and state. Never fabricates passing test status or an absent breaking change, and never creates the PR before the branch is on remote; falls back to a prepared title/body/compare URL if `gh` is missing. Use only when the user explicitly asks to open or create a PR.

Estimate what a codebase, branch diff, or single commit would COST to build — evidence-driven, not a guess: measure the real scope with the helper scripts (LOC counter + git session analyzer), classify every source line into one productivity bucket, run the cost calculator for engineering hours, organizational overhead, calendar and team-cost views plus Claude ROI, and sanity-check the effective lines/hour — runs as a forked analysis workflow with its own reasoning budget, isolated from the main flow. Keeps raw engineering hours separate from overhead and team multipliers, never presents a number without scope, assumptions, and a confidence level, and never claims region-specific market rates unless the user asked and that research was actually done. Use when the user asks to estimate development cost, effort, engineering hours, or ROI.

Create one or more intentional git commits from the working tree — grounded in the REAL diff, never a guessed message over blind staging. Reads `git diff HEAD` and branch/log context first, scans the changed files for blockers (secrets, conflict markers, stray or debug artifacts), runs the narrowest relevant checks for the changed surface, stages files EXPLICITLY by name, drafts a Conventional Commit subject, then verifies the resulting hash and any leftover working-tree state. Never `git add -A`/`.`, `--no-verify`, `--amend`, or co-author trailers unless asked; stops on secrets or conflict markers and asks before an ambiguous split rather than reporting a clean tree that isn't. Use only when the user explicitly asks to commit.

Get an INDEPENDENT second opinion from the OpenAI Codex CLI — a separate reviewer runtime run over the real diff, not Claude reviewing its own work. Verifies Codex is available, resolves the scope (branch, a commit, or uncommitted), writes a focused instruction file grounded in the actual change set, runs `codex review` with disk-read sandbox so it can verify findings against source, then summarizes them by priority. Keeps secrets and credential values out of the instruction file, treats findings as candidates to verify locally before any fix, and reports an explicit clean result rather than fabricating one. Use only when the user explicitly asks for a Codex review or cross-review.

Discover code by MEANING and DEPENDENCY structure, not by matching text — with the `codemap` CLI: hybrid vector+BM25 semantic search, symbol lookup, incoming/outgoing dependency tracing, file summaries, PageRank importance, afferent/efferent coupling, and cycle detection over an indexed repo. Only authoritative when the index exists and is fresh — a stale or empty index is called out, not trusted. Use for architecture-aware code discovery instead of plain text search.

Reduce a change's complexity WITHOUT altering behavior — lower cognitive load, not line count: read the target plus its callers and tests, take a baseline check, then apply the smallest clarifying edits in safest order (dead code and boolean cleanup → flatten nesting with guard clauses → consolidate duplication → local renames and helper extraction), respecting Chesterton's Fence. Re-runs the baseline after each edit and reverts any change that alters observable behavior or regresses, keeping only the safe improvements — a simplification that changes semantics is a bug, not a cleanup. Use only when the user explicitly asks to simplify or clean up existing code.

Get an INDEPENDENT second-opinion review from a separate Claude agent in a read-only worktree — findings only, never edits to your working copy. Reads the real diff (branch, a commit, or uncommitted) to build a focused, risk-targeted brief, launches the reviewer under worktree isolation with report-only instructions, then summarizes findings by priority with `file:line`, carrying an exclusion list forward on later rounds. Treats returned findings as candidates to verify locally, not truth; states an explicit clean result rather than inventing issues; keeps secrets out of the prompt and never lets the reviewer mutate code. Use only when the user explicitly asks for a Claude review.

Build a distributable macOS DMG from an Xcode project via the bundled local helper — archive → export → package into one signed artifact. Resolves the project/workspace, scheme, team ID, and export options, regenerates the project first when `xcodegen` is detected, then runs `helpers/build-dmg.sh` from the project root instead of inlining xcodebuild. User-only workflow that touches code signing and provisioning: it never GUESSES the signing identity, never overwrites `ExportOptions.plist` without approval, and reports the built DMG path, version, and signing status. Use only when the user explicitly asks to build or package a DMG.

Work a Rust crate's recorded issue file to green — one finding at a time, disciplined and sequential: for each finding, write the failing regression test first, apply the smallest correct fix, run the full crate's `cargo test` and `cargo clippy -D warnings`, then mark the finding FIXED / Deferred / Not-a-bug in the issue file before moving on. Never marks a finding fixed without its verification pass, never batches findings, and never buries a warning under `#[allow]` or swaps a real fix for a comment — the issue file and crate state stay in sync after every fix. Use only when the user asks to fix findings from an existing crate issue file.

Fix a CONFIRMED bug at its root cause, smallest correct change only — reproduce before you touch code: write a failing reproducer, diagnose the first broken assumption in the data flow, load the matching framework reference and category playbook, apply the minimal fix, then verify the reproducer goes green and run the regression scope. Never writes fix code without a reproducer (or a documented reason one is impossible), never patches the symptom while the root cause stands, and never weakens a test to pass. Use when the user says "fix this bug", "fix the findings", "/bugfix", or asks to repair a confirmed defect.

Reach sites that BLOCK ordinary automation — the same navigate/inspect/interact/report loop as the `browse` skill, but on browse's camoufox runtime: a hardened Firefox with C++-level fingerprint spoofing, geoip, and humanized timing that passes Cloudflare Turnstile, Google "unusual traffic", DataDome, and PerimeterX, with named profiles, authenticated sessions, and proxy rotation. Honest about its limit: fingerprint spoofing alone will not defeat IP-reputation blocks — pair it with a residential proxy. Use when a page challenges or 403s a normal browser.

Run a full on-page technical SEO audit from a LIVE render — real rendered signals, not source guesses — extracting meta tags, heading hierarchy, structured data, navigation timing, link structure, and multi-viewport mobile rendering via the `browse` CLI (meta/headings/schema/perf/ links/responsive plus targeted JS checks), then rating each area PASS/WARNING/FAIL with prioritized fixes. The agent interprets the raw signals browse extracts; no scores are invented. Use to audit a page's technical/on-page SEO health.

Turn a ticket, URL, or plain-language spec into an executed QA run AND reusable regression flows — scenarios and evidence, not ad-hoc clicking — by decomposing the request into happy/error/edge/ exploratory scenarios, driving each against the real target through the `browse` skill (web or iOS/Android/macOS), capturing pass/fail evidence, and recording cleanly-scoped browse flows worth rerunning. Saves a flow only when it is well-scoped and valuable, never noisy half-recordings. Use to QA a feature and leave behind rerunnable coverage.

Track brand and domain VISIBILITY across AI search engines over a whole query set — Generative Engine Optimization monitoring, not a one-page audit — sweeping each query through Google AI Overviews, Perplexity, and authenticated ChatGPT Search via the `browse` CLI (camoufox for Google), recording each citation into a cross-engine visibility matrix with rates, average position, and competing domains. Reports point-in-time truth: ambiguous citations flagged uncertain, nothing fabricated. Use to monitor a brand's AI-answer presence across engines and queries.

Generate camoufox configuration for the `browse` CLI by INTERVIEW, not hand-edited JSON — an AskUserQuestion-guided flow that turns a chosen preset (stealth, fast-scraping, Google-safe, or a fully custom walkthrough) into a valid `browse.json` camoufox section or a named `.browse/camoufox-profiles/<name>.json`, using camelCase keys, merging without clobbering existing fields, and writing proxy credentials to file only. Use to create or tune an anti-detection browse profile before stealth browsing.

Score a page for how well AI answer engines can CITE it — Answer Engine Optimization, not classic rankings — by pulling structured data, meta, headings, and answer-shaped content via the `browse` CLI (schema/meta/headings/text) into a weighted 0-100 audit, plus a SERP mode that reads Google AI Overviews, Perplexity, and ChatGPT Search snapshots to see who actually gets cited. Never fabricates a score: an un-evaluable dimension is marked N/A, and "appears in AI Overviews" is asserted only after a real SERP check. Use to make a page answer-ready or to check its AI-answer visibility.

Drive a REAL browser and native apps the way a user would — not fetch raw HTML — through the persistent `browse` CLI: one long-lived headless Chromium (plus iOS, Android, and macOS apps via accessibility APIs) where goto, snapshot, click, fill, JavaScript, and screenshot share session state at ~100ms/command and interaction rides stable @eN refs, not brittle selectors. Use when verifying, navigating, or automating live web or app behavior beyond what code-reading or a raw fetch reveals.

Gate a branch before it becomes a PR — catch the STRUCTURAL defects tests miss, not style: read the full diff against the default base, run a two-pass checklist (blocking pass first — unsafe queries, race conditions, trust-boundary and auth mistakes, conditional side effects — then the non-blocking remainder), and verify each candidate against surrounding code before reporting. Stays read-only and reports blocking-first; only becomes mutating after you explicitly approve a specific fix per issue — never batches decisions or auto-fixes. Use as the branch gate right before shipping or opening a PR.

Search code by SYNTAX SHAPE, not by text — matching structures grep and regex can't reliably express — with the `ast-grep` CLI: parse to an AST and match with patterns, node kinds, relational rules (`inside`/`has`), and metavariables, inspecting the tree via `--debug-query` and proving the rule on a minimal example before it runs repo-wide. Requires the `ast-grep` CLI; results are spot-checked, not returned as unverified noise. Use when the target is a code structure rather than a literal string.