## Frequently used skills and when they appear ### How frequency was measured - [“Frequently used” here means the skill instructions were deliberately loaded during work, not merely displayed in an installed-skills catalog] — [A retrospective scan of Codex JSONL session records counted distinct session files containing a read of each skill's `SKILL.md`. Counts are approximate because renamed, aliased, or reinstalled copies can split one skill family across names.] - [A loaded skill does not always mean the user personally typed its name] — [`using-superpowers`, `unslop`, and `verification-before-completion` can be required by another selected skill or by standing agent instructions. Their presence proves that they shaped the session, not that every load was a manual invocation.] - [The recurring skill stack centers on pressure-testing, debugging, proof, browser evidence, and artifact production] — [The highest observed families were `interrogate` (~50 distinct session logs), systematic debugging (~35), verification before completion (~27), browser work (~29 across `gstack-browse` and `browse`), TDD (~20), `figure-it-out` (~20), presentations (~18), and pre-landing review (~17).] ### Adversarial thinking, debugging, and proof - [`interrogate` is the most frequently observed pressure-test skill] — [It adversarially questions a claim, plan, diagnosis, or proposed implementation. It appears when an answer sounds plausible but its assumptions, missing evidence, and failure modes need exposure before action (~50 session logs).] - [`systematic-debugging` is the default family for unexpected failures] — [It requires reproducing the problem, gathering evidence, isolating the responsible layer, and identifying root cause before changing code. It appeared in ~35 session logs around test failures, integration defects, and broken runtime behavior.] - [`gstack-investigate` handles incident-style root-cause work across system boundaries] — [It appears when the task is framed as “why is this happening?” or a symptom crosses code, environment, deployment, and external systems. It appeared in ~13 session logs, including NOMOS investigations.] - [`verification-before-completion` controls when the agent may say “done”] — [It requires fresh commands, runtime checks, or rendered evidence immediately before a completion claim. It appeared in ~27 session logs and matches repeated rejections of lint-only or implementation-only proof.] - [`principle-prove-it-works` makes proof an explicit final phase] — [It asks for observable evidence at the layer the user experiences after implementation. It appeared in ~9 session logs and reinforces definition → import → render → action → persistence checks.] - [`principle-fix-root-causes` prevents symptom-hiding fixes] — [It instructs the agent to trace a defect to the earliest responsible boundary and preserve intended behavior. It appeared in ~7 session logs and matches corrections when agents tried to remove or bypass a broken UI instead of repairing its integration.] - [`test-driven-development` is used when behavior can be expressed as an executable regression] — [It requires writing a failing test, observing the failure, implementing the minimum fix, and rerunning the test. It appeared in ~20 session logs; the explicitly requested `tdd` wrapper appeared in ~7.] - [`principle-make-operations-idempotent` is used for retries, commands, migrations, and lifecycle operations] — [It asks whether repetition converges safely instead of duplicating writes or corrupting state. It appeared in ~7 session logs and aligns with NOMOS deterministic-projection and zero-write retry boundaries.] - [`principle-boundary-discipline` appears when validation, authority, or error handling is drifting into the wrong layer] — [It keeps responsibility at the interface that owns it. It appeared in ~6 session logs around API validation, persistence boundaries, and integration wiring.] - [`principle-model-the-domain` is used for stateful workflows with real lifecycle semantics] — [It pushes the agent to name domain states, transitions, and invariants instead of accumulating booleans and ad hoc branches. It appeared in ~4 session logs during queue, ledger, and workflow reasoning.] ### Planning, decomposition, and execution - [`figure-it-out` generates an auditable playbook when no procedure exists] — [It converts unfamiliar or under-specified operations into a sequence with evidence requirements, decision points, and rollback awareness. It appeared in ~20 session logs when neither a repository script nor a runbook was sufficient.] - [`brainstorming` precedes genuinely creative or design-shaping work] — [It elicits the goal, constraints, alternatives, and preferred direction before implementation. It appeared in ~13 session logs, especially for product concepts, visual directions, and new interactions.] - [`writing-plans` turns an accepted requirement into executable steps] — [It appears after intent is clear but before broad edits, particularly for multi-file or multi-stage implementation. It appeared in ~6 session logs.] - [`executing-plans` takes over after a written plan exists] — [It works through that plan in bounded batches with verification checkpoints rather than reopening design decisions on every step. It appeared in ~5 session logs.] - [`principle-sequence-verifiable-units` breaks large sweeps into independently provable slices] — [It appears when a task risks becoming an unverifiable “fix everything” pass. It appeared in ~5 session logs and matches frozen release slices and per-change proof.] - [`principle-foundational-thinking` is used before selecting abstractions or writing core logic] — [It asks the agent to derive the model and invariants from first principles instead of extending the nearest existing pattern. It appeared in ~7 session logs during architecture and workflow design.] - [`subagent-driven-development` appears when a plan contains separable work packages] — [It assigns bounded tasks to workers, reviews each result, and leaves integration responsibility with the primary agent. It appeared in ~7 session logs, consistent with the recorded model-routing and final-review policy.] - [`using-superpowers` is orchestration glue, not strong evidence of a manual user choice] — [It forces the agent to check for applicable skills before acting. It appeared in ~12 session logs, often because another Superpowers skill required it.] ### Browser work, review, QA, and delivery - [`/browse` is the required route for web browsing and browser-backed evidence] — [The `gstack-browse`/`browse` family opens and inspects pages, captures browser state, and supports interactive QA. It appeared across ~29 session logs, and the current `AGENTS.md` requires `/browse` for all web browsing while banning Claude-in-Chrome tools.] - [`gstack-review` is the common pre-landing checkpoint] — [It reviews the actual diff for correctness, regressions, missing tests, and unsupported completion claims before merge. It appeared in ~17 session logs and is used after implementation but before owner-controlled landing.] - [`requesting-code-review` formalizes the move from implementation to independent scrutiny] — [It appears after a coherent slice is implemented and locally verified, then supplies scope and evidence to the reviewer. It appeared in ~5 session logs.] - [`receiving-code-review` evaluates feedback instead of accepting it mechanically] — [It asks the agent to reproduce or reason through each comment, reject incorrect suggestions with evidence, and implement valid findings. It appeared in ~4 session logs.] - [`finishing-a-development-branch` is used when code is complete but branch disposition remains a decision] — [It checks tests and presents merge, PR, retention, or cleanup outcomes without assuming authority. It appeared in ~4 session logs.] - [`gstack-land-and-deploy` appears only after implementation and owner gates are ready] — [It coordinates exact-head checks, merge, deployment, and post-deploy verification. It appeared in ~4 session logs; release records separately preserve production-write and human-publication gates.] - [`gstack-canary` handles post-deploy observation] — [It watches the deployed system for health and regressions after landing. It appeared in ~3 session logs and fits the sequence deploy → health proof → limited canary → human-controlled public cutover.] - [`gstack-qa` performs systematic end-to-end web checks] — [It exercises user-visible flows in a browser and records failures instead of treating unit tests as complete QA. It appeared in ~2 session logs, with related browser QA occurring more often through `/browse` and Playwright.] - [`gstack-careful` appears when an operation has destructive or production-state risk] — [It adds target resolution, safety checks, and confirmation boundaries. It appeared in ~3 session logs and matches rules against resets, broad staging, silent production writes, and checkout cleanup.] ### Explanations, writing, memory, and context transfer - [`poteto-mode` is a frequently loaded response-style skill] — [It makes the agent concise, direct, and decision-oriented. It appeared in ~16 session logs, usually for low-noise summaries, handoffs, and corrections rather than expansive exposition.] - [`how` is used for code and system walkthroughs] — [It explains the executable path and relationships in plain language, grounded in actual code rather than a generic architecture description. It appeared in ~7 session logs.] - [`technical-writing` is used for durable engineering documents rather than ordinary chat] — [It structures RFCs, handovers, READMEs, audits, and source documents for layered reading and explicit evidence. It appeared in ~4 historical session logs and was applied to this document.] - [`unslop` is the cleanup pass paired with technical writing] — [It removes filler, canned AI transitions, vague intensifiers, and unsupported rhetoric while preserving substance. It appeared in ~6 session logs, though some uses were automatically required by `technical-writing`.] - [`mem0-memory` supplies advisory recall before context-dependent work] — [It retrieves preferences, prior decisions, and incident context that may not exist in the current checkout, and it permits memory curation only with explicit authority. It appeared in at least ~3 directly identifiable session logs and was required for this extraction, including the retry of export `e6429c20-4175-4148-9fe6-11e268f53238`.] - [`loop-eng-format` is an occasional fresh-session handoff tool, not a general high-frequency skill] — [It generates a `START-*.md` kickoff containing goal, state, constraints, evidence, and next steps so a new agent can resume without reconstructing the work from chat. It appeared in ~2 session logs.] ### Documentation, presentations, design, and artifacts - [`presentations` is the main slide-production skill] — [It reads, creates, edits, renders, and validates PowerPoint decks. It appeared in ~18 session logs, including the 41-slide market-expansion deck and reusable presentation-template work.] - [`template-creator` is used for reusable presentation systems rather than one-off decks] — [It creates or updates the template package, example artifacts, and usage contract. It appeared in ~4 session logs around the Elevate Pay template work.] - [`figma-use` and `figma` make a supplied design file the visual authority] — [`figma-use` establishes the required safe read/write workflow, while `figma` retrieves design structure and assets. Each appeared in ~4 session logs, especially when preserving a named Figma reference rather than approximating its look.] - [`pdf` checks the final delivery format, not only the editable source] — [It creates, reads, renders, and validates PDFs. It appeared in ~4 session logs during presentation delivery.] - [`gstack-design-review` appears after a visual implementation exists] — [It inspects the rendered result for hierarchy, spacing, typography, responsiveness, and mismatches with the reference. It appeared in ~3 session logs.] - [`gstack-design-consultation` appears before implementation when visual direction is unresolved] — [It clarifies audience, intent, constraints, and design choices before code or artifact generation. It appeared in ~2 session logs.] - [`gstack-document-generate` creates missing repository documentation from observed system state] — [It appears when the code exists but the durable explanation or operator guide does not. It appeared in ~4 session logs.] - [`gstack-document-release` reconciles documentation after shipping] — [It updates release notes, handovers, status claims, and follow-ups to match what actually landed. It appeared in ~6 session logs and matches the required `recorded`, `verified`, `pending`, `local-only`, and `owner gate` labels.] ### Security review skills - [`security-diff-scan` is the most frequently observed dedicated security skill] — [It limits review to the proposed change, traces security-relevant data and authority changes, and reports evidence-backed findings before landing. It appeared in ~4 session logs.] - [`finding-discovery` investigates a suspected vulnerability class in depth] — [It searches for concrete exploit paths and supporting code evidence instead of producing a generic checklist. It appeared in ~4 session logs.] - [`threat-model` appears when boundaries and attacker paths need to be explicit] — [It maps assets, trust boundaries, actors, attack surfaces, and mitigations before or alongside implementation. It appeared in ~3 session logs.] - [`deep-security-scan`, `attack-path-analysis`, and `security-scan` are supporting rather than frequent skills] — [Each appeared in ~2 identifiable session logs. They are used for broader repository review or to connect validated findings into end-to-end attack paths, not as a ritual on every change.] ### Historically frequent skills whose current definitions could not be verified - [`cavecrew` was historically one of the most frequently loaded skills, but its behavior cannot be safely reconstructed] — [It appeared in ~30 distinct Codex session logs, while an old catalog preserved only the truncated description “Decision gui…”. Its former `SKILL.md` is absent from the current installed set, so fuller claims about what it did, how it was used, or when it triggered would be invention.] - [`caveman` was historically frequent, but only a style-oriented fragment remains] — [It appeared in ~21 distinct Codex session logs, while an old catalog preserved only “Ultra-comp…”. The historical skill file is unavailable this session, so describing it beyond an apparent ultra-compact mode would exceed the evidence.] ### Installed or observed skills that are specialized, not frequent - [The installed catalog is much larger than the recurring working set] — [Game-studio skills, `imagegen`, `playwright`, `openai-docs`, HeroUI skills, deployment setup, and several design and security variants appeared in only one to three identifiable session logs each. They are task-specific tools, not evidence of a habitual workflow.] - [Installation is not evidence of use] — [The environment exposes many bundled and plugin-provided skills, but this section excludes catalog-only appearances and labels low-count skills as supporting or specialized instead of presenting availability as observed behavior.]