vibe-grimoire

Autonomously implement a specification produced by the specify skill. Reads the spec document, builds a task queue in the session database, implements tasks in parallel where dependencies allow, runs deterministic checks, spawns adversarial verification (different model), and iterates until all evaluation criteria pass or convergence is reached. Use when the user has a spec document (from the specify skill or a similar structured spec) and wants it implemented with guaranteed quality verification. Trigger phrases: "implement this spec", "build this", "execute the spec", "implement-spec", "start implementation", "make it happen", or when the user points to a ./specs/*.md file and asks to build it. Also use when the user has just finished using specify and says "now build it", "go", or "implement".

Guide the user through a structured specification process: define the goal, specify exactly what to build (and what NOT to build), and establish measurable evaluation criteria — all before implementation begins. Produces a living spec document. Use when the user has a goal or feature idea and wants to define the spec, says "specify this", "what's the spec", "define the specification", "how do I achieve this goal", "break this down", "what do I need to build", "write a spec", "define requirements", wants to create a specification with verification criteria, or has just finished using the-goal and wants to turn the goal into a precise, implementable specification. Also use when the user wants to define evaluation criteria before coding, or mentions "adversarial verification", "quality criteria", or "acceptance criteria".

Author, validate, and debug GitHub Copilot CLI extensions that add tools, commands, hooks, or session-event behavior. Use when creating or reviewing a Copilot CLI extension, wiring `joinSession`, deciding between project, user, or session scope, troubleshooting extension loading, or adding a custom Copilot CLI tool or slash command. Also use when the user wants a custom Copilot CLI extension scaffold or asks how extensions work.

Interview the user step-by-step to gather every detail needed to build a Microsoft 365 Copilot Cowork plugin package (manifest.json + skills + optional MCP connectors), then produce a complete, self-contained build prompt the user can review or hand off for execution. Use when the user asks to "create a cowork plugin", "build a copilot plugin", "make a M365 copilot agent package", "package my skills as a plugin", "create a copilot agent with MCP", "build a plugin for copilot cowork", or "wizard me through a cowork plugin". Do NOT use for: creating a single personal skill (use the `skills` skill instead), installing an existing plugin, troubleshooting plugin uploads that already exist, or general M365 admin questions.

Extract and clarify the real goal behind a feature, change, or idea through a focused interview. Inspired by Goldratt's *The Goal*. Use this skill whenever the user has a vague idea, a new feature request, or a change they want to make but the underlying goal is unclear, implicit, or too broad. Also use when the user says things like "I want to build X" without articulating why, or when scope creep is a risk and the real constraint needs to be identified first. This skill does not plan or solve — it only finds the goal.

Interview the developer about their workflow goals and produce a valid Playbook YAML file saved to ./playbooks/<name>.yml. A Playbook is a machine-executable workflow graph: Phases (logical groupings) containing Tasks (atomic executable units with inputs, outputs, dependencies, and success criteria). Trigger this skill when the user wants to design, create, edit, or author a repeatable multi-step agentic workflow. Covers the full interview → validate → save flow, including updating existing playbooks.

Read a Playbook YAML file and execute its tasks: resolve !include prompts, substitute variables, validate schema, topologically sort, then execute independent tasks in parallel batches delegating each to the appropriate executor (agent or human). Handles on_failure rules (stop/skip/retry/ fallback), pauses on human executor tasks, and reports progress throughout. Trigger when the user says "run playbook", "execute playbook", or provides a path to a .yml playbook file.

Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue, Azure DevOps work item, or local file. Use when the user wants to create or write a PRD, create a product requirements document, design a new feature, or capture requirements.

Launch a bounded adversarial review panel for code, PRs, designs, PRDs, or docs. The first pass establishes the review contract: baseline, scope, blocker policy, desired end state, and a state file for medium/complex reviews. Later passes verify whether the agreed blockers were cleared instead of reopening the whole problem space. Reviewers stay explicitly adversarial — challenging assumptions, surfacing failure modes, and questioning design choices without bias toward the existing work. Use when the user asks for a critical review, design critique, architecture review, or red-team style feedback such as "tear this apart", "what could go wrong?", or "review this PR".

Run a pre-mortem on a plan, idea, or PRD: stress-test a design by assuming it failed, then relentlessly interrogate every branch of the decision tree to find out why so the user can fix it before implementation starts. Two modes: (1) idea/plan exploration — no document yet, use pre-mortem to surface implications and shape a design; (2) PRD stress-test — an existing PRD or design doc, use pre-mortem to expose contradictions, missing assumptions, and functional ramifications. Use when the user wants to stress-test a plan, asks you to "ask me", says "interrogami" or "fammi domande", mentions "pre-mortem", "design of design", or wants rigorous design discovery before implementation.

Turn a PRD into a multi-phase, local Markdown implementation plan using tracer-bullet vertical slices, saved to ./plans/. Use when the user wants to create an implementation plan from a PRD, plan phases from a PRD, break a PRD into development phases, or mentions "tracer bullets" or "implementation phases". For creating tracker work items (GitHub Issues, Azure DevOps, Jira) use the prd-slice skill instead.

Break a PRD into independently-deliverable work items (vertical slices / tracer bullets) and create them in Azure DevOps, GitHub Issues, or Jira. Use when a user wants to convert a PRD into implementation tickets, decompose a product spec into trackable slices, create work items from requirements, or break down a PRD for any issue tracker — even if they don't say "vertical slice" or "tracer bullet".

Audit code for cleanliness: naming, function size and shape, class responsibilities, SOLID violations, comment hygiene, and Law of Demeter violations. Trigger when the user wants a clean code review, a naming audit, wants to apply SOLID principles, asks "is this code clean?", "are these names good?", "this function feels too big", "does this class do too much?", "should I break this up?", "is this DRY?", "does this violate SRP?", mentions "clean code", "Uncle Bob", "SOLID", "single responsibility", "open-closed", "dependency inversion", "interface segregation", "Law of Demeter", "Tell Don't Ask", or asks for a professional code quality review. Also trigger for: "is this readable?", "rename this", "what should I call this?", "this name is confusing". Trigger when a user pastes code and asks for general feedback — even without mentioning "clean". Trigger when reviewing a PR, when naming feels off, when a class is growing too large. When in doubt, run a clean-code pass — it catches issues every other skill misse

Use this skill whenever the user mentions any pattern by name, any code that smells like it wants a pattern, asks about structure, coupling, or abstraction — even if they don't say "design pattern". Don't wait to be asked explicitly. Trigger on: giant if-else chains on type, telescoping constructors, "how do I add behavior without subclassing?", "this is getting messy", "how do I decouple this?", "is this a Strategy or a State?", mentions of GoF, PEAA, Hexagonal Architecture, Ports & Adapters, DDD tactical patterns, or any named pattern. Also triggers when code shows a pattern applied incorrectly, unnecessarily, or when a simpler pattern would serve better than what the user reached for.

Apply Domain-Driven Design principles: model the core domain, define bounded contexts, build context maps, design aggregates, identify domain events, and surface ubiquitous language. Use this skill early — a bad domain model compounds over time. Triggers: when teams argue about where logic should live, when the same word means different things to different teams, when a service is growing out of control, when someone says "our model doesn't match how the business thinks", when preparing a new microservice boundary, when the user says "the model feels wrong", "our domain is getting complicated", "we have inconsistent naming across teams", "where should this logic live?", "what's the aggregate root here?", "are these the same bounded context?", "strategic design", "tactical DDD", "what's the core domain?", "this looks like an anti-corruption layer", mentions "DDD", "Evans", "Blue Book", "domain events", "CQRS", "event sourcing" (strategic layer), or asks how to structure a complex multi-team system. Also trigge

Analyze code, architecture, or systems for real performance costs — runtime complexity, memory allocation patterns, I/O bottlenecks, lock contention, cache behavior, and unnecessary abstraction overhead. Use when the user has a performance problem, asks "why is this slow?", "is this efficient?", "what's the complexity of this?", "will this scale?", "is this over-engineered?", "does this need to be this complex?", "what's the runtime cost?", "profiling this", "find the bottleneck", "it's too slow in production", "latency issues", "memory pressure", "CPU bound or I/O bound?", mentions "Big O", "profiler", "cache miss", "lock contention", "performance regression", or asks for a systems-level reality check on an architecture. Trigger proactively when reviewing any code that runs in a hot path or on every request, when reviewing database queries, when a codebase has nested loops, or when evaluating architecture complexity. Use this skill proactively — not just when something is already slow. Catching O(n²) algorit

Apply specific behavior-preserving refactoring moves to improve code structure without changing observable behavior. Trigger when: code has long methods (more than ~20 lines), a user says "this is getting complicated" or "how do I clean this up safely", someone is preparing to apply a design pattern, a method is doing more than one thing, you see Feature Envy or a conditional dispatching on type. Also triggers on: "extract this method", "move this field", "replace this conditional", "inline this variable", "introduce a parameter object", "pull up this method", "push down this field", "how do I refactor this safely?", or any named refactoring from Fowler's catalog. Trigger this skill before applying any design pattern — refactoring prepares the ground. Distinct from refactoring-plan (which plans the overall strategy) — this skill executes specific moves.

Route a software engineering task to the right member(s) of The Immortals — a council of five legendary developer personas — and synthesize their perspectives. Trigger this skill whenever the user invokes any @alias (even a single immortal mention), whenever a task spans multiple engineering concerns (design + testing + performance + domain), or whenever the user seems uncertain about which direction to go. When in doubt, invoke the full council — five perspectives cost nothing and frequently surface blind spots that a single-lens review misses. Also use when the user says "get the team", "what do the legends think", "council session", or when a task is architectural in scope. Individual overrides (@fowler, @beck, @uncle-bob, @evans, @linus) skip routing and go directly to the named member.

Create runtime-aware hook enforcement for repo tool constraints. Use this whenever a project must force a package manager, task runner, formatter, linter, or test runner; when the user asks to "create a hook", "enforce pnpm not npm", "block banned commands", "generate Copilot hooks", or "generate OpenCode plugin enforcement"; and whenever setup should move operational tool policy out of AGENTS.md and into hooks. Also use for: "add git safety guards", "block git push force", "block rm -rf", "prevent dangerous deletes", "add git guardrails", "add default tool guards", "protect against destructive commands", or "apply default hooks".

Claude Code workflow tips from Boris Cherny (creator of Claude Code) and the Claude Code team. Use when: setting up Claude Code, optimizing workflows, running parallel sessions, configuring CLAUDE.md, using skills/commands, subagents, hooks, MCP integrations, or learning best practices. Covers: git worktrees, plan mode, verification, permissions, Slack MCP, BigQuery, prompting tips, plugins, custom agents, sandboxing, keybindings, status lines, output styles, customization, /simplify for code quality, /batch for parallel code migrations, /loop for scheduled tasks, code review agents, /btw for mid-task questions, /effort max reasoning, remote control sessions, voice mode, setup scripts, session naming, /color, and PostCompact hook.

Audit a codebase for technical debt: find and remove duplicated code, dead code, god objects, overly complex functions, inconsistent patterns, and other code smells. Use whenever the user wants to clean up code, reduce duplication, remove unused code, simplify complex logic, consolidate repeated patterns, improve code health, or mentions things like "this code is a mess", "we have too much copy-paste", "find all the duplicated logic", "do a code quality audit", "help me pay down tech debt", "clean up before the next sprint", "what needs refactoring", "unused code", "dead code", "we keep writing the same thing over and over", or asks to review code quality or maintainability. Also trigger for phrases like "DRY principle", "consolidate this", "our codebase is getting out of hand", or "I keep seeing this pattern everywhere".

Captures learning moments as short, permanent markdown notes in the project's kaizen/ directory, and registers them in AGENTS.md for progressive discovery. Invoke this skill automatically — without being asked — whenever ANY of these signals appear: the user corrects a mistake you just made ("no", "wrong", "not like that", "undo", "you missed", "that's not right"); the user redirects you after you went down the wrong path; you realize mid-task you made a significant error and had to backtrack; the user has to re-explain something you already got wrong once. This skill is compulsory — every learning must be captured. Do not skip it because the fix is already done. Do not wait to be asked. Invoke it as part of the same response where you acknowledge the correction.

Establish a Canonical Data Model for a project — define authoritative format rules for each primitive type (dates as ISO 8601 with explicit timezone, strings as UTF-8, decimals with explicit precision, identifiers, enums), map every data source to the canonical form with a field-by-field table, generate adapter / validator code, and record decisions in an ADR. Use whenever someone says "canonical data model", "data contracts", "normalize our types", "dates come in different formats from different APIs", "map this API response to our internal model", "how should we store decimals or money", "data format inconsistencies", "interoperability between services", "we need a common format", or when integrating multiple data sources (APIs, databases, files, queues) that use conflicting field formats. Also trigger proactively when you observe that a conversation involves two or more data sources with different primitive-type representations.

Create an Architectural Decision Record (ADR) to formally document a significant technical or architectural choice. Use whenever a user says "write an ADR", "document this decision", "record why we chose X", "capture this architecture choice", "explain why we went with Y", "document the trade-offs", "write up this tech decision", or makes any significant architectural choice that future teammates will need to understand. Also use proactively when you observe a meaningful decision being made during a session — even if the user hasn't explicitly asked for an ADR. ADRs prevent teams from re-debating settled choices and preserve context that would otherwise become tribal knowledge lost to future maintainers.

Create a well-structured issue or bug report in the appropriate tracking system (GitHub, Azure DevOps, Jira). Use whenever a user wants to document a problem, file a bug, capture a regression, log a feature gap, or track a change request — even if they just say "log this", "create a ticket", "file a bug", "add to the backlog", or "I need to track this". Also handles issues pre-analyzed by the triage-bug skill. Adapts to any tracking system and falls back to a copyable template if no CLI is available.

Investigate a bug or unexpected behavior by tracing the root cause through the codebase, then produce a TDD-based fix plan. Use this whenever a user reports a bug, crash, or wrong behavior — even if they say "something is off", "this broke", "not working", "why is X happening", "investigate this", or paste an error message. Also use when the user asks to trace a regression, understand a failure, or plan a fix. This is a hands-off deep-dive that ends with a tracked issue and a concrete fix plan.

Test-driven development with red-green-refactor loop. Use when the user wants to build features or fix bugs using TDD, write tests for existing code, add tests to a module, make code more testable, says "write tests for this", "help me test this", "how do I test this", "my tests keep breaking when I refactor", "I don't know what to test", "should I write the test first", "make this testable", "how do I write good tests", mentions "red-green-refactor", wants integration tests, or asks for test-first development.

Edit and improve writing by restructuring sections, clarifying prose, and tightening flow. Use when the user wants to edit, revise, polish, proofread, or improve a draft; says "clean up my writing", "make this clearer", "this sounds awkward", "tighten this up", "make it more concise", "does this flow well?", or asks for help with an email, README, blog post, PR description, technical doc, or any piece of prose.

Generate multiple radically different interface designs for a module using parallel sub-agents, then compare and synthesize. Use when the user wants to design an API, explore interface options, compare module shapes, asks "how should I structure this", "what's the best shape for this module", "should this be one function or two", "I can't decide between these approaches", mentions "interface design", "API design", "module interface", "how should I model this", "what should I expose", or says "design it twice".

Create a detailed refactor plan with tiny commits via user interview, then submit it as a GitHub issue, Azure DevOps work item, or local file. Use when the user wants to plan a refactor, write a refactoring RFC, break a codebase change into safe incremental steps, reduce technical debt, clean up code, restructure or reorganize a module, rename/move/extract/consolidate components, or says things like "this is a mess", "I need to untangle this", "before I start let's plan", "how do I safely change this without breaking things", or "I want to pay down some tech debt".

Extract a DDD-style ubiquitous language glossary from the current conversation — flags ambiguities, resolves synonyms, and saves a canonical DOMAIN_LANGUAGE.md you can paste into your codebase or PRD. Use whenever the user wants to define domain terms, build a shared glossary, harden terminology, create a ubiquitous language, align on naming, or when the conversation reveals conflicting or inconsistent language. Also triggers on: "ubiquitous language", "bounded context", "domain model", "what should we call X", "are these the same thing", "we keep using these terms interchangeably", "dominio", "linguaggio di dominio", "DDD", or any discussion where the same concept keeps getting called different things.

Manage Azure DevOps resources via CLI including projects, repos, pipelines, builds, pull requests, work items, artifacts, and service endpoints. Use when working with Azure DevOps, az commands, devops automation, CI/CD, or when user mentions Azure DevOps CLI.

Set up or repair a project repository: bootstrap a new repo or update an existing initialized project with AGENTS.md, .gitignore, .gitattributes, hooks, and relevant skills. Use whenever the user wants to set up, refresh, normalize, or fix repo scaffolding.

Patterns and techniques for adding governance, safety, and trust controls to AI agent systems. Use this skill when: - Building AI agents that call external tools (APIs, databases, file systems) - Implementing policy-based access controls for agent tool usage - Adding semantic intent classification to detect dangerous prompts - Creating trust scoring systems for multi-agent workflows - Building audit trails for agent actions and decisions - Enforcing rate limits, content filters, or tool restrictions on agents - Working with any agent framework (PydanticAI, CrewAI, OpenAI Agents, LangChain, AutoGen)

Comprehensive AI prompt engineering safety review and improvement prompt. Analyzes prompts for safety, bias, security vulnerabilities, and effectiveness while providing detailed improvement recommendations.

All changes to code must follow the guidance documented in the repository. Before any issue is filed, branch is made, commits generated, or pull request (or PR) created, a search must be done to ensure the right steps are followed. Whenever asked to create an issue, commit messages, to push code, or create a PR, use this skill so everything is done correctly.