mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-03-06 16:31:12 +08:00
Add quality gates, role library, and templates for team lifecycle v3
- Introduced quality gates documentation outlining scoring dimensions and per-phase criteria. - Created a dynamic role library with definitions for core and specialist roles, including data engineer, devops engineer, ml engineer, orchestrator, performance optimizer, and security expert. - Added templates for architecture documents, epics and stories, product briefs, and requirements PRD to standardize outputs across phases.
This commit is contained in:
catlog22
101
.claude/skills/team-lifecycle-v3/specs/artifact-contract-spec.md
Normal file
101
.claude/skills/team-lifecycle-v3/specs/artifact-contract-spec.md
Normal file
@@ -0,0 +1,101 @@
|
||||
# Artifact Contract Specification
|
||||
|
||||
## Overview
|
||||
|
||||
Every worker role must generate an artifact manifest in Phase 4 to enable quality gating and automatic artifact discovery.
|
||||
|
||||
## Manifest Schema
|
||||
|
||||
**Location**: `<session>/artifacts/<task-id>/artifact-manifest.json`
|
||||
|
||||
```json
|
||||
{
|
||||
"artifact_id": "uuid-...",
|
||||
"creator_role": "role-name",
|
||||
"artifact_type": "spec | architecture | plan | code | test | review",
|
||||
"version": "1.0.0",
|
||||
"path": "./artifacts/output.md",
|
||||
"dependencies": ["upstream-artifact-id"],
|
||||
"validation_status": "pending | passed | failed",
|
||||
"validation_summary": "Details...",
|
||||
"metadata": {
|
||||
"complexity": "low | medium | high",
|
||||
"priority": "P0 | P1 | P2"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Field Definitions
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| artifact_id | string | UUID for this artifact |
|
||||
| creator_role | string | Role that created this artifact |
|
||||
| artifact_type | enum | Type of artifact (spec/architecture/plan/code/test/review) |
|
||||
| version | string | Semantic version |
|
||||
| path | string | Relative path to artifact file |
|
||||
| dependencies | array | List of upstream artifact IDs this depends on |
|
||||
| validation_status | enum | pending/passed/failed |
|
||||
| validation_summary | string | Human-readable validation result |
|
||||
| metadata | object | Additional context (complexity, priority, etc.) |
|
||||
|
||||
## Validation Status
|
||||
|
||||
- **pending**: Artifact created, validation not yet run
|
||||
- **passed**: All quality checks passed, ready for downstream consumption
|
||||
- **failed**: Quality issues detected, blocks downstream spawn
|
||||
|
||||
## Coordinator Integration
|
||||
|
||||
The coordinator checks manifests in `handleCallback`:
|
||||
|
||||
1. Read `<session>/artifacts/<task-id>/artifact-manifest.json`
|
||||
2. If `validation_status == "passed"`:
|
||||
- Register to artifact_registry
|
||||
- Spawn next dependent task
|
||||
3. If `validation_status == "failed"`:
|
||||
- Create fix task
|
||||
- Notify user
|
||||
- Block downstream tasks
|
||||
|
||||
## Context Artifacts Discovery
|
||||
|
||||
Workers read `context-artifacts.json` to discover upstream artifacts:
|
||||
|
||||
```json
|
||||
{
|
||||
"artifacts": [
|
||||
{
|
||||
"artifact_id": "uuid-...",
|
||||
"artifact_type": "spec",
|
||||
"path": "./spec/discovery-context.json",
|
||||
"creator_role": "analyst"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Auto-Discovery (v5)
|
||||
|
||||
In v5, workers declare `input_artifact_types: []` in frontmatter. The coordinator automatically discovers and provides matching artifacts without manual path configuration.
|
||||
|
||||
## Quality Gates
|
||||
|
||||
Validation checks vary by artifact type:
|
||||
|
||||
| Artifact Type | Required Checks |
|
||||
|---------------|----------------|
|
||||
| spec | Completeness, schema compliance |
|
||||
| architecture | ADR presence, component diagram |
|
||||
| plan | Task count (2-7), dependency graph validity |
|
||||
| code | Syntax check, test coverage |
|
||||
| test | Test count > 0, all passing |
|
||||
| review | Issue count, severity distribution |
|
||||
|
||||
## Example Workflow
|
||||
|
||||
1. **Analyst** creates spec → manifest with `validation_status: "passed"`
|
||||
2. **Coordinator** reads manifest → registers to artifact_registry
|
||||
3. **Writer** spawned → reads `context-artifacts.json` → finds analyst's spec
|
||||
4. **Writer** creates document → manifest with `validation_status: "passed"`
|
||||
5. **Coordinator** spawns next role based on dependency graph
|
||||
192
.claude/skills/team-lifecycle-v3/specs/document-standards.md
Normal file
192
.claude/skills/team-lifecycle-v3/specs/document-standards.md
Normal file
@@ -0,0 +1,192 @@
|
||||
# Document Standards
|
||||
|
||||
Defines format conventions, YAML frontmatter schema, naming rules, and content structure for all spec-generator outputs.
|
||||
|
||||
## When to Use
|
||||
|
||||
| Phase | Usage | Section |
|
||||
|-------|-------|---------|
|
||||
| All Phases | Frontmatter format | YAML Frontmatter Schema |
|
||||
| All Phases | File naming | Naming Conventions |
|
||||
| Phase 2-5 | Document structure | Content Structure |
|
||||
| Phase 6 | Validation reference | All sections |
|
||||
|
||||
---
|
||||
|
||||
## YAML Frontmatter Schema
|
||||
|
||||
Every generated document MUST begin with YAML frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
session_id: SPEC-{slug}-{YYYY-MM-DD}
|
||||
phase: {1-6}
|
||||
document_type: {product-brief|requirements|architecture|epics|readiness-report|spec-summary}
|
||||
status: draft|review|complete
|
||||
generated_at: {ISO8601 timestamp}
|
||||
stepsCompleted: []
|
||||
version: 1
|
||||
dependencies:
|
||||
- {list of input documents used}
|
||||
---
|
||||
```
|
||||
|
||||
### Field Definitions
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
|-------|------|----------|-------------|
|
||||
| `session_id` | string | Yes | Session identifier matching spec-config.json |
|
||||
| `phase` | number | Yes | Phase number that generated this document (1-6) |
|
||||
| `document_type` | string | Yes | One of: product-brief, requirements, architecture, epics, readiness-report, spec-summary |
|
||||
| `status` | enum | Yes | draft (initial), review (user reviewed), complete (finalized) |
|
||||
| `generated_at` | string | Yes | ISO8601 timestamp of generation |
|
||||
| `stepsCompleted` | array | Yes | List of step IDs completed during generation |
|
||||
| `version` | number | Yes | Document version, incremented on re-generation |
|
||||
| `dependencies` | array | No | List of input files this document depends on |
|
||||
|
||||
### Status Transitions
|
||||
|
||||
```
|
||||
draft -> review -> complete
|
||||
| ^
|
||||
+-------------------+ (direct promotion in auto mode)
|
||||
```
|
||||
|
||||
- **draft**: Initial generation, not yet user-reviewed
|
||||
- **review**: User has reviewed and provided feedback
|
||||
- **complete**: Finalized, ready for downstream consumption
|
||||
|
||||
In auto mode (`-y`), documents are promoted directly from `draft` to `complete`.
|
||||
|
||||
---
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
### Session ID Format
|
||||
|
||||
```
|
||||
SPEC-{slug}-{YYYY-MM-DD}
|
||||
```
|
||||
|
||||
- **slug**: Lowercase, alphanumeric + Chinese characters, hyphens as separators, max 40 chars
|
||||
- **date**: UTC+8 date in YYYY-MM-DD format
|
||||
|
||||
Examples:
|
||||
- `SPEC-task-management-system-2026-02-11`
|
||||
- `SPEC-user-auth-oauth-2026-02-11`
|
||||
|
||||
### Output Files
|
||||
|
||||
| File | Phase | Description |
|
||||
|------|-------|-------------|
|
||||
| `spec-config.json` | 1 | Session configuration and state |
|
||||
| `discovery-context.json` | 1 | Codebase exploration results (optional) |
|
||||
| `product-brief.md` | 2 | Product brief document |
|
||||
| `requirements.md` | 3 | PRD document |
|
||||
| `architecture.md` | 4 | Architecture decisions document |
|
||||
| `epics.md` | 5 | Epic/Story breakdown document |
|
||||
| `readiness-report.md` | 6 | Quality validation report |
|
||||
| `spec-summary.md` | 6 | One-page executive summary |
|
||||
|
||||
### Output Directory
|
||||
|
||||
```
|
||||
.workflow/.spec/{session-id}/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Content Structure
|
||||
|
||||
### Heading Hierarchy
|
||||
|
||||
- `#` (H1): Document title only (one per document)
|
||||
- `##` (H2): Major sections
|
||||
- `###` (H3): Subsections
|
||||
- `####` (H4): Detail items (use sparingly)
|
||||
|
||||
Maximum depth: 4 levels. Prefer flat structures.
|
||||
|
||||
### Section Ordering
|
||||
|
||||
Every document follows this general pattern:
|
||||
|
||||
1. **YAML Frontmatter** (mandatory)
|
||||
2. **Title** (H1)
|
||||
3. **Executive Summary** (2-3 sentences)
|
||||
4. **Core Content Sections** (H2, document-specific)
|
||||
5. **Open Questions / Risks** (if applicable)
|
||||
6. **References / Traceability** (links to upstream/downstream docs)
|
||||
|
||||
### Formatting Rules
|
||||
|
||||
| Element | Format | Example |
|
||||
|---------|--------|---------|
|
||||
| Requirements | `REQ-{NNN}` prefix | REQ-001: User login |
|
||||
| Acceptance criteria | Checkbox list | `- [ ] User can log in with email` |
|
||||
| Architecture decisions | `ADR-{NNN}` prefix | ADR-001: Use PostgreSQL |
|
||||
| Epics | `EPIC-{NNN}` prefix | EPIC-001: Authentication |
|
||||
| Stories | `STORY-{EPIC}-{NNN}` prefix | STORY-001-001: Login form |
|
||||
| Priority tags | MoSCoW labels | `[Must]`, `[Should]`, `[Could]`, `[Won't]` |
|
||||
| Mermaid diagrams | Fenced code blocks | ````mermaid ... ``` `` |
|
||||
| Code examples | Language-tagged blocks | ````typescript ... ``` `` |
|
||||
|
||||
### Cross-Reference Format
|
||||
|
||||
Use relative references between documents:
|
||||
|
||||
```markdown
|
||||
See [Product Brief](product-brief.md#section-name) for details.
|
||||
Derived from [REQ-001](requirements.md#req-001).
|
||||
```
|
||||
|
||||
### Language
|
||||
|
||||
- Document body: Follow user's input language (Chinese or English)
|
||||
- Technical identifiers: Always English (REQ-001, ADR-001, EPIC-001)
|
||||
- YAML frontmatter keys: Always English
|
||||
|
||||
---
|
||||
|
||||
## spec-config.json Schema
|
||||
|
||||
```json
|
||||
{
|
||||
"session_id": "string (required)",
|
||||
"seed_input": "string (required) - original user input",
|
||||
"input_type": "text|file (required)",
|
||||
"timestamp": "ISO8601 (required)",
|
||||
"mode": "interactive|auto (required)",
|
||||
"complexity": "simple|moderate|complex (required)",
|
||||
"depth": "light|standard|comprehensive (required)",
|
||||
"focus_areas": ["string array"],
|
||||
"seed_analysis": {
|
||||
"problem_statement": "string",
|
||||
"target_users": ["string array"],
|
||||
"domain": "string",
|
||||
"constraints": ["string array"],
|
||||
"dimensions": ["string array - 3-5 exploration dimensions"]
|
||||
},
|
||||
"has_codebase": "boolean",
|
||||
"phasesCompleted": [
|
||||
{
|
||||
"phase": "number (1-6)",
|
||||
"name": "string (phase name)",
|
||||
"output_file": "string (primary output file)",
|
||||
"completed_at": "ISO8601"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
- [ ] Every document starts with valid YAML frontmatter
|
||||
- [ ] `session_id` matches across all documents in a session
|
||||
- [ ] `status` field reflects current document state
|
||||
- [ ] All cross-references resolve to valid targets
|
||||
- [ ] Heading hierarchy is correct (no skipped levels)
|
||||
- [ ] Technical identifiers use correct prefixes
|
||||
- [ ] Output files are in the correct directory
|
||||
207
.claude/skills/team-lifecycle-v3/specs/quality-gates.md
Normal file
207
.claude/skills/team-lifecycle-v3/specs/quality-gates.md
Normal file
@@ -0,0 +1,207 @@
|
||||
# Quality Gates
|
||||
|
||||
Per-phase quality gate criteria and scoring dimensions for spec-generator outputs.
|
||||
|
||||
## When to Use
|
||||
|
||||
| Phase | Usage | Section |
|
||||
|-------|-------|---------|
|
||||
| Phase 2-5 | Post-generation self-check | Per-Phase Gates |
|
||||
| Phase 6 | Cross-document validation | Cross-Document Validation |
|
||||
| Phase 6 | Final scoring | Scoring Dimensions |
|
||||
|
||||
---
|
||||
|
||||
## Quality Thresholds
|
||||
|
||||
| Gate | Score | Action |
|
||||
|------|-------|--------|
|
||||
| **Pass** | >= 80% | Continue to next phase |
|
||||
| **Review** | 60-79% | Log warnings, continue with caveats |
|
||||
| **Fail** | < 60% | Must address issues before continuing |
|
||||
|
||||
In auto mode (`-y`), Review-level issues are logged but do not block progress.
|
||||
|
||||
---
|
||||
|
||||
## Scoring Dimensions
|
||||
|
||||
### 1. Completeness (25%)
|
||||
|
||||
All required sections present with substantive content.
|
||||
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 100% | All template sections filled with detailed content |
|
||||
| 75% | All sections present, some lack detail |
|
||||
| 50% | Major sections present but minor sections missing |
|
||||
| 25% | Multiple major sections missing or empty |
|
||||
| 0% | Document is a skeleton only |
|
||||
|
||||
### 2. Consistency (25%)
|
||||
|
||||
Terminology, formatting, and references are uniform across documents.
|
||||
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 100% | All terms consistent, all references valid, formatting uniform |
|
||||
| 75% | Minor terminology variations, all references valid |
|
||||
| 50% | Some inconsistent terms, 1-2 broken references |
|
||||
| 25% | Frequent inconsistencies, multiple broken references |
|
||||
| 0% | Documents contradict each other |
|
||||
|
||||
### 3. Traceability (25%)
|
||||
|
||||
Requirements, architecture decisions, and stories trace back to goals.
|
||||
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 100% | Every story traces to a requirement, every requirement traces to a goal |
|
||||
| 75% | Most items traceable, few orphans |
|
||||
| 50% | Partial traceability, some disconnected items |
|
||||
| 25% | Weak traceability, many orphan items |
|
||||
| 0% | No traceability between documents |
|
||||
|
||||
### 4. Depth (25%)
|
||||
|
||||
Content provides sufficient detail for execution teams.
|
||||
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 100% | Acceptance criteria specific and testable, architecture decisions justified, stories estimable |
|
||||
| 75% | Most items detailed enough, few vague areas |
|
||||
| 50% | Mix of detailed and vague content |
|
||||
| 25% | Mostly high-level, lacking actionable detail |
|
||||
| 0% | Too abstract for execution |
|
||||
|
||||
---
|
||||
|
||||
## Per-Phase Quality Gates
|
||||
|
||||
### Phase 1: Discovery
|
||||
|
||||
| Check | Criteria | Severity |
|
||||
|-------|----------|----------|
|
||||
| Session ID valid | Matches `SPEC-{slug}-{date}` format | Error |
|
||||
| Problem statement exists | Non-empty, >= 20 characters | Error |
|
||||
| Target users identified | >= 1 user group | Error |
|
||||
| Dimensions generated | 3-5 exploration dimensions | Warning |
|
||||
| Constraints listed | >= 0 (can be empty with justification) | Info |
|
||||
|
||||
### Phase 2: Product Brief
|
||||
|
||||
| Check | Criteria | Severity |
|
||||
|-------|----------|----------|
|
||||
| Vision statement | Clear, 1-3 sentences | Error |
|
||||
| Problem statement | Specific and measurable | Error |
|
||||
| Target users | >= 1 persona with needs described | Error |
|
||||
| Goals defined | >= 2 measurable goals | Error |
|
||||
| Success metrics | >= 2 quantifiable metrics | Warning |
|
||||
| Scope boundaries | In-scope and out-of-scope listed | Warning |
|
||||
| Multi-perspective | >= 2 CLI perspectives synthesized | Info |
|
||||
|
||||
### Phase 3: Requirements (PRD)
|
||||
|
||||
| Check | Criteria | Severity |
|
||||
|-------|----------|----------|
|
||||
| Functional requirements | >= 3 with REQ-NNN IDs | Error |
|
||||
| Acceptance criteria | Every requirement has >= 1 criterion | Error |
|
||||
| MoSCoW priority | Every requirement tagged | Error |
|
||||
| Non-functional requirements | >= 1 (performance, security, etc.) | Warning |
|
||||
| User stories | >= 1 per Must-have requirement | Warning |
|
||||
| Traceability | Requirements trace to product brief goals | Warning |
|
||||
|
||||
### Phase 4: Architecture
|
||||
|
||||
| Check | Criteria | Severity |
|
||||
|-------|----------|----------|
|
||||
| Component diagram | Present (Mermaid or ASCII) | Error |
|
||||
| Tech stack specified | Languages, frameworks, key libraries | Error |
|
||||
| ADR present | >= 1 Architecture Decision Record | Error |
|
||||
| ADR has alternatives | Each ADR lists >= 2 options considered | Warning |
|
||||
| Integration points | External systems/APIs identified | Warning |
|
||||
| Data model | Key entities and relationships described | Warning |
|
||||
| Codebase mapping | Mapped to existing code (if has_codebase) | Info |
|
||||
|
||||
### Phase 5: Epics & Stories
|
||||
|
||||
| Check | Criteria | Severity |
|
||||
|-------|----------|----------|
|
||||
| Epics defined | 3-7 epics with EPIC-NNN IDs | Error |
|
||||
| MVP subset | >= 1 epic tagged as MVP | Error |
|
||||
| Stories per epic | 2-5 stories per epic | Error |
|
||||
| Story format | "As a...I want...So that..." pattern | Warning |
|
||||
| Dependency map | Cross-epic dependencies documented | Warning |
|
||||
| Estimation hints | Relative sizing (S/M/L/XL) per story | Info |
|
||||
| Traceability | Stories trace to requirements | Warning |
|
||||
|
||||
### Phase 6: Readiness Check
|
||||
|
||||
| Check | Criteria | Severity |
|
||||
|-------|----------|----------|
|
||||
| All documents exist | product-brief, requirements, architecture, epics | Error |
|
||||
| Frontmatter valid | All YAML frontmatter parseable and correct | Error |
|
||||
| Cross-references valid | All document links resolve | Error |
|
||||
| Overall score >= 60% | Weighted average across 4 dimensions | Error |
|
||||
| No unresolved Errors | All Error-severity issues addressed | Error |
|
||||
| Summary generated | spec-summary.md created | Warning |
|
||||
|
||||
---
|
||||
|
||||
## Cross-Document Validation
|
||||
|
||||
Checks performed during Phase 6 across all documents:
|
||||
|
||||
### Completeness Matrix
|
||||
|
||||
```
|
||||
Product Brief goals -> Requirements (each goal has >= 1 requirement)
|
||||
Requirements -> Architecture (each Must requirement has design coverage)
|
||||
Requirements -> Epics (each Must requirement appears in >= 1 story)
|
||||
Architecture ADRs -> Epics (tech choices reflected in implementation stories)
|
||||
```
|
||||
|
||||
### Consistency Checks
|
||||
|
||||
| Check | Documents | Rule |
|
||||
|-------|-----------|------|
|
||||
| Terminology | All | Same term used consistently (no synonyms for same concept) |
|
||||
| User personas | Brief + PRD + Epics | Same user names/roles throughout |
|
||||
| Scope | Brief + PRD | PRD scope does not exceed brief scope |
|
||||
| Tech stack | Architecture + Epics | Stories reference correct technologies |
|
||||
|
||||
### Traceability Matrix Format
|
||||
|
||||
```markdown
|
||||
| Goal | Requirements | Architecture | Epics |
|
||||
|------|-------------|--------------|-------|
|
||||
| G-001: ... | REQ-001, REQ-002 | ADR-001 | EPIC-001 |
|
||||
| G-002: ... | REQ-003 | ADR-002 | EPIC-002, EPIC-003 |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Issue Classification
|
||||
|
||||
### Error (Must Fix)
|
||||
|
||||
- Missing required document or section
|
||||
- Broken cross-references
|
||||
- Contradictory information between documents
|
||||
- Empty acceptance criteria on Must-have requirements
|
||||
- No MVP subset defined in epics
|
||||
|
||||
### Warning (Should Fix)
|
||||
|
||||
- Vague acceptance criteria
|
||||
- Missing non-functional requirements
|
||||
- No success metrics defined
|
||||
- Incomplete traceability
|
||||
- Missing architecture review notes
|
||||
|
||||
### Info (Nice to Have)
|
||||
|
||||
- Could add more detailed personas
|
||||
- Consider additional ADR alternatives
|
||||
- Story estimation hints missing
|
||||
- Mermaid diagrams could be more detailed
|
||||
@@ -0,0 +1,65 @@
|
||||
# Role Library - Team Lifecycle v3
|
||||
|
||||
Dynamic role specification library for team-lifecycle-v3. Role definitions are loaded at runtime to extend the built-in role detection table.
|
||||
|
||||
## Purpose
|
||||
|
||||
- Extend role inference beyond hardcoded defaults
|
||||
- Support domain-specific specialist roles
|
||||
- Enable dynamic role injection based on task keywords
|
||||
- Maintain backward compatibility with v2 core roles
|
||||
|
||||
## Role Categories
|
||||
|
||||
### Core Pipeline Roles (v2 inherited)
|
||||
- analyst, writer, planner, executor, tester, reviewer
|
||||
- architect, fe-developer, fe-qa
|
||||
|
||||
### Specialist Roles (v3 new)
|
||||
- **orchestrator**: Complex task decomposition and parallel coordination
|
||||
- **security-expert**: Security analysis and vulnerability scanning
|
||||
- **performance-optimizer**: Performance profiling and optimization
|
||||
- **data-engineer**: Data pipeline and schema design
|
||||
- **devops-engineer**: Infrastructure as code and CI/CD
|
||||
- **ml-engineer**: Machine learning pipeline implementation
|
||||
|
||||
## Dynamic Role Injection
|
||||
|
||||
Specialist roles are injected at runtime when coordinator detects matching keywords in task descriptions:
|
||||
|
||||
| Keywords | Injected Role |
|
||||
|----------|---------------|
|
||||
| security, vulnerability, OWASP | security-expert |
|
||||
| performance, optimization, bottleneck | performance-optimizer |
|
||||
| data, pipeline, ETL, schema | data-engineer |
|
||||
| devops, CI/CD, deployment, docker | devops-engineer |
|
||||
| machine learning, ML, model, training | ml-engineer |
|
||||
| orchestrate, complex, multi-module | orchestrator |
|
||||
|
||||
## Role Definition Format
|
||||
|
||||
Each role definition is a `.role.md` file with YAML frontmatter + description.
|
||||
|
||||
### Schema
|
||||
|
||||
```yaml
|
||||
---
|
||||
role: <role-name>
|
||||
keywords: [<keyword1>, <keyword2>, ...]
|
||||
responsibility_type: <Orchestration|Code generation|Validation|Read-only analysis>
|
||||
task_prefix: <PREFIX>
|
||||
default_inner_loop: <true|false>
|
||||
category: <domain-category>
|
||||
capabilities: [<capability1>, <capability2>, ...]
|
||||
---
|
||||
|
||||
<Role description and responsibilities>
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
Role library is loaded by coordinator during Phase 1 (Requirements Collection) to extend role detection capabilities. Custom roles override built-in roles with same `role` identifier.
|
||||
|
||||
## Extensibility
|
||||
|
||||
Users can add custom role definitions by creating new `.role.md` files in this directory following the schema above.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
role: data-engineer
|
||||
keywords: [data, pipeline, ETL, database, schema, migration, analytics]
|
||||
responsibility_type: Code generation
|
||||
task_prefix: DATA
|
||||
default_inner_loop: false
|
||||
category: data
|
||||
capabilities:
|
||||
- data_pipeline_design
|
||||
- schema_design
|
||||
- etl_implementation
|
||||
---
|
||||
|
||||
# Data Engineer
|
||||
|
||||
Designs and implements data pipelines, schemas, and ETL processes.
|
||||
|
||||
## Responsibilities
|
||||
|
||||
- Design database schemas and data models
|
||||
- Implement ETL pipelines for data processing
|
||||
- Create data migration scripts
|
||||
- Optimize data storage and retrieval
|
||||
- Implement data validation and quality checks
|
||||
|
||||
## Typical Tasks
|
||||
|
||||
- Design and implement data warehouse schema
|
||||
- Build ETL pipeline for analytics
|
||||
- Create database migration scripts
|
||||
- Implement data validation framework
|
||||
|
||||
## Integration Points
|
||||
|
||||
- Called by coordinator when data keywords detected
|
||||
- Works with executor for backend integration
|
||||
- Coordinates with planner for data architecture
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
role: devops-engineer
|
||||
keywords: [devops, CI/CD, deployment, infrastructure, docker, kubernetes, terraform]
|
||||
responsibility_type: Code generation
|
||||
task_prefix: DEVOPS
|
||||
default_inner_loop: false
|
||||
category: devops
|
||||
capabilities:
|
||||
- infrastructure_as_code
|
||||
- ci_cd_pipeline
|
||||
- deployment_automation
|
||||
---
|
||||
|
||||
# DevOps Engineer
|
||||
|
||||
Implements infrastructure as code, CI/CD pipelines, and deployment automation.
|
||||
|
||||
## Responsibilities
|
||||
|
||||
- Design and implement CI/CD pipelines
|
||||
- Create infrastructure as code (Terraform, CloudFormation)
|
||||
- Implement deployment automation
|
||||
- Configure monitoring and alerting
|
||||
- Manage containerization and orchestration
|
||||
|
||||
## Typical Tasks
|
||||
|
||||
- Set up CI/CD pipeline for new project
|
||||
- Implement infrastructure as code for cloud resources
|
||||
- Create Docker containerization strategy
|
||||
- Configure Kubernetes deployment
|
||||
|
||||
## Integration Points
|
||||
|
||||
- Called by coordinator when devops keywords detected
|
||||
- Works with executor for deployment integration
|
||||
- Coordinates with planner for infrastructure architecture
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
role: ml-engineer
|
||||
keywords: [machine learning, ML, model, training, inference, neural network, AI]
|
||||
responsibility_type: Code generation
|
||||
task_prefix: ML
|
||||
default_inner_loop: false
|
||||
category: machine-learning
|
||||
capabilities:
|
||||
- model_training
|
||||
- feature_engineering
|
||||
- model_deployment
|
||||
---
|
||||
|
||||
# ML Engineer
|
||||
|
||||
Implements machine learning pipelines, model training, and inference systems.
|
||||
|
||||
## Responsibilities
|
||||
|
||||
- Design and implement ML training pipelines
|
||||
- Perform feature engineering and data preprocessing
|
||||
- Train and evaluate ML models
|
||||
- Implement model serving and inference
|
||||
- Monitor model performance and drift
|
||||
|
||||
## Typical Tasks
|
||||
|
||||
- Build ML training pipeline
|
||||
- Implement feature engineering pipeline
|
||||
- Deploy model serving infrastructure
|
||||
- Create model monitoring system
|
||||
|
||||
## Integration Points
|
||||
|
||||
- Called by coordinator when ML keywords detected
|
||||
- Works with data-engineer for data pipeline integration
|
||||
- Coordinates with planner for ML architecture
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
role: orchestrator
|
||||
keywords: [orchestrate, coordinate, complex, multi-module, decompose, parallel, dependency]
|
||||
responsibility_type: Orchestration
|
||||
task_prefix: ORCH
|
||||
default_inner_loop: false
|
||||
category: orchestration
|
||||
weight: 1.5
|
||||
capabilities:
|
||||
- task_decomposition
|
||||
- parallel_coordination
|
||||
- dependency_management
|
||||
---
|
||||
|
||||
# Orchestrator
|
||||
|
||||
Decomposes complex multi-module tasks into coordinated sub-tasks with dependency management and parallel execution support.
|
||||
|
||||
## Responsibilities
|
||||
|
||||
- Analyze complex requirements and decompose into manageable sub-tasks
|
||||
- Coordinate parallel execution of multiple implementation tracks
|
||||
- Manage dependencies between sub-tasks
|
||||
- Integrate results from parallel workers
|
||||
- Validate integration points and cross-module consistency
|
||||
|
||||
## Typical Tasks
|
||||
|
||||
- Break down large features into frontend + backend + data components
|
||||
- Coordinate multi-team parallel development
|
||||
- Manage complex refactoring across multiple modules
|
||||
- Orchestrate migration strategies with phased rollout
|
||||
|
||||
## Integration Points
|
||||
|
||||
- Works with planner to receive high-level plans
|
||||
- Spawns multiple executor/fe-developer workers in parallel
|
||||
- Integrates with tester for cross-module validation
|
||||
- Reports to coordinator with integration status
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
role: performance-optimizer
|
||||
keywords: [performance, optimization, bottleneck, latency, throughput, profiling, benchmark]
|
||||
responsibility_type: Read-only analysis
|
||||
task_prefix: PERF
|
||||
default_inner_loop: false
|
||||
category: performance
|
||||
capabilities:
|
||||
- performance_profiling
|
||||
- bottleneck_identification
|
||||
- optimization_recommendations
|
||||
---
|
||||
|
||||
# Performance Optimizer
|
||||
|
||||
Analyzes code and architecture for performance bottlenecks and provides optimization recommendations.
|
||||
|
||||
## Responsibilities
|
||||
|
||||
- Profile code execution and identify bottlenecks
|
||||
- Analyze database query performance
|
||||
- Review caching strategies and effectiveness
|
||||
- Assess resource utilization (CPU, memory, I/O)
|
||||
- Recommend optimization strategies
|
||||
|
||||
## Typical Tasks
|
||||
|
||||
- Performance audit of critical paths
|
||||
- Database query optimization review
|
||||
- Caching strategy assessment
|
||||
- Load testing analysis and recommendations
|
||||
|
||||
## Integration Points
|
||||
|
||||
- Called by coordinator when performance keywords detected
|
||||
- Works with reviewer for performance-focused code review
|
||||
- Reports findings with impact levels and optimization priorities
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
role: security-expert
|
||||
keywords: [security, vulnerability, OWASP, compliance, audit, penetration, threat]
|
||||
responsibility_type: Read-only analysis
|
||||
task_prefix: SECURITY
|
||||
default_inner_loop: false
|
||||
category: security
|
||||
capabilities:
|
||||
- vulnerability_scanning
|
||||
- threat_modeling
|
||||
- compliance_checking
|
||||
---
|
||||
|
||||
# Security Expert
|
||||
|
||||
Performs security analysis, vulnerability scanning, and compliance checking for code and architecture.
|
||||
|
||||
## Responsibilities
|
||||
|
||||
- Scan code for OWASP Top 10 vulnerabilities
|
||||
- Perform threat modeling and attack surface analysis
|
||||
- Check compliance with security standards (GDPR, HIPAA, etc.)
|
||||
- Review authentication and authorization implementations
|
||||
- Assess data protection and encryption strategies
|
||||
|
||||
## Typical Tasks
|
||||
|
||||
- Security audit of authentication module
|
||||
- Vulnerability assessment of API endpoints
|
||||
- Compliance review for data handling
|
||||
- Threat modeling for new features
|
||||
|
||||
## Integration Points
|
||||
|
||||
- Called by coordinator when security keywords detected
|
||||
- Works with reviewer for security-focused code review
|
||||
- Reports findings with severity levels (Critical/High/Medium/Low)
|
||||
Reference in New Issue
Block a user