My Codex Skills

Plugin my-codex-skills in immagiov4/my-codex-skills. Commands read from the repo's manifest — 5 days ago.

Skills (64)

• agent-question-notifications

  Show a persistent desktop note when a long-running agent task needs a user answer, including questions from PR reviews, local agents, or self-review. Answers remain in the original conversation.

• architect

  Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for $architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.

• benchmark-checklist

  Vet a perf measurement (limiter, tuning, limits, errors, repeatability, relevance, and whether the work happened) before you report or act on it. Use when you run a benchmark or report a speedup or regression you measured.

• blast-radius

  Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up. Use for 'blast radius of X', 'what could this break', or reviewing a small diff you don't trust.

• bro

  Restate the last message in plain human language, with no jargon.

• brutal-bug-hunting

  Run a deep, evidence-driven systemic bug hunt across an application, using issue history, structural analysis, targeted classification, and reproducible failure tests.

• code-review

  Revisiona un ramo, una PR o modifiche locali con il Codex CLI e GPT-6.1 Sol: ricerche indipendenti, conferma dei rilievi, copertura e consumi misurati. È la procedura di base per la revisione del codice.

• codebase-design

  Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

• codex-adapter

  Translation layer between Codex conventions and Claude Code. Load BEFORE running any skill, prompt, or instruction written for Codex (mentions $skill-name, AGENTS.md, .codex/, codex exec, spawn_agent, update_plan, apply_patch, ~/.codex/skills, openai.yaml), or when a skill ported from my-codex-skill

• create-verification-skill

  Generate a project-local verification skill that drives your app the way a user does — any language, framework, or platform. Use for $create-verification-skill, \"make a control skill for this repo\", or when a project has no scripted way to prove UI/CLI/service behavior.

• diagnosing-bugs

  Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

• diagram-design

  Create branded architecture, IT current-state, flowchart, sequence, state machine, ER/data model, timeline, swimlane, quadrant, radar/spider, polar chart (polar/radial lollipop), loop/flywheel, nested, tree, org chart, layer stack, Venn, pyramid/funnel, treemap, bar, line, Gantt and scatter charts,

• docs-doc

  Compatibility name for Writing for Humans. Use when explicitly requested through the former docs-doc name.

• domain-modeling

  Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md or CONTEXT.md, or recording or editing an ADR.

• engineering-workflow

  Route non-trivial software work through discovery, architecture, implementation, verification, review, and small living documentation. Use when a coding task needs more than a direct local edit or when the right workflow is unclear.

• esempio-guidato

  Esegui una richiesta di modifica o esplorazione del codice come esempio guidato, mostrando nel browser un passo reale alla volta e attendendo domande o Avanti prima di proseguire.

• figure-it-out

  Design an auditable playbook when no narrower one fits: a large migration, an ambitious multi-part change, or work a human reviews after stepping away. Scales rigor to the task, runs a hypothesis loop, and logs decisions via show-me-your-work. Use for $figure-it-out, 'figure it out', a large migrati

• grill-with-docs

  A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.

• grilling

  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.

• handoff

  Compact the current conversation into a handoff document for another agent to pick up.

• how

  Use for \"how does X work\", code walkthroughs before changing something, and placement / ownership / layering questions (\"where should this live\", \"which package owns this\", \"is this the right layer\"). Explains subsystem architecture, runtime flow, onboarding mental models. Can critique archi

• improve-codebase-architecture

  Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

• look-after-the-environment

  Reuse compatible tools, dependencies, browsers and test data before installing them, and clean up temporary test artifacts and worktrees after verification or before publishing. Use when preparing a test environment, installing a dependency, or closing out work that created temporary files.

• maintain-system-map

  Keep docs/system-map.md synchronized with meaningful architectural changes while avoiding documentation churn.

• maintain-verification-skill

  Periodic pass that keeps a project's verification skill and feature map honest: parallel source readers per feature, one live session driving every feature, at most one PR of proven corrections. Use for $maintain-verification-skill or \"audit the verify skill\".

• orchestrate-nous-backlog

  Orchestrate a Nous backlog run from repository discovery and open-issue triage through user-visible delegation, review, validation, and controlled publication. Keep the Nous-specific discovery, classification, selection, and authority boundaries here; route generic engineering and issue mechanics to

• poteto-mode

  Work in poteto's engineering style with concise prose, simple code, deliberate delegation, and evidence from the real artifact. Use when the user asks for poteto mode or requests this style explicitly.

• principle-boundary-discipline

  Apply when wiring validation, error handling, or framework adapters. Concentrate guards at system boundaries (CLI, config, network, external APIs); trust internal types and keep business logic in pure functions.

• principle-build-the-lever

  Apply to any non-trivial work, not just bulk work: edits, migrations, analyses, checks. Build the tool that does it or proves it (codemod, script, generator, or a skill your subagents follow) instead of working by hand. The tool is the artifact a reviewer can rerun.

• principle-encode-lessons-in-structure

  Apply when you catch yourself writing the same instruction a second time, or notice a recurring correction. Encode the rule as a lint, metadata flag, runtime check, or script instead of more text.

• principle-exhaust-the-design-space

  Apply when facing a novel UI interaction or architectural decision with no precedent in the codebase. Build 2-3 competing prototypes and compare side by side before committing.

• principle-explain-the-number

  Apply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result. Find what limits it, and rule out that it measured something other than the work you think.

• principle-fix-root-causes

  Apply when debugging. Trace each symptom to its root cause and fix it there; reproduce first, ask why until you reach it, resist nil-check guards that silence crashes.

• principle-foundational-thinking

  Apply before writing logic: choosing core types and data structures, sequencing scaffold-vs-feature work, asking what concurrent actors share. Get the data structures right so downstream code becomes obvious.

• principle-laziness-protocol

  Apply when refactoring, evaluating diff size, or tempted to add abstractions, layers, or signal threading. Bias toward deletion and the smallest change that solves the problem.

• principle-outcome-oriented-execution

  Apply during planned rewrites and migrations with explicit phase boundaries. Converge on the target architecture; don't preserve smooth intermediate states with throwaway compatibility code.

• principle-prove-it-works

  Apply after completing a task, before declaring done. Verify against the real artifact (run the feature, read the actual value, inspect the diff), not a proxy, self-report, or 'it compiles.'

• principle-redesign-from-first-principles

  Apply when integrating a new requirement into an existing design.

• principle-separate-before-serializing-shared-state

  Apply when concurrent actors might write to the same file, branch, key, or state object. Eliminate the sharing first; serialize structurally only when one shared writer is a real invariant.

• principle-sequence-verifiable-units

  Apply to multi-step work (sweeps, migrations, runs of similar edits) and to how you stack commits and PRs. Break work into small units that each end in a verifiable state, check each before the next, and order delivery so the sequence proves itself to a reviewer.

• principle-subtract-before-you-add

  Apply when sequencing an addition, refactor, or rewrite. Remove dead code, redundant validators, and stub references first, then build on the simpler base.

• principle-test-behavior-not-implementation

  Apply when you write, change, or keep a test. Call the code as its users do and assert the exact result they see. Rewrite or delete a test that would pass if every imported function returned undefined.

• problem-to-github-issue

  Diagnose a reported repository problem, capture a product idea or investigation, and govern a GitHub issue without inventing requirements. Use before creating, editing, labeling, commenting on, closing, reopening, deduplicating, or preparing an issue for autonomous implementation.

• prototype

  Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

• receiving-pr-reviews

  Evaluate findings from PR reviews, local reviewing agents, self-review, and reviews of documents or other artifacts before applying corrections. Validate requirements, evidence, scope, and decisions.

• requirements-blast-radius

  Map implicit requirements before implementing a substantial new request or steering that changes the agreed outcome. Find every surface delivering the capability and the lifecycle boundaries needed to make the request true for the user.

• research

  Investigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.

• retro

  Esamina una sessione di sviluppo e propone miglioramenti agli strumenti, ai controlli e alle istruzioni dell'agente.

• setup-matt-pocock-skills

  Configure this repo for the engineering skills: set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.

• show-me-your-work

  Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why, evidence, result). Local by default; commit it when a reviewer needs the trail to trust the result. Use for $show-me-your-work, autonomous or multi-phase runs, or work a human review

• skill-learning-patterns

  Derive verifiable skill improvements from a correction, faulty instructions, or a reusable technique discovered in a chat. Also use when asked to refine a skill or review a collection for overlap and outdated content.

• tdd

  Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.

• teach

  Explain a body of work plainly so a person actually understands it. Runs the `how` and `why` skills and weaves what they find into one clear explanation. Use for 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'.

• to-spec

  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.

• to-tickets

  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).

• unslop

  Compatibility name for Writing for Humans. Use when explicitly requested through the former unslop name.

• wayfinder

  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.

• web-performance

  Measure and diagnose browser-facing web performance with Lighthouse, runtime traces, field data, build artifacts, or source inspection. Use for performance audits, Core Web Vitals, slow loading or interactions, bundle regressions, and evidence-based optimization.

• website-creator

  Find website design tools, visual recipes and resource research in the Geppetto website-tools memory bucket.

• why

  Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, prod

• wizard

  Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can pe

• write-pr

  Draft or revise a pull-request body from the actual change and verification evidence. Use when no maintainer-selected PR procedure already owns the task.

• writing-for-agents

  Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.

• writing-for-humans

  Write or revise text for people, including conversation, documents, reports and messages, preserving the author's voice, the reader's competence and supported meaning. Use for human-facing prose; agent instructions follow writing-for-agents.

Similar plugins