ai-toolkit

Interrogates a plan or codebase using Domain-Driven Design vocabulary. Enforces CONTEXT.md terminology, surfaces code/plan contradictions, and records domain decisions as ADRs sparingly. Use when designing a bounded context, reviewing a domain model, or asked to "apply DDD", "model the domain", or "review the domain model". Creates CONTEXT.md lazily from CONTEXT-FORMAT.md when the first term is resolved. Model-invocable so grill-with-docs, improve-codebase-architecture, codebase-design, and qraspi-architecture can pull it in mid-session. Ported from https://github.com/mattpocock/skills (Matt Pocock).

Shared vocabulary for designing deep modules — a lot of behaviour behind a small interface, placed at a clean seam, testable through that interface. Use when designing or improving a module's interface, finding deepening opportunities, deciding where a seam goes, making code more testable, or when another skill needs the deep-module vocabulary. Pairs with improve-codebase-architecture (which applies it) and domain-model (which supplies the domain nouns). Ported from https://github.com/mattpocock/skills (Matt Pocock).

Deep module refactoring using APOSD vocabulary: eliminates shallow modules, reduces information leakage, resolves temporal coupling, and aligns naming with the ubiquitous language. Use when asked to "improve the architecture", "refactor this module", "apply APOSD", or "clean up the design". Works best after domain-model is established. Ported from https://github.com/mattpocock/skills (Matt Pocock).

Runs a relentless interview to sharpen a plan or design. Use when the user wants to stress-test a plan, get grilled on their design, or says "grill me". Do NOT use when the session should also produce ADRs and a glossary; use grill-with-docs instead.

Runs a relentless interview to sharpen a plan or design, capturing the decisions as ADRs and a glossary along the way. Use when the user wants to be grilled AND wants the session to leave durable domain documentation behind. Do NOT use for a throwaway stress-test with no artifacts; use grill-me instead.

Interviews the user relentlessly about a plan, decision, or idea — one question at a time, each with a recommended answer. Shared engine behind "grill-me" and "grill-with-docs". Use on any "grill" trigger phrase or to stress-test thinking. Do NOT use to build the plan; it ends at shared understanding, not implementation.

Structured multi-pass pipeline for turning raw technical notes into publication-quality Substack/blog posts for a professional software-engineering portfolio. Use whenever the user wants to draft, outline, revise, or polish a Substack post, technical blog article, or portfolio writing piece — especially anything about AI-augmented development, edge AI, RAG, .NET/C#, Python, Rust, APIs, or industrial automation. Trigger even if they just say "help me write a post about X" or paste raw notes to turn into an article. Keeps the human as the source of technical substance and applies editorial craft rather than generating generic filler.

Scaffold vertical slice architecture with CQRS + FreeMediator, including optional Telerik Blazor UI generation. Use when creating feature-based .NET projects with command/query separation and pipeline behaviors. Do NOT use when the project uses layer-based (N-tier) architecture — this skill enforces feature folder structure and will conflict with existing layer conventions.

QRASPI Research phase -- map the solution LANDSCAPE for a new system, factual only, no recommendations. Use for "/qraspi-research <project>", "research the solution landscape for new X", "what libraries / prior art exist for X", "survey the options before architecting X". Mode switch: external-domain (no codebase) or inherited-repo. Do NOT use for QRSPI (an EXISTING codebase / adding a feature) -- that routes to qrspi-research. Do NOT use for the deprecated RPI workflow.

QRSPI Research phase -- objective, ticket-hidden codebase mapping via parallel read-only subagents. Use for "/qrspi-research <feature>", "qrspi research X", "ticket-hidden research", "map what exists for X before designing". Reads the answered questions.md and writes research.md.

Grades an existing .NET solution against the style it actually uses — controller-based layered/N-tier Web API OR vertical-slice CQRS (FreeMediator/Mapster)/Blazor — detecting framework, hosting model, and style FIRST (a layered API is not penalized for not being vertical-slice), then checking architectural coherence, controller/handler discipline, EF Core lifetimes, framework health, and config/secrets hygiene with file:line evidence. Use to review or grade a .NET solution. Not for Socratic critique (architecture-review), security audits (dotnet-security-review), or new test-first code (tdd).

Analyze .NET Framework to .NET 10 migration paths. Use when assessing legacy codebases for modernization, identifying breaking changes, and planning incremental migration strategies. Also

Scaffolds .NET 10 Minimal API endpoints with OpenAPI documentation, versioning strategies, and security patterns. Use when creating REST APIs, adding endpoints, setting up API projects, or configuring API infrastructure. Do NOT use when the project is controller-based MVC — use dotnet-vertical-slice for handler architecture instead.

NuGet package creation with CI/CD pipeline setup and test harness. Use when creating new NuGet packages, configuring package metadata, or setting up publish workflows. Do NOT use when the library is internal-only and not intended for NuGet publication; Do NOT use when the target is an application project.

Scaffolds Axum HTTP endpoints with OpenAPI (utoipa), Tower middleware, JWT auth, rate limiting, CORS, health checks, and versioning. Axum-first: typed extractors, typed responses, compile-time route verification. Use when creating Rust REST APIs, scaffolding Axum endpoints/projects, configuring Tower middleware, or adding OpenAPI/JWT to Axum. Not when the codebase uses Actix-web — Axum-into-Actix needs manual integration not covered here.

Cargo crate creation with CI/CD pipeline setup, test harness, and crates.io publish workflow. Use when creating new Rust crates, configuring Cargo.toml metadata, setting up GitHub Actions for Rust CI, or publishing to crates.io. Do NOT use when the crate is internal-only and not intended for crates.io publication; Do NOT use when the target is a binary application — this skill targets library crates.

Grades an existing Rust codebase. Detects Rust edition, async runtime, and workspace structure, then checks ownership discipline, trait coherence, error-handling conventions, unsafe-block justification, and crate-boundary hygiene with file:line evidence. Use to review or grade a Rust codebase. Not for Socratic critique (architecture-review), security audits (rust-security-review), or new test-first code (tdd).

Feature-based vertical-slice architecture for Rust using Axum routers, handler functions, and service traits. No DI framework — dependencies wired manually via Arc<dyn Trait> in Axum State. CQRS via trait separation: reader traits for queries, writer traits for commands. Use when scaffolding Rust features, creating Axum feature modules, adding service layers, or organizing Rust code by feature rather than technical layer. Not for microservice/inter-process boundaries — scopes to module organization within a single Rust binary.

Analyzes Rust migration paths: C/C++ to Rust rewrites via incremental FFI strangler fig, and Rust modernization (edition upgrades 2015->2018->2021->2024, deprecated-crate replacement, sync to async). Assesses risk, quantifies effort, and produces a phased plan — does NOT perform the migration. Use when migrating C/C++ to Rust, upgrading editions, modernizing legacy Rust, replacing deprecated crates, or planning sync-to-async. Not when you want to execute the migration (assessment only), or the codebase is already current stable Rust with no legacy.

Scaffolds a production-ready React + TypeScript application skeleton with Vite, a router, strict TypeScript, Vitest + React Testing Library, ESLint (hooks + jsx-a11y), Prettier, environment handling, an error boundary, and a feature-folder layout. React analog of an app/project scaffolder. Use when starting a new React app, bootstrapping a Vite + React + TypeScript project, setting up the testing/lint toolchain, or establishing the base folder structure and app shell.

Grades an existing React/TypeScript codebase. Detects React version, bundler (Vite/CRA/Next), TypeScript usage, state library, and router, then checks hooks discipline, component cohesion, effect correctness, render performance, state boundaries, accessibility, and type safety with file:line evidence. Use to review or grade a React codebase. Not for Socratic critique (architecture-review), security audits (react-security-review), or new test-first code (tdd).

Analyzes legacy React codebases and produces actionable modernization plans. Primary migration paths include class components to function components + hooks, Create React App to Vite, React 16/17 to 18 to 19, JavaScript to TypeScript, Enzyme to React Testing Library, legacy Redux to Redux Toolkit / Zustand / Context, and deprecated lifecycle/API removal. Does NOT perform the migration — assesses, quantifies risk, and plans.

Scaffolds a production-ready Vue 3 + TypeScript application skeleton with Vite, Vue Router, strict TypeScript, Vitest + Vue Testing Library, ESLint (vue + a11y plugins), Prettier, environment handling, app-level error handling, and a feature-folder layout. Vue analog of an app/project scaffolder. Use when starting a new Vue app, bootstrapping a Vite + Vue + TypeScript project, setting up the testing/lint toolchain, or establishing the base folder structure and app shell.

Grades an existing Vue/TypeScript codebase. Detects Vue version (2 vs 3), API style (Options vs Composition), bundler (Vite/Vue CLI/Nuxt), TypeScript usage, state library (Pinia/Vuex), and router, then checks Composition API discipline, component cohesion, lifecycle/watcher correctness, render performance, state boundaries, accessibility, and type safety with file:line evidence. Use to review or grade a Vue codebase. Not for Socratic critique (architecture-review), security audits (vue-security-review), or new test-first code (tdd).

Scaffolds a single Vue / TypeScript single-file component (SFC) or route with typed props via defineProps, a co-located Vue Testing Library test, an accessibility baseline, and an optional Storybook story. Vue analog of fastapi-scaffolder — the SFC/route is the front-end "unit". Use when creating a new Vue component, adding a route/page, generating a typed presentational or container SFC, or standing up a component with its test and story.

Scaffolds feature-based Vue / TypeScript architecture using feature folders, presentational + container SFCs, composables, a typed data layer, and structural CQRS (query composables vs mutation composables). Vue analog of dotnet-vertical-slice and react-feature-slice — no DI framework; uses props/provide-inject for dependency injection and a query layer for server state. Use when creating feature-based Vue projects, adding Vue features, organizing components by feature rather than by technical type, or scaffolding a feature's data layer.

Analyzes legacy Vue codebases and produces actionable modernization plans. Primary migration paths include Options API to Composition API, Vue 2 to Vue 3, Vue CLI to Vite, JavaScript to TypeScript, Vue Test Utils/Karma/Mocha to Vitest + Vue Testing Library, legacy Vuex to Pinia, and removed-in-Vue-3 pattern cleanup (filters, event bus, `$listeners`). Does NOT perform the migration — assesses, quantifies risk, and plans.

OWASP-based security review of Vue/TypeScript front-ends. Detects framework (Vite/Vue CLI/Nuxt), entry points, and data flows; scans the OWASP Top 10 (2025) mapped to Vue client-side risks (raw-HTML XSS via v-html, URL/protocol injection, bundled secrets, insecure token storage, dependency CVEs, missing CSP, open redirects, router guard bypass); emits an exec summary plus graded findings. Use to audit Vue for vulnerabilities. Not for architecture grading (vue-architecture-checklist).

Scaffolds Laravel API endpoints with API Resource responses, Form Request validation, Sanctum authentication, throttle-based rate limiting, URI versioning, OpenAPI documentation, and health checks. PHP analog of fastapi-scaffolder, minimal-api-scaffolder, and axum-scaffolder. Use when creating REST APIs in Laravel, adding API endpoints, setting up API routing and middleware, or configuring API infrastructure.

Grades an existing PHP/Laravel codebase. Detects PHP version, framework (Laravel/Symfony/plain), and autoloading layout, then checks service-layer boundaries, strict typing, input validation, query safety, and config/secrets hygiene with file:line evidence. Use to review or grade a PHP codebase. Not for Socratic critique (architecture-review), security audits (php-security-review), or new test-first code (tdd).

Scaffolds feature-based PHP / Laravel architecture using feature folders, thin controllers, Form Requests, a service/action layer, and API Resources. PHP analog of dotnet-vertical-slice and python-feature-slice — no mediator library; uses the Laravel service container for dependency injection and structural CQRS conventions. Use when creating feature-based PHP projects, adding Laravel features, scaffolding service layers, or organizing PHP code by feature rather than by technical layer.

Scaffolds production-ready Composer packages for Packagist with a complete composer.json, PSR-4 autoloading, a Pest/PHPUnit test harness, GitHub Actions CI (PHP version matrix, PHPStan, PHP-CS-Fixer), and a semver tag-based publish workflow. PHP analog of nuget-package-scaffold, pypi-package-scaffold, and cargo-package-scaffold. Use when creating a reusable PHP library, configuring composer.json metadata, setting up Composer/Packagist publishing, or building a PHP package CI pipeline.

Scaffolds production-ready PyPI packages with pyproject.toml, hatch/flit/build tooling, GitHub Actions publish workflow, test harness, and documentation. Python analog of nuget-package-scaffold. Use when creating Python packages, setting up PyPI publishing, configuring package metadata, or building Python libraries.

Grades an existing Python codebase. Detects Python version, framework (FastAPI/Django/Flask), and package layout, then checks clean-architecture boundaries, type-safety discipline, complexity, dependency direction, and config/secrets hygiene with file:line evidence. Use to review or grade a Python codebase. Not for Socratic critique (architecture-review), security audits (python-security-review), or new test-first code (tdd).

Analyzes legacy Python codebases and produces actionable modernization plans. Primary migration paths include Python 2 to 3.12+, sync to async, Flask/Django monolith to FastAPI, requirements.txt to pyproject.toml, and bare classes to Pydantic/dataclasses. Does NOT perform the migration — assesses, quantifies risk, and plans.

Reviews Jira issues for implementation readiness. Detects complexity signals, parses acceptance criteria, and recommends clarification or planning mode when needed. Use when reviewing a Jira issue for readiness, checking whether a ticket has enough detail to implement, assessing acceptance-criteria completeness, or evaluating a story before sprint planning. Not for completed implementations (reviews readiness, not accuracy), or non-Jira trackers.

QRSPI Spec phase -- a Design Brain-Dump the human redirects ("brain surgery"), followed by a vertically-sliced Structure Outline. Use for "/qrspi-spec <feature>", "design discussion for X", "structure outline for X", "spec out X from the research". Do NOT use for an open-ended design chat (use spec-coach); this phase consumes research.md and produces an approved spec.md.

Systematic review execution engine -- transforms structured human review coaching patterns into autonomous review checklists with pass/fail gates, convention detection, and structured finding production. Use when running autonomous code reviews to ensure systematic coverage and consistent quality.

Devil's advocate architecture critic -- challenges designs via Socratic questioning against SOLID, coupling, failure modes, scalability, and operational complexity. Use when stress-testing an architecture decision, evaluating a proposed system design, reviewing architecture before implementation, or asked to critique a technical approach.

Interactive spec design coach. Guides through vision, PRD structure, three-tier boundary definition, INVEST user-story quality, specification by example, and measurable success criteria to produce a complete, deployable spec. Use when designing a new skill, agent, feature, or any AI system that needs explicit behavioral boundaries — writing an agent spec, an SRS/requirements doc, a spec.md/plan.md, or running a spec-kit/specify workflow.