{"schemaVersion":1,"generatedAt":"2026-07-17","marketplace":{"name":"dev-digest-ai-marketplace","repo":"SyukPublic/dev-digest-ai-marketplace","description":"Reusable Claude Code skills, agents, and MCP servers for any project","counts":{"plugins":4,"skills":12,"agents":7,"commands":0,"mcpServers":0}},"artifacts":[{"id":"plugin:engineering-paved-path","type":"plugin","name":"engineering-paved-path","displayName":"engineering-paved-path","description":"Curated engineering skills for React, Next.js, Fastify, onion architecture, testing, TypeScript, and security","keywords":["react","nextjs","fastify","typescript","testing","security","architecture","best-practices"],"category":"development","plugin":"engineering-paved-path","version":"1.0.0","installCommand":"/plugin install engineering-paved-path@dev-digest-ai-marketplace","invocation":null,"path":"plugins/engineering-paved-path","lastModified":"2026-07-17","body":"engineering-paved-path Curated, project-agnostic engineering skills for the modern TypeScript stack: React, Next.js, Fastify, onion architecture, testing, TypeScript, and security. One installed source of truth that other plugins and agents build on instead of copying skill content around. Installation This plugin has no dependencies and executes nothing on its own (one optional diagnostic script, see below). Other plugins in this marketplace ( architecture-review , sdd-engineering ) declare a dependency on it and expect it to be installed first. Skills Skill Scope What it covers ----- ----- -------------- react-best-practices Frontend React component correctness: purity, hooks usage, memoization, keys, derive-don't-store, common runtime pitfalls. react-frontend-architecture Frontend Where frontend code lives and how it is split: feature-based structure, colocation, import boundaries, barrel files, naming conventions. react-testing-library Frontend Testing React UIs the Testing-Library way: accessible queries, userEvent , MSW, integration-first test structure (Vitest-oriented, works with Jest). next-best-practices Frontend Next.js App Router: RSC boundaries, file conventions, data patterns, metadata, images/fonts, error handling, hydration, bundling. fastify-best-practices Backend Fastify server rules (19 rule files): plugins, routes, schemas, hooks, decorators, auth, CORS, logging, error handling, performance, testing, WebSockets. onion-architecture Backend Onion architecture for TypeScript backends: dependency direction, layers, ports and adapters, repositories, composition root, mechanical enforcement (dependency-cruiser). security Full-stack Application security review: input validation, authn/authz, secrets handling, injection, uploads — OWASP-aligned checklists and worked examples. typescript-expert Full-stack Advanced TypeScript: type-level programming, compiler performance, migration strategies, monorepos, tooling; ships a strict tsconfig reference, a utilit","security":{"hooks":[],"mcpServers":[],"executables":false},"tokenEstimate":122809},{"id":"skill:engineering-paved-path/fastify-best-practices","type":"skill","name":"fastify-best-practices","displayName":"fastify-best-practices","description":"Guides development of Fastify Node.js backend servers and REST APIs using TypeScript or JavaScript. Use when building, configuring, or debugging a Fastify application — including defining routes, implementing plugins, setting up JSON Schema validation, handling errors, optimising performance, managing authentication, configuring CORS and security headers, integrating databases, working with WebSockets, and deploying to production. Covers the full Fastify request lifecycle (hooks, serialization, logging with Pino) and TypeScript integration via strip types. Trigger terms: Fastify, Node.js server, REST API, API routes, backend framework, fastify.config, server.ts, app.ts.","keywords":["react","nextjs","fastify","typescript","testing","security","architecture","best-practices"],"category":"development","plugin":"engineering-paved-path","version":"1.0.0","installCommand":"/plugin install engineering-paved-path@dev-digest-ai-marketplace","invocation":"/engineering-paved-path:fastify-best-practices","path":"plugins/engineering-paved-path/skills/fastify-best-practices/SKILL.md","lastModified":"2026-07-17","body":"When to use Use this skill when you need to: - Develop backend applications using Fastify - Implement Fastify plugins and route handlers - Get guidance on Fastify architecture and patterns - Use TypeScript with Fastify (strip types) - Implement testing with Fastify's inject method - Configure validation, serialization, and error handling Quick Start A minimal, runnable Fastify server to get started immediately: Recommended Reading Order for Common Scenarios - New to Fastify? Start with plugins.md → routes.md → schemas.md - Adding authentication: plugins.md → hooks.md → authentication.md - Improving performance: schemas.md → serialization.md → performance.md - Setting up testing: routes.md → testing.md - Going to production: logging.md → configuration.md → deployment.md How to use Read individual rule files for detailed explanations and code examples: - rules/plugins.md - Plugin development and encapsulation - rules/routes.md - Route organization and handlers - rules/schemas.md - JSON Schema validation - rules/error-handling.md - Error handling patterns - rules/hooks.md - Hooks and request lifecycle - rules/authentication.md - Authentication and authorization - rules/testing.md - Testing with inject() - rules/performance.md - Performance optimization - rules/logging.md - Logging with Pino - rules/typescript.md - TypeScript integration - rules/decorators.md - Decorators and extensions - rules/content-type.md - Content type parsing - rules/serialization.md - Response serialization - rules/cors-security.md - CORS and security headers - rules/websockets.md - WebSocket support - rules/database.md - Database integration patterns - rules/configuration.md - Application configuration - rules/deployment.md - Production deployment - rules/http-proxy.md - HTTP proxying and reply.from() Core Principles - Encapsulation : Fastify's plugin system provides automatic encapsulation - Schema-first : Define schemas for validation and serialization - Performance : Fastify is optimized for"},{"id":"skill:engineering-paved-path/next-best-practices","type":"skill","name":"next-best-practices","displayName":"next-best-practices","description":"Next.js best practices - file conventions, RSC boundaries, data patterns, async APIs, metadata, error handling, route handlers, image/font optimization, bundling","keywords":["react","nextjs","fastify","typescript","testing","security","architecture","best-practices"],"category":"development","plugin":"engineering-paved-path","version":"1.0.0","installCommand":"/plugin install engineering-paved-path@dev-digest-ai-marketplace","invocation":"/engineering-paved-path:next-best-practices","path":"plugins/engineering-paved-path/skills/next-best-practices/SKILL.md","lastModified":"2026-07-17","body":"Next.js Best Practices Apply these rules when writing or reviewing Next.js code. File Conventions See file-conventions.md for: - Project structure and special files - Route segments (dynamic, catch-all, groups) - Parallel and intercepting routes - Middleware rename in v16 (middleware → proxy) RSC Boundaries Detect invalid React Server Component patterns. See rsc-boundaries.md for: - Async client component detection (invalid) - Non-serializable props detection - Server Action exceptions Async Patterns Next.js 15+ async API changes. See async-patterns.md for: - Async params and searchParams - Async cookies() and headers() - Migration codemod Runtime Selection See runtime-selection.md for: - Default to Node.js runtime - When Edge runtime is appropriate Directives See directives.md for: - 'use client' , 'use server' (React) - 'use cache' (Next.js) Functions See functions.md for: - Navigation hooks: useRouter , usePathname , useSearchParams , useParams - Server functions: cookies , headers , draftMode , after - Generate functions: generateStaticParams , generateMetadata Error Handling See error-handling.md for: - error.tsx , global-error.tsx , not-found.tsx - redirect , permanentRedirect , notFound - forbidden , unauthorized (auth errors) - unstable rethrow for catch blocks Data Patterns See data-patterns.md for: - Server Components vs Server Actions vs Route Handlers - Avoiding data waterfalls ( Promise.all , Suspense, preload) - Client component data fetching Route Handlers See route-handlers.md for: - route.ts basics - GET handler conflicts with page.tsx - Environment behavior (no React DOM) - When to use vs Server Actions Metadata & OG Images See metadata.md for: - Static and dynamic metadata - generateMetadata function - OG image generation with next/og - File-based metadata conventions Image Optimization See image.md for: - Always use next/image over - Remote images configuration - Responsive sizes attribute - Blur placeholders - Priority loading for LCP Font Optim"},{"id":"skill:engineering-paved-path/onion-architecture","type":"skill","name":"onion-architecture","displayName":"onion-architecture","description":"Enforces Onion Architecture (dependencies point inward) on a TypeScript backend (a Fastify + Drizzle + Zod server/ package and a pure domain core, reviewer-core in the reference layout). Use this skill whenever you add or change a backend route, service, repository, adapter, DB query, contract, or DI wiring — and whenever deciding WHERE a piece of logic, an external-tool call (LLM/OpenAI/Anthropic/OpenRouter, GitHub/octokit, git, ripgrep/ast-grep, Postgres), a type, or a validation belongs across layers. Also use when reviewing layering, an import that crosses package/layer boundaries, a leaked Drizzle query, a directly-instantiated SDK client, or business logic creeping into a route. Trigger terms: onion architecture, layer, dependency direction/rule, ports and adapters, repository, service, adapter, composition root, container, dependency inversion, where should this live, layering violation.","keywords":["react","nextjs","fastify","typescript","testing","security","architecture","best-practices"],"category":"development","plugin":"engineering-paved-path","version":"1.0.0","installCommand":"/plugin install engineering-paved-path@dev-digest-ai-marketplace","invocation":"/engineering-paved-path:onion-architecture","path":"plugins/engineering-paved-path/skills/onion-architecture/SKILL.md","lastModified":"2026-07-17","body":"Onion Architecture (TypeScript backend) Keeps the backend's dependencies pointing inward : the pure domain core ( reviewer-core ) knows nothing about the database, GitHub, git, or any SDK; those are replaceable outer details reached only through interfaces. This skill is about layers, dependency direction, and where each kind of code lives — not how to write a Fastify route, a Drizzle query, or a Zod schema (those have their own skills). For a good/bad code example per rule see examples.md; for sources and the canonical definition see references.md. Sibling skills (do not duplicate — defer to them for mechanics): - engineering-paved-path:fastify-best-practices → route/plugin/hook mechanics, JSON-schema validation, error handling. - ORM mechanics (how to write queries, relations, transactions, migrations) and schema-authoring mechanics (Zod schemas, safeParse , z.infer , refinements) → dedicated ORM/validation skills, when the host project provides them. - engineering-paved-path:react-frontend-architecture → the same \"where does it live\" question for the frontend . Severity Levels - CRITICAL — Breaks the dependency rule or leaks infrastructure into the core. Destroys testability and the ability to swap implementations; the core stops being pure. - HIGH — Erodes a boundary (DB/SDK escapes its layer, logic in the wrong place). Compiles and runs, but couples layers and makes tests need real I/O. - MEDIUM — Hurts navigability or invites future erosion. The layers (outer → inner) and where they live (reference layout) Dependencies may point only inward (toward the core). Nothing inner may import anything outer. Layer Where Tool --- --- --- Presentation / edge server/src/modules/ /routes.ts Fastify 5 Application services server/src/modules/ /service.ts (+ run-executor.ts , helpers.ts ) — Ports (interfaces) server/src/vendor/shared/adapters.ts + Zod contracts in vendor/shared/contracts/ Zod 3 Infrastructure adapters server/src/adapters/ (llm, github, git, astgrep, codeindex"},{"id":"skill:engineering-paved-path/react-best-practices","type":"skill","name":"react-best-practices","displayName":"react-best-practices","description":"Modern React best practices and anti-pattern catalog (2025-26). Use when writing, reviewing, or refactoring React components, hooks, and state management. Covers component design, state patterns, hooks misuse, performance, data fetching, and code organization.","keywords":["react","nextjs","fastify","typescript","testing","security","architecture","best-practices"],"category":"development","plugin":"engineering-paved-path","version":"1.0.0","installCommand":"/plugin install engineering-paved-path@dev-digest-ai-marketplace","invocation":"/engineering-paved-path:react-best-practices","path":"plugins/engineering-paved-path/skills/react-best-practices/SKILL.md","lastModified":"2026-07-17","body":"React Best Practices & Anti-Patterns Modern React conventions (2025-26). Covers what to do and what to avoid. For code examples, see examples.md. Severity Levels Each rule is tagged with a severity for use by consuming agents: - CRITICAL — Will cause bugs, broken reconciliation, or maintenance nightmares - HIGH — Will cause performance issues or scaling problems - MEDIUM — Will hurt maintainability or developer experience --- Component Design (CRITICAL) - Components must be pure — same inputs = same outputs, no side effects during render - Business logic in hooks/helpers, NOT in component bodies - Container components fetch data; presentational components receive props and render UI - Helper functions extracted OUTSIDE the component body - Max 200 lines per component — split if larger - Max 5-7 props — more suggests the component does too much - One component per file (small colocated internal helpers are fine) Composition Patterns - Compose small focused components over monolithic ones - \"Lift Content Up\" — move children to the parent when the wrapper doesn't use them for logic - \"Push State Down\" — keep state in the component that actually needs it - Prefer children prop and composition over deep prop drilling Derive, Don't Store (CRITICAL) The #1 React anti-pattern. Look for it in every review. - NEVER store derived values in useState — compute during render - NEVER use useState + useEffect to sync a computed value — just compute it - Use useMemo ONLY if the computation is expensive (measured, not assumed) - If a value can be calculated from existing props/state, calculate it inline State Management (HIGH) State Location - Colocate state with the components that use it - Don't lift state higher than necessary — it causes unnecessary re-renders - Don't duplicate state across components Context API - Context is for dependency injection (auth, theme), NOT global state management - Context changes re-render ALL consumers — split contexts by concern - Prefer hook retu"},{"id":"skill:engineering-paved-path/react-frontend-architecture","type":"skill","name":"react-frontend-architecture","displayName":"react-frontend-architecture","description":"React/Next.js frontend architecture & code organization (2025-26): where files live, how to split components, feature-based structure, co-location, constants/utils/helpers/types/hooks placement, where business logic goes, import boundaries, barrel files, path aliases, and naming conventions. Use when structuring a new frontend, deciding where a file or piece of logic belongs, splitting an oversized component/module, reviewing folder layout, or naming files. Stack-agnostic (React 19 + Next.js 15 App Router aware).","keywords":["react","nextjs","fastify","typescript","testing","security","architecture","best-practices"],"category":"development","plugin":"engineering-paved-path","version":"1.0.0","installCommand":"/plugin install engineering-paved-path@dev-digest-ai-marketplace","invocation":"/engineering-paved-path:react-frontend-architecture","path":"plugins/engineering-paved-path/skills/react-frontend-architecture/SKILL.md","lastModified":"2026-07-17","body":"React Frontend Architecture & Code Organization How a React/Next.js frontend should be organized — where code lives, how it's split, and what to name it. This is about structure and placement , not component runtime correctness. For code examples (good/bad per rule) see examples.md; for sources see references.md. Sibling skills (do not duplicate): - engineering-paved-path:react-best-practices → component purity, hooks misuse, memoization, keys, derive-don't-store. - engineering-paved-path:next-best-practices → App Router file conventions, RSC mechanics, metadata, image/font optimization. Severity Levels - CRITICAL — Will cause coupling/maintenance failures or leak server code to the client - HIGH — Will cause scaling problems or hard-to-navigate codebases - MEDIUM — Hurts maintainability or developer experience Guiding principle Colocation: place code as close to where it's used as possible. A file's location is a claim about its scope. Promote code to a shared layer only when a second consumer actually appears — not in anticipation. Premature shared abstractions (AHA: Avoid Hasty Abstractions ) are as harmful as duplication. --- Project Structure: feature-based over type-based (HIGH) - Organize by feature/domain , not by technical role. features/checkout/ beats a global components/ , hooks/ , utils/ split once the app has more than a handful of screens. - Type-based grouping ( components/ , hooks/ , utils/ at the root) is fine for small apps but scales poorly: working on one feature forces edits across many directories (low cohesion, high coupling). - A feature folder colocates everything that feature needs and only the subfolders it needs : api/ , components/ , hooks/ , stores/ , types/ , utils/ . - Keep a shared layer ( shared/ , components/ui/ , lib/ ) for genuinely cross-feature primitives only. - There is no single mandated layout. Pick one strategy and apply it consistently across the project — inconsistency costs more than the specific choice. - For large/en"},{"id":"skill:engineering-paved-path/react-testing-library","type":"skill","name":"react-testing-library","displayName":"react-testing-library","description":"General-purpose React Testing Library guide with Vitest. Use when writing, reviewing, or setting up React component and hook tests. Covers project setup from scratch, RTL query priority, userEvent, async patterns, mocking strategies, and common anti-patterns. Applicable to any Vite + React project.","keywords":["react","nextjs","fastify","typescript","testing","security","architecture","best-practices"],"category":"development","plugin":"engineering-paved-path","version":"1.0.0","installCommand":"/plugin install engineering-paved-path@dev-digest-ai-marketplace","invocation":"/engineering-paved-path:react-testing-library","path":"plugins/engineering-paved-path/skills/react-testing-library/SKILL.md","lastModified":"2026-07-17","body":"React Testing Library General-purpose guide for testing React components and hooks with React Testing Library (RTL) and Vitest. Project-agnostic — works with any Vite + React setup. Philosophy: Fewer Tests, Real Scenarios \"Write tests. Not too many. Mostly integration.\" — Kent C. Dodds 1. Use-case coverage code coverage — aim for 100% use-case coverage, not 100% line coverage. Think about what the user can DO, not what the code does internally. 2. Write fewer, longer tests — one test that walks through a full user flow beats six isolated assertions. Combine related steps (render → interact → verify) into a single test. 3. Test behavior, not implementation — assert on what the user sees and can do. Never assert on internal state, hook calls, or DOM structure. 4. Mock at boundaries only — mock API calls and external services. Never mock your own components, hooks, or context internals. 5. Each test must justify its existence — if removing a test wouldn't reduce your confidence that the app works, delete it. The Testing Trophy (what to invest in) --- Setup from Scratch 1. Install Dependencies Optional but recommended: 2. Vitest Config Create vitest.config.js at the client root (or extend vite.config.js ): 3. Setup File Create src/test/setup.js : This registers matchers like toBeInTheDocument() , toBeVisible() , toHaveTextContent() . 4. Package Scripts Add to package.json : --- Test Scenarios by Component Type Before writing tests, identify the component type and pick scenarios from this matrix. Write 1-3 tests per component — each test covers a full user flow, not a single assertion. Form Component (e.g., BlogEditor, LoginForm, CommentForm) # Test What it covers --- ------ ---------------- 1 Happy path: fill all fields → submit → success feedback Rendering, typing, validation passing, API call, success state 2 Validation: submit empty/invalid → error messages appear Required fields, validation rules, error rendering 3 API failure: fill valid → submit → server error sho"},{"id":"skill:engineering-paved-path/security","type":"skill","name":"security","displayName":"security","description":"Web application security best practices based on OWASP Top 10:2025. Use when reviewing code for vulnerabilities, implementing auth/authorization, handling user input, working with file uploads, managing secrets, or building API endpoints. Covers React, Express, MongoDB, and JWT security.","keywords":["react","nextjs","fastify","typescript","testing","security","architecture","best-practices"],"category":"development","plugin":"engineering-paved-path","version":"1.0.0","installCommand":"/plugin install engineering-paved-path@dev-digest-ai-marketplace","invocation":"/engineering-paved-path:security","path":"plugins/engineering-paved-path/skills/security/SKILL.md","lastModified":"2026-07-17","body":"Security Best Practices — OWASP Top 10:2025 Security guidance for React + Express + MongoDB + JWT stacks. See examples.md for unsafe/safe code pairs, checklists.md for quick checklists, references.md for all sources. --- Core Philosophy — Confidence-Based Review Before flagging any issue, trace the data flow and confirm the input source. Confidence Criteria Action ------------ ---------- -------- HIGH Vulnerable pattern + attacker-controlled input confirmed Report with file, line, exploit, and fix MEDIUM Vulnerable pattern, input source unclear Note for manual verification LOW Theoretical / best-practice deviation Do not report — mention only if asked Do NOT flag : test files, dead code, server-controlled values (env vars, config constants), framework-mitigated patterns (React JSX escaping, Mongoose parameterized queries), development-only code gated by NODE ENV . Golden rule : fetch(process.env.API URL) = safe. fetch(req.query.url) = vulnerable. Always ask: \"Can an attacker control this value?\" --- OWASP Top 10:2025 # Category Key Risk in This Stack --- ---------- ---------------------- A01 Broken Access Control Missing auth middleware, IDOR, no ownership checks A02 Security Misconfiguration Helmet disabled, CORS wildcard, stack traces in prod A03 Supply Chain Failures Compromised npm packages, typosquatting A04 Cryptographic Failures Weak JWT secret, low bcrypt cost, hardcoded secrets A05 Injection MongoDB operator injection, XSS, command injection A06 Insecure Design Missing rate limiting, no threat model A07 Authentication Failures jwt.decode() instead of verify(), brute force A08 Integrity Failures Mass assignment via req.body spread, unvalidated uploads A09 Logging Failures Passwords in logs, missing auth event audit trail A10 Exceptional Conditions Fail-open auth, stack trace leaks, missing async error handling --- A01 — Broken Access Control - Deny by default — every route is protected unless explicitly public - Apply auth middleware as a barrier (via router"},{"id":"skill:engineering-paved-path/typescript-expert","type":"skill","name":"typescript-expert","displayName":"typescript-expert","description":"TypeScript and JavaScript expert with deep knowledge of type-level programming, performance optimization, monorepo management, migration strategies, and modern tooling.","keywords":["react","nextjs","fastify","typescript","testing","security","architecture","best-practices"],"category":"development","plugin":"engineering-paved-path","version":"1.0.0","installCommand":"/plugin install engineering-paved-path@dev-digest-ai-marketplace","invocation":"/engineering-paved-path:typescript-expert","path":"plugins/engineering-paved-path/skills/typescript-expert/SKILL.md","lastModified":"2026-07-17","body":"TypeScript Expert You are an advanced TypeScript expert with deep, practical knowledge of type-level programming, performance optimization, and real-world problem solving based on current best practices. When invoked: 0. If the issue requires ultra-specific expertise, recommend switching and stop: - Deep webpack/vite/rollup bundler internals → typescript-build-expert - Complex ESM/CJS migration or circular dependency analysis → typescript-module-expert - Type performance profiling or compiler internals → typescript-type-expert Example to output: \"This requires deep bundler expertise. Please invoke: 'Use the typescript-build-expert subagent.' Stopping here.\" 1. Analyze project setup comprehensively: Use internal tools first (Read, Grep, Glob) for better performance. Shell commands are fallbacks. After detection, adapt approach: - Match import style (absolute vs relative) - Respect existing baseUrl/paths configuration - Prefer existing project scripts over raw tools - In monorepos, consider project references before broad tsconfig changes 2. Identify the specific problem category and complexity level 3. Apply the appropriate solution strategy from my expertise 4. Validate thoroughly: Safety note: Avoid watch/serve processes in validation. Use one-shot diagnostics only. Advanced Type System Expertise Type-Level Programming Patterns Branded Types for Domain Modeling - Use for: Critical domain primitives, API boundaries, currency/units - Resource: https://egghead.io/blog/using-branded-types-in-typescript Advanced Conditional Types - Use for: Library APIs, type-safe event systems, compile-time validation - Watch for: Type instantiation depth errors (limit recursion to 10 levels) Type Inference Techniques Performance Optimization Strategies Type Checking Performance Build Performance Patterns - Enable skipLibCheck: true for library type checking only (often significantly improves performance on large projects, but avoid masking app typing issues) - Use incremental: true wi"},{"id":"plugin:research-tools","type":"plugin","name":"research-tools","displayName":"research-tools","description":"Read-only research agent that investigates codebases and the web and returns structured, verifiable reports","keywords":["research","investigation","read-only","agent","websearch"],"category":"development","plugin":"research-tools","version":"1.0.0","installCommand":"/plugin install research-tools@dev-digest-ai-marketplace","invocation":null,"path":"plugins/research-tools","lastModified":"2026-07-17","body":"research-tools Read-only research agent that investigates codebases and the web and returns structured, verifiable reports. What's inside Component Type Description --------- ---- ----------- researcher agent Finds information inside the project (code, config, docs, git history) or on the internet, and returns a strictly structured report with sources. Never modifies anything. Installation No dependencies — the plugin is self-contained. When to use it Delegate to researcher instead of searching in the main conversation when: - The search is broad — sweeping many files, directories, or naming conventions would flood the main context with file dumps; the agent reads in its own context and hands back only the conclusion with citations. - You need evidence, not vibes — every claim in its report carries a file:line or a URL, and what it could not find is listed explicitly. - A workflow needs facts before acting — the sdd-engineering agents ( spec-creator , implementation-planner ) fan out fact-finding to researcher during the spec and planning stages for exactly this reason. For a quick single-fact lookup where you already know the file, a direct search in the main conversation is cheaper. How to use the agent Once installed, researcher is available as a subagent type in every Claude Code session. Spawn it by asking Claude to delegate: - \"Use the researcher agent to find where rate limiting is configured in this repo.\" - \"Have researcher look up the current best practice for rotating JWT signing keys.\" - \"Researcher: does the codebase have any usage of the deprecated crypto API?\" The main conversation launches it via the agent/task mechanism; the agent does the searching in its own context and hands back only the report. It works in two modes and reports them separately: - PROJECT — the answer lives in the repository. Uses Grep , Glob , Read , and read-only Bash (e.g. git log , git show ). Every finding cites a concrete file:line . - WEB — the answer is external (library","security":{"hooks":[],"mcpServers":[],"executables":false},"tokenEstimate":1555},{"id":"agent:research-tools/researcher","type":"agent","name":"researcher","displayName":"researcher","description":"Read-only research agent. Finds information either INSIDE the project (code, config, docs, git history) OR on the INTERNET, and returns a strictly structured report. Use when the user asks to \"find\", \"look up\", \"research\", \"investigate\", \"where is\", \"does the codebase have\", or to gather external facts/best-practices. The agent never writes or edits files, never runs a deep-research harness, and honestly reports what it could NOT find. If the request is ambiguous or contains no concrete question, it asks clarifying questions first (interview mode) instead of guessing.","keywords":["research","investigation","read-only","agent","websearch"],"category":"development","plugin":"research-tools","version":"1.0.0","installCommand":"/plugin install research-tools@dev-digest-ai-marketplace","invocation":null,"path":"plugins/research-tools/agents/researcher.md","lastModified":"2026-07-17","body":"researcher You are researcher , a read-only investigation agent. Your single job is to find information and report it — in the project or on the internet — with a strictly structured, verifiable output. You never modify anything. Hard constraints (non-negotiable) - Read-only. You have no Write / Edit tools. Never attempt to create, modify, or delete files. With Bash , use only non-mutating, read-only commands (e.g. git log , git show , git diff , ls , cat , rg , find , wc ). NEVER run commands that change state (no git commit/push/checkout , no rm , mv , mkdir , npm install , package builds, migrations, writes, or redirections like / ). - No deep-research harness. Do NOT invoke any deep-research skill or spawn sub-agents. Do your own focused searching with the tools you have. - Honesty over completeness. If you cannot find something, say so explicitly in the \"Not found\" section. Never invent files, line numbers, APIs, URLs, or facts. No source → no claim. - Stay read-only on scope too. You research and report; you do not propose to implement, and you do not edit. Hand findings back to the caller. Interview mode (ask before researching) Before doing any research, decide if the request is actionable — and when it is not, ask clarifying questions instead of guessing. - When clarification is needed, do NOT research and do NOT guess. Emit the \"Clarification needed\" block below and stop. Ask only the questions that actually block you — prefer 1–4 sharp questions , and offer a best-guess default for each so the user can answer fast or just confirm. - Treat a prompt as needing clarification when it contains no concrete question , is ambiguous, or could reasonably mean several different things. Useful axes for questions: PROJECT vs WEB scope; which package/area (e.g. server/ , client/ , core/ , e2e/ ); the specific symbol/feature/term; how recent the external info must be; depth expected (quick lookup vs thorough). - If the request is already clear enough to act on, skip the"},{"id":"plugin:architecture-review","type":"plugin","name":"architecture-review","displayName":"architecture-review","description":"Read-only architectural auditor agent that reviews layering, dependency direction, and boundary violations","keywords":["architecture","review","audit","onion","read-only"],"category":"development","plugin":"architecture-review","version":"1.0.0","installCommand":"/plugin install architecture-review@dev-digest-ai-marketplace","invocation":null,"path":"plugins/architecture-review","lastModified":"2026-07-17","body":"architecture-review Read-only architectural auditor agent that reviews layering, dependency direction, and boundary violations. What's inside Component Type Description --------- ---- ----------- architecture-reviewer agent Audits already-written code for Onion Architecture violations, forbidden-import boundary breaches, and structural erosion. Reports findings with verbatim file:line evidence and ends with an explicit PASS/FAIL gate verdict. Never modifies files. Requirements This plugin requires engineering-paved-path ^1.0.0 from the same marketplace. The agent preloads three skills from it at spawn time ( engineering-paved-path:onion-architecture , engineering-paved-path:typescript-expert , engineering-paved-path:security ) and loads its surface skills (React/Next.js/Fastify) on demand during a review. Claude Code does not auto-install plugin dependencies — the dependencies field in the manifest is a declarative contract, so install in this order: Without engineering-paved-path installed, the preloaded skills are unavailable; the agent still runs with the self-contained rules embedded in its prompt, but reviews are stronger with the full skill set. When to run it - As a merge gate — before a PR, on the branch diff; the PASS/FAIL verdict line is designed for exactly this. - After a feature lands — audit the touched packages for erosion that accumulated during implementation. - Inside the SDD pipeline — the sdd-engineering plugin's run-plan skill spawns this agent automatically in its review stage, in parallel with plan-verifier ; you don't invoke it yourself there. - Periodically on a hot module — layering violations are cheapest to fix while the code is still warm. How to use the agent Once installed, architecture-reviewer is available as a subagent type in every Claude Code session. Spawn it by asking Claude to delegate: - \"Run an architecture review on the server/ package.\" - \"Use the architecture-reviewer agent to audit this PR diff for layering violations.\" -","security":{"hooks":[],"mcpServers":[],"executables":false},"tokenEstimate":2960},{"id":"agent:architecture-review/architecture-reviewer","type":"agent","name":"architecture-reviewer","displayName":"architecture-reviewer","description":"Read-only architectural auditor. Trigger when someone asks for: \"architecture review\", \"architectural audit\", \"layering\", \"dependency direction\", \"onion\", \"boundary violation\", \"review the architecture\", \"is this layered correctly\". This agent audits ALREADY WRITTEN code — unlike a planning agent (which designs FUTURE code) and unlike a plan verifier (which checks requirement coverage of a plan) — this agent evaluates ARCHITECTURAL QUALITY and adherence to Onion Architecture best-practices. It never modifies files; it only reads, greps, and reports findings with verbatim evidence.","keywords":["architecture","review","audit","onion","read-only"],"category":"development","plugin":"architecture-review","version":"1.0.0","installCommand":"/plugin install architecture-review@dev-digest-ai-marketplace","invocation":null,"path":"plugins/architecture-review/agents/architecture-reviewer.md","lastModified":"2026-07-17","body":"architecture-reviewer You are the read-only architectural auditor . Your single question is: \"Does the dependency graph respect the layer contracts?\" You audit the host project's already-written code for Onion Architecture violations, forbidden-import boundary breaches, and structural erosion — not bugs, not style, not performance (those belong to other reviews). - Unlike a planning agent (which designs future code) — you audit existing code. - Unlike a plan verifier (which checks requirement coverage) — you evaluate architectural quality and best-practices adherence , not spec completeness. Hard constraints (non-negotiable) Read-only. You never create, modify, or delete files. You have no Write or Edit tool. With Bash , use only non-mutating, read-only commands (e.g. git log , git show , git diff , ls , cat , rg , find , wc ). NEVER run commands that change state (no git commit/push/checkout , no rm , mv , mkdir , npm install , package builds, migrations, writes, or redirections like / ). Evidence-first (anti-hallucination, CAPRA rule). Every finding MUST cite file:line with the exact import/symbol verbatim. A finding without a verbatim citation is a hypothesis, not a finding — do not report it. Never extrapolate from filenames; open the file and read the actual code. Verify, don't recall. Ground every decision in the loaded skills and the actual source code. Reuse existing findings; never assert from memory alone. Severity calibration — use exactly these levels: Severity Criteria --- --- CRITICAL Dependency rule violation: domain imports infrastructure; UI imports repository/schema; an inner core package imports from an outer application package; any reversal of the inward-only arrow HIGH Missing abstraction: ORM entity/row types as the return type of a service/API method; raw query-builder calls (e.g. .select()/.where() / db.query() ) in a service or route; database driver error codes caught outside the repository layer; HTTP framework request/response types (e.g"},{"id":"plugin:sdd-engineering","type":"plugin","name":"sdd-engineering","displayName":"sdd-engineering","description":"Spec-driven development workflow: spec, plan, implement, verify - with run orchestration and retro tooling","keywords":["sdd","spec-driven","workflow","agents","planning","orchestration"],"category":"development","plugin":"sdd-engineering","version":"1.1.0","installCommand":"/plugin install sdd-engineering@dev-digest-ai-marketplace","invocation":null,"path":"plugins/sdd-engineering","lastModified":"2026-07-17","body":"sdd-engineering Spec-driven development (SDD) workflow for Claude Code: spec → plan → implement → verify → retro. The plugin ships the workflow agents and the orchestration/retro skills; stack-specific engineering skills and the read-only review/research agents come from its dependency plugins. The SDD pipeline 1. spec-creator turns a feature request into a reviewable spec (default convention: docs/specs/SPEC- .md ). 2. implementation-planner turns an approved spec into a phased Development Plan with a traceability matrix (default convention: docs/plans/ .md ). 3. run-plan (skill) executes an approved plan end-to-end: parallel implementer waves per phase → one test-writer gap pass → a green barrier (tests + typecheck must pass) → parallel read-only review by architecture-reviewer and plan-verifier → a bounded fix loop (max 2 iterations) → a final report. It never commits, pushes, or opens PRs. 4. workflow-retro (skill) measures how the run actually went — true token/tool/duration/parallelism metrics from session journals — and turns findings into concrete optimization actions. Quick start — one feature end to end With this plugin and its three dependencies installed: 1. Spec. Ask for a spec; answer the interview questions (or front-load the decisions to skip the round-trip): Create a spec for CSV export of the orders table. Decisions: async export with email link, max 100k rows, admin-only. spec-creator writes docs/specs/SPEC- -csv-export.md and stops while open questions remain — a final spec has zero. 2. Plan. Point the planner at the approved spec and state the execution mode up front: Plan the feature from docs/specs/SPEC-2026-07-17-csv-export.md, multi-agent execution. implementation-planner writes docs/plans/csv-export.md — phased, with disjoint scopes and a traceability matrix. 3. Run. Start from a clean working tree (the skill stops on a dirty one), then: The orchestrator spawns implementer waves, the test gap pass, the green barrier, the parallel review, an","security":{"hooks":[],"mcpServers":[],"executables":false},"tokenEstimate":33275},{"id":"skill:sdd-engineering/engineering-insights","type":"skill","name":"engineering-insights","displayName":"engineering-insights","description":"Capture durable engineering insights into the host project's insights file (default docs/engineering-insights.md), and prune that log. Use during any session when a non-obvious discovery is confirmed — a gotcha, a fix's root cause, a why-it's-like-this decision, an antipattern, or a tool/library quirk — and at session wrap-up to sweep for learnings. Also use to review, dedup, or declutter the insights file. Trigger terms: insight, learning, gotcha, engineering insights, lesson learned, wrap-up, retrospective, prune insights.","keywords":["sdd","spec-driven","workflow","agents","planning","orchestration"],"category":"development","plugin":"sdd-engineering","version":"1.1.0","installCommand":"/plugin install sdd-engineering@dev-digest-ai-marketplace","invocation":"/sdd-engineering:engineering-insights","path":"plugins/sdd-engineering/skills/engineering-insights/SKILL.md","lastModified":"2026-07-17","body":"Engineering Insights Persist hard-won, non-obvious engineering knowledge into the host project's insights file , append-only — so the next session starts knowing what this one learned. Two modes: Capture (default) and Review / Prune . Details, section rubric, target-file rules, examples, and the full prune procedure live in reference.md — read it before a prune. Target file - Default: docs/engineering-insights.md in the host project. - Override: the caller may name any path (or several per-package files in a monorepo — see the reference for routing rules in that case). - Never write inside this plugin's own directory: the plugin cache is read-only, shared across projects, and overwritten on update. Insights belong to the project they describe, committed with its code. - If the target file does not exist, create it (check-before-create) with this header: Start of session — read first When a session begins and the user has stated their task, BEFORE doing the work: read the project's insights file first . It may already hold the gotcha, decision, or fix you'd otherwise rediscover. Mandatory, not optional — treat the entries as high-confidence guidance unless something proves one stale. When to capture — double trigger Capture at TWO moments: - As you go — the instant you confirm something non-obvious during the work. - At wrap-up — sweep the finished session for anything worth keeping. Capture when a competent engineer reading the code would NOT already know it: - a gotcha / footgun, or the root cause of a bug you just fixed; - a \"why it's like this\" decision (with the reason); - an antipattern (\"X looks right but fails because…\"); - a tool/library quirk (version-specific behavior, config landmine); - something to revisit later → an Open Question . Cadence / what NOT to capture: worth it after a substantive session (≈ 30 min with a real problem, solution, or discovery). Skip trivia — renames, formatting, routine config edits, anything obvious from the code. Signal qual"},{"id":"skill:sdd-engineering/mermaid-diagram","type":"skill","name":"mermaid-diagram","displayName":"mermaid-diagram","description":"Create Mermaid diagrams in markdown. Use when the user wants to visualize workflows, architectures, API flows, data models, state machines, or system designs. Covers flowcharts, sequence diagrams, class diagrams, ER diagrams, state diagrams, and more.","keywords":["sdd","spec-driven","workflow","agents","planning","orchestration"],"category":"development","plugin":"sdd-engineering","version":"1.1.0","installCommand":"/plugin install sdd-engineering@dev-digest-ai-marketplace","invocation":"/sdd-engineering:mermaid-diagram","path":"plugins/sdd-engineering/skills/mermaid-diagram/SKILL.md","lastModified":"2026-07-17","body":"Mermaid Diagram Creator Generate Mermaid diagrams embedded in markdown that communicate clearly — showing relationships, flows, and structure that words alone can't express. See examples.md for ready-to-use templates for each diagram type. --- Core Philosophy - Diagrams should clarify, not decorate — every element must serve a purpose - Text-first — Mermaid is text-based, version-controllable, and diff-friendly - Right diagram for the job — pick the type that matches the concept (see Decision Guide) - Validate before sharing — test in Mermaid Live Editor or render locally with mmdc --- Diagram Type Decision Guide You want to show... Use Mermaid keyword --------------------- ----- ----------------- Steps, decisions, branches Flowchart flowchart TD API calls between services over time Sequence Diagram sequenceDiagram Object relationships, inheritance Class Diagram classDiagram Database tables and relationships ER Diagram erDiagram Transitions between states State Diagram stateDiagram-v2 Project timeline, task dependencies Gantt Chart gantt Proportions, distribution Pie Chart pie Hierarchical idea breakdown Mindmap mindmap Git branching strategy Git Graph gitGraph User experience steps User Journey journey Chronological events Timeline timeline --- Flowcharts The most common diagram type. Use for workflows, decision trees, and process flows. Direction Code Direction ------ ----------- TD / TB Top → Down LR Left → Right BT Bottom → Top RL Right → Left Node Shapes Syntax Shape Use for -------- ------- --------- [text] Rectangle Process, action (text) Rounded Start/end {text} Diamond Decision ((text)) Circle Event, trigger [(text)] Cylinder Database, storage [[text]] Subroutine External process Arrow Types Syntax Style -------- ------- -- Solid arrow -.- Dashed arrow == Bold arrow --text-- Arrow with label ~~~ Invisible link (layout) Subgraphs Group related nodes into labeled containers: --- Sequence Diagrams Use for API flows, service interactions, and request/response p"},{"id":"skill:sdd-engineering/run-plan","type":"skill","name":"run-plan","displayName":"run-plan","description":"Executes an APPROVED Development Plan through the SDD implementation pipeline: implementer wave(s) → test-writer gap pass → green barrier (tests + typecheck) → architecture-reviewer ∥ plan-verifier → bounded fix loop (max 2 iterations) → final report. HARD GATE: an existing plan file is a required input — no plan, no run. Unlike implementer (ships ONE slice) — this skill orchestrates the WHOLE plan across agents; unlike workflow-retro (measures a PAST run) — this skill performs the run; unlike a pre-publish diff review — this skill implements and verifies, it never publishes. Trigger terms: run-plan, run the plan, execute the plan, run the implementation pipeline, запусти план, запусти конвеєр, виконай план, прожени план через конвеєр.","keywords":["sdd","spec-driven","workflow","agents","planning","orchestration"],"category":"development","plugin":"sdd-engineering","version":"1.1.0","installCommand":"/plugin install sdd-engineering@dev-digest-ai-marketplace","invocation":"/sdd-engineering:run-plan","path":"plugins/sdd-engineering/skills/run-plan/SKILL.md","lastModified":"2026-07-17","body":"Run Plan — implementation pipeline orchestrator Drive one approved Development Plan end-to-end with subagents: The main session is the orchestrator: it spawns agents via the Agent tool (parallel calls in ONE message when independent), continues them via SendMessage , tracks stages with TodoWrite , and never implements code itself. Spawn-prompt templates live in references/spawn-prompts.md — use them verbatim, filling the {{placeholders}} . Inputs - Plan path (REQUIRED) — produced by implementation-planner ; default convention docs/plans/ .md , but the caller may point anywhere. - Additional prompt (optional) — extra requirements/constraints given in the invocation or the chat. - Design sources (optional) — descriptions or images attached to the chat. Gate 0 — plan gate (blocking; no plan → no run) 1. No path given, or the file does not exist → STOP. Report the blocker and list docs/plans/ .md (or the project's plan directory) as candidate hints. Never guess which plan was meant, never run without one. 2. Validate structure. The file must contain: Execution mode , ## Tasks with task lines shaped - [ ] T … → AC-… → test … , and a ## Traceability matrix . Invalid → STOP; advise re-running implementation-planner . 3. Approval proxy. Plans carry no Status field: an explicitly passed path + no open BLOCKING questions inside the plan counts as approved. Blocking open questions found → STOP and surface them. Pre-flight 1. Clean tree check. Run git status . A dirty working tree → STOP and ask: reviewers audit the uncommitted diff, so a dirty baseline poisons both the review and any later retro. Record the baseline HEAD sha. 2. Read the plan fully. Extract: execution mode, phases with depends on: / parallel-safe markers, per-phase Disjoint scope , Shared scaffold (context pack) , the traceability matrix (RTM). 3. E2e prerequisites probe (only when the plan contains e2e tasks). BEFORE Stage 1, probe the prerequisites the host project documents for its e2e suite (browser toolin"},{"id":"skill:sdd-engineering/workflow-retro","type":"skill","name":"workflow-retro","displayName":"workflow-retro","description":"Post-run retrospective of the multi-agent SDD pipeline (spec-creator → implementation-planner → implementer / test-writer → architecture-reviewer / plan-verifier, plus nested researcher/Explore agents). Manually invoked after a run to produce TRUE token/tool/duration/parallelism metrics — deep mode parses session + subagent journals from disk because parent-visible usage EXCLUDES subagent tokens — plus insights with concrete optimization actions, a trend row appended to the retro ledger (default docs/retros/ledger.md), and an audit verdict. Trigger terms: workflow retro, retro, ретро, retrospective, pipeline metrics, agent token usage, cache hit, parallelism, як пройшов конвеєр.","keywords":["sdd","spec-driven","workflow","agents","planning","orchestration"],"category":"development","plugin":"sdd-engineering","version":"1.1.0","installCommand":"/plugin install sdd-engineering@dev-digest-ai-marketplace","invocation":"/sdd-engineering:workflow-retro","path":"plugins/sdd-engineering/skills/workflow-retro/SKILL.md","lastModified":"2026-07-17","body":"Workflow Retro Retrospective of how a multi-agent pipeline run ACTUALLY went: metrics → insights → concrete actions → trend ledger → audit verdict. Manual invocation only (no hook). Output locations are default conventions the caller may override: reports and the ledger go to docs/retros/ unless the invocation names another retro directory. Modes - deep (default) — parse journals from disk with the bundled script. This is the only accurate source: a parent's does NOT include its subagents' tokens, so anything measured in-context undercounts the run (often by 5–10×). - in-context (fallback) — only when journals are unavailable (other machine, cleaned up). Reconstruct what you can from the conversation and label every token figure \" lower bound — excludes subagent usage \". Never present in-context numbers as totals. Step 1 — collect metrics (deep) 1. Journals live in ~/.claude/projects/ / where = absolute repo path with every non-alphanumeric char replaced by - . The CURRENT session id is the UUID segment of your scratchpad path. Journals live on the HOST filesystem — run the script with the host machine's Python, not from inside a container/VM shell that cannot see the host home directory. 2. Run (from the project root; the project journal dir auto-resolves from cwd): python ${CLAUDE SKILL DIR}/scripts/retro metrics.py --session - retro of a past run → --list first (newest first, shows each session's agent types), pick the session whose agent types match the pipeline, confirm with the user if ambiguous. - omitted --session → latest session that has subagent journals. - Redirect stdout to a scratchpad file and read that; don't dump raw JSON into the chat. 3. The JSON gives you per journal (orchestrator + each agent): usage (input / output / cache-read / cache-creation, deduped by message.id ), cache hit pct , api turns , tool calls by tool , tool errors , skills loaded , writes paths , start/end/duration, parent + spawn depth (nesting tree); plus totals , parallelism "},{"id":"agent:sdd-engineering/implementation-planner","type":"agent","name":"implementation-planner","displayName":"implementation-planner","description":"Spec-driven planning specialist that turns an APPROVED feature spec (default convention docs/specs/SPEC-*.md) into a structured, traceable \"Development Plan\" at docs/plans/<feature>.md (default convention; the caller may pass different paths for both). Use when the user asks to \"plan\", \"design\", \"break down a feature\", \"create a development plan\", or to \"update/revise the plan\" for a feature whose spec already exists — it creates the plan file or EDITS the existing one in place (never a wholesale overwrite; filled Commit cells in the traceability matrix are preserved). HARD GATE: an approved spec is a required input — if it is missing, or still a draft with [NEEDS CLARIFICATION] items, the agent STOPS and asks for a spec-creator run first; it never captures or invents requirements itself (that is spec-creator's job). Interview-first: it reviews the spec's requirements and, when blocking questions remain OR the execution mode was not provided, returns its questions (always including \"multi-agent or single-agent execution?\") plus recommendations and stops WITHOUT writing a plan — callers SHOULD pass the spec path and execution mode up front to skip that round-trip. Every task in the plan maps to AC-IDs and a test (T1 → AC-1 → test_facts), and the plan carries a Traceability matrix (AC → task → test → commit) shared by test-writer, implementer, and plan-verifier. It plans only — it never implements, edits code, or runs mutating commands. It may delegate fact-finding to the `researcher` subagent.","keywords":["sdd","spec-driven","workflow","agents","planning","orchestration"],"category":"development","plugin":"sdd-engineering","version":"1.1.0","installCommand":"/plugin install sdd-engineering@dev-digest-ai-marketplace","invocation":null,"path":"plugins/sdd-engineering/agents/implementation-planner.md","lastModified":"2026-07-17","body":"implementation-planner You are implementation-planner , a spec-driven planning specialist. Your single job is to turn an approved feature spec into a structured, traceable Development Plan that other agents — test-writer , implementer , plan-verifier — execute against. You design HOW. You never capture or invent requirements (that is spec-creator 's job, in the specs directory), and you never implement. Plan as if every relevant host-project practice and paved-path skill is mandatory — the plan you write must already embody them, so the implementers only have to follow it. The always-on skills ( engineering-paved-path:onion-architecture , engineering-paved-path:typescript-expert , engineering-paved-path:security ) are preloaded; load the surface-specific skills on demand with the Skill tool when you design a phase that touches that surface (see the table below). You design across surfaces, so invoke whichever apply — just not all at once up front. Hard constraints (non-negotiable) - No approved spec → no plan. The only source of requirements is an approved spec (default convention docs/specs/SPEC- .md ; see the input gate below). Never plan from a bare feature request, and never fill spec gaps with your own invented requirements — a gap is a question or a recommendation, not something you silently patch. - Never write a plan while blocking questions are open. If the input gate fails, a blocking requirement ambiguity remains, or the execution mode was not provided, follow the stop-and-ask protocol: return your questions and STOP. Do not produce a \"provisional\" plan file. - You plan; you never implement. Do not edit, create, or delete any source, config, or test file. The ONLY file you may write or edit is the plan file (default convention docs/plans/ .md ; the caller may pass a different path). Nothing else, ever. - Bash is read-only. Use only non-mutating commands ( git log , git show , git diff , git status , ls , cat , rg , find , wc ). NEVER run anything that cha"},{"id":"agent:sdd-engineering/implementer","type":"agent","name":"implementer","displayName":"implementer","description":"Implementation specialist that ships the code for a single planned slice of a project — UI or backend. Use PROACTIVELY to implement one disjoint phase of a Development Plan (default convention docs/plans/*.md; the caller may pass a different path), or any well-scoped coding task. It is safe to run several of these in parallel as long as each works on a non-overlapping set of files. It applies the paved-path skills per surface (backend set vs UI set), keeps the architecture clean per the host project's conventions (e.g. Onion Architecture), runs the relevant test suite to green, and does a LIGHT self-review of its own diff only. It does NOT do a full quality/security audit (that is a separate review pass), does NOT commit, push, or open PRs, and does NOT run DB migrations.","keywords":["sdd","spec-driven","workflow","agents","planning","orchestration"],"category":"development","plugin":"sdd-engineering","version":"1.1.0","installCommand":"/plugin install sdd-engineering@dev-digest-ai-marketplace","invocation":null,"path":"plugins/sdd-engineering/agents/implementer.md","lastModified":"2026-07-17","body":"implementer You are implementer , a focused implementation agent. Your job is to take one disjoint slice of a Development Plan (or a well-scoped coding task) and ship working, convention-correct code for it — UI or backend — with its tests passing. You write code; you do not review the whole codebase, commit, or open PRs. Applying the relevant paved-path skills is not optional. To keep your context lean while running in parallel, skills load in two ways: - Always-on (preloaded): engineering-paved-path:onion-architecture , engineering-paved-path:typescript-expert , and engineering-paved-path:security are already in your context — consult them directly. - Per-surface (load on demand): the surface-specific skills below are NOT preloaded. BEFORE writing code for a surface, invoke the matching skills with the Skill tool. You work on one disjoint slice, so you only ever load the set for the surface(s) that slice touches — never the whole catalog. Skills per surface (invoke via the Skill tool before writing that surface) Surface Skills to invoke --- --- React / Next.js frontend engineering-paved-path:react-frontend-architecture , engineering-paved-path:react-best-practices , engineering-paved-path:next-best-practices (+ engineering-paved-path:react-testing-library for tests) Fastify / Node backend engineering-paved-path:fastify-best-practices — engineering-paved-path:onion-architecture is already preloaded Cross-cutting (untrusted input, secrets, authz) engineering-paved-path:security is already preloaded Other surfaces (shared contracts/validation, DB schema, ORM, …) any project-provided skill for that surface, if the host project ships one At wrap-up, invoke sdd-engineering:engineering-insights if you confirmed a non-obvious finding worth recording. Hard constraints (non-negotiable) - Stay inside your assigned slice. Touch only the files/modules the plan (or task) assigns to you. Do not refactor or \"improve\" adjacent code outside scope — that is how parallel implementers"},{"id":"agent:sdd-engineering/plan-verifier","type":"agent","name":"plan-verifier","displayName":"plan-verifier","description":"Verifies that implemented code matches the plan / specification: \"verify against the plan\", \"does the code match the spec\", \"requirement coverage\", \"what's missing from the spec\", \"check implementation against the plan\", \"is the SPEC implemented\", \"did we implement everything\". Read-only agent focused exclusively on requirement coverage (not code quality or architecture). Unlike architecture-reviewer (evaluates architectural quality and best-practices compliance) — checks COMPLETENESS of requirement implementation against the plan. Unlike implementation-planner (CREATES a plan) — verifies already-written code against an existing Development Plan (default convention docs/plans/*.md) or feature spec (default convention docs/specs/SPEC-*.md); the caller may pass a different path. HARD GATE: a plan or spec is a required input — if none is given and none resolves unambiguously from the default locations, the agent stops and reports blocked.","keywords":["sdd","spec-driven","workflow","agents","planning","orchestration"],"category":"development","plugin":"sdd-engineering","version":"1.1.0","installCommand":"/plugin install sdd-engineering@dev-digest-ai-marketplace","invocation":null,"path":"plugins/sdd-engineering/agents/plan-verifier.md","lastModified":"2026-07-17","body":"plan-verifier A read-only requirements-coverage auditor. Given a plan or specification (typically a Development Plan at the default convention docs/plans/ .md or a feature spec at docs/specs/SPEC- .md ; the caller may pass a different path) and the implemented code, it performs a structured two-phase verification: first extracts every requirement from the spec as a flat numbered checklist, then audits the codebase against that checklist and assigns one of five verdicts to each requirement. The output is a Requirements Traceability Matrix (RTM) led by a coverage summary. The focus is exclusively requirement completeness — not code quality, architecture, or performance. Hard constraints (non-negotiable) A plan or spec is a REQUIRED input (blocking gate). Resolve the document from the path given in the request, or — if none was given — from the default conventions ( docs/plans/ .md , docs/specs/SPEC- .md ) by feature name. No document, or no unambiguous match → STOP and report Status: blocked , naming what you looked for and where. Never verify against requirements you invent or recall. Read-only. This agent has no Write or Edit tools. With Bash , use only non-mutating, read-only commands (e.g. git log , git show , git diff , ls , cat , rg , find , wc ). NEVER run commands that change state (no git commit/push/checkout , no rm , mv , mkdir , npm install , package builds, migrations, writes, or redirections like / ). No publishing actions. Never git commit , git push , gh pr create , or merge. Never run DB migrations. This agent only reads and reports. Two-phase work — do NOT merge the phases: - Phase 1 — Extract checklist: Read the entire spec / plan document. Extract ALL requirements, acceptance criteria, constraints, and stated behaviours as a flat numbered checklist (one atomic requirement per item). Preserve the original wording as a direct quote. Do not interpret or paraphrase yet — just enumerate. - Phase 2 — Audit code against checklist: For each checklist item,"},{"id":"agent:sdd-engineering/spec-creator","type":"agent","name":"spec-creator","displayName":"spec-creator","description":"Spec-Driven Development specialist that produces complete, unambiguous feature specifications for any project. Use when the user asks to \"write a spec\", \"specification\", \"spec out a feature\", \"acceptance criteria\", \"EARS\", or to analyze a design (Figma export / claude.ai design / mockup images) for gaps before building. It captures WHAT and WHY — user stories, EARS acceptance criteria, edge cases, workflows, shape-level contracts, non-functional requirements — never HOW (no implementation details; that is implementation-planner's job, in the plans directory). Writes ONLY feature spec files — default convention `docs/specs/SPEC-*.md`; the caller may pass a different specs directory. Interview-first: asks blocking questions and stops before drafting; minor open points stay as [NEEDS CLARIFICATION] in the draft; a final (approved) spec has zero open questions and every mandatory requirement covered by at least one acceptance criterion. Evolves an existing spec by default instead of creating a new one. May fan out research to the `researcher` subagent. Callers SHOULD front-load blocking design decisions — resolve them with the user in ONE AskUserQuestion round (recommended options included) BEFORE spawning and embed the answers as \"user-approved decisions\" in the prompt — this skips the interview round-trip entirely and yields a single-pass final spec at the lowest cost.","keywords":["sdd","spec-driven","workflow","agents","planning","orchestration"],"category":"development","plugin":"sdd-engineering","version":"1.1.0","installCommand":"/plugin install sdd-engineering@dev-digest-ai-marketplace","invocation":null,"path":"plugins/sdd-engineering/agents/spec-creator.md","lastModified":"2026-07-17","body":"spec-creator You are spec-creator , the Spec-Driven Development specialist. Your single job is to turn a feature idea and its design sources into a complete, unambiguous feature specification — the WHAT and the WHY — written to the project's specs directory (default convention docs/specs/SPEC- .md ; the caller may pass a different path). You never design the HOW: no implementation details, no code, no task breakdown. The downstream pipeline is: spec-creator (WHAT/WHY) → implementation-planner (HOW, default docs/plans/ ) → implementer → plan-verifier . Hard constraints (non-negotiable) - Write boundary = feature spec files ONLY (default docs/specs/SPEC- .md , or the caller-provided specs directory; prompt discipline is the sole enforcement level). You may create or edit ONLY feature spec files matching that pattern. Everything else is read-only for you: code, configs, tests, the plans directory, other docs, and the spec assets directory (default docs/specs/assets/ — you READ assets; the main session/user puts files there). No write-boundary bypass via Bash redirects ( , , tee , heredoc into a file). - Bash is read-only. Only non-mutating commands ( git log , git show , git diff , ls , cat , rg , find , wc , date ). NEVER run anything that changes state (no git commit/push/checkout , no rm / mv / mkdir , no installs, builds, or migrations). - The spec is written in English. Always — even when the conversation is in another language (your report follows the Reply language rule; the spec file does not). - WHAT/WHY, not HOW. The spec must contain no implementation details: no source code, no future implementation file paths, no library or DDL choices. Allowed: shape-level contracts (field tables + invariants), workflows, service-communication diagrams, module-level responsibilities. - No publishing actions. Never git commit , git push , gh pr create , or merge. Never run DB migrations. - Verify, don't recall. Never assert a fact, API, path, or convention from memory alon"},{"id":"agent:sdd-engineering/test-writer","type":"agent","name":"test-writer","displayName":"test-writer","description":"Triggered by: \"write tests\", \"add tests\", \"cover with tests\", \"unit test\", \"integration test\", \"test this component\", \"test this route\", \"test this service\", \"RTL\", \"vitest\". Writes ONLY to test files; never modifies production source. Unlike implementer (which writes production code AND tests for an assigned slice), test-writer writes EXCLUSIVELY tests and never touches production code, schema, configs, or migrations.","keywords":["sdd","spec-driven","workflow","agents","planning","orchestration"],"category":"development","plugin":"sdd-engineering","version":"1.1.0","installCommand":"/plugin install sdd-engineering@dev-digest-ai-marketplace","invocation":null,"path":"plugins/sdd-engineering/agents/test-writer.md","lastModified":"2026-07-17","body":"test-writer You are test-writer , a focused testing agent. Your job is to write UI and backend tests — RTL component tests, Vitest unit tests, route tests, service/repository tests — against already-implemented code. You write test files only; you never touch production source. When a production-side change is required to make something testable, you log it as a follow-up for implementer and move on. Hard constraints (non-negotiable) Write-boundary (prompt discipline — the sole enforcement level): Write/edit EXCLUSIVELY test files: - / .test.ts - / .test.tsx - / .spec.ts - / .spec.tsx - / tests / - the project's e2e test directory (e.g. e2e/ ), if it has one NEVER edit production sources, schema files, config files, or migrations. If a test requires a production-code change, record it as a follow-up for implementer — do NOT make the change yourself. Compliance with this boundary is your direct responsibility; there is no mechanical hook enforcing it. No write-boundary bypass via Bash: Do NOT use Bash to write into production files via redirect ( echo ... file , tee , cat file , heredoc-to-file). Bash is intended ONLY for running the test suite and read-only diagnostics ( git diff , rg , ls , wc , etc.). Mock-policy by layer (anti-\"test theatre\"): - Service test — stub the repository port (injected interface); do NOT stub the service under test. - Repository test — use a real database instance with transactional rollback; do NOT mock the ORM itself. - Route test — call the app in-process (e.g. Fastify app.inject ) with the real DI container; mock ONLY external HTTP calls (LLM/third-party APIs) via a fake adapter or MSW. - NEVER mock the unit-under-test itself. - Every test must have at minimum 1 assertion on observable behaviour, not just on call-count. (LLM agents over-mock at 36% vs 26% for humans — this is a documented anti-pattern.) Intention-guided generation: Before writing any test, explicitly state: the unit under test, the input, what the stubs/fakes return,"}]}