universal-dev-standards 4.1.0 → 5.0.0-beta.10

package/bundled/skills/workflows/integrated-flow.workflow.yaml

@@ -0,0 +1,238 @@
+# Integrated Development Flow Workflow
+# Complete ATDD → SDD → BDD → TDD development cycle
+#
+# This workflow orchestrates the full software development lifecycle,
+# integrating acceptance testing, specification, behavior, and test-driven approaches.
+
+name: integrated-flow
+version: 1.0.0
+description: |
+  Complete development workflow integrating ATDD, SDD, BDD, and TDD methodologies.
+  Use for comprehensive feature development with full traceability from requirements to tests.
+  Keywords: ATDD, SDD, BDD, TDD, integrated, full-cycle, 整合流程, 完整開發.
+
+metadata:
+  author: universal-dev-standards
+  category: development
+  difficulty: advanced
+  estimated_steps: 8
+  related_skills:
+    - atdd-assistant
+    - spec-driven-dev
+    - bdd-assistant
+    - tdd-assistant
+
+prerequisites:
+  - Project initialized with UDS standards
+  - Git repository configured
+  - Test framework set up
+  - AI tool with Task support (recommended)
+
+# Workflow execution steps
+steps:
+  # Phase 1: ATDD - Acceptance Test-Driven Development
+  - id: specification-workshop
+    name: Specification Workshop
+    phase: ATDD
+    type: agent
+    agent: spec-analyst
+    description: |
+      Conduct specification workshop to define acceptance criteria.
+      Involves stakeholder collaboration to clarify requirements.
+    inputs:
+      - user_story
+      - business_context
+    outputs:
+      - acceptance_criteria
+      - test_scenarios
+    checklist:
+      - Stakeholders identified
+      - User story clarified
+      - Acceptance criteria in Given-When-Then format
+      - Edge cases documented
+
+  # Phase 2: SDD - Spec-Driven Development
+  - id: spec-proposal
+    name: Specification Proposal
+    phase: SDD
+    type: agent
+    agent: spec-analyst
+    description: |
+      Draft formal specification document based on acceptance criteria.
+      Include technical design, API contracts, and data models.
+    inputs:
+      - acceptance_criteria
+      - test_scenarios
+    outputs:
+      - spec_document
+    template: |
+      # SPEC-XXX: [Feature Name]
+
+      ## Summary
+      [Brief description]
+
+      ## Acceptance Criteria
+      [From workshop]
+
+      ## Technical Design
+      [Architecture, components]
+
+      ## API Contract
+      [Endpoints, data structures]
+
+      ## Risks & Mitigations
+      [Identified risks]
+
+  - id: spec-review
+    name: Specification Review
+    phase: SDD
+    type: manual
+    description: |
+      Review and approve specification document.
+      Ensure technical feasibility and alignment with requirements.
+    inputs:
+      - spec_document
+    outputs:
+      - approved_spec
+    instructions: |
+      Review the specification document:
+      1. Verify technical accuracy
+      2. Check acceptance criteria completeness
+      3. Assess risks and mitigations
+      4. Approve or request changes
+    checklist:
+      - Technical design is sound
+      - Acceptance criteria are testable
+      - Risks are acceptable
+      - Stakeholders approved
+
+  # Phase 3: BDD - Behavior-Driven Development
+  - id: discovery
+    name: BDD Discovery
+    phase: BDD
+    type: agent
+    agent: test-specialist
+    description: |
+      Discover and formulate BDD scenarios from approved spec.
+      Generate Gherkin feature files.
+    inputs:
+      - approved_spec
+    outputs:
+      - feature_files
+      - scenario_outlines
+    example_output: |
+      Feature: User Authentication
+        As a user
+        I want to log in with my credentials
+        So that I can access my account
+
+        Scenario: Successful login
+          Given I am on the login page
+          When I enter valid credentials
+          Then I should be redirected to dashboard
+
+  - id: formulation
+    name: BDD Formulation
+    phase: BDD
+    type: manual
+    description: |
+      Review and refine BDD scenarios with stakeholders.
+      Ensure scenarios are clear and testable.
+    inputs:
+      - feature_files
+    outputs:
+      - refined_features
+    checklist:
+      - Scenarios cover all acceptance criteria
+      - Language is clear to all stakeholders
+      - Examples are realistic
+      - Edge cases included
+
+  # Phase 4: TDD - Test-Driven Development
+  - id: tdd-red
+    name: TDD Red Phase
+    phase: TDD
+    type: agent
+    agent: test-specialist
+    description: |
+      Write failing tests based on BDD scenarios.
+      Tests should be minimal and focused.
+    inputs:
+      - refined_features
+    outputs:
+      - failing_tests
+    instructions: |
+      For each BDD scenario:
+      1. Write unit test that captures behavior
+      2. Run test to verify it fails
+      3. Document test purpose
+
+  - id: tdd-green
+    name: TDD Green Phase
+    phase: TDD
+    type: manual
+    description: |
+      Implement minimum code to make tests pass.
+      Focus on functionality, not optimization.
+    inputs:
+      - failing_tests
+    outputs:
+      - passing_implementation
+    instructions: |
+      Implementation guidelines:
+      1. Write minimum code to pass tests
+      2. Do not optimize yet
+      3. Commit when tests pass
+    checklist:
+      - All tests pass
+      - No extra functionality added
+      - Code committed
+
+  - id: tdd-refactor
+    name: TDD Refactor Phase
+    phase: TDD
+    type: agent
+    agent: reviewer
+    description: |
+      Refactor implementation while maintaining passing tests.
+      Review code quality and suggest improvements.
+    inputs:
+      - passing_implementation
+    outputs:
+      - refactored_code
+      - review_report
+    checklist:
+      - Code follows project standards
+      - No code duplication
+      - Tests still pass
+      - Documentation updated
+
+# Final outputs
+outputs:
+  - name: spec_document
+    description: Approved specification document
+    format: markdown
+    path: specs/SPEC-XXX.md
+
+  - name: feature_files
+    description: BDD feature files
+    format: gherkin
+    path: features/
+
+  - name: test_suite
+    description: TDD test files
+    format: varies
+    path: tests/
+
+  - name: implementation
+    description: Refactored implementation
+    format: varies
+    path: src/
+
+# Workflow completion criteria
+completion_criteria:
+  - All acceptance criteria met
+  - All tests passing
+  - Code reviewed and approved
+  - Documentation updated
+  - Spec archived with links to implementation

package/bundled/skills/workflows/large-codebase-analysis.workflow.yaml

@@ -0,0 +1,226 @@
+# Large Codebase Analysis Workflow (RLM-enhanced)
+# Workflow for analyzing large codebases (50+ files) using RLM principles
+#
+# This workflow uses hierarchical analysis and parallel processing
+# to efficiently analyze large codebases that exceed typical context limits.
+
+name: large-codebase-analysis
+version: 1.0.0
+description: |
+  RLM-enhanced workflow for analyzing large codebases with 50+ files.
+  Uses hierarchical analysis (structure first, then details) and parallel
+  processing for efficient analysis of projects exceeding context limits.
+  Keywords: large codebase, analysis, RLM, parallel processing, 大型代碼庫, 分析.
+
+metadata:
+  author: universal-dev-standards
+  category: development
+  difficulty: advanced
+  estimated_steps: 4
+  related_skills:
+    - project-structure-guide
+    - spec-driven-dev
+
+# RLM Context Configuration
+context-strategy:
+  enable-rlm: true
+  max-context-per-step: 100000
+  context-inheritance: selective
+
+prerequisites:
+  - Git repository with codebase
+  - AI tool with Task support (Claude Code, OpenCode)
+  - Project size > 50 files or > 200K tokens
+
+# Workflow Variables (set during execution)
+variables:
+  modules: []               # Populated by structure-scan step
+  total_files: 0
+  estimated_tokens: 0
+
+steps:
+  # Step 1: Structure Scan
+  - id: structure-scan
+    name: Scan Project Structure
+    type: agent
+    agent: code-architect
+    description: |
+      Perform initial high-level scan of the codebase.
+      Identify major modules, directories, and entry points.
+      This step uses minimal context to get the big picture.
+    context-mode: minimal
+    inputs:
+      - project_root
+    outputs:
+      - structure_map
+      - module_boundaries
+      - entry_points
+      - dependency_overview
+    instructions: |
+      Scan the project structure without reading file contents deeply.
+      Focus on:
+      1. Directory structure and organization
+      2. Package/module boundaries
+      3. Entry points (main files, index files)
+      4. Configuration files
+      5. Test directories
+
+      Output a structured map that can be used for parallel analysis.
+    checklist:
+      - Directory tree mapped
+      - Module boundaries identified
+      - Entry points documented
+      - File count by directory
+
+  # Step 2: Module Partition (Manual)
+  - id: module-partition
+    name: Define Analysis Partitions
+    type: manual
+    description: |
+      Based on the structure scan, define logical partitions for parallel analysis.
+      Each partition should be independently analyzable.
+    inputs:
+      - structure_map
+      - module_boundaries
+    outputs:
+      - partition_definitions
+      - analysis_priority
+    instructions: |
+      Review the structure scan results and define partitions:
+
+      1. **Group related modules**
+         - Identify modules that can be analyzed independently
+         - Keep tightly coupled modules together
+
+      2. **Set priorities**
+         - Core/critical modules first
+         - Dependencies before dependents
+         - Shared utilities early
+
+      3. **Estimate complexity**
+         - Token count per partition
+         - Expected analysis depth
+
+      Example partition format:
+      ```yaml
+      partitions:
+        - name: core-auth
+          paths: [src/auth/, src/middleware/auth/]
+          priority: 1
+          estimated_tokens: 15000
+
+        - name: api-layer
+          paths: [src/api/, src/routes/]
+          priority: 2
+          depends_on: [core-auth]
+          estimated_tokens: 25000
+      ```
+    checklist:
+      - All major areas covered
+      - Dependencies mapped
+      - Priorities assigned
+      - Token estimates reasonable
+
+  # Step 3: Parallel Module Analysis
+  - id: parallel-module-analysis
+    name: Analyze Modules in Parallel
+    type: parallel-agents
+    agent: code-architect
+    description: |
+      Execute architecture analysis on each partition in parallel.
+      Each analysis focuses only on its partition with minimal cross-module context.
+    foreach: ${partitions}
+    context-mode: focused
+    merge-strategy: aggregate
+    max-concurrent: 3
+    timeout: 300
+    inputs:
+      - structure_map
+      - partition_definitions
+    outputs:
+      - module_analyses
+    analysis_focus:
+      - Module purpose and responsibility
+      - Internal architecture patterns
+      - Public interfaces/APIs
+      - Dependencies (internal and external)
+      - Code quality observations
+      - Potential issues or debt
+
+  # Step 4: Integration Analysis
+  - id: integration-analysis
+    name: Synthesize Integration Analysis
+    type: agent
+    agent: code-architect
+    description: |
+      Synthesize all parallel analyses into a unified codebase understanding.
+      Focus on cross-module interactions and overall architecture.
+    context-mode: summary
+    inputs:
+      - module_analyses
+      - structure_map
+      - dependency_overview
+    outputs:
+      - integrated_analysis
+      - architecture_diagram
+      - recommendations
+      - technical_debt_inventory
+    instructions: |
+      Combine parallel analysis results:
+
+      1. **Architecture Overview**
+         - Overall system architecture
+         - Module interaction patterns
+         - Data flow between modules
+
+      2. **Cross-Cutting Concerns**
+         - Shared patterns and conventions
+         - Common utilities and helpers
+         - Configuration management
+
+      3. **Quality Assessment**
+         - Consistency across modules
+         - Identified technical debt
+         - Security considerations
+
+      4. **Recommendations**
+         - Improvement opportunities
+         - Refactoring suggestions
+         - Documentation gaps
+    checklist:
+      - All modules integrated
+      - Cross-module interactions documented
+      - Architecture diagram created
+      - Recommendations prioritized
+
+outputs:
+  - name: full_analysis_report
+    description: Complete codebase analysis report
+    format: markdown
+
+  - name: architecture_diagram
+    description: System architecture visualization (Mermaid)
+    format: mermaid
+
+  - name: module_summaries
+    description: Individual module analysis summaries
+    format: json
+
+  - name: recommendations
+    description: Prioritized improvement recommendations
+    format: markdown
+
+completion_criteria:
+  - All partitions analyzed
+  - Integration analysis completed
+  - Architecture diagram generated
+  - Recommendations documented
+  - Report suitable for team sharing
+
+# Best Practices for This Workflow
+best_practices:
+  - Start with quick structure scan before deep analysis
+  - Keep partitions small enough to fit in context
+  - Use focused context mode to avoid overwhelming agents
+  - Review partition definitions before parallel analysis
+  - Validate cross-module findings in integration step