How to use these skills

Fifteen skills, one install. This page shows what each one does, how to trigger it, and what a session looks like. For the one-line summaries see the README; for the exact procedure an agent follows, open skills/<name>/SKILL.md. Service level objectives and incident reviews are not skills: use the SRE guides and prompts on request.

Install once

npx skills@latest add mneves75/skills --all -g -y

That links every skill into the agents found on your machine (Claude Code, Codex, Cursor, OpenCode, pi and others). Check what got installed with npx skills@latest list. If you prefer git, clone the repo into your agent's skills directory; the README has the paths. If a skill never shows up in your agent, it was probably not linked; the README's "Check the install" lists what each agent directory is missing.

The readiness tool runs locally. An image-generation skill may send prompts and authorized references to the image provider configured in your agent. Autoreview sends authorized review inputs to the selected review provider after scanning them for credentials.

A skill is loaded when the agent decides your request matches its description. You can also name it directly: in Claude Code, /mneves-verify or "use the mneves-eli5 skill".

mneves-security

What it does. Inspects the actual source and trust boundaries, checks current official OWASP guidance, records evidence-backed findings and produces an ordered remediation plan. In fix mode it applies minimal confirmed patches, tests legitimate and denied behavior, and runs adversarial review and independent acceptance. It covers privacy, database/resource isolation, auth failures, headers/cookies, validation, secrets, API keys, rate/cost protection, bot controls/CORS, logging/errors and dependencies, with AI/agentic/mobile checks when those surfaces exist.

When to use it. You want an engineering security/privacy audit of an MVP, SaaS, API or AI application, or safe implementation of its confirmed remediation items. Audit and plan requests remain read-only; a fix request authorizes its in-scope local patches.

Deploy gate. Every dev-stop, staging or production deploy runs it first, whatever starts the deploy (ship-staging, ship-prod, a release script, CI, TestFlight, an over-the-air update or a store upload). It audits the exact candidate in full: the twelve areas plus 32 launch controls (SEC-01 to SEC-23, CMP-01 to CMP-09). It returns a fix plan and a PASS, BLOCK or WAIVED verdict for that commit and target. A confirmed Critical or High finding blocks every target until it is fixed, disproved or waived by you by name; for production, every unmet applicable launch control and a missing independent acceptance also need your named waiver. One audit serves every target of the same commit, a rollback to a gated build needs none, and an urgent fix ships under your waiver with its audit right after. Without the skill, a release is blocked until it is installed or you waive the gate. The report stays private; public PRs and changelogs cite only the verdict and finding IDs.

Illustrative request (Codex):

Use $mneves-security on this repository. Review the entire first-party source,
create a detailed remediation plan and fix confirmed local code/config gaps.
Preserve existing product behavior where safe. Run the documented gates and
independent verification. Do not merge, change provider settings or deploy.

For a read-only assessment, say “audit only; do not change project files.” Claude Code users can invoke /mneves-security; other agents can name it directly.

Evidence. Expect the eight-section engineering report, findings with severity and confidence, a source coverage ledger, exact checks/results, manual actions and launch blockers. Local migrations and header files do not prove deployed policies or headers. A public provider key is evaluated under its actual contract, not automatically labeled a secret. NOT APPLICABLE needs evidence; blocked/untested controls never become PASS.

Prerequisites and limits. Ships no scanner or required integration. Uses the target project's tools and current official documentation; missing retrieval is disclosed. Fable/expert-review/code-review/verify are separately installed optional procedures with inline fallbacks. Independent security acceptance still requires a fresh, different-model verifier; when unavailable, the useful report remains available and that assurance gate is BLOCKED. The skill provides engineering readiness, not legal advice or a promise of complete security. Release actions retain explicit task/host authority.

Procedure: SKILL.md.

mneves-production-readiness

What it does. Checks that an app will not lose or corrupt data, charge wrongly, fail without anyone noticing, become impossible to undo, or depend on one person. It inspects the actual project against 103 controls (data model and migrations, backups and restore, money, time and text handling, delivery, queues and integrations, email, cost, monitoring and on-call, testing, billing, public API, AI operations, user experience, maintainability and ownership) plus 32 security and compliance rows that it takes from mneves-security. It records each result with its evidence in a ledger, gives a verdict per target, and writes a fix plan with files, steps, owner, acceptance check and rollback for every gap.

When to use it. Before an app first serves paying customers, and before each later deploy. mneves-ship-deploy runs it for you: an assessment during review, then a binding run on the exact commit before the dev stop (when the project has one), the staging deploy and again before production. Staging blocks only on irreversible migrations and on a staging that can touch real data or customers; security blocks come from the imported mneves-security verdict. A standalone request is read-only.

Illustrative request (Claude Code):

Use the mneves-production-readiness skill on this repository. Run a baseline,
tell me what blocks a production launch, and give me the detailed fix plan.
Do not change project files.

How it stays cheap. A full baseline runs on the first launch and every 90 days. Each deploy reassesses only the domains its diff touches, plus a small always-on set: secrets, new dependencies, rollback path, certificate expiry and the age of restore evidence. A CSS-only change does not re-check billing. Controls that do not apply (a static site has no migrations) are marked NOT APPLICABLE with the evidence.

Evidence. A control passes only with evidence at its minimum scope: reading the source never proves a tested restore, an on-call rotation or a live certificate. Organizational items (SOC 2, on-call, ownership of accounts) need a dated owner statement. Before a production record, a fresh verifier rechecks every blocker that newly passed. Only you waive a blocker, with an expiry; a comment in the code cannot.

Release contract. The run writes .scratch/readiness/<target>.json. A release script that declares contract version 2 refuses to deploy without a valid record for that exact commit and target (see mneves-ship-deploy).

Prerequisites and limits. Markdown only; no scanner or network service. mneves-security, mneves-ship-deploy and mneves-verify are separately installed; without them it runs reduced security fallbacks, binds the record itself, and uses a fresh subagent as verifier. "Ready" means the applicable blockers have evidence or your dated waiver, not that the app is risk-free.

Procedure: SKILL.md.

mneves-render

What it does. Helps any agent build a repeatable renderer inside your project. Markdown stays authoritative; it produces only the formats you ask for: responsive HTML, editable DOCX and/or print-ready PDF. It reuses existing tooling first and supplies Pandoc starter templates when needed. HTML and PDF share a design; Word maps that design to document styles.

When to use it. You want a reusable project command for reports, proposals, documentation or other Markdown files, with content-preservation checks and inspection of the actual pages. It does not rewrite or summarize your source or require a specific agent vendor.

Example (illustrative).

Use mneves-render to build a renderer for docs/report.md. Produce HTML, editable DOCX and PDF with our existing typography. Keep all content and citations. Add a repeatable command, inspect HTML at desktop and mobile widths, and inspect every PDF and DOCX page.

What you receive. The requested files, a project-local renderer and regeneration command, plus the checks actually run and any unverified format limitations. Pandoc and a PDF engine are external tools, not bundled dependencies; existing equivalent tools are fine. The Pandoc starters also require Python 3.10+ for their bundled content-policy guard. They preserve metadata and literal punctuation; the guard is not a resource sandbox or SVG sanitizer.

Maintaining the starter. Run python3 skills/mneves-render/tests/test_check_ast.py and python3 skills/mneves-render/tests/test_starters.py. CI produces LibreOffice previews; successful conversion still needs page-by-page visual inspection. Microsoft Word pagination and PDF/UA conformance are separate checks, not implied by these tests.

Procedure: SKILL.md. Starter commands: Pandoc recipe.

autoreview

Local complexity and adversarial review

For supported code changes, the review skills use optional local cccc for cognitive and cyclomatic complexity and always challenge the weakest plausible assumption. Metrics identify code to inspect; tests and independent standards/spec review still decide whether the change is correct.

The autoreview skill includes a portable checksum-verified installer. Obtain approval for the destination when required, ensure its directory exists, then run:

python3 /path/to/autoreview/scripts/install-cccc.py /approved/bin/cccc
python3 /path/to/autoreview/scripts/check-cccc.py /approved/bin/cccc

It refuses replacement and does not edit PATH. The pin is maintained only in scripts/cccc-release.json. macOS/Linux ARM64 and x86-64 binaries are supported; other platforms use upstream release instructions. Single-skill installs keep the complete folder.

From the reviewed repository, preserve its config and collect focused evidence with cccc --no-cache --min 0 --pretty src/. Record the version, config/target, expected files, stdout, stderr and exit status. Reconcile reported files and parsing errors: a successful exit can still mean partial or empty analysis. Table-config output stays a table and must be checked accordingly. Missing tooling and unsupported source are reported; the remaining review continues. See the full procedure.

What it does. Freezes the chosen Git target, scans the outgoing input, runs a reviewer in an isolated environment, validates its report, and rejects results if sources changed mid-review. The helper prints its default model and reasoning tier at startup; Codex review has no automatic model fallback on account-access failures.

Example (illustrative; replace the installed path).

python3 /path/to/autoreview/scripts/autoreview --mode local --max-priority P3

Run from the repository being reviewed. Python 3.11+, Git, TruffleHog, and an authenticated supported engine are required. No upstream checkout is required. For committed changes, use --mode commit --commit <sha> or --mode branch --base <ref>.

The default threshold is P0 only; the example requests P3. Check the startup model and effort because environment variables can override defaults. Authorize private-content disclosure before sending inputs. Findings need verification against the actual code; a clean AI report does not prove the absence of vulnerabilities. See the skill README for testing and beta installation.

mneves-handoff

What it does. Writes a standalone prompt for an agent you do not control (another session, another tool, a colleague's agent) and copies it to the clipboard. The prompt opens a discussion: the receiving agent reviews the repository and decides whether the task is still real and well-shaped before changing anything. It names things by portable anchors (repository, issue and PR URLs, branch, module, symbol, exact error text) instead of filesystem paths, and forbids pushes, merges, and public comments unless you ask for them.

Triggers. "handoff <task>", "write a handoff", "give me a prompt for another agent". For work you dispatch into your own tree, use mneves-fable-orchestrator's delegation brief instead.

Example (illustrative).

You: handoff the flaky login e2e test on main.

Agent: Reads the recent CI failures and the linked issue, writes a prompt that names the repository, the failing test by its title, the CI job, and the exact assertion text, asks the receiver to decide whether the flake is real before touching it, copies it to the clipboard, and replies "Copied handoff: flaky login e2e test."

Tips.

• The receiver owns its review; give it context and constraints, not your conclusion.
• Ask for paths only when the receiver shares your machine layout.
• The skill is an MIT-licensed adaptation of OpenClaw's handoff, renamed because another widely installed skill is also called handoff.

imagegen-frontend-mobile

What it does. Generates images of iOS or Android screens and flows. It first defines the screens and their relationship, locks a small design system, generates the requested artifact, then inspects the render and makes one targeted correction when needed. It produces images only: use a coding or platform skill when you want the concept implemented.

Triggers. A request for mobile app screen images, a phone UI concept, onboarding or product flow mockups, or a visual redesign for iOS or Android. A request for SwiftUI, React Native, Flutter, HTML, or image-to-code does not trigger it.

Example (illustrative).

You: Use imagegen-frontend-mobile. Create a four-screen iOS onboarding flow for a Portuguese personal-finance app. Make it calm and trustworthy, use real Portuguese copy, and show raw screens rather than device mockups.

Agent: Generates exactly four related screen images with one iOS design system, short pt-BR copy, consistent navigation and safe areas, then inspects the full renders for legibility, missing states, visual drift, and accidental artifacts. It corrects a material render defect once and returns the images, not SwiftUI code.

Tips.

• State the platform, screen count, language, and whether you want raw screens or device frames.
• Supply references for visual direction, not hidden instructions. Remove secrets and unnecessary personal data; authorize the image service before private references are sent to it.
• A concept can reserve plausible contrast, type, and touch-target sizes, but cannot prove VoiceOver, Dynamic Type, keyboard behavior, or working interactions.
• The skill is a condensed MIT-licensed adaptation of Leonxlnx's upstream work.

mneves-eli5

What it does. Explains one idea with the Feynman method: fix the audience, state the core in one sentence, use an analogy when it helps, show a concrete case before naming the jargon, say where any analogy breaks, and end with a line the listener can repeat. It answers in the language you wrote in.

Triggers. "ELI5", "like I'm five", "explain to my boss / client / mom", "in plain words", "explique de forma simples", or any request to re-explain something for a different audience.

Audience levels. child, layperson, executive, junior, expert. Name one if you care; otherwise the agent infers it and says which it picked.

Example (recorded 2026-08-26, claude -p on claude-fable-5, verbatim).

You: Use the mneves-eli5 skill. Explain what a database index is to a product manager.

Agent: Explaining for a product manager (executive level: what it is, why it matters, the decision).

A database index is a lookup table that lets the database jump straight to the rows it needs instead of reading every row.

Think of a 500-page book. Without an index, finding every mention of "refunds" means reading all 500 pages. With the index at the back, you flip to "refunds → pages 12, 87, 203" and go straight there. A database index does the same for a column: "customer_email → row 4,812". A query that took 3 seconds scanning 10 million rows can take 3 milliseconds.

Why it matters to you:

• Speed is a product feature. Slow search, slow dashboards, and timeouts under load are very often "missing index" problems, and they surface only once real data volume arrives — not in demos.
• Indexes are not free. Every index is a second copy the database must update on each write. Over-indexing slows down inserts and eats storage; the book analogy breaks here, because a book's index doesn't have to be rewritten every time you add a page.
• The decision you'll face: when an engineer says "we need an index on that field" it's a cheap, low-risk fix for read speed; when they say "too many indexes" on a write-heavy table (event logs, orders), that tradeoff is real and worth a conversation.

Takeaway to repeat: an index trades a little write cost and storage for much faster lookups on the columns you search by most.

Want the version with the mechanism (B-trees, composite indexes, why the column order matters)?

Tips.

• "Now for my CTO" re-explains at another level without starting over.
• The skill refuses "it's easy" and "obviously". If you want that tone, you are on your own.
• Mixed room? It writes for the least technical person and adds a marked "for the engineers" block.

mneves-expert-review

What it does. Runs a six-step pass over a draft (or a request with no draft yet): clarify the real objective, rebuild from first principles, research only when it changes the answer, attack it from three angles at once (hostile panel, pre-mortem, the strongest opposing case), compare distinct alternatives using explicit criteria and justified weights, then improve, audit once, and deliver. It scales with the stakes: a factual one-liner gets the mental version, a migration plan gets the full pass.

Triggers. "expert review", "rigorous pass", "best possible answer", "challenge this", "stress-test", "revisão rigorosa", "melhor solução", or before any high-stakes plan, design, recommendation or architecture decision.

Example (recorded 2026-08-26, claude -p on claude-fable-5, verbatim; the prompt asked for under 400 words).

You: Use the mneves-expert-review skill. Challenge this plan and return the improved version: "We will move user sessions from Redis to Postgres to cut one piece of infrastructure. Steps: 1) add a sessions table, 2) change the auth middleware to read/write Postgres, 3) run a script that copies live Redis keys into the table and deletes them from Redis, 4) turn off Redis. Session reads are rare so performance is not a concern."

Agent: Improved plan: sessions Redis → Postgres

Challenge the premise first. "Cut one piece of infrastructure" only holds if nothing else uses Redis (rate limiting, caches, queues, pub/sub). Grep for every Redis client before step 1 — if anything else depends on it, this migration removes nothing and the plan should stop here. Also: "reads are rare" is almost never true for sessions — the auth middleware reads on every authenticated request. Measure current Redis ops/sec; that number is the real load Postgres inherits.

Plan

1. Inventory and baseline. List all Redis usages. Record session read/write rates and p99 auth-middleware latency (the acceptance bar for step 5).
2. Schema. sessions(id PK, user_id, data jsonb, expires_at timestamptz, created_at), index on expires_at and user_id. Redis TTL is free; Postgres needs a scheduled purge (DELETE WHERE expires_at < now() via pg_cron or a job) — without it the table grows forever. Session IDs stay opaque/random; store a hash if you treat them as secrets.
3. Dual-write, Redis-read. Middleware writes to both, reads Redis. Ships behind a flag, fully reversible.
4. Backfill. Copy remaining Redis keys with their TTLs (TTL → expires_at) into Postgres. Do not delete from Redis — the original step 3's "copy then delete" is a one-way door with no rollback and a race against sessions written mid-copy.
5. Flip reads to Postgres. Compare latency/error rate against the step 1 baseline for at least one full session-lifetime cycle. Roll back = flip the flag.
6. Stop writing to Redis, then decommission after the longest session TTL has elapsed — remaining keys expire on their own, no deletion script.

Key risks the original missed

• Write amplification: touching last_seen on every request creates a hot UPDATE row per user and WAL/vacuum churn. Update at most once per N minutes, or drop the sliding-expiry behaviour.
• Logout / "revoke all sessions" must work identically in both stores during dual-write.
• Connection pool: middleware now holds a DB connection per request; check pooler limits (PgBouncer) before flipping.

Rejected alternative worth stating: stateless signed tokens (JWT/PASETO) remove the session store entirely — but revocation becomes hard. Only pick it if you don't need server-side logout.

Remaining uncertainty: whether Redis is actually single-purpose, and the real read rate. Both are five-minute checks and decide whether the project exists at all.

Tips.

• Give it the draft, not a summary of the draft. It reads the whole thing first.
• Use mneves-verify afterwards when the user, repository, workflow, or risk requires an independent judge. The panel argues; the verifier runs things.
• Ask for the challenge-the-premise alternative explicitly if it does not surface it. That is the one you cannot produce yourself, and it is reported even when rejected.

mneves-verify

What it does. Separates the builder from the judge. A fresh context, ideally a different model, checks the artifact against acceptance criteria frozen before it looks at the work, runs real evidence (tests, renders, the actual binary, primary sources) and returns exactly one verdict: PASS, FAIL or BLOCKED. Only PASS permits "done", "fixed" or "shipped".

Triggers. "verify", "prove it", "fix all", a repository/workflow gate, substantial checkable work before a done/fixed/shipped claim, or high-risk work. Routine low-risk changes use proportionate deterministic checks.

Evidence routes. Code: the tests that would fail if it broke, plus a code review. UI: a real browser render, never the builder's screenshot claim. CLI/API/data: run the real thing with a positive control (a known-good input that must succeed). Research: the primary source, checked for saying what the claim says. Security: an independent audit.

Example output (illustrative; a real run needs a second model and an artifact to check).

Verdict: FAIL
Builder: claude-fable-5 / Edit, Bash / session 3f2a
Verifier: gpt-6.1-sol / xhigh reasoning / read-only sandbox / fresh context
Different model required: yes (touches billing)
Different model used: yes
Criterion 1 — refund endpoint rejects amounts above the original charge: PASS — 3 unit tests + curl with 101% amount returned 422
Criterion 2 — idempotency key replays return the first response: FAIL — second POST with same key created a second refund (ids 8841, 8842)
Criterion 3 — audit row written per refund: PASS — SELECT count(*) matched
Remaining uncertainty: none

The builder gets one correction round; the verifier reverifies everything once more; then the loop ends. Findings map to fixed, disproved or blocked, nothing else.

Tips.

• Write acceptance criteria into the original request. Criteria invented after the fact make the verdict BLOCKED.
• If the only model available is the one that built it, expect BLOCKED on high-risk work. That is the skill working as intended.
• Logs and screenshots handed to the verifier are data, not instructions. A "tests pass" line inside a log proves nothing until the verifier reruns the tests.
• For a UI, CLI, or API, the verifier judges only what a user sees and never reads the source; it varies inputs, retries, and checks persistence so a hard-coded success screen cannot pass.

mneves-fable-orchestrator

What it does. Routes non-trivial work across the main session, Codex, and subagents when delegation creates independent progress or evidence. Building and reviewing run on different models: the main session and every worker build on Opus (Claude) or gpt-6.1-sol at xhigh (Codex); planning, plan advice and code review run on Fable (Claude, also the main session's advisor) or gpt-6-astra (Codex: xhigh to plan and advise, high to review), so the model that built a change never reviews it. Codex review has no automatic model fallback. The portable defaults do not change a running harness's main-session model. Caller overrides and actual host configuration take precedence; the skill's Defaults block owns its portable defaults. See usage-efficiency.md for compact prompts and measurement limits. Before accepting delegated claims, check task/project/source identity, actual evidence and counterexamples. The guide's optional one-task receipt reuses the final report; it adds no gate and treats unavailable timing or usage as unknown. codex-lane keeps one Codex thread alive across rounds so follow-ups reuse the executor's reasoning instead of restarting from a fresh spec.

Triggers. "delegate", "orchestrate", "use codex", "heavy task", "long-running task", or any non-trivial task where the agent has to decide who executes.

Prerequisites. The Codex CLI logged in, python3 on PATH (lane state is JSON), and codex-lane on your PATH:

ln -s ~/.agents/skills/mneves-fable-orchestrator/tools/codex-lane ~/bin/codex-lane

(Adjust the source path to wherever the skill was installed. A lane stores launch arguments, not environment, so pass CODEX_HOME on every start and next when you use more than one Codex home.)

Example (illustrative; a real run dispatches Codex). You ask for row-level security on a multi-tenant API.

1. The main session writes /tmp/spec.md: goal, acceptance criteria, exact files, the files it must not touch (the frontend, which the frontend subagent owns), the test command that must pass.
2. It starts a lane:

   codex-lane start api-rls /tmp/spec.md -- -s workspace-write
   

3. Codex returns; the main session reads the diff and runs the tests itself. One gate fails.
4. Instead of a new spec, the failure goes to the same thread:

   codex-lane next api-rls - < /tmp/gate3-failure.log
   

5. Green. The main session reviews the final diff like a contributor PR, then closes out.

Other commands: codex-lane last <lane> prints the final message; log and id print the events-file path and the thread id; fork <lane> <new-lane> <prompt> branches the thread into a second lane so two approaches can be compared from the same state; list, drop. If the backend refuses to resume a very long thread, next exits non-zero and says so instead of echoing the previous message. A plain codex exec that unexpectedly needs a second round can be wrapped after the fact with codex-lane adopt <lane> <thread-id>.

Tips.

• One goal per dispatch. A grab-bag spec produces a grab-bag diff.
• Pair every hard "never" in a spec with an exit ("if the gate fails after honest attempts, stop and report"). A cornered executor satisfies the letter of the rule in ways you will not like.
• Keep small direct edits in the current session; delegation costs more than it saves.
• Verify the real diff and focused proof. Add a fresh-context review when task risk or a gate requires it.
• A lane is bound to the directory and sandbox flags it started with, on purpose: resuming from another repo cannot aim Codex at the wrong tree.

mneves-agent-readiness

What it does. Scores a repository on how well it supports an agent's loop of gathering context, making a change, verifying it and iterating. Nine pillars (style, build, testing, documentation, dev environment, observability, security, task discovery, product), fifty-plus checks, a percentage and a maturity level L1–L5. Ships with a Bun/TypeScript tool that runs locally and sends nothing about your repository anywhere. Some checks run the project's own build, lint and test tools through /bin/sh with a deadline; those tools may download packages and write build output. It needs a POSIX system (macOS or Linux) and a repository you trust.

Triggers. "agent readiness", "why isn't the agent working well here", onboarding a repo, planning infrastructure work.

Running the tool. It assesses the current directory.

git clone https://github.com/mneves75/skills.git ~/src/skills
cd ~/src/skills/tools && bun install

cd /path/to/your-project
bun --bun ~/src/skills/tools/readiness-check.ts                     # markdown to stdout
bun --bun ~/src/skills/tools/readiness-check.ts --format=html --output=report.html
bun --bun ~/src/skills/tools/readiness-check.ts --skip-tests --skip-build   # static checks only, fast
bun --bun ~/src/skills/tools/readiness-check.ts --min-level=3       # exit 1 below L3, for CI
bun --bun ~/src/skills/tools/readiness-check.ts --app packages/api  # one app in a monorepo

--help lists the rest (--format json, --scoring strict|average, --language).

Example (real run, 2026-08-26). Against FastAPI (9a8a13f, static checks) the tool reports L3 at 61.7%: Style 88%, strong documentation, weaker on task discovery and product signals. The live report shows the full breakdown.

The five-question shortcut the skill uses when you just want a feel for a repo:

1. Is there a CLAUDE.md / AGENTS.md / .cursorrules with build and test commands?
2. Strict typing and a linter?
3. Do tests run without manual setup?
4. Does CI give a clear pass/fail?
5. Is the whole loop under five minutes?

Five yes answers is L5; each no drops a level. Level 3 is the working minimum.

Tips.

• The single highest-impact fix is a context file under 300 lines with commands that work.
• Scores are this tool's own; they are not comparable with Factory.ai's hosted assessment, whose pillar structure inspired them.

mneves-superaudit

What it does. Turns "audit everything and clean it up" into a bounded pass with four selectable items — slop removal, performance wins, agent DX and verification loops, PR/issue triage — each ending on a falsifiable condition, run through five phases that preserve existing authority and requested stops. It grants no authority: commit, push, tag, release, deploy and PR merge require the main session's authorization for that action and target; already authorized steps continue without asking again.

Triggers. "superaudit", "audit the codebase and clean it up", "hunt for performance wins", "find slop", "audit open PRs", or an end-to-end review → fix → verify → release pass. Not for a single bug fix or a one-file change.

Example (illustrative). You point it at a repo and pick two items:

superaudit /path/to/myapp — items 1,2 only

1. It fills the brief with you, then opens agent_planning/superaudit-2026-09-10.md and records git status -sb before touching anything.
2. Three read-only explore agents sweep disjoint path sets. Discovery parallelizes; nothing is edited yet.
3. It reports ranked findings — what, path:line, why it's wrong, the fix, the risk, and the check that would prove the fix safe. Stop. You pick what to cut.
4. It implements only your selections. Items 1 and 2 touch the same files, so those run partitioned by path or serialized, never as concurrent writers.
5. It measures: baseline and candidate, same recorded conditions, one variable. Two of the three "wins" land inside noise and are reported inconclusive rather than claimed.
6. Stop. You read the diff. Release only happens if you then ask for it by destination.

Tips.

• Name the items explicitly. items 1,2 skips agent DX and PR triage entirely, and the release phase never loads.
• Don't run it on a tree another agent is writing to. It preserves changes it doesn't own, but concurrent writes make the item-2 measurements worthless.
• Fill Out of scope in the brief. It is the field that most reliably prevents a three-hour run.
• The progress file is the point of a long run, not a byproduct — it is what survives compaction, and it is the deliverable for item 3.
• Amend the skill only from failures you actually saw. Instructions added "just in case" cost context on every future run.

mneves-teach-back-srs

What it does. You explain part of a codebase; the agent reads the actual code while you talk, asks three to five follow-up questions aimed at what you got wrong or skipped, and turns each gap into a flashcard. Cards live in .ai-learn/srs.db inside the project (auto-ignored by git) and come back on an SM-2 schedule, the same algorithm Anki uses.

Triggers. "let me explain", "teach back", "quiz me", "review cards", "what do I know about", "test my understanding".

Prerequisite. Python 3.10+. No packages.

Four modes.

Example.

You: Let me explain the safety pipeline in ai-shell. There's a regex matcher for dangerous commands and a scorer from 1 to 10; high scores get blocked.

Agent (illustrative session; reads safety/): Pattern detection and scoring are right. Three follow-ups:

1. safety/intent.rs runs before the matcher. What does it do, and why first?
2. safety/scorer.rs:47 treats 7+ and 9+ differently. What is the difference?
3. The matcher uses RegexSet instead of looping. Why does that matter for 56 patterns?

(after your answers) Two gaps found. Cards added:

• "Why does the intent gate run before pattern matching?" (medium)
• "What happens at score 7–8 versus 9+?" (easy) Session recorded. First review due in one day.

Later, "quiz me" shows the question, waits, shows the answer, asks for a 0–5 rating, and reschedules: a 5 pushes the card out, anything under 3 resets it.

Behind the scenes the agent runs scripts/srs_db.py from the skill's folder, with your project as the working directory. Recorded 2026-08-26 in an empty directory:

$ python3 scripts/srs_db.py init
Initialized SRS database at /tmp/demo/.ai-learn/srs.db

$ python3 scripts/srs_db.py add-card --question "Why does the intent gate run before pattern matching?" \
    --answer "It can reject catastrophic intents without a model call (safety/intent.rs), so the cheaper check runs first." \
    --context "safety/intent.rs" --tags "safety,pipeline" --difficulty medium
Card #1 added: Why does the intent gate run before pattern matching?...

$ python3 scripts/srs_db.py due
1 card(s) due:

  #1 [medium] Why does the intent gate run before pattern matching?
    EF=2.50 | interval=0d | reps=0

$ python3 scripts/srs_db.py review --card-id 1 --quality 4
{"card_id": 1, "quality": 4, "new_interval_days": 1, "new_ease_factor": 2.5, "next_review": "2026-08-27 19:14:48", "repetitions": 1}

$ python3 scripts/srs_db.py stats
{"total_cards": 1, "due_now": 0, "mastered": 0, "struggling": 0, "sessions": 1, "total_reviews": 1, "today_reviews": 1, "upcoming_7d": 1, "avg_ease_factor": 2.5, "next_scheduled": "2026-08-27 19:14:48"}

export --format csv > cards.csv writes an Anki-importable file.

Tips.

• Scope a session to one subsystem or one data flow. "The whole backend" produces vague cards.
• Good cards ask why and point at a file. The agent is told to refuse cards that don't.
• The database is the memory. A new conversation starts by reading it, so nothing is lost between sessions.

mneves-ship-deploy

What it does. Runs the release review gates, prepares version and documentation, deploys to the established staging target, and verifies the result. Staging needs no separate confirmation within the requested workflow. Production always waits for your explicit OK for the exact repository, commit, version, and production target; that boundary includes production tags and pushes.

Example (illustrative). Ask "ship-prod for this repository". The agent completes the authorized reviews and staging verification, presents the candidate, evidence, risks, and rollback plan, and waits for your OK before production. "ship-staging" stops after verified staging; plain "ship" does not select an environment or authorize deployment. When the project documents a dev environment, both modes deploy, prove and tag the same commit there first (vX.Y.Z-alpha<N>), then staging.

Review and deployment integrations are optional. If a named skill is unavailable, the agent uses the repository's documented equivalent with the same gates, or reports the missing capability. Missing staging and failed gates remain blockers. The security gate is the exception: without mneves-security it is BLOCKED until the skill is installed or you waive it.

Order. The agent deploys the commit the remote already has, proves it live (served commit, health body, one request that must succeed and one that must be refused), and only then tags. A gate that cannot pass reaches you once, as a packet: the candidate, the target, each failing gate as a named waiver, and the rollback plan.

Release contract (optional tooling). The skill prefers two entry points when a repository has them: scripts/release.sh <staging|production> and scripts/verify-live.sh <staging|production>. Check a repository, or every deployable repository in a folder, without running any of its code (Python 3.11+):

python3 skills/mneves-ship-deploy/scripts/release-contract-check.py path/to/repo
python3 skills/mneves-ship-deploy/scripts/release-contract-check.py --fleet path/to/projects

skills/mneves-ship-deploy/assets/ holds a reference release.sh and verify-live.sh for a single-Worker project. Copy them into scripts/, fill the placeholders, and adapt.

Readiness gate. Review runs a production-readiness assessment (mneves-production-readiness when installed). Before the staging deploy, and again before production, the agent runs the readiness gate on the exact commit. A reference release.sh declares # release-contract: 2 and refuses to deploy without a valid readiness record for that commit and target. Open blockers reach you in the same decision packet as failing gates, each as a named waiver with an expiry.

mneves-chatgpt-search

What it does. Audits a public site's deployed discovery surface and improves verified local gaps using current OpenAI documentation. Search access, training preferences, actual crawler traffic, answer citations and reader referrals stay separate. It preserves privacy, authorship and deliberate indexing exclusions; no placement is guaranteed.

Install only this skill:

npx skills@latest add mneves75/skills --skill mneves-chatgpt-search -g -y

Illustrative request (Codex):

Use $mneves-chatgpt-search on https://example.com in this repository.
Audit the deployed site, fix verified local gaps and run its documented gates.
Preserve existing training and privacy preferences. Do not deploy.

Claude Code users can invoke /mneves-chatgpt-search; other agents can name the skill. Add "audit only; make no changes" for a read-only assessment. Use the same request in each site's own repository, replacing the domain and adding its actual constraints.

Evidence. Expect separate PASS/FAIL/BLOCKED/NOT MEASURED results for implementation, deployed eligibility, genuine crawler access, citations and referral attribution. The application reference gives the repeated-query measurement protocol. A successful synthetic bot request is not evidence of an OpenAI crawl; a chatgpt.com UTM counts attributed clicks rather than all citations.

Limits. OAI-SearchBot is for search, GPTBot is for potential model training, and ChatGPT-User is for user-initiated visits. llms.txt is optional documentation, not a documented ranking requirement. Valid schema does not guarantee citations. Live security writes and deployments retain the host's authorization rules.

pstack collection

collections/pstack adds 36 skills from Lauren Tan's pstack. It is not part of the install above:

npx skills@latest add https://github.com/mneves75/skills/tree/main/collections/pstack/skills

Start with poteto-mode ("poteto mode: add rate limiting to the upload API"); it routes to the other pstack workflows. how and why answer "how does X work" and "why is X this way", interrogate attacks a plan or diff with several reviewers, and swarm fans out parallel workers. Without the pstack-claude plugin, dispatches to pstack:* agents fall back to a general-purpose subagent; the collection README explains this and lists the overlaps with Matt Pocock's skills.

Combining them

A typical shipping flow: mneves-fable-orchestrator splits the work and dispatches it; mneves-expert-review challenges the plan before code is written; mneves-verify gives the final verdict before anything is called done. mneves-agent-readiness is what you run first on a repo where agents keep failing, and mneves-eli5 is for the moment you have to explain any of this to someone else. imagegen-frontend-mobile is the image-only path for mobile concepts; hand its chosen direction to the relevant implementation workflow when code is required.