speccrew 0.1.0

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

@@ -0,0 +1,79 @@
+---
+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

@@ -0,0 +1,80 @@
+---
+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-dev-backend/SKILL.md

@@ -0,0 +1,205 @@
+---
+name: speccrew-dev-backend
+description: Backend Development SOP. Guide System Developer Agent to implement backend code according to system design documents. Reads design blueprints, extracts task checklist, and executes implementation task by task with local quality checks.
+tools: Bash, Edit, Write, Glob, Grep, Read
+---
+
+# Trigger Scenarios
+
+- Backend system design has been approved, user requests backend development
+- User asks "Start backend development", "Implement backend code"
+- System Developer Agent receives task to implement backend for a specific platform
+
+# Workflow
+
+## Step 1: Read Design Documents
+
+Read in order:
+
+1. **Backend Design Documents**: `speccrew-workspace/iterations/{number}-{type}-{name}/03.system-design/{platform_id}/*-design.md`
+2. **Platform INDEX**: `speccrew-workspace/iterations/{number}-{type}-{name}/03.system-design/{platform_id}/INDEX.md`
+3. **API Contract**: `speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/[feature-name]-api-contract.md`
+4. **Techs Knowledge** (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: ORM, data modeling, migration)
+5. **Task Record Template**: `speccrew-dev-backend/templates/TASK-RECORD-TEMPLATE.md`
+
+## Step 2: Create Task Record File
+
+Before coding, create the task record:
+
+**Path**: `speccrew-workspace/iterations/{number}-{type}-{name}/04.development/{platform_id}/[module]-task.md`
+
+Initialize with design metadata and prepare task checklist structure.
+
+## Step 3: Extract Task List
+
+Parse design documents to extract all implementation tasks.
+
+### Backend Task Types
+
+| Category | Description | Example Files |
+|----------|-------------|---------------|
+| Entity/Model | Data model definitions | `entity/`, `model/`, `domain/` |
+| Repository/DAO | Data access layer | `repository/`, `dao/`, `mapper/` |
+| Service | Business logic layer | `service/`, `manager/`, `handler/` |
+| Controller/API | REST endpoints | `controller/`, `router/`, `api/` |
+| Database Migration | Schema changes | `db/migration/`, `migrations/` |
+| API Configuration | Route/middleware config | `config/`, `routes/` |
+| Middleware/Interceptor | Cross-cutting concerns | `middleware/`, `interceptor/` |
+
+### Task Checklist Table Format
+
+| Task ID | Module | Description | Target Files | API Endpoint | DB Migration | Dependencies | Status |
+|---------|--------|-------------|--------------|--------------|--------------|--------------|--------|
+| BE-001 | User | Define User entity | `entity/User.java` | - | V001__create_user.sql | - | ⏳ Pending |
+| BE-002 | User | Create UserRepository | `repository/UserRepository.java` | - | - | BE-001 | ⏳ Pending |
+| BE-003 | Auth | Login endpoint | `controller/AuthController.java` | POST /auth/login | - | BE-002 | ⏳ Pending |
+
+> Status: ⏳ Pending / 🔄 In Progress / ✅ Complete / 🚫 Blocked
+
+**Checkpoint A: Present task checklist to user for confirmation before proceeding.**
+
+## Step 4: Task-by-Task Implementation
+
+Execute tasks in dependency order.
+
+### Implementation Principles
+
+- Follow design document file paths, naming, and structure exactly
+- Use actual framework syntax from techs knowledge (not generic pseudo-code)
+- Follow conventions-data.md for ORM patterns and migration naming
+- Reuse existing code where possible (use Grep to search)
+- Directly write code based on design blueprint (no template filling for source code)
+
+### Per-Task Workflow
+
+1. **Mark task as 🔄 In Progress**
+2. **Implement the code** following design specification
+3. **Run local checks** (Step 5)
+4. **Update status to ✅ Complete** if checks pass
+5. **Record deviations** if implementation differs from design
+
+### When Design Issues Found
+
+- Stop current task
+- Describe issue clearly to user
+- Wait for user decision: return to design phase OR proceed with documented deviation
+
+## Step 5: Local Checks
+
+After completing each task, run quality checks:
+
+### Check Matrix
+
+| Check | Command Example | When Required |
+|-------|-----------------|---------------|
+| **Compile** | `mvn compile` / `gradle build` / `go build` | After code changes |
+| **Lint** | `mvn checkstyle:check` / `golangci-lint run` | After code changes |
+| **Unit Tests** | `mvn test -Dtest=XxxTest` / `go test ./...` | When testable logic added |
+| **API Smoke Test** | Start service, `curl http://localhost:8080/health` | After controller changes |
+
+### Check Failure Handling
+
+- Fix issues before marking task complete
+- For complex issues, record in task file "Pending Issues" section
+- Do NOT proceed to next task until current task passes checks
+
+### Environment Diagnostics
+
+When task is blocked (compile fail, test fail, env issue):
+
+1. **Check logs**: `docker logs [container] --tail 100` or process output
+2. **Verify services**: `docker ps` / `docker compose ps`
+3. **Check environment**: `.env` variables, database connectivity
+4. **Record diagnosis**: symptom → investigation steps → root cause → resolution
+
+## Step 6: Record Deviations
+
+If implementation differs from design, record in task file "Deviation Log" section:
+
+```markdown
+### Deviation Log
+
+| Task ID | Design Spec | Actual Implementation | Reason |
+|---------|-------------|----------------------|--------|
+| BE-003 | Use JWT library A | Used JWT library B | Library A has security vulnerability |
+```
+
+## Step 7: Handle Technical Debt
+
+If accepting suboptimal solutions, write to tech-debt directory:
+
+**Path**: `speccrew-workspace/iterations/{number}-{type}-{name}/tech-debt/[module]-tech-debt.md`
+
+Use the unified tech_debt document template defined in the workspace document templates configuration.
+
+## Step 8: Completion Notification
+
+When all tasks complete, update task record and notify user:
+
+```
+Backend Development Complete: {module-name}
+Platform: {platform_id}
+
+Tasks Completed: {X}
+├── ✅ Complete: {count}
+├── 🚫 Blocked: {count}
+└── Deviations: {count}
+
+API Endpoints:
+├── Implemented: {count} endpoints
+└── Status: See task record for details
+
+Database Changes:
+├── New Tables: {count}
+├── Modified Tables: {count}
+└── Migrations: {count}
+
+Technical Debt: {count} items (see tech-debt/)
+Task Record: speccrew-workspace/iterations/{number}-{type}-{name}/04.development/{platform_id}/[module]-task.md
+
+Ready for testing phase.
+```
+
+# Key Rules
+
+| Rule | Description |
+|------|-------------|
+| **Blueprint-Driven** | Implement directly from system design, no template filling for source code |
+| **Actual Framework Syntax** | Use real framework annotations/syntax from techs knowledge |
+| **API Contract is READ-ONLY** | Do NOT modify API Contract; report issues if found |
+| **Checkpoint A Required** | Must confirm task list with user before implementation |
+| **Per-Task Quality Gates** | Each task must pass local checks before proceeding |
+| **Deviation Recording** | ALL deviations from design must be documented |
+| **Tech Debt Tracking** | Suboptimal solutions written to tech-debt/ directory |
+
+# 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 design documents and techs knowledge loaded before implementation
+- [ ] Task record file created with complete checklist
+- [ ] Checkpoint A passed: task list confirmed with user
+- [ ] Each task marked in progress before coding
+- [ ] Local checks run after each task (compile/lint/test/smoke)
+- [ ] Code follows conventions-data.md ORM patterns
+- [ ] Database migrations follow naming conventions
+- [ ] API endpoints match API Contract specifications
+- [ ] All deviations recorded in task file
+- [ ] Technical debt written to tech-debt/ directory (if any)
+- [ ] Task record status updated to complete
+- [ ] All Mermaid diagrams follow compatibility guidelines

package/.speccrew/skills/speccrew-dev-backend/templates/TASK-RECORD-TEMPLATE.md

@@ -0,0 +1,118 @@
+# Backend Development Task Record - [Module Name]
+
+> Based on design document: [Link to 03.system-design/{platform_id}/[module]-design.md]  
+> Platform: {platform_id}  
+> Created: [Date]
+
+---
+
+## Task Checklist
+
+| Task ID | Module | Description | Target Files | API Endpoint | DB Migration | Dependencies | Status |
+|---------|--------|-------------|--------------|--------------|--------------|--------------|--------|
+| BE-001 | [Module] | [Description] | `src/...` | - | V001__xxx.sql | - | ⏳ Pending |
+| BE-002 | [Module] | [Description] | `src/...` | POST /api/xxx | - | BE-001 | ⏳ Pending |
+
+> Status: ⏳ Pending / 🔄 In Progress / ✅ Complete / 🚫 Blocked
+
+---
+
+## API Endpoint Tracking
+
+| Method | Endpoint | Controller | Service | Repository | Status | Notes |
+|--------|----------|------------|---------|------------|--------|-------|
+| POST | /api/auth/login | AuthController | AuthService | UserRepository | ⏳ Pending | - |
+| GET | /api/users/:id | UserController | UserService | UserRepository | ⏳ Pending | - |
+
+> Track implementation status of each API endpoint from API Contract.
+
+---
+
+## Database Migration Log
+
+| Migration ID | Description | Tables Created | Tables Modified | Status |
+|--------------|-------------|----------------|-----------------|--------|
+| V001 | Create user table | users | - | ⏳ Pending |
+| V002 | Add email column | - | users | ⏳ Pending |
+
+> Track all database schema changes and migration file status.
+
+---
+
+## Progress Summary
+
+### Completed Tasks
+
+- [No completed tasks yet]
+
+### In Progress
+
+- [No tasks in progress]
+
+### Blocked Tasks
+
+| Task ID | Blocker | Blocking Since | Resolution Plan |
+|---------|---------|----------------|-----------------|
+| - | - | - | - |
+
+---
+
+## Deviation Log
+
+| Task ID | Design Specification | Actual Implementation | Reason |
+|---------|---------------------|----------------------|--------|
+| - | - | - | - |
+
+> Record ALL deviations from design documents. If no deviations, write "None".
+
+---
+
+## Pending Issues
+
+| Issue | Severity | Affected Tasks | Resolution | Status |
+|-------|----------|----------------|------------|--------|
+| - | - | - | - | - |
+
+> Severity: 🔴 High / 🟡 Medium / 🟢 Low  
+> Status: ⏳ Unresolved / 🔄 Investigating / ✅ Resolved
+
+---
+
+## Technical Debt Recorded
+
+| Debt ID | Description | File | Tech Debt Document |
+|---------|-------------|------|-------------------|
+| - | - | - | - |
+
+> If technical debt was created during implementation, record reference here.  
+> Tech debt files are stored in: `iterations/{number}-{type}-{name}/tech-debt/`
+
+---
+
+## Local Checks Log
+
+### BE-001 Checks
+
+| Check | Command | Result | Notes |
+|-------|---------|--------|-------|
+| Compile | `mvn compile` | ⏳ Pending | - |
+| Lint | `mvn checkstyle:check` | ⏳ Pending | - |
+| Unit Test | `mvn test -Dtest=XxxTest` | ⏳ Pending | - |
+
+> Update check results as tasks are completed.  
+> Result: ⏳ Pending / ✅ Pass / ❌ Fail
+
+---
+
+## Completion Status
+
+- Overall Progress: `0 / {total} tasks complete`
+- Deviations: `0`
+- Technical Debt Items: `0`
+- Status: ⏳ In Progress / ✅ Complete / 🚫 Blocked
+
+---
+
+## Notes
+
+[Any additional notes or context about the implementation]