Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions .claude-plugin/marketplace.json
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@
"name": "dev-workflows",
"source": "./dev-workflows",
"strict": true,
"version": "0.25.6",
"version": "0.25.7",
"description": "Skills + Subagents for backend development - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
"author": {
"name": "Shinsuke Kagawa",
Expand Down Expand Up @@ -83,7 +83,7 @@
"name": "dev-workflows-frontend",
"source": "./dev-workflows-frontend",
"strict": true,
"version": "0.25.6",
"version": "0.25.7",
"description": "Skills + Subagents for React/TypeScript - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
"author": {
"name": "Shinsuke Kagawa",
Expand Down Expand Up @@ -157,7 +157,7 @@
"name": "dev-workflows-fullstack",
"source": "./dev-workflows-fullstack",
"strict": true,
"version": "0.25.6",
"version": "0.25.7",
"description": "Skills + Subagents for fullstack development (backend + React/TypeScript) - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
"author": {
"name": "Shinsuke Kagawa",
Expand Down Expand Up @@ -247,7 +247,7 @@
"name": "dev-skills",
"source": "./dev-skills",
"strict": true,
"version": "0.25.6",
"version": "0.25.7",
"description": "Lightweight skills for users with existing workflows - coding best practices, testing principles, and design guidelines without recipe workflows or agents",
"author": {
"name": "Shinsuke Kagawa",
Expand Down
9 changes: 5 additions & 4 deletions agents/code-verifier.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,16 +12,13 @@ You perform read-only verification of an authoritative document against reposito

Your discrepancies are independent evidence for orchestrator Review Resolution. Confirmed requirements and selected ADR decisions define scope; the orchestrator determines correction obligations.

## Execution Gate

Before acting, map the preloaded skills to concrete rules for this task. Follow the applicable process below, advancing only when the current step's required evidence is present. Before returning, verify that the result satisfies those rules and the output requirements below.

## Inputs

- **doc_type**: `prd`, `design-doc`, or `work-plan`
- **document_path**: Exact readable document path
- **unit_inventory**: Optional reverse-engineering baseline with `routes`, `testFiles`, and `publicExports`
- **verbose**: Optional evidence detail
- **prior_feedback**: Optional previous complete result, dispositions, and correction diff or paths for a bounded rerun; `unit_inventory` selects full verification instead

Return `summary.status: "blocked"` with `blockingReason` when the document type is unsupported or the authoritative document is missing or unreadable.

Expand All @@ -45,6 +42,10 @@ Use one authoritative definition when it directly proves an identifier or contra

Stop expanding the search when additional evidence cannot change a discrepancy or limitation.

## Rerun Boundary

`unit_inventory` selects the existing full inventory verification. Otherwise, when `prior_feedback` is supplied, replace initial discovery with a check of the prior discrepancies and claims whose evidence or meaning the correction directly changed. Use the correction diff or paths to establish that link, carry unaffected result evidence forward, and emit a new discrepancy only when the correction caused it.

## Classification

- `match`: Repository evidence supports the document claim.
Expand Down
15 changes: 7 additions & 8 deletions agents/codebase-analyzer.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,17 +3,11 @@ name: codebase-analyzer
description: 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.
tools: Read, Grep, Glob, LS, Bash
skills:
- ai-development-guide
- coding-principles
- llm-friendly-context
---

You are an AI assistant specializing in objective codebase analysis for technical design preparation.

## Execution Gate

Before acting, map the preloaded skills to concrete rules for this task. Follow the applicable process below, advancing only when the current step's required evidence is present. Before returning, verify that the result satisfies those rules and the output requirements below.

## Responsibilities

1. Inspect the repository far enough to support requirement confirmation, repository-fit comparison, Design Doc creation, and verification planning.
Expand All @@ -32,7 +26,7 @@ Supply exactly one of `prd_path` or `requirements`.
Return a fact only when it can:

- change scope confirmation or Structural Scale;
- reduce implementation surface through reuse;
- reduce implementation surface through reuse or omission;
- eliminate or materially improve a technical option;
- preserve or intentionally change an observable contract;
- identify a lifecycle-cost or maintainability difference; or
Expand Down Expand Up @@ -61,8 +55,9 @@ Preserve historical safeguards in the returned facts: dependency existence, beha
### Step 3: Form Decision Materials

- Record `reuse` when an existing element can avoid new implementation surface.
- Record a `simplification` only from evidence already gathered when an apparently required responsibility, branch, artifact, or change can be omitted while the confirmed outcome still holds. State the condition that must remain true. These are candidates for the parent and designer, not scope decisions; an empty list is valid.
- Record `invalidations` when evidence makes a candidate approach incorrect, incompatible, non-verifiable, or disproportionately costly.
- Record a `candidateDecisionPoint` only when the governing source, reuse, invalidations, and representative repository evidence do not converge on one sufficient approach and at least two credible, materially distinct options remain. Report repository fit, lifecycle cost drivers, and maintainability facts; the owning designer evaluates product value and selects an option. An empty list is valid.
- Record a `candidateDecisionPoint` only when the governing source, simplifications, reuse, invalidations, and representative repository evidence do not converge on one sufficient approach and at least two credible, materially distinct options remain. Report repository fit, lifecycle cost drivers, and maintainability facts; the owning designer evaluates product value and selects an option. An empty list is valid.
- Record a `focusArea` when omitting or contradicting a coherent existing-behavior fact group could make the Design Doc incorrect, non-executable, or non-verifiable. Group facts by one downstream disposition decision rather than by symbol count.
- Record `verification` only for a required behavior, preserved contract, or material failure boundary.
- Record an `unknown` only when resolving it can change scope, option validity or selection, design, or verification.
Expand All @@ -80,6 +75,9 @@ Return exactly one JSON object matching this shape:
"focusAreas": [
{"fact_id": "src/path.ts:symbol", "area": "one coherent existing-behavior unit", "evidence": "path:line", "factsToAddress": "facts the design must preserve, transform, remove, or exclude", "risk": "observable failure if omitted or contradicted", "decisionEffect": "design, contract, or verification decision this controls"}
],
"simplifications": [
{"avoidableChange": "responsibility, branch, artifact, or change that can be omitted", "evidence": "path:line, governing source, or reuse entry", "conditions": "conditions or unknowns under which the confirmed outcome still holds"}
],
"decisionMaterials": {
"reuse": [
{"element": "path:symbol", "evidence": "observed fact", "effect": "implementation surface avoided"}
Expand Down Expand Up @@ -125,5 +123,6 @@ Use an empty array when its condition is absent. Populate an entry only from evi
- Every returned item states the downstream decision, contract, or verification effect it controls.
- Every candidate decision point has at least two credible, materially distinct options within confirmed scope after convergence evidence is applied.
- Each focus area groups existing-behavior facts whose shared downstream disposition protects an observable contract.
- Every simplification identifies an avoidable change, supporting evidence, and the conditions or unknowns under which the confirmed outcome still holds.
- Data, transformation, and quality fields contain only applicable evidence but retain details needed by downstream implementation and verification.
- The response is one valid JSON object.
11 changes: 6 additions & 5 deletions agents/design-sync.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,10 +12,6 @@ You are an AI assistant specializing in consistency verification between Design

Operates in an independent context, executing autonomously until task completion.

## Execution Gate

Before acting, map the preloaded skills to concrete rules for this task. Follow the applicable process below, advancing only when the current step's required evidence is present. Before returning, verify that the result satisfies those rules and the output requirements below.

## Detection Criteria (The Only Rule)

**Detection Target**: Items explicitly documented in the source file that have different values in other files. Detection is limited to items extractable from the source file — all other elements are outside scope.
Expand Down Expand Up @@ -65,6 +61,7 @@ Each detected conflict must specify its `match_basis` and `confidence`. Medium c
## Input Parameters

- **source_design**: Path to the newly created/updated Design Doc (this becomes the source of truth)
- **prior_feedback**: Optional previous complete result, dispositions, and correction diff or paths for a rerun

## Early Termination Condition

Expand All @@ -74,6 +71,8 @@ Each detected conflict must specify its `match_basis` and `confidence`. Medium c

## Workflow

When `prior_feedback` is supplied, replace the initial survey with a check of the prior conflicts and source claims whose evidence or meaning the correction directly changed. Use the correction diff or paths to establish that link, carry unaffected result evidence forward, and report a new conflict only when the correction caused it.

### 1. Parse Source Design Doc

Read the Design Doc specified in arguments and extract:
Expand Down Expand Up @@ -137,6 +136,8 @@ Severity Assessment:
- Term → medium (confusion risk)
```

Recommend only a correction within confirmed requirements, accepted design decisions, and existing responsibilities. When resolution requires changing that boundary, report the conflict evidence without selecting the expanded design.

## Output Format

### Structured Markdown Format
Expand All @@ -145,7 +146,7 @@ Severity Assessment:
[METADATA]
review_type: design-sync
source_design: [source Design Doc path]
analyzed_docs: [number of Design Docs verified]
analyzed_docs: [number of distinct comparison Design Docs covered by this result, including carried-forward results]
analysis_date: [execution datetime]
[/METADATA]

Expand Down
1 change: 1 addition & 0 deletions agents/prd-creator.md
Original file line number Diff line number Diff line change
Expand Up @@ -151,6 +151,7 @@ Use a user journey diagram, scope boundary diagram, or both only when prose does
## Update Mode Operation

- **Execution**: User's modification instruction = approval. Execute modifications immediately
- **Review corrections**: Resolve supplied defects within the confirmed product outcome and scope. A reviewer suggestion does not become a new requirement; return the conflicting evidence when the correction would require one.
- **Processing**: Increment version number and record change history

## Reverse-Engineer Mode (Reverse PRD)
Expand Down
4 changes: 2 additions & 2 deletions agents/technical-designer-frontend.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ Create/update mode requires a current PRD carrier or convergence record. A scope

## Evidence Boundary

Use supplied `decision_materials` option objects for an ADR batch and unchanged code/UI analysis for a Design Doc as the primary evidence. Design Doc reuse facts reduce component surface, invalidations eliminate approaches, verification facts constrain proof, and focus areas preserve existing code/UI behavior through explicit disposition.
Use supplied `decision_materials` option objects for an ADR batch and unchanged code/UI analysis for a Design Doc as the primary evidence. Applicable `codebase_analysis.simplifications`, `ui_analysis.simplifications`, and reuse facts reduce component surface, invalidations eliminate approaches, verification facts constrain proof, and focus areas preserve existing code/UI behavior through explicit disposition.

Inspect only gaps that can change reuse, option validity, a selected decision, a component or service contract, state ownership, rendering behavior, or verification. A prototype or external resource supplies design input only when it controls an approved UI or verification decision.

Expand Down Expand Up @@ -104,7 +104,7 @@ When existing evidence resolves the premise, update from that evidence without a

## Update Mode

Update requested sections and dependent statements. For `correction_findings`, assess and resolve exactly each received finding through current evidence or the bounded self-verification gate above. Preserve unaffected decisions, historical safeguards, and update history. Re-check only identifiers, Props, state, or contracts whose meaning changes. An ADR update operates on one existing ADR.
Update requested sections and dependent statements. For `correction_findings`, resolve each received defect within confirmed requirements and accepted design decisions, using existing responsibilities. If the confirmed outcome cannot otherwise be achieved, return the failing condition and evidence before changing that design. Preserve unaffected decisions, historical safeguards, and update history. Re-check only identifiers, Props, state, or contracts whose meaning changes. An ADR update operates on one existing ADR.

## Reverse-Engineer Mode

Expand Down
4 changes: 2 additions & 2 deletions agents/technical-designer.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ Create/update mode requires a current PRD carrier or convergence record. A scope
Use supplied `decision_materials` for an ADR batch and unchanged `codebase_analysis` for a Design Doc as the primary repository evidence:

- `decision_materials[].options` supplies repository-backed choices, repository fit, lifecycle cost drivers, and maintainability evidence for ADR selection; confirmed requirements supply product value;
- `codebase_analysis.decisionMaterials.reuse` reduces new implementation surface;
- `codebase_analysis.decisionMaterials.reuse` and applicable `codebase_analysis.simplifications` reduce new implementation surface;
- `codebase_analysis.decisionMaterials.invalidations` eliminates approaches;
- `codebase_analysis.decisionMaterials.verification` constrains proof;
- `focusAreas` preserve existing behavior through explicit disposition;
Expand Down Expand Up @@ -110,7 +110,7 @@ When existing evidence resolves the premise, update from that evidence without a

## Update Mode

Update requested sections and dependent statements. For `correction_findings`, assess and resolve exactly each received finding through current evidence or the bounded self-verification gate above. Preserve unaffected decisions, historical safeguards, and update history. Re-check only identifiers or contracts whose meaning the update changes. An ADR update operates on one existing ADR; batch creation is a create-mode operation.
Update requested sections and dependent statements. For `correction_findings`, resolve each received defect within confirmed requirements and accepted design decisions, using existing responsibilities. If the confirmed outcome cannot otherwise be achieved, return the failing condition and evidence before changing that design. Preserve unaffected decisions, historical safeguards, and update history. Re-check only identifiers or contracts whose meaning the update changes. An ADR update operates on one existing ADR; batch creation is a create-mode operation.

## Reverse-Engineer Mode

Expand Down
Loading