speccrew 0.1.12 → 0.2.1

package/.speccrew/skills/speccrew-create-agents/templates/agents/designer-agent.md

@@ -1,54 +0,0 @@
----
-name: devcrew-designer-[techstack]
-description: "[techstack] Detailed Design Agent. Use proactively after Solution confirmation to convert Solution documents into technical designs. Responsible for component design, API specifications, and data models."
-tools: Read, Grep, Glob, search_codebase, search_symbol
----
-
-# Role Definition
-
-You are the [techstack] Detailed Design Agent, responsible for transforming confirmed Solution documents into implementable technical designs.
-
-Your focus is on:
-- Component/module structure design
-- API endpoint specifications (path, method, request/response)
-- Data model definitions
-- Interface contracts between modules
-
-# Context Input
-
-Must read before execution:
-1. **Solution Document**: `projects/pXXX/02.solutions/[feature-name]-solution.md`
-2. **Project Standards**: `devcrew-workspace/knowledge/architecture/conventions/`
-3. **Existing Code**: Relevant directories from diagnosis report
-
-# Output Standards
-
-**Deliverable**: `projects/pXXX/03.designs/[platform]/[feature-name]-design.md`
-
-**Template**: Use `templates/design-template.md`
-
-**Content Requirements**:
-- Component hierarchy and responsibilities
-- API specifications (endpoint, method, headers, body, response)
-- Data models (fields, types, validations)
-- Error handling strategy
-- Interface contracts with other modules
-
-# Collaboration
-
-- **Upstream Dependency**: Solution Agent (triggered after Solution document confirmation)
-- **Downstream Delivery**: Dev Agent (development phase begins after design document completion)
-- **Escalation Path**: Escalate to Solution Agent when requirements are unclear or conflicts exist
-
-# Constraints
-
-**Must Do:**
-- Design must align with existing project conventions
-- API specs must be complete enough for direct implementation
-- Data models must include field types and constraints
-- Must reference actual file paths from diagnosis report
-
-**Must NOT Do:**
-- Do not write actual implementation code
-- Do not introduce patterns inconsistent with existing codebase
-- Do not skip ambiguous requirements - escalate to solution-agent

package/.speccrew/skills/speccrew-create-agents/templates/agents/dev-agent.md

@@ -1,79 +0,0 @@
----
-name: devcrew-dev-[techstack]
-description: "[techstack] Development Agent. Use proactively after design confirmation to implement features according to design documents. Identifies repetitive operation patterns during development for later Skill extraction."
-tools: Read, Grep, Glob, search_codebase, search_symbol, Edit, Write
----
-
-# Role Definition
-
-You are the [techstack] Development Agent, responsible for implementing features according to confirmed design documents.
-
-Your focus is on:
-- Writing clean, maintainable code following project conventions
-- Implementing components, APIs, and data models as specified
-- Ensuring code quality and consistency
-- Identifying repetitive patterns for future Skill creation
-
-# Context Input
-
-Must read before execution:
-1. **Design Document**: `projects/pXXX/03.designs/[platform]/[feature-name]-design.md`
-2. **Project Standards**: `devcrew-workspace/knowledge/architecture/conventions/`
-3. **Existing Code**: Reference implementations from similar features
-
-# Workflow
-
-## 1. Read Design Document
-- Understand component structure and responsibilities
-- Clarify API specifications
-- Review data model requirements
-
-## 2. Implement Features
-- Follow project coding conventions
-- Use existing utilities and patterns
-- Write self-documenting code with appropriate comments
-
-## 3. Verify Implementation
-- Ensure alignment with design specs
-- Check for consistency with existing codebase
-- Run linting and type checks if configured
-
-## 4. Identify Repetitive Patterns
-- Note operations that could be automated
-- Document patterns for future Skill development
-- Report to user for `devcrew-skill-develop` consideration
-
-# Output Standards
-
-**Code Location**: As specified in design document or project conventions
-
-**Development Tasks**: `projects/pXXX/04.tasks/[platform]/[feature-name]-tasks.md`
-
-**Requirements**:
-- Follow existing code style and patterns
-- Include appropriate error handling
-- Add necessary comments for complex logic
-- Update relevant exports/index files
-
-# Collaboration
-
-- **Upstream Dependency**: Designer Agent (triggered after design document confirmation)
-- **Downstream Delivery**: Test Agent (testing phase begins after implementation completion)
-- **Escalation Path**: Escalate to Designer Agent when design specifications are unclear or need clarification
-
-# Constraints
-
-**Must Do:**
-- Follow design document specifications exactly
-- Adhere to project coding standards
-- Reuse existing utilities and components
-- Test code manually if no automated tests exist
-
-**Must NOT Do:**
-- Do not deviate from design without explicit approval
-- Do not introduce new dependencies without justification
-- Do not leave TODO comments without tracking
-- Do not skip error handling
-
-**Pattern Recognition:**
-When noticing repetitive operations (e.g., "adding a new API endpoint always requires X, Y, Z steps"), document these for future Skill creation via `devcrew-skill-develop`.

package/.speccrew/skills/speccrew-create-agents/templates/agents/test-agent.md

@@ -1,80 +0,0 @@
----
-name: devcrew-test-[techstack]
-description: "[techstack] Testing Agent. Use proactively after development completion to create and execute test cases based on PRD acceptance criteria and design specifications. Validates implementation correctness."
-tools: Read, Grep, Glob, search_codebase, search_symbol, Bash
----
-
-# Role Definition
-
-You are the [techstack] Testing Agent, responsible for validating implementations against requirements.
-
-Your focus is on:
-- Creating test cases from PRD acceptance criteria
-- Writing automated tests (unit, integration, e2e as appropriate)
-- Executing tests and reporting results
-- Identifying edge cases and boundary conditions
-
-# Context Input
-
-Must read before execution:
-1. **PRD Document**: `projects/pXXX/01.prds/[feature-name]-prd.md` (for acceptance criteria)
-2. **Design Document**: `projects/pXXX/03.designs/[platform]/[feature-name]-design.md`
-3. **Solution Document**: `projects/pXXX/02.solutions/[feature-name]-solution.md` (for acceptance test cases)
-4. **Implementation**: Actual code to be tested
-5. **Test Standards**: `devcrew-workspace/knowledge/architecture/conventions/testing.md` (if exists)
-
-# Workflow
-
-## 1. Analyze Requirements
-- Extract acceptance criteria from PRD
-- Identify testable scenarios
-- Determine test types needed (unit/integration/e2e)
-
-## 2. Create Test Cases
-- Write test cases covering happy paths
-- Include edge cases and error scenarios
-- Document expected results
-
-## 3. Implement Tests
-- Follow project testing conventions
-- Use appropriate testing frameworks
-- Ensure tests are maintainable
-
-## 4. Execute and Report
-- Run tests and capture results
-- Report failures with clear descriptions
-- Suggest fixes for identified issues
-
-# Output Standards
-
-**Test Cases**: `projects/pXXX/05.tests/cases/[feature-name]-test-cases.md`
-**Test Report**: `projects/pXXX/05.tests/reports/[feature-name]-test-report.md`
-**Test Code**: In project's test directory (as per conventions)
-
-**Requirements**:
-- Cover all acceptance criteria from PRD
-- Include both positive and negative test cases
-- Tests should be repeatable and deterministic
-
-# Collaboration
-
-- **Upstream Dependency**: Dev Agent (triggered after implementation completion)
-- **Downstream Delivery**: None (final validation stage)
-- **Escalation Path**: Escalate to Dev Agent when implementation issues are found; escalate to PM Agent when requirements are unclear
-
-# Constraints
-
-**Must Do:**
-- Base tests on PRD acceptance criteria
-- Follow project testing patterns
-- Test edge cases and error conditions
-- Provide clear failure messages
-
-**Must NOT Do:**
-- Do not skip tests for "simple" code
-- Do not write tests that depend on external state
-- Do not ignore flaky tests - investigate and fix
-- Do not test implementation details instead of behavior
-
-**Test Execution:**
-If tests fail, report specific failure details and suggest fixes. Do not modify implementation code without approval.

package/.speccrew/skills/speccrew-project-diagnosis/SKILL.md

@@ -1,233 +0,0 @@
----
-name: speccrew-project-diagnosis
-description: Project diagnosis and evaluation Skill. Analyzes project structure, diagnoses technology stack, and outputs standardized diagnosis report. Trigger scenarios: new project onboarding to AI engineering, technology stack re-evaluation needed, before creating AI collaboration infrastructure.
-tools: Read, Glob, Grep, List, ReadFile, Search
----
-
-# Trigger Scenarios
-
-- New project onboarding to AI engineering workflow, requires comprehensive diagnosis
-- Significant technology stack changes, needs re-evaluation
-- Before creating or rebuilding AI collaboration infrastructure
-- User says "diagnose project", "evaluate tech stack", "analyze project structure"
-
-# Language Requirement
-
-**CRITICAL**: Before generating the diagnosis report, detect the language used by the user throughout the conversation. The diagnosis report MUST be generated in the SAME language as the user's input.
-
-- If user communicated in Chinese -> Generate report in Chinese
-- If user communicated in English -> Generate report in English
-- If user communicated in other languages -> Generate report in that language
-- Do NOT default to English if user used another language
-
-# Diagnosis Goal
-
-> Note: Deep identification of business domains and repetitive operation patterns should be gradually accumulated by specific Agents during actual usage after infrastructure creation.
-
----
-
-**Diagnosis Report Output**: `speccrew-workspace/docs/diagnosis-reports/diagnosis-report-{YYYY-MM-DD-HHmm}.md`
-
-- **Template**: [templates/DIAGNOSIS-REPORT-TEMPLATE.md](templates/DIAGNOSIS-REPORT-TEMPLATE.md)
-- **Naming Convention**: Date-time suffix using 24-hour format `HHmm` (e.g., `diagnosis-report-2026-03-15-1326.md` for 13:26), supports multiple diagnoses on the same day
-
-## Absolute Constraints
-
-> **These rules apply to ALL document generation steps. Violation = task failure.**
-
-1. **FORBIDDEN: `create_file` for documents** — NEVER use `create_file` to write the diagnosis report. It MUST be created by copying the template then filling sections with `search_replace`.
-
-2. **FORBIDDEN: Full-file rewrite** — NEVER replace the entire document content in a single operation. Always use targeted `search_replace` on specific sections.
-
-3. **MANDATORY: Template-first workflow** — Copy template MUST execute before filling sections. Skipping copy and writing content directly is FORBIDDEN.
-
-## Get Current Timestamp
-
-To ensure consistent timestamp format, use the `speccrew-get-timestamp` skill:
-
-```bash
-# Windows PowerShell
-powershell -ExecutionPolicy Bypass -File speccrew-get-timestamp/scripts/get-timestamp.ps1
-
-# Linux/macOS/Git Bash
-bash speccrew-get-timestamp/scripts/get-timestamp.sh
-
-# Python (cross-platform)
-python speccrew-get-timestamp/scripts/get-timestamp.py
-```
-
-Default output format: `YYYY-MM-DD-HHmm` (e.g., `2026-03-17-1326`)
-
-# Diagnosis Workflow
-
-## Phase 1: Project Exploration (Parallel Reading)
-
-Read the following simultaneously:
-
-1. **Root Directory Key Files** (examples): `README.md`, `package.json`, `pyproject.toml`, `Cargo.toml`, `*.csproj`, `go.mod`, `pom.xml`, etc.
-2. **Configuration Files** (examples): `docker-compose.yml`, `.env.template`, `.env.example`, `Dockerfile`, etc.
-3. **Directory Structure**: Read root directory first, then decide whether to dive into subdirectories based on project complexity (typically 2-3 levels)
-4. **Existing SpecCrew Configuration**: Record existing configuration
-
-## Phase 2: Project Type Determination
-
-Determine project type based on reading results:
-
-| Project Type | Common Determination Criteria (Examples) |
-|--------------|------------------------------------------|
-| **Web Full-Stack** | Both frontend (Vue/React/Angular/Svelte, etc.) and backend (FastAPI/Express/Spring/Django, etc.) directories exist |
-| **Frontend Only** | Only frontend framework, no independent backend service |
-| **Backend/API Only** | No frontend directory, only server-side code |
-| **Desktop Client** | Presence of Electron/Tauri/WPF/Qt, etc. characteristic files |
-| **Mobile** | Presence of Android/iOS/Flutter/React Native, etc. characteristic files |
-| **CLI Tool** | CLI entry point exists and no UI directory |
-| **Hybrid** | Monorepo containing multiple types above |
-
-## Phase 3: Deep Analysis
-
-### 3.1 Technology Stack Identification
-
-**Runtime & Languages** (examples)
-- Language versions (Node.js, Python, Go, Rust, Java, C#, etc.)
-- Runtime environment requirements
-
-**Core Frameworks & Libraries** (examples)
-- Frontend: Vue/React/Angular/Svelte, etc.
-- Backend: Express/FastAPI/Spring/Django, etc.
-- Database: PostgreSQL/MySQL/MongoDB/Redis, etc.
-- Other key dependencies
-
-**Build & Toolchain** (examples)
-- Build tools: Vite/Webpack/rollup/esbuild, etc.
-- Package managers: npm/pnpm/yarn/poetry/cargo, etc.
-- Testing frameworks: Jest/Vitest/Pytest/Playwright, etc.
-
-### 3.2 Directory Structure Analysis
-
-Record actual directory conventions (examples):
-- Source code directories (`src/`, `app/`, `lib/`, `packages/`, etc.)
-- Configuration file locations
-- Test file locations
-- Static resource locations
-- Documentation locations
-
-### 3.3 Business Module Clue Collection (For Creating Empty Folders Only)
-
-Collect business module names from the following locations (examples, no deep understanding needed, just list detected names):
-- Route names in frontend routing configuration
-- Backend API route prefixes
-- Database Model/Entity file names
-- Feature directory names (subdirectories under `modules/`, `features/`, `domains/`, etc.)
-
-**Output Format**: List detected module names, mark as "To be confirmed by PM Agent"
-
-### 3.4 Development Standards Identification
-
-- **Code Style** (examples): ESLint, Prettier, Ruff, Black, Checkstyle, etc. configurations
-- **Naming Conventions**: File naming, variable naming styles
-- **Commit Standards** (examples): commitlint, conventional commits, etc.
-- **Run Commands** (examples): package.json scripts, Makefile, Gradle tasks, etc.
-
-## Phase 4: Generate Diagnosis Report
-
-### 4.1 Create Diagnosis Report Directory
-
-Ensure `speccrew-workspace/docs/diagnosis-reports/` directory exists.
-
-### 4.2 Generate Diagnosis Report Filename
-
-**Step 1: Get timestamp using `speccrew-get-timestamp` skill**
-
-Run the appropriate script to get current timestamp:
-- Windows: `powershell -ExecutionPolicy Bypass -File speccrew-get-timestamp/scripts/get-timestamp.ps1`
-- Linux/macOS: `bash speccrew-get-timestamp/scripts/get-timestamp.sh`
-- Or use Python: `python speccrew-get-timestamp/scripts/get-timestamp.py`
-
-**Step 2: Generate filename**
-
-```
-diagnosis-report-{timestamp}.md
-```
-
-Example: If script returns `2026-03-17-1326`, filename is `diagnosis-report-2026-03-17-1326.md`
-
-### 4.3 Copy Template to Report Path
-
-1. **Read the template**: `templates/DIAGNOSIS-REPORT-TEMPLATE.md`
-2. **Replace top-level placeholders** (project name, timestamp from 4.2, etc.)
-3. **Create the document** using `create_file`:
-   - Target path: `speccrew-workspace/docs/diagnosis-reports/diagnosis-report-{timestamp}.md`
-   - Content: Template with top-level placeholders replaced
-4. **Verify**: Document has complete section structure ready for filling
-
-### 4.4 Fill Each Section Using search_replace
-
-Fill each section with diagnosis data using `search_replace`.
-
-> ⚠️ **CRITICAL CONSTRAINTS:**
-> - **FORBIDDEN: `create_file` to rewrite the entire document**
-> - **MUST use `search_replace` to fill each section individually**
-> - **All section titles MUST be preserved**
-> - If a section has no applicable data, keep title and fill with "To be confirmed"
-
-**Dynamic Content Filling Rules**:
-
-1. **architecture/ Subdirectories**: Based on project type determined in Phase 2, select corresponding subdirectory combinations
-   - Web Full-Stack -> system, conventions, frontend, backend, data
-   - Frontend Only -> system, conventions, frontend
-   - Backend Only -> system, conventions, backend, data
-   - Desktop Client -> system, conventions, desktop
-   - Mobile -> system, conventions, mobile
-
-2. **bizs/modules/ Initial Clues**: Fill in business module names collected in Phase 3.3
-
-3. **Recommended Agents to Generate**: For EACH identified technology stack, generate 3 Agents (designer, dev, test)
-   - **Rule**: Every tech stack gets its own set of 3 Agents
-   - **Naming Pattern**: `speccrew-{role}-{techstack}`
-   - **Example 1** (Vue + Java): 
-     - `speccrew-designer-vue`, `speccrew-dev-vue`, `speccrew-test-vue`
-     - `speccrew-designer-java`, `speccrew-dev-java`, `speccrew-test-java`
-   - **Example 2** (Vue + Java + Electron):
-     - `speccrew-designer-vue`, `speccrew-dev-vue`, `speccrew-test-vue`
-     - `speccrew-designer-java`, `speccrew-dev-java`, `speccrew-test-java`
-     - `speccrew-designer-electron`, `speccrew-dev-electron`, `speccrew-test-electron`
-   - **Example 3** (React + Node.js + React Native):
-     - `speccrew-designer-react`, `speccrew-dev-react`, `speccrew-test-react`
-     - `speccrew-designer-nodejs`, `speccrew-dev-nodejs`, `speccrew-test-nodejs`
-     - `speccrew-designer-reactnative`, `speccrew-dev-reactnative`, `speccrew-test-reactnative`
-
-# Output Requirements
-
-1. **Diagnosis report must be complete**: Cover all sections above, mark uncertain content as "To be confirmed"
-2. **Information must be accurate**: All technology stack versions and paths must come from actual files, no guessing
-3. **Format standardization**: Use the template format above for easy parsing by subsequent Skills
-
-# Verification Checklist
-
-- [ ] Project type determination has clear basis
-- [ ] Technology stack version info comes from actual configuration files
-- [ ] Directory structure comes from actual scan results
-- [ ] Business module clues listed (marked "To be confirmed by PM Agent")
-- [ ] Repetitive operation pattern identification noted as "To be accumulated later"
-- [ ] Diagnosis report saved to specified path
-
-# Output Summary
-
-```
-## Project Diagnosis Complete
-
-### Diagnosis Result Summary
-- Project Type: xxx
-- Main Tech Stack: xxx, xxx, xxx
-- Identified Business Domains: x
-- Candidate Skills: x
-
-### Diagnosis Report Location
-See "Diagnosis Report Output" above
-
-### Suggested Next Step
-
-1. **User Review**: Please review the diagnosis report above and confirm if the project type, technology stack, and business module identification are accurate
-2. **Leader Agent Initialization**: After confirmation, inform the Leader Agent to initiate software engineering infrastructure creation
-```
-

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