core

Plugin core from marketplace mintuz-skills in mintuz/skills. Commands read from the repo's manifest — today.

Skills (32)

• acceptance-review

  WHEN deciding whether a PR, branch, diff, or current code satisfies an authoritative issue, specification, or decision contract; NOT for reconstructing meetings, tracing decision lineage, general code review, or implementation; returns a criterion-by-criterion proof and acceptance verdict.

• adam-mode

  WHEN explicitly invoked as /adam-mode or asked to work in Adam's style; NOT for automatic invocation; routes the task to a playbook, loads the principle and domain skills it needs, delegates through adam-agent and proves the result before it reports.

• architect

  WHEN shaping non-trivial code whose types, signatures or module boundaries are not settled, before implementation; NOT for edits inside one function, read-only explanation, or work whose design is already agreed; sketches caller usage, types and module boundaries through arena, then implements again

• arena

  WHEN choosing between alternative shapes for a non-trivial artifact (code, interface, prompt, document or visual direction) by producing several independent attempts in one pass, judging them against a rubric, picking a base and grafting in the best parts of the others; NOT for raising one artifact

• babysit

  USE WHEN a branch with committed work must reach green CI and merge while the user is away, or WHEN you are about to write a loop that polls or re-runs CI for one branch; NOT WHEN you watch many PRs as an agent inbox (github-monitor), only draft a PR description (pr), write commit messages (commit-m

• benchmark-checklist

  WHEN validating a benchmark or measured performance claim; NOT for an unmeasured optimization guess; checks completed work, fairness and repeatability

• blast-radius

  WHEN investigating impact analysis or what a change could break beyond its diff; NOT for a requirement verdict; maps material risks and decisive checks

• commit-messages

  WHEN writing git/conventional commits; NOT for PR text; returns concise, why-first commit lines with proper type/scope.

• correct

  WHEN preventing a repeated codebase mistake; NOT for one-off hypotheses or writing preferences; proves scoped mechanical enforcement

• create-verification-skill

  WHEN bootstrapping a reusable project verification recipe; NOT for routine runs or ongoing bundle maintenance; records indexed journeys, deterministic checks and cold-replay evidence

• creative-seed

  WHEN creating UI concepts, prototype designs or exploratory visual variants whose look is open; NOT for matching an agreed mock-up or repair rounds on a picked design; derives each variant's creative direction from a deterministic seed string that the design never shows.

• double-check

  WHEN finished work, review findings or a done claim needs a second opinion, or before shipping high-stakes work such as security, money, migrations or destructive changes; NOT for routine checks while building, unfinished drafts or a spec acceptance verdict; briefs a read-only reviewer cold, checks

• gauntlet-loop

  WHEN a user asks for a Gauntlet Loop or relentless improvement of one ambitious artifact against a concrete, inspectable bar over repeated rounds; NOT for routine changes with clear acceptance tests, or for choosing between alternative shapes in one pass (arena); coordinates separate builders and fr

• github-monitor

  WHEN monitoring open PRs and issues as an agent inbox, or sending messages to other agents through GitHub, Forgejo, or Gitea comments; NOT for shipping code, reviewing diffs, or watching one PR's checks until it is green and merged (babysit); polls with gh or tea from one scripted cycle, routes mess

• graph-engineering

  WHEN orchestrating interdependent specs, stories, or work items across agents—deciding what runs serially, what may run in parallel, and how each unit is independently verified; NOT for single-task delegation, code review, or PR delivery mechanics; returns a contract-first execution graph with a per

• how

  WHEN explaining code flow, current execution, or state ownership; NOT for historical rationale or redesign; gives an evidence-grounded walkthrough

• in-your-own-words

  WHEN explicitly invoked as /in-your-own-words; NOT for automatic invocation; restates the user's goals and underlying problem for confirmation

• maintain-verification-skill

  WHEN auditing or refreshing an existing project verification bundle and its harness discovery; NOT for bootstrapping, routine execution or product fixes; repairs owned recipes and reports full coverage honestly

• pr

  WHEN drafting PR descriptions, sizing/splitting work, or opening pull requests on GitHub or Forgejo/Gitea; NOT for commit messages; provides reviewer-first templates and gh or tea pr steps.

• pseudocode

  WHEN rendering pseudocode of how code composes—module boundaries, types, signatures, arguments, and execution flow—for code that exists or a change about to be built; NOT for code review, verdicts, diagrams, or implementation; returns the shape and a cited call graph.

• recall

  WHEN recovering prior working context, an earlier decision, or a named session; NOT for habit mining; reconciles bounded history with live state

• record-lesson

  WHEN preserving a durable project learning, gotcha, or decision in repository instructions such as AGENTS.md or CLAUDE.md, including when the user names the file; NOT for trivial or one-off details; checks the authoritative instruction file and writes the smallest safe rule.

• reducer

  WHEN reducing whole-system complexity—branches, state, dependencies, layers, or moving parts—in an existing system or feature; NOT for functionality cuts or unproven rewrites; derives the minimum mechanism from first principles and proves behavior and guarantees are conserved.

• sharpen

  WHEN explicitly invoked as /sharpen; NOT for automatic invocation; makes a task deeper, not bigger, and returns the analysis plus a rewritten prompt

• tdd

  WHEN using framework-neutral TDD Red-Green-Refactor in any project; NOT for merely classifying runtime evidence or replacing the project's test framework; proves failing-before and passing-after tests, then assesses refactoring.

• teach

  WHEN explicitly invoked as /teach by a person who wants to be tutored, quizzed or drilled to mastery on a topic; NOT for automatic invocation, one-off \"explain X\" or \"what is X\" questions, or recording lessons into AGENTS.md or CLAUDE.md; runs a Socratic tutoring session with a diagnostic, a 0–5

• visual-feedback

  WHEN assessing a reported visual issue or iterating on agreed visual changes in a web or iOS app; NOT for unattended visual-regression suites or requirement acceptance; reproduces actual states and compares evidence before and after authorised changes.

• why

  WHEN investigating why this code exists, its rationale, or design tradeoffs; NOT for runtime walkthroughs; separates historical facts, inference and unknowns

• writing-for-agents

  WHEN writing cross-agent messages, handovers or delegation briefs, or creating/editing agent skills; NOT for human-facing tutorials, marketing copy or code implementation; produces concise instructions without losing operational meaning.

• writing-for-humans

  WHEN drafting, editing or reviewing human-facing prose, including articles, docs, messages, marketing and UI text; NOT for agent instructions, skill authoring, code implementation or AI-authorship detection; improves clarity and voice while preserving facts and specialised formats.

• wtf

  WHEN the immediately previous LLM response was unclear, too dense, or hard to follow; NOT for doing the work that response describes, and NOT for writing a new document from it; returns a plain UK English re-explanation that keeps every detail that changes how the response should be understood.

• yagni

  WHEN changing production code under this codebase's working agreements, or when a task risks overengineering—extra abstractions, speculative design, or test sprawl; NOT for removing complexity from existing code; enforces TDD, minimum sufficient execution, hard scope boundaries, and documentation pr

Subagents (1)

• adam-agent

  Delegate for code, review and research tasks spawned during an `/adam-mode` run. Use for delegates, not as the runner for `/adam-mode` itself. Spawn a fresh `adam-agent` for each new task. Reads the `adam-mode` SKILL.md in full before any work; a general-purpose agent without that read drifts.

MCP servers (1)

• memory

  runs: npx -y @modelcontextprotocol/server-memory

Similar plugins