speccrew 0.1.11 → 0.2.0

package/.speccrew/skills/speccrew-project-diagnosis/templates/DIAGNOSIS-REPORT-TEMPLATE.md

@@ -1,202 +0,0 @@
-# Project Diagnosis Report
-
-Generated At: {{GeneratedAt}}
-
-## 1. Project Basic Information
-
-| Item | Content |
-|------|---------|
-| Project Name | {{ProjectName}} |
-| Project Type | {{WebFullStack/FrontendOnly/BackendOnly/DesktopClient/Mobile/CLI/Hybrid}} |
-| Determination Basis | {{DeterminationBasis}} |
-
-## 2. Technology Stack List
-
-### 2.1 Runtime & Languages
-- Language: {{LanguageAndVersion}}
-- Runtime: {{RuntimeEnvironment}}
-
-### 2.2 Core Frameworks
-- Frontend: {{FrontendFrameworkAndVersion}}
-- Backend: {{BackendFrameworkAndVersion}}
-- Database: {{DatabaseType}}
-
-### 2.3 Toolchain
-- Build: {{BuildTools}}
-- Package Management: {{PackageManager}}
-- Testing: {{TestingFramework}}
-
-## 3. Project Directory Structure Conventions
-
-Source code directory structure of the diagnosed project:
-
-```
-{{ProjectRootDirectoryStructure}}
-```
-
-## 4. Development Standards
-
-- Code Linting: {{LintingToolsAndConfig}}
-- Naming Style: {{NamingConventions}}
-- Commit Standards: {{CommitStandards}}
-
-## 5. Follow-up Work Recommendations
-
-Based on diagnosis results, recommend creating the following:
-
-### 5.1 Recommended Agents to Generate
-
-Based on project type `{{ProjectType}}`, recommend generating the following Agents:
-
-| Agent | Responsibility |
-|-------|----------------|
-| devcrew-designer-[techstack] | Detailed design |
-| devcrew-dev-[techstack] | Development implementation |
-| devcrew-test-[techstack] | Testing and validation |
-
-### 5.2 Recommended devcrew-workspace Directory Structure
-
-Based on project type and diagnosis results, recommend creating the following directory structure:
-
-```
-devcrew-workspace/
-├── docs/                       # Management documents
-│   ├── diagnosis-reports/      # Diagnosis reports
-│   │   └── diagnosis-report-{date}.md
-│   ├── README.md
-│   └── AGENTS.md
-├── knowledge/                  # Project knowledge base
-│   ├── README.md
-│   ├── constitution.md
-│   ├── architecture/           # Architecture docs (subdirs dynamically selected by project type)
-│   │   ├── system/             # System overall architecture
-│   │   ├── conventions/        # Development conventions
-│   │   {{#if hasFrontend}}├── frontend/           # Frontend architecture (Web Full-Stack / Frontend Only){{/if}}
-│   │   {{#if hasBackend}}├── backend/            # Backend architecture (Web Full-Stack / Backend Only){{/if}}
-│   │   {{#if hasDatabase}}├── data/               # Data architecture (Web Full-Stack / Backend Only){{/if}}
-│   │   {{#if hasDesktop}}├── desktop/            # Desktop architecture (Desktop Client){{/if}}
-│   │   {{#if hasMobile}}└── mobile/             # Mobile architecture (Mobile){{/if}}
-│   ├── bizs/                   # Business knowledge (empty initially, content accumulated by PM Agent)
-│   │   {{#each detectedModules}}├── {{this}}/              # {{this}} module{{/each}}
-│   └── domain/                 # Domain knowledge (empty initially, content accumulated later)
-│       ├── standards/
-│       ├── glossary/
-│       └── qa/
-└── projects/                   # Iteration projects
-    └── archive/                # Archive directory
-```
-
-**architecture/ Subdirectory Description**:
-Based on project type `[{{ProjectType}}]` determined in Phase 2, dynamically select corresponding subdirectory combinations:
-
-| Project Type | Recommended Subdirectories | Mapping to SKILL.md Phase 2 |
-|--------------|----------------------------|----------------------------|
-| Web Full-Stack | system, conventions, frontend, backend, data | system, conventions, frontend, backend, data |
-| Frontend Only | system, conventions, frontend | system, conventions, frontend |
-| Backend Only | system, conventions, backend, data | system, conventions, backend, data |
-| Desktop Client | system, conventions, desktop | system, conventions, desktop |
-| Mobile | system, conventions, mobile | system, conventions, mobile |
-| Hybrid | Create based on actual included platforms | Combine subdirs from detected platforms |
-
-**bizs/ Dynamic Generation Rules**:
-
-Based on Phase 3.3 Business Module Clue Collection, dynamically generate `bizs/` subdirectories:
-
-| Condition | Generated Content |
-|-----------|-------------------|
-| `hasModules=true` | Create subdirectories named after detected business modules (e.g., `bizs/User/`, `bizs/Order/`) |
-| `hasModules=false` | Skip `bizs/` directory creation or create empty structure |
-
-**Initial Clues from Phase 3.3** (detected from code structure, to be confirmed by PM Agent):
-- {{Module1FromRoute/DirectoryAnalysis}} (Source: frontend routing / backend API routes / directory structure)
-- {{Module2FromRoute/DirectoryAnalysis}} (Source: frontend routing / backend API routes / directory structure)
-- ...
-
-> **Note**: 
-> - `hasModules` = true when business modules detected from routes/entities/directories
-> - Business flows will be organized by PM Agent during PRD phase
-> - PM Agent will confirm and refine during actual project execution
-
-## 6. Business Analysis (Initial)
-
-Based on source code route/directory structure analysis, preliminary identification of business modules:
-
-### 6.1 Frontend Page Modules
-
-| Route Path | Page Name | Possible Function | Associated Module |
-|------------|-----------|-------------------|-------------------|
-| {{RoutePath1}} | {{PageName1}} | {{FunctionDesc1}} | {{ModuleName1}} |
-| {{RoutePath2}} | {{PageName2}} | {{FunctionDesc2}} | {{ModuleName2}} |
-
-> Data Source: Frontend routing configuration / pages directory structure analysis
-
-### 6.2 Backend API Modules
-
-| Route Prefix | Module Name | Possible Function | HTTP Methods |
-|--------------|-------------|-------------------|--------------|
-| {{ApiPrefix1}} | {{ModuleName1}} | {{FunctionDesc1}} | {{Methods1}} |
-| {{ApiPrefix2}} | {{ModuleName2}} | {{FunctionDesc2}} | {{Methods2}} |
-
-> Data Source: Backend router files / API directory structure analysis
-
-### 6.3 Data Model Clues
-
-| Table/Model Name | Associated Module | Possible Purpose | Key Fields |
-|------------------|-------------------|------------------|------------|
-| {{TableName1}} | {{Module1}} | {{Purpose1}} | {{Fields1}} |
-| {{TableName2}} | {{Module2}} | {{Purpose2}} | {{Fields2}} |
-
-> Data Source: ORM model files / database migration files analysis
-
-### 6.4 Business Module Summary
-
-```
-{{ProjectName}}
-├── {{Module1Name}}
-│   ├── Frontend: {{Pages1}}
-│   ├── Backend: {{Apis1}}
-│   └── Data: {{Tables1}}
-├── {{Module2Name}}
-│   ├── Frontend: {{Pages2}}
-│   ├── Backend: {{Apis2}}
-│   └── Data: {{Tables2}}
-```
-
-> Note: This is preliminary analysis based on code structure only. Business logic details need to be confirmed by PM Agent during requirements phase.
-
----
-
-## 7. Knowledge Base Initialization Guide
-
-Based on this diagnosis report, the following knowledge base structure should be generated during initialization:
-
-### 7.1 Techs Layer (Auto-generated by Techs Pipeline)
-
-| Directory | Generated By | Input From This Report |
-|-----------|--------------|------------------------|
-| `knowledges/techs/{platform}/` | Techs Pipeline | Section 2: Technology Stack |
-| `knowledges/techs/{platform}/architecture.md` | Techs Pipeline | Section 2.2, 3: Framework & directory structure |
-| `knowledges/techs/{platform}/conventions-*.md` | Techs Pipeline | Section 4: Development standards |
-
-### 7.2 Business Layer (Framework generated by Leader Agent)
-
-| Directory | Generated By | Input From This Report |
-|-----------|--------------|------------------------|
-| `bizs/{ModuleName}/` | Leader Agent | Section 6.4: Business module summary |
-
-### 7.3 Domain Layer (Empty initially)
-
-| Directory | Content | Populated By |
-|-----------|---------|--------------|
-| `domain/standards/` | Industry standards | PM Agent on-demand |
-| `domain/glossary/` | Business terminology | PM Agent during PRD phase |
-| `domain/qa/` | Q&A knowledge | All Agents gradually |
-
----
-
-## 8. Content for Deep Identification
-
-The following needs to be gradually accumulated during Agent usage:
-- **Business Flows**: Organized by PM Agent during PRD phase, associated with corresponding modules
-- **Domain Knowledge**: Added to `domain/` when involving industry standards
-- **Repetitive Operation Patterns**: Identified by Dev Agent during development and accumulated as Skills

package/.speccrew/skills/speccrew-workflow-diagnose/SKILL.md

@@ -1,155 +0,0 @@
----
-name: speccrew-workflow-diagnose
-description: Diagnose issues in AI engineering workflows. Analyze workflow bottlenecks, Agent behavior anomalies, deliverable quality issues, and provide solutions. Trigger scenarios: user mentions "workflow stuck", "diagnose problem", "Agent not working as expected", "poor deliverable quality"
-tools: Read, Glob, Grep
----
-
-# Trigger Scenarios
-
-- AI engineering workflow stuck at a certain stage
-- Agent output does not meet expectations
-- Deliverable quality does not meet standards
-- User mentions "workflow issues", "diagnose", "Agent behavior anomaly"
-
-# Workflow
-
-## 1. Collect Problem Information
-
-Ask or identify the following information:
-- Which stage did the problem occur? (PM / Solution / Design / Development / Testing)
-- What are the specific symptoms?
-- What solutions have been tried?
-
-## 2. Read Related Deliverables
-
-Based on the problem stage, read the corresponding deliverables:
-
-| Problem Stage | Deliverables to Read |
-|---------------|----------------------|
-| PM Stage | `se/prd.md` |
-| Solution Stage | `se/solution.md` |
-| Design Stage | `se/*-design.md` |
-| Development Stage | Related code files |
-| Testing Stage | Test cases, test reports |
-
-## 3. Analyze Root Cause
-
-Common problem types and diagnostic directions:
-
-### Agent Behavior Issues
-
-| Symptom | Possible Cause | Solution |
-|---------|----------------|----------|
-| Output too generic | Agent prompt lacks project-specific information | Use `agent-optimize` Skill to supplement specific tech stack |
-| Skipping necessary steps | Workflow description unclear | Add checklists (checkboxes) |
-| Output format chaotic | Output specification unclear | Provide specific template examples |
-| Responsibility overreach | Insufficient constraints | Clearly define prohibited actions |
-
-### Workflow Handoff Issues
-
-| Symptom | Possible Cause | Solution |
-|---------|----------------|----------|
-| Design document unclear | Missing transition from Solution to design | Add context input requirements for design Agent |
-| Code does not match design | Design document not detailed enough | Output pseudo-code level details in design stage |
-| Test cases incomplete coverage | Testing Agent lacks design input | Ensure testing Agent reads design documents |
-
-### Deliverable Quality Issues
-
-| Symptom | Possible Cause | Solution |
-|---------|----------------|----------|
-| PRD requirements vague | PM Agent did not fully explore requirements | Add multi-round dialogue confirmation |
-| Solution lacks feasibility analysis | Technical constraints not identified | Add technical feasibility checkpoints |
-| Design document too complex | Not following simple design principles | Split modules, design in phases |
-
-## 4. Provide Solutions
-
-For identified problems, provide:
-1. **Immediate Solution** - Actions that can be taken immediately
-2. **Long-term Improvement** - Mechanisms to prevent similar issues
-3. **Files to Modify** - Specific configurations or documents to adjust
-
-## 5. Execute Fixes (Optional)
-
-If user agrees, execute fixes:
-- Use `agent-optimize` to adjust Agent prompts
-- Use `skill-develop` to create new check Skills
-- Update related deliverable templates
-
-# Diagnostic Checklist
-
-Standard checklist items when analyzing problems:
-
-- [ ] Problem stage accurately identified
-- [ ] Related deliverables have been read
-- [ ] Root cause analysis is well-founded
-- [ ] Solutions are specific and feasible
-- [ ] Long-term prevention measures considered
-
-# Common Diagnostic Scenarios
-
-## Scenario 1: Agent Output Does Not Meet Expectations
-
-**Diagnostic Steps:**
-1. Read the corresponding Agent file
-2. Check if description contains trigger scenarios
-3. Check if workflow has checklists
-4. Check if constraints are clear
-
-**Fix Solutions:**
-- Optimize Agent prompts (call `agent-optimize`)
-- Add example outputs
-- Clearly define prohibited actions
-
-## Scenario 2: Workflow Loops at a Certain Stage
-
-**Diagnostic Steps:**
-1. Check if previous stage deliverables are complete
-2. Check if current stage input requirements are clear
-3. Check if deliverable standards are too high or vague
-
-**Fix Solutions:**
-- Adjust deliverable acceptance standards
-- Add intermediate checkpoints
-- Split overly long workflow steps
-
-## Scenario 3: Multiple Agent Responsibility Conflicts
-
-**Diagnostic Steps:**
-1. Compare responsibility descriptions of related Agents
-2. Check for overlaps (what can/cannot be done)
-3. Check deliverable definitions at handoff points
-
-**Fix Solutions:**
-- Redefine responsibility boundaries
-- Clarify deliverable handoff standards
-- Add dedicated handoff Agent
-
-# Verification Checklist
-
-- [ ] Problem root cause identified
-- [ ] Solutions provided
-- [ ] User understands and agrees with solution
-- [ ] If fixes needed, fixes completed
-
-# Output Format
-
-```
-## Workflow Diagnostic Report
-
-### Problem Description
-[User described problem]
-
-### Root Cause Analysis
-[Analyzed root cause]
-
-### Solutions
-1. **Immediate Measures**: [What can be done immediately]
-2. **Long-term Improvement**: [Prevention mechanism]
-
-### Files to Modify
-- [File path] - [Modification content]
-
-### Recommendations
-[Next step action recommendations]
-```
-