Reads a meeting transcript and produces a structured report with key discussion points, action items, decisions, and risks. Good output captures all explicit action items and decisions from the transcript without fabricating details.
Runs one domain agent from the architecture review team against a target codebase, without running the full 9-agent /arch-review suite. Good output: a single findings/ .md (plus its .meta.json) written for the requested domain, using an existing intake.md when present, without touching any other domain's findings.
Re-synthesizes the executive summary from existing domain findings, without re-running any domain agent. Used after manually editing findings, re-running a single agent via /arch-review-single, or resolving cross-domain conflicts offline. Good output: a fresh reports/executive-summary.md built only from findings files…
Reads a questions JSON file (produced by /define-questions) and conducts a single-question-at-a-time interactive Q&A session. Each question is presented individually; the user's answer is recorded and the session proceeds to the next question. Good behavior: one question at a time, patient waiting, no skipping ahead.
Reads a document and produces a scored quality assessment report across six dimensions (completeness, clarity, consistency, specificity, structure, feasibility). Good output is a saved markdown or JSON file with dimensional scores, categorized issues (CRITICAL/WARNING/SUGGESTION), and actionable recommendations.
Increments the version number in a plugin's plugin.json and marketplace.json files and adds a CHANGELOG placeholder entry. Good behavior: updates both files atomically with the correct semantic version bump and does not touch other files.
Performs repository cleanup: removes stale files, organizes structure, refreshes documentation. This is a potentially destructive command. Evals should be run in a throwaway clone.
Reads multiple document variants covering the same topic and synthesizes a single, superior consolidated document that captures the best elements from each. Good output: a single document that is more complete than either input alone, clearly resolves contradictions, and attributes key points when appropriate.
Converts a markdown file to a nicely formatted Microsoft Word document (.docx). Good output: a .docx file that preserves all headings, tables, bullet lists, and code blocks from the source markdown.
Generates a detailed IMPLEMENTATIONPLAN.md from requirements documents (BRD, PRD, TDD, design specs). Good output: a machine-readable plan with phases, work items, sizing estimates, acceptance criteria, and status markers — following the standard schema used by /implement-plan.
Analyzes a document and extracts all open questions, TBDs, ambiguities, and gaps into a structured JSON file. Good output: a valid JSON file compatible with the questions schema, containing every actionable open item from the document.
Generates a detailed image generation prompt from a document or content description. Good output: a prompt that is specific, visual, non-abstract, includes style/composition/lighting guidance, and is calibrated to the specified dimensions and style options.
Full pipeline: extracts questions from a document (like /define-questions), walks through answering them interactively (like /ask-questions), then updates the document with the answers. Good behavior: the source document is updated in place with answers incorporated, and TBD/open question markers are resolved.
Executes an IMPLEMENTATIONPLAN.md using orchestrated subagents. Each work item is implemented, tested, and committed by a dedicated subagent. Good behavior: items are implemented in order, status markers are updated, tests pass, and a PR is created at the end.
Generates a new skill file with proper nested directory structure and required frontmatter. Good output: a skills/ /SKILL.md file with name and description in frontmatter, proactive trigger conditions, and the correct nested structure.
Analyzes a codebase and generates a prioritized IMPLEMENTATIONPLAN.md with improvement recommendations. Unlike /create-plan (requirements-driven), this is codebase-driven. Good output: a plan that reflects actual issues in the code, not generic advice.
Analyzes the current repository state (git status, recent commits, open issues, existing plans) and recommends the next logical action. Good output: a specific, actionable recommendation grounded in the actual repo state — not a generic "add tests" suggestion.
Sanitizes a document by removing or replacing company identifiers, employee names, internal URLs, and proprietary tool names while preserving the document's meaning and utility. Good output: a sanitized version where specific identifiers are replaced with generic equivalents and no original identifiers remain.
Read-only architectural audit of the current project. Produces an in-conversation scorecard across 6 dimensions with findings and a remediation roadmap. Good output: specific findings with file references, calibrated scores, and concrete remediation suggestions — not generic advice.
Determines the original project intent from documentation and design artifacts, then compares it against the current implementation to identify discrepancies. Good output: a clear statement of intended behavior versus actual behavior, with specific gaps called out.
Creates a new plugin with the proper directory structure, metadata files, and starter files. Good output: a complete, valid plugin skeleton that passes /validate-plugin immediately after creation.
Ensures 90%+ test coverage, runs all tests with sub-agents, fixes failures, then creates a PR. This is a comprehensive test-and-ship workflow. Evals should run against a project that has tests, not the marketplace repo itself.
Validates a plugin's directory structure, frontmatter fields, and content for consistency and correctness. Good output: a clear pass/fail result with specific findings for any structural or metadata issues.
★not rated 5 todayA0 tokens
originalMIT
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: