speccrew 0.1.0

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

@@ -0,0 +1,208 @@
+---
+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
+
+## 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 Fill Report Content
+
+Based on template `templates/DIAGNOSIS-REPORT-TEMPLATE.md`, generate the diagnosis report.
+
+**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

@@ -0,0 +1,202 @@
+# 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-sd-backend/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: speccrew-sd-backend
+description: Backend System Design SOP. Guide System Designer Agent to generate platform-specific backend detailed design documents by filling technology implementation details into the Feature Spec skeleton. Reads techs knowledge to determine actual framework syntax, ORM patterns, and conventions.
+tools: Read, Write, Glob, Grep
+---
+
+# Trigger Scenarios
+
+- Feature Spec has been confirmed, user requests backend system design
+- System Designer Agent receives task to create backend detailed design for a specific platform
+- User asks "Design backend implementation" or "Create backend design for {platform}"
+
+# Workflow
+
+## Step 1: Read Inputs
+
+Read in order:
+
+1. **Feature Spec document(s)**: `speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/[feature-name]-feature-spec.md`
+2. **API Contract**: `speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/[feature-name]-api-contract.md`
+3. **Backend techs knowledge** (paths from agent context):
+   - `speccrew-workspace/knowledges/techs/{platform_id}/tech-stack.md`
+   - `speccrew-workspace/knowledges/techs/{platform_id}/architecture.md`
+   - `speccrew-workspace/knowledges/techs/{platform_id}/conventions-design.md`
+   - `speccrew-workspace/knowledges/techs/{platform_id}/conventions-dev.md`
+   - `speccrew-workspace/knowledges/techs/{platform_id}/conventions-data.md` (critical for backend: ORM, data modeling, migration)
+4. **Design template**: `speccrew-sd-backend/templates/SD-BACKEND-TEMPLATE.md`
+5. **Index template**: `speccrew-sd-backend/templates/INDEX-TEMPLATE.md`
+
+## Step 2: Analyze Existing Code Structure
+
+Use Glob/Grep to understand current backend codebase:
+
+| Analysis Target | Purpose |
+|-----------------|---------|
+| Controller/Router layer structure | Understand routing patterns and naming conventions |
+| Service layer organization | Identify service boundaries and reuse opportunities |
+| Repository/DAO layer patterns | Review data access patterns |
+| Entity/Model definitions | Understand existing data models |
+| Middleware stack | Identify cross-cutting concerns |
+| Exception handling patterns | Review error handling approach |
+| Database migration structure | Understand migration naming and structure |
+| Naming conventions | Ensure consistency with existing code |
+
+## Step 3: Extract Functions from Feature Spec
+
+Parse Feature Spec to identify all backend-relevant functions.
+
+For each function, extract:
+
+| Aspect | Content |
+|--------|---------|
+| **API Interfaces** | From Feature Spec Section 2.N backend part |
+| **Data Access Requirements** | What data needs to be read/written |
+| **Business Logic Flow** | Core processing steps |
+| **Cross-Module Dependencies** | Dependencies on other modules or services |
+
+Cross-reference with API Contract for exact endpoint specifications.
+
+Mark each function as:
+
+| Marker | Meaning |
+|--------|---------|
+| `[EXISTING]` | Reuse current implementation, no changes needed |
+| `[MODIFIED]` | Modify existing implementation |
+| `[NEW]` | Create brand new implementation |
+
+**Checkpoint A: Present function list with markers to user for confirmation before proceeding.**
+
+## Step 4: Generate Module Design Documents
+
+For each function (or logical group = one controller/module):
+
+### 4.1 Read Template
+
+Read the SD-BACKEND-TEMPLATE.md to understand document structure.
+
+### 4.2 Fill Template Sections
+
+Fill each section with technology-specific implementation details:
+
+| Section | Content Source |
+|---------|----------------|
+| **Module Structure** | Use actual framework layering from techs knowledge |
+| **Interface Pseudo-code** | Use actual framework decorators/annotations |
+| **Database Design** | Use actual ORM entity definitions from conventions-data.md |
+| **Transaction Boundaries** | Use actual framework transaction mechanism |
+| **Exception Handling** | Use actual exception classes and error codes |
+
+**Pseudo-code Requirements:**
+- MUST use actual framework syntax from techs knowledge
+- Spring Boot: `@RestController`, `@PostMapping`, `@Valid`, `@Transactional`, etc.
+- NestJS: `@Controller`, `@Post`, `@Body`, `@UseGuards`, etc.
+- Go: `gin.Context`, `echo.Context`, GORM annotations, etc.
+
+### 4.3 Write Output
+
+Write to: `speccrew-workspace/iterations/{number}-{type}-{name}/03.system-design/{platform_id}/{module}-design.md`
+
+## Step 5: Generate Platform INDEX.md
+
+After all module designs are complete:
+
+### 5.1 Read Index Template
+
+Read INDEX-TEMPLATE.md to understand platform-level document structure.
+
+### 5.2 Fill Index Sections
+
+| Section | Content |
+|---------|---------|
+| **Tech Stack Summary** | Extract from techs knowledge |
+| **Shared Design Decisions** | Middleware stack, data source config, base service classes, common utilities |
+| **Module List Table** | Links to each module design document |
+| **Cross-Module Interaction Notes** | Shared services, event-driven patterns, dependencies |
+| **Database Schema Overview** | New tables, modified tables, entity relationships |
+
+### 5.3 Write Output
+
+Write to: `speccrew-workspace/iterations/{number}-{type}-{name}/03.system-design/{platform_id}/INDEX.md`
+
+## Step 6: Present Summary
+
+Present to user:
+
+```
+Backend System Design Summary for: {feature-name}
+Platform: {platform_id}
+
+Module Designs: {count}
+├── [NEW] {count} modules
+├── [MODIFIED] {count} modules
+└── [EXISTING] {count} modules (no design needed)
+
+Database Changes:
+├── New Tables: {count}
+├── Modified Tables: {count}
+└── Migration Files: {count}
+
+Key Design Decisions:
+- {decision 1}
+- {decision 2}
+- {decision 3}
+
+Files Generated:
+- {list all file paths}
+```
+
+# Key Rules
+
+| Rule | Description |
+|------|-------------|
+| **Actual Framework Syntax** | All pseudo-code MUST use actual framework/library syntax from techs knowledge |
+| **API Contract is READ-ONLY** | Do NOT modify API Contract, stop and report if issues found |
+| **Migration Strategy Required** | Database design must include migration strategy, not just final schema |
+| **Explicit Transaction Boundaries** | Transaction boundaries must be explicitly marked |
+| **Exception Code Mapping** | Exception handling must map to API Contract error codes |
+| **Follow Techs Conventions** | Naming, directory structure, patterns from techs knowledge |
+
+# Mermaid Diagram Requirements
+
+When generating Mermaid diagrams, follow compatibility guidelines:
+
+- Use only basic node definitions: `A[text content]`
+- No HTML tags (e.g., `<br/>`)
+- No nested subgraphs
+- No `direction` keyword
+- No `style` definitions
+- No special characters in node text
+- Use standard `graph TB/LR` or `flowchart TD/LR` or `erDiagram` syntax only
+
+# Checklist
+
+- [ ] All techs knowledge documents loaded before design
+- [ ] Feature Spec and API Contract read and understood
+- [ ] Existing codebase structure analyzed (Glob/Grep)
+- [ ] Function extraction completed with [EXISTING]/[MODIFIED]/[NEW] markers
+- [ ] Checkpoint A passed: function list confirmed with user
+- [ ] Every API in API Contract has a corresponding implementation design
+- [ ] Database entities cover all data requirements from Feature Spec
+- [ ] Transaction boundaries defined for multi-step operations
+- [ ] Exception types map to API Contract error codes
+- [ ] Pseudo-code uses actual framework syntax (not generic)
+- [ ] conventions-data.md ORM patterns followed
+- [ ] Migration requirements documented
+- [ ] INDEX.md generated with complete module list
+- [ ] All files written to correct paths under 03.system-design/{platform_id}/
+- [ ] All Mermaid diagrams follow compatibility guidelines

package/.speccrew/skills/speccrew-sd-backend/templates/INDEX-TEMPLATE.md

@@ -0,0 +1,85 @@
+# Backend System Design Index - {PlatformId}
+
+> Platform: {PlatformId} | Framework: {Framework} | Language: {Language}
+> Feature Spec: {FeatureSpecPath}
+> Generated: {Timestamp}
+
+## 1. Platform Tech Stack Summary
+
+| Category | Technology | Version | Purpose |
+|----------|-----------|---------|---------|
+| Framework | {e.g., Spring Boot} | {version} | {purpose} |
+| ORM | {e.g., MyBatis-Plus} | {version} | {purpose} |
+| Database | {e.g., MySQL} | {version} | {purpose} |
+| Cache | {e.g., Redis} | {version} | {purpose} |
+| Auth | {e.g., Spring Security + JWT} | {version} | {purpose} |
+| API Docs | {e.g., Swagger/SpringDoc} | {version} | {purpose} |
+
+## 2. Shared Design Decisions
+
+### 2.1 Middleware Stack
+
+| Middleware | Order | Purpose | Configuration |
+|-----------|-------|---------|--------------|
+| {middleware} | {order} | {purpose} | {key config} |
+
+### 2.2 Data Source Configuration
+
+{Description of database connection, connection pool, read-write separation if applicable}
+
+### 2.3 Base Classes and Shared Services
+
+| Class/Service | Path | Purpose | Used By |
+|--------------|------|---------|---------|
+| {base class} | {path} | {purpose} | {which modules} |
+
+### 2.4 Common Utilities
+
+| Utility | Path | Purpose |
+|---------|------|---------|
+| {utility} | {path} | {purpose} |
+
+### 2.5 Authentication and Authorization
+
+{Description of auth mechanism, permission model, annotation-based access control}
+
+## 3. Module Design Index
+
+| Module | Scope | APIs | Entities | Status | Document |
+|--------|-------|------|----------|--------|----------|
+| {module-name} | {brief scope} | {count} | {count} | [NEW]/[MODIFIED] | [{module-name}-design.md](./{module-name}-design.md) |
+
+## 4. Cross-Module Interaction Notes
+
+{Describe any shared services, event-driven patterns, or cross-module dependencies}
+
+## 5. Database Schema Overview
+
+### 5.1 New Tables
+
+| Table | Module | Description |
+|-------|--------|-------------|
+| {table} | {module} | {purpose} |
+
+### 5.2 Modified Tables
+
+| Table | Module | Change Type | Description |
+|-------|--------|------------|-------------|
+| {table} | {module} | ADD COLUMN/MODIFY/... | {what changed} |
+
+### 5.3 Entity Relationship Overview
+
+```mermaid
+erDiagram
+    ENTITY_A ||--o{ ENTITY_B : "has"
+    ENTITY_B ||--o{ ENTITY_C : "contains"
+    ENTITY_A ||--o| ENTITY_D : "references"
+```
+
+## 6. Directory Structure Impact
+
+```
+{source-directory}/
+├── {new directories and files to be created}
+└── {modified directories and files}
+```