sdd

Plugin sdd from marketplace eli-marketplace in bingeli1379/eli-marketplace. Commands read from the repo's manifest — 6 days ago.

Skills (31)

• agent-guidelines

  Universal behavioral guidelines for ALL agents. Covers coding discipline (think before coding, simplicity first), scanning coverage (scope it, show it), language conventions, and spec-driven input rules. MUST be loaded when: dispatching any agent for implementation, review, or analysis tasks.

• apply-all

  Use when the user has several prepared changes and wants to batch-implement them unattended, running /apply on each of them sequentially.

• apply

  Implement tasks from a spec change using Agent Team dispatch. Use when the user wants to start or continue implementing a change. Reads spec artifacts and dispatches tasks to specialized agents.

• clean-architecture

  Clean Architecture for .NET applications. Covers the 4-project layout (Domain, Application, Infrastructure, Api), dependency inversion, use case handlers, domain entities with behavior, and infrastructure as a plugin. Load this skill when building a project with Clean Architecture, discussing layere

• codebase-design

  Use when designing or reviewing a module's interface — deciding how much surface to expose, where to put a seam, whether to introduce an abstraction, or whether code is testable through its interface. Provides the deep-module vocabulary (depth, seam, adapter, leverage, locality) shared by the archit

• complete

  Use when a change's implementation is finished and it should be closed out — confirm its tasks are done, then clean up the change artifacts and commit. If a name is given, complete that specific change. If omitted, scan for and batch-complete every fully finished change.

• conventional-commits

  Use when an sdd workflow step is already committing — a per-group commit during /apply, the cleanup commit at /complete — and needs the Conventional Commits format rules for feat/fix/chore/docs type choice, scope, and BREAKING CHANGE notation. Format reference only; NOT a trigger to start committing

• ddd

  Domain-Driven Design tactical patterns for .NET applications. Covers aggregates, aggregate roots, value objects, domain events, domain services, strongly-typed IDs, and repository patterns for aggregate persistence. Load this skill when implementing DDD, working with aggregates, value objects, domai

• differential-review

  Use when reviewing code changes (PRs, commits, diffs) for security regressions, vulnerability introduction, or attack surface changes. - Read - Write - Grep - Glob - Bash

• engineering-checklist

  Mandatory principles and checklist for ALL engineers (frontend & backend) when writing or modifying code. MUST be loaded when: implementing tasks, fixing bugs, refactoring code, or reviewing code. Covers rename completeness, import integrity, dead code cleanup, test hygiene, lock-file regeneration a

• frontend-checklist

  Mandatory principles and checklist for frontend engineers when writing or modifying JS/TS/Vue code. MUST be loaded when: implementing frontend tasks, writing Vue components, composables, migrating Options API to Composition API, refactoring SFC structure, authoring a JS/TS library/plugin, or reviewi

• insecure-defaults

  Detects fail-open insecure defaults (hardcoded secrets, weak auth, permissive security) that allow apps to run insecurely in production. Use when auditing security, reviewing config management, or analyzing environment variable handling.

• kafka-consumer-patterns

  Use when building, reviewing, or debugging a Kafka consumer: delivery semantics, offset-commit strategy, consumer-group rebalancing, idempotent processing, dedup, poison-message handling, dead-letter topics, ordering, or backpressure. MUST be loaded when: a repo consumes from Kafka using any client.

• owasp-security

  Use when reviewing code for security vulnerabilities, implementing authentication/authorization, handling user input, or discussing web application security. Covers OWASP Top 10:2025, ASVS 5.0, and Agentic AI security (2026).

• performance

  Optimize web performance for faster loading and better user experience. Use when asked to "speed up my site", "optimize performance", "reduce load time", "fix slow loading", "improve page speed", or "performance audit".

• playwright-best-practices

  Use when writing, debugging, or stabilizing Playwright tests — flaky tests, Page Object Model, fixtures, CI configuration, network mocking and interception, auth/OAuth flows, visual and accessibility checks, performance budgets, tags and sharding. Covers E2E, component, API, visual, accessibility, s

• playwright

  Use when setting up Playwright, automating browser interactions, or running cross-browser / visual-regression / component tests. For how to write good tests, fix flaky tests, and test patterns, use playwright-best-practices.

• propose

  Use when the user wants to describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation — produces the spec artifacts (proposal, design, tasks, specs) for a new change.

• quick

  Quick task execution with orchestrator analysis but no spec artifacts. Use when the user has small-to-medium tasks and wants agent team dispatch without the full propose → validate → apply ceremony.

• research

  Use when you need to understand an area of a codebase and produce a durable findings document to hand to someone else — how a flow works, what a subsystem touches, what depends on it, where the risks are, why it was built that way — without proposing or making any change. Read-only: no spec artifact

• review-triage

  Use when consolidating findings from multiple read-only review agents into one report for a human — verifying each finding's cited location still exists, dropping only findings the diff or file disproves, and collapsing one root cause reported across many files into a single item. Load before writin

• review

  Use when you want a standalone, read-only review of existing code, a diff, an API/controller, a stored procedure, or a page — without changing anything, by lens (quality / security / performance / e2e). Also use when you have no specific target and want to know where the codebase is decaying ("哪裡爛了"

• role

  Use when you want to interactively work AS one of the sdd specialist agents (architect, dotnet/vue/python/electron/godot engineer, database, devops, security, performance, qa, review, technical-writer) — adopting its expertise, skills, and conventions as a conversational persona. Unlike dispatching

• scope-contract

  Use when a change's intent should be confirmed with the user BEFORE any code or design is written — standalone before a native coding session, inside /quick, or as the propose checkpoint. Presents the intent as a single 現在 → 改成 (Before → After) list, so a missed downstream consumer — a callsite not

• setup

  Initialize feature-spec directory and auto-generate config.yaml — a one-time baseline of tool commands plus a pointer-form architecture map. Two-phase: SCAN (dry-run + confirm) then BUILD (write file). Use when setting up a new project for sdd, or when the user wants to regenerate the config baselin

• sharp-edges

  Identifies error-prone APIs, dangerous configurations, and footgun designs that enable security mistakes. Use when reviewing API designs, configuration schemas, cryptographic library ergonomics, or evaluating whether code follows 'secure by default' and 'pit of success' principles. Triggers: footgun

• supply-chain-risk-auditor

  Identifies dependencies at heightened risk of exploitation or takeover. Use when assessing supply chain attack surface, evaluating dependency health, or scoping security engagements.

• systematic-debugging

  Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes. Enforces root cause investigation through 4 phases: reproduce, gather evidence, analyze, verify. MUST be loaded when: debugging issues, fixing test failures, investigating unexpected behavior.

• test-driven-development

  Use when implementing any feature or bugfix, before writing implementation code. Enforces RED-GREEN-REFACTOR cycle: write failing test first, minimal code to pass, then refactor. MUST be loaded when: implementing new features, fixing bugs, writing any production code.

• validate

  Validate spec artifacts against structural and content rules. Use when the user wants to check if spec artifacts are complete and well-formed before implementation.

• verification-before-completion

  Use when about to claim work is complete, fixed, or passing, before committing or creating PRs. Requires running verification commands and confirming output before making any success claims. Evidence before assertions, always.

Subagents (7)

• architect

  Software Architect. Designs system architecture, defines API contracts, ensures frontend-backend integration, and produces implementation specs for other agents to follow. - agent-guidelines - clean-architecture - codebase-design

• orchestrator

  Tech Lead role the main session adopts during /apply and /quick: dispatches task groups to specialist agents, runs the review/fix loop, squashes commits. Never writes code directly. Not dispatched as a subagent. - agent-guidelines

• performance-engineer

  Performance engineer — static, report-only. Reviews frontend performance (Core Web Vitals, bundle size, rendering), backend performance (API/query/stored-procedure paths, caching), and data-scale capacity (will this API hold N rows / how much can it pull) across Vue, Python and .NET/C#; prescribes t

• qa-engineer

  Senior QA Engineer specializing in E2E acceptance testing with Playwright. Writes and runs E2E tests to verify all spec scenarios (WHEN/THEN) pass. Does NOT write unit tests (that's frontend/backend agents' responsibility). - agent-guidelines - engineering-checklist

• review-engineer

  Strict but fair code reviewer. Reviews architecture compliance, correctness, performance, maintainability for frontend (Vue ecosystem) and backend (ASP.NET / Python) projects. - agent-guidelines - engineering-checklist - frontend-checklist - codebase-design

• security-engineer

  Security specialist. Reviews code for vulnerabilities, misconfigurations, and compliance issues across frontend (Vue ecosystem) and backend (ASP.NET / Python) stacks. - agent-guidelines - owasp-security - differential-review

• technical-writer

  Documentation specialist. Generates and updates API docs, changelogs, README sections, and technical documentation from code changes and specs. - agent-guidelines

Similar plugins