dev-workflows-frontend

Plugin dev-workflows-frontend from marketplace claude-code-workflows in shinpr/claude-code-workflows. Commands read from the repo's manifest — yesterday.

Skills (18)

• ai-development-guide

  Applies technical decision criteria, anti-pattern detection, debugging, and quality gates for backend and frontend code. Use when implementing, reviewing, or diagnosing code, code smells, failures, or implementation completeness.

• coding-principles

  Language-agnostic coding principles for maintainability, readability, and quality. Use when implementing features, refactoring code, or reviewing code quality.

• documentation-criteria

  Determines which of PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires, and where each is stored. Use when deciding documentation scope, or when creating or reviewing a technical document.

• external-resource-context

  Records where resources outside the repository live (design source, design system, API schema, IaC source, secret store) and how design, implementation, and verification reach them. Use when work depends on an external resource, or when the user mentions design source, design system, API schema, IaC

• implementation-approach

  Implementation strategy selection framework. Use when planning implementation strategy, selecting development approach, or defining verification criteria.

• integration-e2e-testing

  Defines integration/E2E skeleton annotations, lane and file contracts, and route-parity review criteria. Use when generating or consuming test skeletons or reviewing shared mutation routes.

• llm-friendly-context

  Clarifies inputs, outputs, success criteria, decisions, and unresolved conditions so downstream consumers can execute without guessing. Use when writing or revising LLM-facing prompts, handoffs, planning artifacts, reviews, reports, or generated instructions.

• recipe-diagnose

  Investigate problem, verify findings, and derive solutions

• recipe-front-adjust

  Adjust an already-implemented UI in-session with verification against the design source

• recipe-front-build

  Execute materialized frontend task files in autonomous execution mode

• recipe-front-design

  Execute from repository evidence through applicable UI Spec and optional ADR decisions to complete frontend Design Doc approval

• recipe-front-plan

  Create frontend work plan from design document and obtain plan approval

• recipe-front-review

  Reviews completed frontend implementation for governing-source compliance, scope economy, repository quality, and security, then applies user-approved React corrections.

• recipe-quality-profile

  Proposes repository-specific quality policy for implementation and review and, after confirmation, creates or updates docs/project-context/quality.yaml. Use when asked to create or update a repository quality profile.

• recipe-update-doc

  Update existing design documents (Design Doc / PRD / ADR) with review

• requirement-convergence

  Separates the outcome a change must produce from the requirements proposed to reach it, records what the user excluded, and bands cost from decision-relevant repository evidence. Use when a requirement enters a workflow, before design begins.

• subagents-orchestration-guide

  Guides subagent coordination through implementation workflows. Use when orchestrating multiple agents, managing workflow phases, or determining autonomous execution mode.

• testing-principles

  Language-agnostic testing principles for choosing which tests a change needs, test quality, and proof ownership, including frontend and browser E2E tests. Use when writing tests, deciding test scope, or reviewing test quality.

Subagents (20)

• acceptance-test-generator

  Generates integration/E2E test skeletons from Design Doc ACs using required proof boundaries and existing coverage. Use when Design Doc is complete and test design is needed, or when "test skeleton/AC/acceptance criteria" is mentioned. Behavior-first approach for minimal tests with maximum coverage.

• code-reviewer

  Reviews completed implementation for material code correctness, unnecessary mechanisms and tests, governing-source compliance, and repository quality policy. Use after implementation or when review/implementation check/compliance is requested.

• code-verifier

  Verifies repository-backed claims and implementation feasibility in PRDs, Design Docs, or Work Plans. Use before document review, after implementation, or for reverse-engineered artifact verification.

• codebase-analyzer

  Collects compact repository evidence for scope confirmation, technical option selection, complete design, and verification. Use before Design Doc creation when repository facts can change scope, reuse, contracts, cost, or proof.

• design-sync

  Detects conflicts across multiple Design Docs and provides structured reports. Use when multiple Design Docs exist, or when "consistency/conflict/sync/between documents" is mentioned. Focuses on detection and reporting only, no modifications.

• document-reviewer

  Reviews one document or one ADR batch against governing requirements, repository evidence, and the needs of its next consumer. Use before user approval or when document consistency and completeness need verification.

• integration-test-reviewer

  Reviews changed integration and E2E tests against skeletons, proof obligations, or explicit prompt claims. Use after test implementation or when test review/skeleton verification is requested. Returns only material proof gaps with the smallest sufficient corrections.

• investigator

  Comprehensively collects problem-related information and creates evidence matrix. Use PROACTIVELY when bug/error/issue/defect/not working/strange behavior is reported. Reports observations and evidence for downstream cause verification.

• prd-creator

  Creates PRD and structures business requirements. Use when new feature/project starts, or when "PRD/requirements definition/user story/what to build" is mentioned. Defines user value and success metrics.

• quality-fixer-frontend

  Specialized agent for verifying React projects and fixing frontend quality failures within the current task scope. Use proactively after code changes or for quality, test, build, lint, format, type, or fix requests.

• requirement-analyzer

  Collects compact repository scope and cost evidence for requirement confirmation while the user retains product requirements and exclusions and the orchestrator owns comparison, Structural Scale, and document routing. Use when new requirements, scope, or implementation extent must be confirmed.

• security-reviewer

  Reviews completed implementation against governing security requirements and the reachable trust model. Use after implementation or when security review/security check/vulnerability check is requested. Returns only must-fix findings with the smallest sufficient corrections.

• solver

  Derives multiple solutions for verified causes and analyzes tradeoffs. Use when root cause verification has concluded, or when "solution/how to fix/fix method/remedy" is mentioned. Focuses on solutions from given conclusions without investigation.

• task-decomposer

  Converts each approved Work Plan task into one executable implementation task file. Use when work plans are approved and task materialization is needed.

• task-executor-frontend

  Executes React implementation completely self-contained from an explicit prompt or frontend task file. Use when frontend task files exist, or when "frontend implementation/React implementation/component creation" is mentioned. Asks no questions, executes consistently from investigation to implementa

• technical-designer-frontend

  Creates a scoped frontend ADR batch or one Design Doc from UI requirements and decision-relevant repository evidence. Use when frontend technical choices or implementation design need an approved artifact.

• ui-analyzer

  Gathers decision-relevant UI facts from recorded external resources and the existing codebase. Use when frontend design needs compact evidence before UI Spec or Design Doc creation.

• ui-spec-designer

  Creates UI Specifications from requirements and optional prototype code. Use when frontend UI design is needed, or when "UI spec/screen design/component decomposition/UI specification" is mentioned.

• verifier

  Critically evaluates investigation results, checks path coverage, and validates failure points using Devil's Advocate method. Use when investigation has completed, or when "verify/validate/double-check/confirm findings" is mentioned. Focuses on verification and conclusion derivation.

• work-planner

  Creates implementation-focused work plans from approved Design Docs. Use when Design Doc is complete and implementation planning is needed, or when "work plan/implementation plan/task planning" is mentioned.

Similar plugins