mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-05 01:50:27 +08:00
feat: add api-designer command for generating framework-based analysis
This commit is contained in:
566
.claude/commands/workflow/brainstorm/api-designer.md
Normal file
566
.claude/commands/workflow/brainstorm/api-designer.md
Normal file
@@ -0,0 +1,566 @@
|
||||
---
|
||||
name: api-designer
|
||||
description: Generate or update api-designer/analysis.md addressing topic-framework discussion points
|
||||
argument-hint: "optional topic - uses existing framework if available"
|
||||
allowed-tools: Task(conceptual-planning-agent), TodoWrite(*), Read(*), Write(*)
|
||||
---
|
||||
|
||||
## 🔌 **API Designer Analysis Generator**
|
||||
|
||||
### Purpose
|
||||
**Specialized command for generating api-designer/analysis.md** that addresses topic-framework.md discussion points from backend API design perspective. Creates or updates role-specific analysis with framework references.
|
||||
|
||||
### Core Function
|
||||
- **Framework-based Analysis**: Address each discussion point in topic-framework.md
|
||||
- **API Design Focus**: RESTful/GraphQL API design, endpoint structure, and contract definition
|
||||
- **Update Mechanism**: Create new or update existing analysis.md
|
||||
- **Agent Delegation**: Use conceptual-planning-agent for analysis generation
|
||||
|
||||
### Analysis Scope
|
||||
- **API Architecture**: RESTful/GraphQL design patterns and best practices
|
||||
- **Endpoint Design**: Resource modeling, URL structure, and HTTP method selection
|
||||
- **Data Contracts**: Request/response schemas, validation rules, and data transformation
|
||||
- **API Documentation**: OpenAPI/Swagger specifications and developer experience
|
||||
|
||||
## ⚙️ **Execution Protocol**
|
||||
|
||||
### Phase 1: Session & Framework Detection
|
||||
```bash
|
||||
# Check active session and framework
|
||||
CHECK: .workflow/.active-* marker files
|
||||
IF active_session EXISTS:
|
||||
session_id = get_active_session()
|
||||
brainstorm_dir = .workflow/WFS-{session}/.brainstorming/
|
||||
|
||||
CHECK: brainstorm_dir/topic-framework.md
|
||||
IF EXISTS:
|
||||
framework_mode = true
|
||||
load_framework = true
|
||||
ELSE:
|
||||
IF topic_provided:
|
||||
framework_mode = false # Create analysis without framework
|
||||
ELSE:
|
||||
ERROR: "No framework found and no topic provided"
|
||||
```
|
||||
|
||||
### Phase 2: Analysis Mode Detection
|
||||
```bash
|
||||
# Check existing analysis
|
||||
CHECK: brainstorm_dir/api-designer/analysis.md
|
||||
IF EXISTS:
|
||||
SHOW existing analysis summary
|
||||
ASK: "Analysis exists. Do you want to:"
|
||||
OPTIONS:
|
||||
1. "Update with new insights" → Update existing
|
||||
2. "Replace completely" → Generate new
|
||||
3. "Cancel" → Exit without changes
|
||||
ELSE:
|
||||
CREATE new analysis
|
||||
```
|
||||
|
||||
### Phase 3: Agent Task Generation
|
||||
**Framework-Based Analysis** (when topic-framework.md exists):
|
||||
```bash
|
||||
Task(subagent_type="conceptual-planning-agent",
|
||||
prompt="Generate API designer analysis addressing topic framework
|
||||
|
||||
## Framework Integration Required
|
||||
**MANDATORY**: Load and address topic-framework.md discussion points
|
||||
**Framework Reference**: @{session.brainstorm_dir}/topic-framework.md
|
||||
**Output Location**: {session.brainstorm_dir}/api-designer/analysis.md
|
||||
|
||||
## Analysis Requirements
|
||||
1. **Load Topic Framework**: Read topic-framework.md completely
|
||||
2. **Address Each Discussion Point**: Respond to all 5 framework sections from API design perspective
|
||||
3. **Include Framework Reference**: Start analysis.md with @../topic-framework.md
|
||||
4. **API Design Focus**: Emphasize endpoint structure, data contracts, versioning strategies
|
||||
5. **Structured Response**: Use framework structure for analysis organization
|
||||
|
||||
## Framework Sections to Address
|
||||
- Core Requirements (from API design perspective)
|
||||
- Technical Considerations (detailed API architecture analysis)
|
||||
- User Experience Factors (developer experience and API usability)
|
||||
- Implementation Challenges (API design risks and solutions)
|
||||
- Success Metrics (API performance metrics and adoption tracking)
|
||||
|
||||
## Output Structure Required
|
||||
```markdown
|
||||
# API Designer Analysis: [Topic]
|
||||
|
||||
**Framework Reference**: @../topic-framework.md
|
||||
**Role Focus**: Backend API Design and Contract Definition
|
||||
|
||||
## Core Requirements Analysis
|
||||
[Address framework requirements from API design perspective]
|
||||
|
||||
## Technical Considerations
|
||||
[Detailed API architecture and endpoint design analysis]
|
||||
|
||||
## Developer Experience Factors
|
||||
[API usability, documentation, and integration ease]
|
||||
|
||||
## Implementation Challenges
|
||||
[API design risks and mitigation strategies]
|
||||
|
||||
## Success Metrics
|
||||
[API performance metrics, adoption rates, and developer satisfaction]
|
||||
|
||||
## API Design-Specific Recommendations
|
||||
[Detailed API design recommendations and best practices]
|
||||
```",
|
||||
description="Generate API designer framework-based analysis")
|
||||
```
|
||||
|
||||
### Phase 4: Update Mechanism
|
||||
**Analysis Update Process**:
|
||||
```bash
|
||||
# For existing analysis updates
|
||||
IF update_mode = "incremental":
|
||||
Task(subagent_type="conceptual-planning-agent",
|
||||
prompt="Update existing API designer analysis
|
||||
|
||||
## Current Analysis Context
|
||||
**Existing Analysis**: @{session.brainstorm_dir}/api-designer/analysis.md
|
||||
**Framework Reference**: @{session.brainstorm_dir}/topic-framework.md
|
||||
|
||||
## Update Requirements
|
||||
1. **Preserve Structure**: Maintain existing analysis structure
|
||||
2. **Add New Insights**: Integrate new API design insights and recommendations
|
||||
3. **Framework Alignment**: Ensure continued alignment with topic framework
|
||||
4. **API Updates**: Add new endpoint patterns, versioning strategies, documentation improvements
|
||||
5. **Maintain References**: Keep @../topic-framework.md reference
|
||||
|
||||
## Update Instructions
|
||||
- Read existing analysis completely
|
||||
- Identify areas for enhancement or new insights
|
||||
- Add API design depth while preserving original structure
|
||||
- Update recommendations with new API design patterns and approaches
|
||||
- Maintain framework discussion point addressing",
|
||||
description="Update API designer analysis incrementally")
|
||||
```
|
||||
|
||||
## Document Structure
|
||||
|
||||
### Output Files
|
||||
```
|
||||
.workflow/WFS-[topic]/.brainstorming/
|
||||
├── topic-framework.md # Input: Framework (if exists)
|
||||
└── api-designer/
|
||||
└── analysis.md # ★ OUTPUT: Framework-based analysis
|
||||
```
|
||||
|
||||
### Analysis Structure
|
||||
**Required Elements**:
|
||||
- **Framework Reference**: @../topic-framework.md (if framework exists)
|
||||
- **Role Focus**: Backend API Design and Contract Definition perspective
|
||||
- **5 Framework Sections**: Address each framework discussion point
|
||||
- **API Design Recommendations**: Endpoint-specific insights and solutions
|
||||
|
||||
## ⚡ **Two-Step Execution Flow**
|
||||
|
||||
### ⚠️ Session Management - FIRST STEP
|
||||
Session detection and selection:
|
||||
```bash
|
||||
# Check for active sessions
|
||||
active_sessions=$(find .workflow -name ".active-*" 2>/dev/null)
|
||||
if [ multiple_sessions ]; then
|
||||
prompt_user_to_select_session()
|
||||
else
|
||||
use_existing_or_create_new()
|
||||
fi
|
||||
```
|
||||
|
||||
### Step 1: Context Gathering Phase
|
||||
**API Designer Perspective Questioning**
|
||||
|
||||
Before agent assignment, gather comprehensive API design context:
|
||||
|
||||
#### 📋 Role-Specific Questions
|
||||
1. **API Type & Architecture**
|
||||
- RESTful, GraphQL, or hybrid API approach?
|
||||
- Synchronous vs asynchronous communication patterns?
|
||||
- Real-time requirements (WebSocket, Server-Sent Events)?
|
||||
|
||||
2. **Resource Modeling & Endpoints**
|
||||
- What are the core domain resources/entities?
|
||||
- Expected CRUD operations for each resource?
|
||||
- Complex query requirements (filtering, sorting, pagination)?
|
||||
|
||||
3. **Data Contracts & Validation**
|
||||
- Request/response data format requirements (JSON, XML, Protocol Buffers)?
|
||||
- Input validation and sanitization requirements?
|
||||
- Data transformation and mapping needs?
|
||||
|
||||
4. **API Management & Governance**
|
||||
- API versioning strategy requirements?
|
||||
- Authentication and authorization mechanisms?
|
||||
- Rate limiting and throttling requirements?
|
||||
- API documentation and developer portal needs?
|
||||
|
||||
5. **Integration & Compatibility**
|
||||
- Client platforms consuming the API (web, mobile, third-party)?
|
||||
- Backward compatibility requirements?
|
||||
- External API integrations needed?
|
||||
|
||||
#### Context Validation
|
||||
- **Minimum Response**: Each answer must be ≥50 characters
|
||||
- **Re-prompting**: Insufficient detail triggers follow-up questions
|
||||
- **Context Storage**: Save responses to `.brainstorming/api-designer-context.md`
|
||||
|
||||
### Step 2: Agent Assignment with Flow Control
|
||||
**Dedicated Agent Execution**
|
||||
|
||||
```bash
|
||||
Task(conceptual-planning-agent): "
|
||||
[FLOW_CONTROL]
|
||||
|
||||
Execute dedicated api-designer conceptual analysis for: {topic}
|
||||
|
||||
ASSIGNED_ROLE: api-designer
|
||||
OUTPUT_LOCATION: .brainstorming/api-designer/
|
||||
USER_CONTEXT: {validated_responses_from_context_gathering}
|
||||
|
||||
Flow Control Steps:
|
||||
[
|
||||
{
|
||||
\"step\": \"load_role_template\",
|
||||
\"action\": \"Load api-designer planning template\",
|
||||
\"command\": \"bash($(cat ~/.claude/workflows/cli-templates/planning-roles/api-designer.md))\",
|
||||
\"output_to\": \"role_template\"
|
||||
}
|
||||
]
|
||||
|
||||
Conceptual Analysis Requirements:
|
||||
- Apply api-designer perspective to topic analysis
|
||||
- Focus on endpoint design, data contracts, and API governance
|
||||
- Use loaded role template framework for analysis structure
|
||||
- Generate role-specific deliverables in designated output location
|
||||
- Address all user context from questioning phase
|
||||
|
||||
Deliverables:
|
||||
- analysis.md: Main API design analysis
|
||||
- api-specification.md: Detailed endpoint specifications
|
||||
- data-contracts.md: Request/response schemas and validation rules
|
||||
- api-documentation.md: API documentation strategy and templates
|
||||
|
||||
Embody api-designer role expertise for comprehensive conceptual planning."
|
||||
```
|
||||
|
||||
### Progress Tracking
|
||||
TodoWrite tracking for two-step process:
|
||||
```json
|
||||
[
|
||||
{"content": "Gather API designer context through role-specific questioning", "status": "in_progress", "activeForm": "Gathering context"},
|
||||
{"content": "Validate context responses and save to api-designer-context.md", "status": "pending", "activeForm": "Validating context"},
|
||||
{"content": "Load api-designer planning template via flow control", "status": "pending", "activeForm": "Loading template"},
|
||||
{"content": "Execute dedicated conceptual-planning-agent for api-designer role", "status": "pending", "activeForm": "Executing agent"}
|
||||
]
|
||||
```
|
||||
|
||||
## 📊 **Output Specification**
|
||||
|
||||
### Output Location
|
||||
```
|
||||
.workflow/WFS-{topic-slug}/.brainstorming/api-designer/
|
||||
├── analysis.md # Primary API design analysis
|
||||
├── api-specification.md # Detailed endpoint specifications (OpenAPI/Swagger)
|
||||
├── data-contracts.md # Request/response schemas and validation rules
|
||||
├── versioning-strategy.md # API versioning and backward compatibility plan
|
||||
└── developer-guide.md # API usage documentation and integration examples
|
||||
```
|
||||
|
||||
### Document Templates
|
||||
|
||||
#### analysis.md Structure
|
||||
```markdown
|
||||
# API Design Analysis: {Topic}
|
||||
*Generated: {timestamp}*
|
||||
|
||||
## Executive Summary
|
||||
[Key API design findings and recommendations overview]
|
||||
|
||||
## API Architecture Overview
|
||||
### API Type Selection (REST/GraphQL/Hybrid)
|
||||
### Communication Patterns
|
||||
### Authentication & Authorization Strategy
|
||||
|
||||
## Resource Modeling
|
||||
### Core Domain Resources
|
||||
### Resource Relationships
|
||||
### URL Structure and Naming Conventions
|
||||
|
||||
## Endpoint Design
|
||||
### Resource Endpoints
|
||||
- GET /api/v1/resources
|
||||
- POST /api/v1/resources
|
||||
- GET /api/v1/resources/{id}
|
||||
- PUT /api/v1/resources/{id}
|
||||
- DELETE /api/v1/resources/{id}
|
||||
|
||||
### Query Parameters
|
||||
- Filtering: ?filter[field]=value
|
||||
- Sorting: ?sort=field,-field2
|
||||
- Pagination: ?page=1&limit=20
|
||||
|
||||
### HTTP Methods and Status Codes
|
||||
- Success responses (2xx)
|
||||
- Client errors (4xx)
|
||||
- Server errors (5xx)
|
||||
|
||||
## Data Contracts
|
||||
### Request Schemas
|
||||
[JSON Schema or OpenAPI definitions]
|
||||
|
||||
### Response Schemas
|
||||
[JSON Schema or OpenAPI definitions]
|
||||
|
||||
### Validation Rules
|
||||
- Required fields
|
||||
- Data types and formats
|
||||
- Business logic constraints
|
||||
|
||||
## API Versioning Strategy
|
||||
### Versioning Approach (URL/Header/Accept)
|
||||
### Version Lifecycle Management
|
||||
### Deprecation Policy
|
||||
### Migration Paths
|
||||
|
||||
## Security & Governance
|
||||
### Authentication Mechanisms
|
||||
- OAuth 2.0 / JWT / API Keys
|
||||
### Authorization Patterns
|
||||
- RBAC / ABAC / Resource-based
|
||||
### Rate Limiting & Throttling
|
||||
### CORS and Security Headers
|
||||
|
||||
## Error Handling
|
||||
### Standard Error Response Format
|
||||
```json
|
||||
{
|
||||
"error": {
|
||||
"code": "ERROR_CODE",
|
||||
"message": "Human-readable error message",
|
||||
"details": [],
|
||||
"trace_id": "uuid"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Error Code Taxonomy
|
||||
### Validation Error Responses
|
||||
|
||||
## API Documentation
|
||||
### OpenAPI/Swagger Specification
|
||||
### Developer Portal Requirements
|
||||
### Code Examples and SDKs
|
||||
### Changelog and Migration Guides
|
||||
|
||||
## Performance Optimization
|
||||
### Response Caching Strategies
|
||||
### Compression (gzip, brotli)
|
||||
### Field Selection (sparse fieldsets)
|
||||
### Bulk Operations and Batch Endpoints
|
||||
|
||||
## Monitoring & Observability
|
||||
### API Metrics
|
||||
- Request count, latency, error rates
|
||||
- Endpoint usage analytics
|
||||
### Logging Strategy
|
||||
### Distributed Tracing
|
||||
|
||||
## Developer Experience
|
||||
### API Usability Assessment
|
||||
### Integration Complexity
|
||||
### SDK and Client Library Needs
|
||||
### Sandbox and Testing Environments
|
||||
```
|
||||
|
||||
#### api-specification.md Structure
|
||||
```markdown
|
||||
# API Specification: {Topic}
|
||||
*OpenAPI 3.0 Specification*
|
||||
|
||||
## API Information
|
||||
- **Title**: {API Name}
|
||||
- **Version**: 1.0.0
|
||||
- **Base URL**: https://api.example.com/v1
|
||||
- **Contact**: api-team@example.com
|
||||
|
||||
## Endpoints
|
||||
|
||||
### Users API
|
||||
|
||||
#### GET /users
|
||||
**Description**: Retrieve a list of users
|
||||
|
||||
**Parameters**:
|
||||
- `page` (query, integer): Page number (default: 1)
|
||||
- `limit` (query, integer): Items per page (default: 20, max: 100)
|
||||
- `sort` (query, string): Sort field (e.g., "created_at", "-updated_at")
|
||||
- `filter[status]` (query, string): Filter by user status
|
||||
|
||||
**Response 200**:
|
||||
```json
|
||||
{
|
||||
"data": [
|
||||
{
|
||||
"id": "uuid",
|
||||
"username": "string",
|
||||
"email": "string",
|
||||
"created_at": "2025-10-15T00:00:00Z"
|
||||
}
|
||||
],
|
||||
"meta": {
|
||||
"page": 1,
|
||||
"limit": 20,
|
||||
"total": 100
|
||||
},
|
||||
"links": {
|
||||
"self": "/users?page=1",
|
||||
"next": "/users?page=2",
|
||||
"prev": null
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### POST /users
|
||||
**Description**: Create a new user
|
||||
|
||||
**Request Body**:
|
||||
```json
|
||||
{
|
||||
"username": "string (required, 3-50 chars)",
|
||||
"email": "string (required, valid email)",
|
||||
"password": "string (required, min 8 chars)",
|
||||
"profile": {
|
||||
"first_name": "string (optional)",
|
||||
"last_name": "string (optional)"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Response 201**:
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"id": "uuid",
|
||||
"username": "string",
|
||||
"email": "string",
|
||||
"created_at": "2025-10-15T00:00:00Z"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Response 400** (Validation Error):
|
||||
```json
|
||||
{
|
||||
"error": {
|
||||
"code": "VALIDATION_ERROR",
|
||||
"message": "Request validation failed",
|
||||
"details": [
|
||||
{
|
||||
"field": "email",
|
||||
"message": "Invalid email format"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
[Continue for all endpoints...]
|
||||
|
||||
## Authentication
|
||||
|
||||
### OAuth 2.0 Flow
|
||||
1. Client requests authorization
|
||||
2. User grants permission
|
||||
3. Client receives access token
|
||||
4. Client uses token in requests
|
||||
|
||||
**Header Format**:
|
||||
```
|
||||
Authorization: Bearer {access_token}
|
||||
```
|
||||
|
||||
## Rate Limiting
|
||||
|
||||
**Headers**:
|
||||
- `X-RateLimit-Limit`: 1000
|
||||
- `X-RateLimit-Remaining`: 999
|
||||
- `X-RateLimit-Reset`: 1634270400
|
||||
|
||||
**Response 429** (Too Many Requests):
|
||||
```json
|
||||
{
|
||||
"error": {
|
||||
"code": "RATE_LIMIT_EXCEEDED",
|
||||
"message": "API rate limit exceeded",
|
||||
"retry_after": 3600
|
||||
}
|
||||
}
|
||||
```
|
||||
```
|
||||
|
||||
## 🔄 **Session Integration**
|
||||
|
||||
### Status Synchronization
|
||||
Upon completion, update `workflow-session.json`:
|
||||
```json
|
||||
{
|
||||
"phases": {
|
||||
"BRAINSTORM": {
|
||||
"api_designer": {
|
||||
"status": "completed",
|
||||
"completed_at": "timestamp",
|
||||
"output_directory": ".workflow/WFS-{topic}/.brainstorming/api-designer/",
|
||||
"key_insights": ["endpoint_design", "versioning_strategy", "data_contracts"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Cross-Role Collaboration
|
||||
API designer perspective provides:
|
||||
- **API Contract Specifications** → Frontend Developer
|
||||
- **Data Schema Requirements** → Data Architect
|
||||
- **Security Requirements** → Security Expert
|
||||
- **Integration Endpoints** → System Architect
|
||||
- **Performance Constraints** → DevOps Engineer
|
||||
|
||||
## ✅ **Quality Assurance**
|
||||
|
||||
### Required Analysis Elements
|
||||
- [ ] Complete endpoint inventory with HTTP methods and paths
|
||||
- [ ] Detailed request/response schemas with validation rules
|
||||
- [ ] Clear versioning strategy and backward compatibility plan
|
||||
- [ ] Comprehensive error handling and status code usage
|
||||
- [ ] API documentation strategy (OpenAPI/Swagger)
|
||||
|
||||
### API Design Principles
|
||||
- [ ] **Consistency**: Uniform naming conventions and patterns across all endpoints
|
||||
- [ ] **Simplicity**: Intuitive resource modeling and URL structures
|
||||
- [ ] **Flexibility**: Support for filtering, sorting, pagination, and field selection
|
||||
- [ ] **Security**: Proper authentication, authorization, and input validation
|
||||
- [ ] **Performance**: Caching strategies, compression, and efficient data structures
|
||||
|
||||
### Developer Experience Validation
|
||||
- [ ] API is self-documenting with clear endpoint descriptions
|
||||
- [ ] Error messages are actionable and helpful for debugging
|
||||
- [ ] Response formats are consistent and predictable
|
||||
- [ ] Code examples and integration guides are provided
|
||||
- [ ] Sandbox environment available for testing
|
||||
|
||||
### Technical Completeness
|
||||
- [ ] **Resource Modeling**: All domain entities mapped to API resources
|
||||
- [ ] **CRUD Coverage**: Complete create, read, update, delete operations
|
||||
- [ ] **Query Capabilities**: Advanced filtering, sorting, and search functionality
|
||||
- [ ] **Versioning**: Clear version management and migration paths
|
||||
- [ ] **Monitoring**: API metrics, logging, and tracing strategies defined
|
||||
|
||||
### Integration Readiness
|
||||
- [ ] **Client Compatibility**: API works with all target client platforms
|
||||
- [ ] **External Integration**: Third-party API dependencies identified
|
||||
- [ ] **Backward Compatibility**: Changes don't break existing clients
|
||||
- [ ] **Migration Path**: Clear upgrade paths for API consumers
|
||||
- [ ] **SDK Support**: Client libraries and code generation considered
|
||||
@@ -14,6 +14,7 @@ allowed-tools: SlashCommand(*), Task(*), TodoWrite(*), Read(*), Write(*), Bash(*
|
||||
|
||||
## Role Selection Logic
|
||||
- **Technical & Architecture**: `architecture|system|performance|database|security` → system-architect, data-architect, security-expert, subject-matter-expert
|
||||
- **API & Backend**: `api|endpoint|rest|graphql|backend|interface|contract|service` → api-designer, system-architect, data-architect
|
||||
- **Product & UX**: `user|ui|ux|interface|design|product|feature|experience` → ui-designer, user-researcher, product-manager, ux-expert, product-owner
|
||||
- **Business & Process**: `business|process|workflow|cost|innovation|testing` → business-analyst, innovation-lead, test-strategist
|
||||
- **Agile & Delivery**: `agile|sprint|scrum|team|collaboration|delivery` → scrum-master, product-owner
|
||||
@@ -23,7 +24,7 @@ allowed-tools: SlashCommand(*), Task(*), TodoWrite(*), Read(*), Write(*), Bash(*
|
||||
|
||||
**Template Loading**: `bash($(cat "~/.claude/workflows/cli-templates/planning-roles/<role-name>.md"))`
|
||||
**Template Source**: `.claude/workflows/cli-templates/planning-roles/`
|
||||
**Available Roles**: data-architect, product-manager, product-owner, scrum-master, subject-matter-expert, system-architect, test-strategist, ui-designer, ux-expert
|
||||
**Available Roles**: api-designer, data-architect, product-manager, product-owner, scrum-master, subject-matter-expert, system-architect, test-strategist, ui-designer, ux-expert
|
||||
|
||||
**Example**:
|
||||
```bash
|
||||
@@ -70,6 +71,7 @@ Auto command coordinates independent specialized commands:
|
||||
|
||||
**Role Selection Logic**:
|
||||
- **Technical**: `architecture|system|performance|database` → system-architect, data-architect, subject-matter-expert
|
||||
- **API & Backend**: `api|endpoint|rest|graphql|backend|interface|contract|service` → api-designer, system-architect, data-architect
|
||||
- **Product & UX**: `user|ui|ux|interface|design|product|feature|experience` → ui-designer, ux-expert, product-manager, product-owner
|
||||
- **Agile & Delivery**: `agile|sprint|scrum|team|collaboration|delivery` → scrum-master, product-owner
|
||||
- **Domain Expertise**: `domain|standard|compliance|expertise|regulation` → subject-matter-expert
|
||||
|
||||
@@ -1,253 +0,0 @@
|
||||
---
|
||||
name: auto-squeeze
|
||||
description: Orchestrate 3-phase brainstorming workflow by executing commands sequentially
|
||||
argument-hint: "topic or challenge description for coordinated brainstorming"
|
||||
allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*), Glob(*)
|
||||
---
|
||||
|
||||
# Workflow Brainstorm Auto-Squeeze Command
|
||||
|
||||
## Coordinator Role
|
||||
|
||||
**This command is a pure orchestrator**: Execute brainstorming commands in sequence (artifacts → roles → synthesis), auto-select relevant roles, and ensure complete brainstorming workflow execution.
|
||||
|
||||
**Execution Flow**:
|
||||
1. Initialize TodoWrite → Execute Phase 1 (artifacts) → Validate framework → Update TodoWrite
|
||||
2. Select 2-3 relevant roles → Display selection → Execute Phase 2 (role analyses) → Update TodoWrite
|
||||
3. Execute Phase 3 (synthesis) → Validate outputs → Return summary
|
||||
|
||||
## Core Rules
|
||||
|
||||
1. **Start Immediately**: First action is TodoWrite initialization, second action is Phase 1 command execution
|
||||
2. **Auto-Select Roles**: Analyze topic keywords to select 2-3 most relevant roles (max 3)
|
||||
3. **Display Selection**: Show selected roles to user before execution
|
||||
4. **Sequential Execution**: Execute role commands one by one, not in parallel
|
||||
5. **Complete All Phases**: Do not return to user until synthesis completes
|
||||
6. **Track Progress**: Update TodoWrite after every command completion
|
||||
|
||||
## 3-Phase Execution
|
||||
|
||||
### Phase 1: Framework Generation
|
||||
|
||||
**Step 1.1: Role Selection**
|
||||
Auto-select 2-3 roles based on topic keywords (see Role Selection Logic below)
|
||||
|
||||
**Step 1.2: Generate Role-Specific Framework**
|
||||
**Command**: `SlashCommand(command="/workflow:brainstorm:artifacts \"[topic]\" --roles \"[role1,role2,role3]\"")`
|
||||
|
||||
**Input**: Selected roles from step 1.1
|
||||
|
||||
**Parse Output**:
|
||||
- Verify topic-framework.md created with role-specific sections
|
||||
|
||||
**Validation**:
|
||||
- File `.workflow/[session]/.brainstorming/topic-framework.md` exists
|
||||
- Contains sections for each selected role
|
||||
- Includes cross-role integration points
|
||||
|
||||
**TodoWrite**: Mark phase 1 completed, mark "Display selected roles" as in_progress
|
||||
|
||||
---
|
||||
|
||||
### Phase 2: Role Analysis Execution
|
||||
|
||||
**Step 2.1: Role Selection**
|
||||
Use keyword analysis to auto-select 2-3 roles:
|
||||
|
||||
**Role Selection Logic**:
|
||||
- **Technical/Architecture keywords**: `architecture|system|performance|database|api|backend|scalability`
|
||||
→ system-architect, data-architect, subject-matter-expert
|
||||
- **UI/UX keywords**: `user|ui|ux|interface|design|frontend|experience`
|
||||
→ ui-designer, ux-expert
|
||||
- **Product/Business keywords**: `product|feature|business|workflow|process|customer`
|
||||
→ product-manager, product-owner
|
||||
- **Agile/Delivery keywords**: `agile|sprint|scrum|team|collaboration|delivery`
|
||||
→ scrum-master, product-owner
|
||||
- **Domain Expertise keywords**: `domain|standard|compliance|expertise|regulation`
|
||||
→ subject-matter-expert
|
||||
- **Default**: product-manager (if no clear match)
|
||||
|
||||
**Selection Rules**:
|
||||
- Maximum 3 roles
|
||||
- Select most relevant role first based on strongest keyword match
|
||||
- Include complementary perspectives (e.g., if system-architect selected, also consider security-expert)
|
||||
|
||||
**Step 2.2: Display Selected Roles**
|
||||
Show selection to user before execution:
|
||||
```
|
||||
Selected roles for analysis:
|
||||
- ui-designer (UI/UX perspective)
|
||||
- system-architect (Technical architecture)
|
||||
- security-expert (Security considerations)
|
||||
```
|
||||
|
||||
**Step 2.3: Execute Role Commands Sequentially**
|
||||
Execute each selected role command one by one:
|
||||
|
||||
**Commands**:
|
||||
- `SlashCommand(command="/workflow:brainstorm:ui-designer")`
|
||||
- `SlashCommand(command="/workflow:brainstorm:ux-expert")`
|
||||
- `SlashCommand(command="/workflow:brainstorm:system-architect")`
|
||||
- `SlashCommand(command="/workflow:brainstorm:data-architect")`
|
||||
- `SlashCommand(command="/workflow:brainstorm:product-manager")`
|
||||
- `SlashCommand(command="/workflow:brainstorm:product-owner")`
|
||||
- `SlashCommand(command="/workflow:brainstorm:scrum-master")`
|
||||
- `SlashCommand(command="/workflow:brainstorm:subject-matter-expert")`
|
||||
- `SlashCommand(command="/workflow:brainstorm:test-strategist")`
|
||||
|
||||
**Validation** (after each role):
|
||||
- File `.workflow/[session]/.brainstorming/[role]/analysis.md` exists
|
||||
- Contains role-specific analysis
|
||||
|
||||
**TodoWrite**: Mark each role task completed after execution, start next role as in_progress
|
||||
|
||||
---
|
||||
|
||||
### Phase 3: Synthesis Generation
|
||||
**Command**: `SlashCommand(command="/workflow:brainstorm:synthesis")`
|
||||
|
||||
**Validation**:
|
||||
- File `.workflow/[session]/.brainstorming/synthesis-report.md` exists
|
||||
- Contains cross-references to role analyses using @ notation
|
||||
|
||||
**TodoWrite**: Mark phase 3 completed
|
||||
|
||||
**Return to User**:
|
||||
```
|
||||
Brainstorming complete for topic: [topic]
|
||||
Framework: .workflow/[session]/.brainstorming/topic-framework.md
|
||||
Roles analyzed: [role1], [role2], [role3]
|
||||
Synthesis: .workflow/[session]/.brainstorming/synthesis-report.md
|
||||
```
|
||||
|
||||
## TodoWrite Pattern
|
||||
|
||||
```javascript
|
||||
// Initialize (before Phase 1)
|
||||
TodoWrite({todos: [
|
||||
{"content": "Generate topic framework", "status": "in_progress", "activeForm": "Generating topic framework"},
|
||||
{"content": "Display selected roles", "status": "pending", "activeForm": "Displaying selected roles"},
|
||||
{"content": "Execute ui-designer analysis", "status": "pending", "activeForm": "Executing ui-designer analysis"},
|
||||
{"content": "Execute system-architect analysis", "status": "pending", "activeForm": "Executing system-architect analysis"},
|
||||
{"content": "Execute security-expert analysis", "status": "pending", "activeForm": "Executing security-expert analysis"},
|
||||
{"content": "Generate synthesis report", "status": "pending", "activeForm": "Generating synthesis report"}
|
||||
]})
|
||||
|
||||
// After Phase 1
|
||||
TodoWrite({todos: [
|
||||
{"content": "Generate topic framework", "status": "completed", "activeForm": "Generating topic framework"},
|
||||
{"content": "Display selected roles", "status": "in_progress", "activeForm": "Displaying selected roles"},
|
||||
{"content": "Execute ui-designer analysis", "status": "pending", "activeForm": "Executing ui-designer analysis"},
|
||||
{"content": "Execute system-architect analysis", "status": "pending", "activeForm": "Executing system-architect analysis"},
|
||||
{"content": "Execute security-expert analysis", "status": "pending", "activeForm": "Executing security-expert analysis"},
|
||||
{"content": "Generate synthesis report", "status": "pending", "activeForm": "Generating synthesis report"}
|
||||
]})
|
||||
|
||||
// After displaying roles
|
||||
TodoWrite({todos: [
|
||||
{"content": "Generate topic framework", "status": "completed", "activeForm": "Generating topic framework"},
|
||||
{"content": "Display selected roles", "status": "completed", "activeForm": "Displaying selected roles"},
|
||||
{"content": "Execute ui-designer analysis", "status": "in_progress", "activeForm": "Executing ui-designer analysis"},
|
||||
{"content": "Execute system-architect analysis", "status": "pending", "activeForm": "Executing system-architect analysis"},
|
||||
{"content": "Execute security-expert analysis", "status": "pending", "activeForm": "Executing security-expert analysis"},
|
||||
{"content": "Generate synthesis report", "status": "pending", "activeForm": "Generating synthesis report"}
|
||||
]})
|
||||
|
||||
// Continue pattern for each role and synthesis...
|
||||
```
|
||||
|
||||
## Data Flow
|
||||
|
||||
```
|
||||
User Input (topic)
|
||||
↓
|
||||
Role Selection (analyze topic keywords)
|
||||
↓ Output: 2-3 selected roles (e.g., ui-designer, system-architect, security-expert)
|
||||
↓
|
||||
Phase 1: artifacts "topic" --roles "role1,role2,role3"
|
||||
↓ Input: topic + selected roles
|
||||
↓ Output: role-specific topic-framework.md
|
||||
↓
|
||||
Display: Show selected roles to user
|
||||
↓
|
||||
Phase 2: Execute each role command sequentially
|
||||
↓ Role 1 → reads role-specific section → analysis.md
|
||||
↓ Role 2 → reads role-specific section → analysis.md
|
||||
↓ Role 3 → reads role-specific section → analysis.md
|
||||
↓
|
||||
Phase 3: synthesis
|
||||
↓ Input: role-specific framework + all role analyses
|
||||
↓ Output: synthesis-report.md with role-targeted insights
|
||||
↓
|
||||
Return summary to user
|
||||
```
|
||||
|
||||
**Session Context**: All commands use active brainstorming session, sharing:
|
||||
- Role-specific topic framework
|
||||
- Role-targeted analyses
|
||||
- Cross-role integration points
|
||||
- Synthesis with role-specific insights
|
||||
|
||||
**Key Improvement**: Framework is generated with roles parameter, ensuring all discussion points are relevant to selected roles
|
||||
|
||||
## Role Selection Examples
|
||||
|
||||
### Example 1: UI-Focused Topic
|
||||
**Topic**: "Redesign user authentication interface"
|
||||
**Keywords detected**: user, interface, design
|
||||
**Selected roles**:
|
||||
- ui-designer (primary: UI/UX match)
|
||||
- ux-expert (secondary: user experience)
|
||||
- subject-matter-expert (complementary: auth standards)
|
||||
|
||||
### Example 2: Architecture Topic
|
||||
**Topic**: "Design scalable microservices architecture"
|
||||
**Keywords detected**: architecture, scalable, system
|
||||
**Selected roles**:
|
||||
- system-architect (primary: architecture match)
|
||||
- data-architect (secondary: scalability/data)
|
||||
- subject-matter-expert (complementary: domain expertise)
|
||||
|
||||
### Example 3: Agile Delivery Topic
|
||||
**Topic**: "Optimize team sprint planning and delivery process"
|
||||
**Keywords detected**: sprint, team, delivery, process
|
||||
**Selected roles**:
|
||||
- scrum-master (primary: agile process match)
|
||||
- product-owner (secondary: backlog/delivery focus)
|
||||
- product-manager (complementary: product strategy)
|
||||
|
||||
## Error Handling
|
||||
|
||||
- **Framework Generation Failure**: Stop workflow, report error, do not proceed to role selection
|
||||
- **Role Analysis Failure**: Log failure, continue with remaining roles, note in final summary
|
||||
- **Synthesis Failure**: Retry once, if still fails report partial completion with available analyses
|
||||
- **Session Error**: Report session issue, prompt user to check session status
|
||||
|
||||
## Output Structure
|
||||
|
||||
```
|
||||
.workflow/[session]/.brainstorming/
|
||||
├── topic-framework.md # Phase 1 output
|
||||
├── [role1]/
|
||||
│ └── analysis.md # Phase 2 output (role 1)
|
||||
├── [role2]/
|
||||
│ └── analysis.md # Phase 2 output (role 2)
|
||||
├── [role3]/
|
||||
│ └── analysis.md # Phase 2 output (role 3)
|
||||
└── synthesis-report.md # Phase 3 output
|
||||
```
|
||||
|
||||
## Coordinator Checklist
|
||||
|
||||
✅ Initialize TodoWrite with framework + display + N roles + synthesis tasks
|
||||
✅ Execute Phase 1 (artifacts) immediately
|
||||
✅ Validate topic-framework.md exists
|
||||
✅ Analyze topic keywords for role selection
|
||||
✅ Auto-select 2-3 most relevant roles (max 3)
|
||||
✅ Display selected roles to user with rationale
|
||||
✅ Execute each role command sequentially
|
||||
✅ Validate each role's analysis.md after execution
|
||||
✅ Update TodoWrite after each role completion
|
||||
✅ Execute Phase 3 (synthesis) after all roles complete
|
||||
✅ Validate synthesis-report.md exists
|
||||
✅ Return summary with all generated files
|
||||
@@ -8,9 +8,11 @@ allowed-tools: TodoWrite(*), Read(*), Write(*), Glob(*), Bash(*), Task(ui-design
|
||||
# Layout Extraction Command
|
||||
|
||||
## Overview
|
||||
|
||||
Extract structural layout information from reference images, URLs, or text prompts using AI analysis. This command separates the "scaffolding" (HTML structure and CSS layout) from the "paint" (visual tokens handled by `style-extract`).
|
||||
|
||||
**Strategy**: AI-Driven Structural Analysis
|
||||
|
||||
- **Agent-Powered**: Uses `ui-design-agent` for deep structural analysis
|
||||
- **Dual-Mode**:
|
||||
- `imitate`: High-fidelity replication of single layout structure
|
||||
@@ -22,6 +24,7 @@ Extract structural layout information from reference images, URLs, or text promp
|
||||
## Phase 0: Setup & Input Validation
|
||||
|
||||
### Step 1: Detect Input, Mode & Targets
|
||||
|
||||
```bash
|
||||
# Detect input source
|
||||
# Priority: --urls + --images → hybrid | --urls → url | --images → image | --prompt → text
|
||||
|
||||
Reference in New Issue
Block a user