design-solution

name	design-solution
description	Turn an approved PRD or implementation goal into SRS/FRS technical requirements (How), architecture, contracts, and verification decisions.
metadata	{"triggers":{"keywords":["design solution","workflow"]}}

Design Solution Skill

[!IMPORTANT] Turn an approved PRD or implementation goal into SRS/FRS technical requirements (How), architecture, contracts, and verification decisions.

Instructions

When the user asks to perform this workflow, execute the following steps:

Design Solution Workflow (SRS/FRS / How)

Goal: Produce a build-ready technical design with explicit boundaries, contracts, risks, and tests.

Steps

1. Load inputs:
   • Load baseline: docs/requirements-standards-baseline.md (SRS/FRS section).
   • Load common-software-requirements.
   • PRD or ticket
   • Existing implementation plan if present
   • Relevant AGENTS.md and matched framework skills
   • Existing code patterns and architecture docs
   • Trace source: BRD-OBJ-* -> REQ-* -> AC-*
2. Define architecture:
   • Name bounded contexts and module owners.
   • Define dependency direction.
   • Choose sync, async, or hybrid communication.
   • Record data ownership and migration needs.
3. Define contracts:
   • Functional flows (FRS): user/system steps, inputs/outputs, validations, and error states.
   • For complex flows, use one actor, one goal, one session; split normal course from alternatives and exceptions.
   • Requirement cards: statement, priority, status, source, behavior, NFRs, measurement, and verification lane.
   • API inputs/outputs and interface contracts.
   • Events/jobs and async guarantees.
   • Storage shape, ownership, retention, and migration rules.
   • Security, permission, and privacy checks.
   • NFR thresholds for performance, reliability, and scalability.
4. Plan verification:
   • Unit, integration, E2E, visual, mobile, security, and migration checks.
   • Save technical requirements to docs/specs/srs-[slug].md when file writes are allowed.
   • Record evidence in docs/templates/walkthrough.md.
   • Rollback or degradation path.
5. Record ADR:
   • Write one concise ADR when architecture or public contract changes.
   • Route next step to implement-feature or dev-fix.

Output

Output Template

# Technical Design (SRS/FRS): [Name]

## Context

## Requirement Trace

## Architecture

## Functional Flows (FRS)

## Requirement Cards

## Contracts

## Data And Migration

## NFR Thresholds

## Measurement Methods

## Security And Privacy

## Failure Modes

## Verification Plan

## ADR

## Next Workflow

implement-feature | dev-fix

## Cost Report