dev-workflow

Plugin dev-workflow from marketplace kisune in xbklairith/kisune. Commands read from the repo's manifest — 6 days ago.

Skills (29)

• graders
• brainstorming

  Collaborative refinement of rough ideas into clear requirements/designs through systematic questioning. Use when requirements are vague or exploring architectural options.

• codebase-design

  Shared vocabulary for designing deep modules — module, interface, depth, seam, adapter. Use when designing or improving a module's interface, deciding where a seam goes, hunting for deepening opportunities, or making code more testable.

• completion-validation

  Use when about to claim work is complete, fixed, passing, or ready to commit/PR — requires running verification commands and reading fresh output before any success claim. Evidence before assertions, always.

• deslop

  Rewrites prose in English or Thai so it reads like a person wrote it - lessons, explanations, research notes, reports, docs, READMEs, commit messages, PR descriptions, changelogs. Reorders it so the point and prerequisites come first, swaps LLM vocabulary for words people actually use, and removes a

• domain-modeling

  Build and sharpen a project's domain model — challenge terms, resolve them into a glossary, and record hard-to-reverse decisions as ADRs. Use when codebase terminology is fuzzy or contested, when writing or editing a glossary, or when recording an architectural decision.

• explain-in-html

  Render structure as an HTML page instead of terminal text — Mermaid diagrams, UML, ER and state charts, comparison tables — or put a multi-question round in the browser for the user to answer. Use when the shape of the thing is the point (schemas, state machines, dependency graphs), or when asking t

• git-workflow

  Writes commit messages, manages branches, and opens pull requests with summaries. Use when the user asks to commit, push, branch, or create a PR, and before any destructive git operation such as reset, rebase, or force-push.

• grill-with-docs

  Grilling that leaves a paper trail — runs the grilling interview while capturing resolved terminology and hard-to-reverse decisions into docx/ as they settle.

• grilling

  Interviews the user round by round to stress-test a plan that lives in their head — maps it as a design tree and asks every unblocked question at once, each with a recommended answer, until nothing is silently assumed. Use when the user says 'grill me', 'tear my plan apart', or runs /grilling. For a

• handoff

  Compact the current conversation into a handoff document so a fresh agent can pick up the work.

• investigate

  Research a question against high-trust primary sources and capture the findings as a cited Markdown file. Use when a topic needs researching, docs or API facts gathered, or reading legwork delegated to a background agent.

• more-creativity

  Use when generating ideas, hypotheses or options — "give me ideas", "what are the possibilities", "I'm stuck", "what else could cause X", "hypotheses for why X". Forces divergence before convergence — suppresses evaluation while generating, requires a cross-domain technique, and gates every survivor

• post-mortem

  Write the canonical engineering record of a fixed bug — root cause, mechanism, fix, validation, and how it slipped through. Use after a debug session lands a validated fix, before closing the bug.

• prototype

  Build a throwaway prototype to answer a design question. Use when sanity-checking whether a state model or logic feels right, or exploring what a UI should look like, before committing the decision to real code.

• retro

  Use when a coding session went badly or slowly and the user asks what to change so the next one goes better — "retro", "retrospective", "that session was painful", "why did that take so long", "improve the agent setup". Reads the session's own log (current project only) and proposes changes to the a

• review

  Reviews changed code against a 25-point checklist covering structure, error handling, security, performance, and tests. Use when the user asks to review or improve code or mentions a code smell, before a commit or PR, and after finishing a feature.

• scrutinize

  Outsider-perspective deep review of a plan, PR, design doc, or code change — questions intent first (should this exist?), then traces the actual code path end-to-end to verify the change does what it claims. Use for serious PR reviews, design audits, or second opinions. Lighter pre-commit checks use

• security-review

  OWASP Top 10 vulnerability detection. Use PROACTIVELY for code handling user input, auth, APIs, payments, or sensitive data.

• skill-maker

  Create and edit Claude Code skills with TDD methodology. Use when creating or editing skills. Test with subagents before deployment, iterate until bulletproof.

• spawn-agents

  Use when facing 2+ independent problems (different test files, unrelated bugs, separate subsystems) that can be investigated in parallel without shared state — covers the dispatch decision, the actual Claude Code parallelism mechanism, prompt construction, and integration after agents return

• spec-driven-implementation

  Execute spec-driven implementation — auto-detects Quick (plan.md) or Full (tasks.md) mode and runs step-by-step with verification. Use when implementing a planned feature or running TDD tasks.

• spec-driven-planning

  Plan new features using spec-driven workflow — auto-picks Quick (single plan.md) or Full (3-file EARS spec) mode. Use when creating features, writing requirements, or designing architecture.

• spec-review

  Reviews a feature spec under docx/features/ (requirements, design, tasks) with three sequential agents — spec quality, completeness, and buildability. Use when the user says 'review the spec', 'check the spec', or 'validate the spec', or before a feature moves from planning to implementation.

• systematic-debug

  Finds the root cause of a bug before any fix is written, including failures that cross component boundaries. Use when the user says debug, broken, failing, flaky, or root cause, pastes a stack trace or error log, or tests fail unexpectedly.

• test-driven-development

  Strict RED-GREEN-REFACTOR enforcement with no exceptions. Use when implementing features or fixing bugs. No production code without a failing test first.

• using-kisune

  Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

• wayfinder

  Use when an effort is too big for one agent session and the route is foggy — "huge job, don't know where to start", a migration or re-architecture spanning weeks, "pick up where we left off" on a multi-session plan. Charts a shared map of decision tickets under docx/wayfinder/, then resolves one tic

• wizard

  Use when a human must do steps the agent cannot — creating accounts or API keys in a third-party dashboard, filling .env values, setting GitHub Actions secrets/variables, provisioning a service, a one-off migration or cutover. Generates a runnable interactive bash wizard that opens each URL, says wh

Slash commands (7)

• /dev-workflow:spec

  Launch spec-driven development workflow — picks Quick (single plan.md) or Full (3-file EARS spec) automatically

• /dev-workflow:spec:create

  Create new feature specification

• /dev-workflow:spec:design

  Generate technical design

• /dev-workflow:spec:execute

  Execute implementation with TDD

• /dev-workflow:spec:list

  List all features with status

• /dev-workflow:spec:requirements

  Define requirements using EARS format

• /dev-workflow:spec:tasks

  Break down design into TDD tasks

Subagents (8)

• architect

  Software architecture specialist. Use PROACTIVELY when a change needs a system-design or technology decision, scalability assessment, or comparison of architectural options.

• build-error-resolver

  Build and compilation error resolution specialist. Use PROACTIVELY when build fails or type/compilation errors occur. Fixes build errors only with minimal diffs, no architectural edits. Focuses on getting the build green quickly.

• code-reviewer

  Expert code review specialist. Use PROACTIVELY after writing or modifying code. Reviews for quality, security, and maintainability.

• database-reviewer

  PostgreSQL database specialist for query optimization, schema design, security, and performance. Use PROACTIVELY when writing SQL, creating migrations, designing schemas, or troubleshooting database performance. Incorporates Supabase best practices.

• planner

  Implementation planning specialist. Use PROACTIVELY when users request a multi-file feature or complex refactoring whose architecture is already settled.

• refactor-cleaner

  Dead code cleanup and consolidation specialist. Use PROACTIVELY for removing unused code, duplicates, and refactoring. Identifies dead code through static analysis and safely removes it.

• security-reviewer

  Security vulnerability detection specialist. Use PROACTIVELY after writing code that handles user input, authentication, API endpoints, or sensitive data.

• tdd-guide

  TDD specialist enforcing write-tests-first methodology. Use PROACTIVELY when writing new features, fixing bugs, or refactoring. Ensures every new behavior has a test through the public interface.

Hooks (1)

• SessionStart

  "${CLAUDE_PLUGIN_ROOT}/hooks/run-hook.cmd" session-start

Similar plugins