speccrew 0.7.74 → 0.7.75

package/.speccrew/skills/speccrew-dev-mobile/SKILL.md

@@ -14,297 +14,5 @@ tools: Bash, Edit, Write, Glob, Grep, Read
 
 <!-- @agentflow: SKILL.xml -->
 
-> **REQUIRED**: Before executing this workflow, read the XML workflow specification: `speccrew-workspace/docs/rules/agentflow-spec.md`
-
----
-
-## Workflow
-
-### Absolute Constraints
-
-> **These rules apply to Task Record document generation. Violation = task failure.**
-
-1. **FORBIDDEN: `create_file` for Task Record** — NEVER use `create_file` to write the Task Record document. It MUST be created by copying the template then filling sections with `search_replace`. `create_file` produces truncated output on large files.
-
-2. **FORBIDDEN: Full-file rewrite** — NEVER replace the entire Task Record content in a single operation. Always use targeted `search_replace` on specific sections.
-
-3. **MANDATORY: Template-first workflow** — Copy template MUST execute before fill sections. Skipping copy and writing content directly is FORBIDDEN.
-
-4. **CLARIFICATION: Source code is NOT template-filled** — Actual source code files are written directly based on design blueprints. The template-fill workflow applies ONLY to the Task Record document.
-
-## Step 1: Read Design Documents
-
-**Input**: Single module design document path `design_doc_path` (provided by upstream system-developer agent).
-
-Read in order:
-
-1. **Module design document**: `design_doc_path` (single module design document)
-2. **API Contract**: `speccrew-workspace/iterations/{iteration}/03.api-contract/{feature-name}-api-contract.md`
-3. **Task record template**: `speccrew-dev-mobile/templates/TASK-RECORD-TEMPLATE.md`
-
-## Step 2: Read Techs Knowledge
-
-Read platform-specific development conventions:
-
-| Document | Path | Purpose |
-|----------|------|---------|
-| conventions-dev.md | `knowledges/techs/{platform_id}/conventions-dev.md` | Code style, naming, patterns |
-| architecture.md | `knowledges/techs/{platform_id}/architecture.md` | Layer structure, state management |
-| tech-stack.md | `knowledges/techs/{platform_id}/tech-stack.md` | Framework version, dependencies |
-
-### Platform-Specific Patterns
-
-**Flutter:**
-- Widget patterns (StatelessWidget vs StatefulWidget)
-- State management (Provider, Bloc, Riverpod)
-- Navigation (GoRouter, Navigator)
-- Platform channels for native integration
-
-**React Native:**
-- Component patterns (Functional components with Hooks)
-- State management (Redux, MobX, Zustand)
-- Navigation (React Navigation)
-- Native modules bridge
-
-## Step 3: Extract Task List
-
-Parse module design documents to extract all implementation tasks.
-
-### Mobile-Specific Task Types
-
-| Task Type | Description | Example |
-|-----------|-------------|---------|
-| Screen/Page | Full screen UI implementation | LoginScreen, ProductDetailPage |
-| Widget/Component | Reusable UI components | ProductCard, SearchBar |
-| Navigation flow | Route configuration | GoRouter config, Stack navigator |
-| State management | Store/provider setup | CartBloc, UserStore |
-| API service | HTTP client integration | ProductService, AuthApi |
-| Local storage | Persistence layer | Hive box, SQLite schema |
-| Platform channel | Native module integration | BiometricAuth, CameraAccess |
-| Asset management | Images, fonts, icons | pubspec.yaml, asset bundling |
-
-### Task ID Prefix
-
-Use `MB-001`, `MB-002`, etc. for mobile tasks.
-
-### Task Checklist Table
-
-```markdown
-| Task ID | Module | Description | Target Files | Platform Specific | Offline Support | Dependencies | Status |
-|---------|--------|-------------|--------------|-------------------|-----------------|--------------|--------|
-| MB-001 | Auth | LoginScreen implementation | lib/screens/auth/ | iOS/Android | Yes | - | ⏳ Pending |
-| MB-002 | Auth | BiometricAuth channel | lib/channels/ | iOS (Face ID) / Android (Biometric) | Yes | MB-001 | ⏳ Pending |
-```
-
-**Status Values**: ⏳ Pending | 🔄 In Progress | ✅ Complete | 🚫 Blocked
-
-**Proceed directly to implementation — no user confirmation required.**
-
-## Step 4: Create Task Record File
-
-Before writing code, create task record file using template-fill workflow:
-
-**Path**: `speccrew-workspace/iterations/{iteration}/04.development/{platform_id}/{module}-task.md`
-
-### 4a Copy Template to Task Record Path
-
-1. **Read the template file**: `speccrew-dev-mobile/templates/TASK-RECORD-TEMPLATE.md`
-2. **Replace top-level placeholders** (module name, feature name, platform ID, iteration info)
-3. **Create the document** using `create_file`:
-   - Target path: `speccrew-workspace/iterations/{iteration}/04.development/{platform_id}/{module}-task.md`
-   - Content: Template with top-level placeholders replaced
-4. **Verify**: Document has complete section structure ready for filling
-
-### 4b Fill Task Record Sections Using search_replace
-
-Fill each section with task checklist and design metadata extracted from input documents.
-
-> ⚠️ **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**
-
-## Step 5: Execute Task by Task
-
-Implement tasks sequentially, following dependencies.
-
-### Implementation Principles
-
-1. **Follow Design Blueprint**: Strictly follow file paths, naming, structure from design documents
-2. **Direct Code Writing**: Write actual code directly according to design (no template filling for source code)
-3. **Reuse Existing Code**: Use Glob/Grep to find existing widgets/stores before creating new ones
-4. **Platform Conventions**: Follow techs knowledge for naming, patterns, directory structure
-5. **Cross-Platform Consideration**: Handle iOS/Android differences where specified
-
-### Local Checks (After Each Task)
-
-Before marking task complete, run these checks:
-
-| Check | Flutter Command | React Native Command |
-|-------|-----------------|---------------------|
-| Static analysis | `flutter analyze` | `npx react-native lint` |
-| Build verification | `flutter build [ios/android]` | `npx react-native build-ios/build-android` |
-| Unit tests | `flutter test` | `npm test` |
-| Quick verify | App launches on simulator without crash | App launches on emulator without crash |
-
-**Check Failure Handling:**
-- Fix issues before marking task complete
-- Complex issues: record in task file "Known Issues" section
-- Design issues: stop and describe problem to user
-
-### Blocked Task Diagnosis
-
-When task is blocked (build failure, test failure, environment issues):
-
-1. **Check Logs**
-   - Flutter: `flutter logs` or IDE debug console
-   - React Native: Metro bundler output, `adb logcat` (Android), Xcode console (iOS)
-
-2. **Verify Dependencies**
-   - Flutter: `flutter pub get`, check `pubspec.yaml`
-   - React Native: `npm install`, check `package.json`
-
-3. **Platform-Specific Issues**
-   - iOS: Check Xcode build settings, CocoaPods
-   - Android: Check Gradle config, SDK versions
-
-4. **Record Diagnosis**
-   - In task file: Symptom → Investigation Steps → Root Cause → Solution
-
-## Step 6: Record Deviations
-
-If actual implementation differs from design, record in task file:
-
-```markdown
-### Deviation Notes
-- MB-003: Originally designed with Provider, switched to Riverpod due to [reason]
-- MB-005: Added iOS-specific permission handling not in original design
-```
-
-## Step 7: Record Technical Debt
-
-If technical debt identified during implementation:
-
-**Path**: `speccrew-workspace/iterations/{iteration}/tech-debt/{feature-name}-tech-debt.md`
-
-Common mobile technical debts:
-- Platform-specific workarounds
-- Temporary offline sync solutions
-- Missing error handling for edge cases
-- Deferred accessibility features
-- Incomplete test coverage
-
-## Step 8: Completion Notification
-
-After all tasks complete, update task record and notify user:
-
-```
-Mobile Development Complete:
-- Tasks implemented: [X]
-- Deviation records: [Y] (see task file)
-- Technical debt records: [Z] (see tech-debt file)
-- Task record: speccrew-workspace/iterations/{iteration}/04.development/{platform_id}/{module}-task.md
-
-Ready for QA Agent acceptance testing.
-```
-
-## Task Completion Report
-
-At the end of Step 8 (or if the skill fails at any point), output a structured Task Completion Report:
-
-### Success Report
-
-```
-## Task Completion Report
-- **Status**: SUCCESS
-- **Task ID**: {task_id from dispatch context}
-- **Platform**: {platform_id}
-- **Module**: {module_name}
-- **Output Files**:
-  - {file_path_1}
-  - {file_path_2}
-  - ...
-- **Summary**: Mobile module {module_name} implemented with {X} tasks completed
-```
-
-### Failure Report
-
-If the skill fails at any step:
-
-```
-## Task Completion Report
-- **Status**: FAILED
-- **Task ID**: {task_id from dispatch context}
-- **Platform**: {platform_id}
-- **Module**: {module_name}
-- **Output Files**: {list of partially generated files, or "None"}
-- **Summary**: {one-line description of what was attempted}
-- **Error**: {detailed error description}
-- **Error Category**: {DEPENDENCY_MISSING | BUILD_FAILURE | VALIDATION_ERROR | RUNTIME_ERROR | BLOCKED}
-- **Partial Outputs**: {list of files that were generated before failure, or "None"}
-- **Recovery Hint**: {suggestion for how to resolve and retry}
-```
-
-**Error Category Definitions**:
-- `DEPENDENCY_MISSING`: Required Flutter/Dart or npm dependency not available
-- `BUILD_FAILURE`: Flutter build error, Gradle/Xcode compilation failure
-- `VALIDATION_ERROR`: Static analysis error (`flutter analyze`), test failure
-- `RUNTIME_ERROR`: App crash on simulator/emulator, runtime exception
-- `BLOCKED`: Blocked by external dependency, native module issue, or unresolved design issue
-
-## OUTPUT EFFICIENCY RULES
-
-When executing this skill:
-
-1. **Direct-to-File Output**: All implementation code, task records, and helper scripts MUST be written directly to output files
-2. **Minimal Conversation Output**: Only output:
-   - Block execution announcements (1 line each): `"[Block XX] Implementing..."`
-   - Error messages requiring attention
-   - Task Completion Report (final summary)
-3. **FORBIDDEN in conversation**:
-   - ❌ Full source code blocks or file contents
-   - ❌ Complete implementation listings
-   - ❌ Large configuration file dumps
-   - ❌ Architecture diagrams displayed in chat
-   - ❌ API endpoint listings longer than 3 lines
-4. **Rationale**: Workers run in batch mode (up to 6 concurrent). Displaying code content in conversation wastes context window and provides no value since content goes to files anyway.
-
-## ABORT CONDITIONS
-
-When script execution or build/compile fails:
-
-1. **STOP immediately** — Report: Task ID, error message, failed command
-2. **FORBIDDEN responses on failure**:
-   - ❌ DO NOT provide A/B/C alternative options
-   - ❌ DO NOT suggest "skip this step and continue"
-   - ❌ DO NOT run ad-hoc PowerShell/Bash commands as workaround
-   - ❌ DO NOT create temporary scripts to work around the issue
-3. **ONLY correct response**: Report the failure in Task Completion Report with status FAILED and error details
-
-# Key Rules
-
-| Rule | Description |
-|------|-------------|
-| **Direct Implementation** | Write code directly according to design documents, NOT template filling |
-| **Platform-Specific Handling** | Properly handle iOS/Android differences, permissions, native integrations |
-| **Offline-First Consideration** | Consider offline patterns where applicable |
-| **API Contract READ-ONLY** | API Contract is reference only - do not modify |
-| **Status Markers Consistent** | Use same markers as design: [EXISTING], [MODIFIED], [NEW] |
-| **Follow Techs Conventions** | Naming, directory structure, patterns must follow techs knowledge |
-| **Tech Debt to Unified Path** | Write technical debt to `iterations/{iter}/tech-debt/` directory |
-
-# Checklist
-
-- [ ] Design document loaded (single module design_doc_path)
-- [ ] Techs knowledge loaded (conventions-dev, architecture, tech-stack)
-- [ ] Task record file created
-- [ ] All design tasks extracted to checklist
-- [ ] Each task has local checks passed (analyze/build/test/quick verify)
-- [ ] Code follows architecture layer conventions
-- [ ] Naming follows conventions-dev.md
-- [ ] Platform-specific features properly handled
-- [ ] Navigation flow matches design
-- [ ] All deviations recorded
-- [ ] Technical debt written to `iterations/{iter}/tech-debt/`
-- [ ] Task record status updated to complete
-- [ ] Task list extracted and recorded in task file
+> **REQUIRED**: Before executing this workflow, read the XML workflow specification: speccrew-workspace/docs/rules/agentflow-spec.md
+> Then read and execute the XML workflow in SKILL.xml block-by-block as the authoritative execution plan.

package/.speccrew/skills/speccrew-dev-review-backend/SKILL.md

@@ -8,213 +8,11 @@ tools: Read, Glob, Grep
 
 - When speccrew-system-developer dispatches backend code review for a completed module
 - When user requests "Review this backend module's implementation"
-- When user asks "Check if backend code matches design"
 - When incremental review is needed after partial backend implementation
 
-# Input Parameters
-
-| Parameter | Required | Description |
-|-----------|----------|-------------|
-| `design_doc_path` | Yes | Path to backend module design document |
-| `implementation_report_path` | Yes | Path to backend development report |
-| `source_root` | Yes | Root directory of backend source code |
-| `platform_id` | Yes | Backend platform (backend-spring, backend-nodejs) |
-| `api_contract_path` | No | Path to API contract file for endpoint validation |
-| `task_id` | Yes | Task identifier from dispatch context |
-| `previous_review_path` | No | Path to previous review report for incremental review |
-
 ## AgentFlow Definition
 
 <!-- @agentflow: SKILL.xml -->
 
-> **REQUIRED**: Before executing this workflow, read the XML workflow specification: `speccrew-workspace/docs/rules/agentflow-spec.md`
-
----
-
-## Workflow
-
-### Absolute Constraints
-
-> **Violation = review failure.**
-
-1. **READ-ONLY OPERATION** — NEVER modify source code files. Only read and report findings.
-2. **FORBIDDEN: Code fixes** — Do NOT attempt to fix issues. Only document them.
-3. **MANDATORY: Actionable output** — PARTIAL/FAIL results MUST include specific "Re-dispatch Guidance".
-4. **INCREMENTAL REVIEW SUPPORT** — If `previous_review_path` provided, skip items already marked as passed.
-
-## Step 1: Load Documents
-
-### 1.1 Validate Inputs
-
-Verify all required parameters provided. If any missing → Report error, stop.
-
-### 1.2 Read Design Document
-
-Extract from backend design document:
-
-| Section | Information to Extract |
-|---------|------------------------|
-| Module Overview | Module name, responsibilities |
-| File Structure | Required files (DO, VO, Mapper, Service, Controller, Convert, Enums) |
-| Class Specifications | Class names, inheritance requirements, annotations |
-| API Endpoints | Endpoint definitions, HTTP methods, paths |
-| Business Logic | Service methods, transaction requirements |
-
-### 1.3 Read Implementation Report
-
-Extract: Completed Files, Implementation Status, Known Issues.
-
-### 1.4 Read API Contract (if provided)
-
-Extract for validation: Endpoint Definitions, Request/Response Schemas, HTTP Methods, Error Codes.
-
-## Step 2: File Completeness Check
-
-### 2.1 Build Expected File List
-
-Backend file categories:
-
-| Category | Pattern | Example |
-|----------|---------|---------|
-| Enums | `enums/*.java` | `enums/ErrorCodeConstants.java` |
-| DO | `dal/dataobject/**/*.java` | `dal/dataobject/employee/EmployeeDO.java` |
-| VO | `controller/admin/vo/**/*.java` | `controller/admin/vo/EmployeeRespVO.java` |
-| Mapper | `dal/mapper/**/*.java` | `dal/mapper/employee/EmployeeMapper.java` |
-| Service | `service/**/*.java` | `service/employee/EmployeeService.java` |
-| Controller | `controller/admin/**/*.java` | `controller/admin/employee/EmployeeController.java` |
-| Convert | `convert/**/*.java` | `convert/employee/EmployeeConvert.java` |
-
-### 2.2 Scan Actual Files
-
-Use `Glob` to scan `source_root` for implemented files.
-
-### 2.3 Calculate Completeness
-
-Generate completeness matrix and percentage: `completeness_pct = (created / required) * 100`
-
-## Step 3: Backend-Specific Compliance Check
-
-### 3.1 DO/VO/DTO Compliance
-
-| Check | Rule | Severity |
-|-------|------|----------|
-| Base Class | Must extend correct base class (e.g., `TenantBaseDO`) | ERROR |
-| @TableName | Must have `@TableName` with correct table name | ERROR |
-| @Schema | Must have `@Schema` for documentation | WARN |
-| Validation | Required fields must have `@NotNull` or similar | ERROR |
-| Desensitization | Sensitive fields must have desensitization | ERROR |
-
-### 3.2 Service Layer Check
-
-| Check | Rule | Severity |
-|-------|------|----------|
-| Interface | Must have Service interface and implementation separation | WARN |
-| @Service | Implementation must have `@Service` annotation | ERROR |
-| @Transactional | DB write methods must have `@Transactional` | ERROR |
-| Method Coverage | All methods in design must be implemented | ERROR |
-| Data Permission | Must check data permissions where required | ERROR |
-
-### 3.3 Controller Layer Check
-
-| Check | Rule | Severity |
-|-------|------|----------|
-| @RestController | Must have `@RestController` annotation | ERROR |
-| @RequestMapping | Must have base `@RequestMapping` annotation | ERROR |
-| @Operation | Endpoints should have `@Operation` for documentation | WARN |
-| @PreAuthorize | Must have permission annotations where required | ERROR |
-| @Valid | Request VO parameters must have `@Valid` | ERROR |
-
-### 3.4 Database Mapping Validation
-
-- Verify Entity fields match design document
-- Check MyBatis XML mappers exist alongside Mapper interfaces
-- Validate Lombok `@Data` or similar on DO/VO classes
-
-## Step 4: API Consistency Check
-
-If `api_contract_path` provided:
-
-| Check | Description | Severity |
-|-------|-------------|----------|
-| Endpoint Coverage | All contract endpoints exist in Controller | ERROR |
-| HTTP Method | Methods match contract | ERROR |
-| Path Match | URL paths match contract exactly | ERROR |
-| VO Fields | All contract fields present in VO | ERROR |
-| Field Types | Data types match contract | ERROR |
-
-## Step 5: Generate Review Report
-
-### 5.1 Determine Result
-
-| Result | Criteria |
-|--------|----------|
-| **PASS** | 100% files created, 0 ERROR-level issues |
-| **PARTIAL** | 70-99% files created, or non-critical ERROR issues |
-| **FAIL** | <70% files created, or critical blockers present |
-
-### 5.2 Write Report
-
-Generate report at: `speccrew-workspace/iterations/{number}-{type}-{name}/04.development/{platform_id}/[module]-review-report.md`
-
-Use template from `templates/REVIEW-REPORT-TEMPLATE.md`.
-
-## Step 6: Task Completion Report
-
-### Success
-
-```markdown
-## Task Completion Report
-- **Status**: SUCCESS
-- **Task ID**: review-{original_task_id}
-- **Platform**: {platform_id}
-- **Module**: {module_name}
-- **Output Files**: {review_report_path}
-- **Summary**: Review {result}: {completed}/{total} files, {error_count} errors
-```
-
-### Failure
-
-```markdown
-## Task Completion Report
-- **Status**: FAILED
-- **Task ID**: review-{original_task_id}
-- **Platform**: {platform_id}
-- **Module**: {module_name}
-- **Output Files**: None
-- **Summary**: Review failed during {step}
-- **Error**: {detailed error description}
-- **Error Category**: DEPENDENCY_MISSING | VALIDATION_ERROR | BLOCKED
-- **Recovery Hint**: {suggestion}
-```
-
-# Severity Levels
-
-| Level | Definition | Action Required |
-|-------|------------|-----------------|
-| **CRITICAL** | Security vulnerability or data integrity issue | Must fix immediately |
-| **ERROR** | Blocking functionality or violating core requirements | Must fix before PASS |
-| **WARN** | Best practice violation or missing documentation | Should fix |
-| **LOW** | Code style or minor optimization suggestion | Optional |
-
-# Key Rules
-
-| Rule | Description |
-|------|-------------|
-| **Read-Only** | NEVER modify any source code |
-| **Blueprint-Driven** | Validate against design document specifications |
-| **Actionable Output** | PARTIAL/FAIL must include specific fix guidance |
-| **Incremental Support** | Skip already-passed items when previous review provided |
-| **Completeness First** | File existence is primary check before content validation |
-
-# Checklist
-
-- [ ] All required inputs validated
-- [ ] Design document loaded and parsed
-- [ ] File completeness check completed with category breakdown
-- [ ] DO classes checked for base class and annotations
-- [ ] VO classes checked for validation and desensitization
-- [ ] Service classes checked for @Transactional and permissions
-- [ ] Controller classes checked for annotations and endpoints
-- [ ] API contract validated against implementation (if provided)
-- [ ] Review report written with clear verdict
-- [ ] Re-dispatch guidance provided for PARTIAL/FAIL
+> **REQUIRED**: Before executing this workflow, read the XML workflow specification: speccrew-workspace/docs/rules/agentflow-spec.md
+> Then read and execute the XML workflow in SKILL.xml block-by-block as the authoritative execution plan.

package/.speccrew/skills/speccrew-dev-review-desktop/SKILL.md

@@ -8,182 +8,11 @@ tools: Read, Glob, Grep
 
 - When speccrew-system-developer dispatches desktop code review for a completed module
 - When user requests "Review this desktop module's implementation"
-- When user asks "Check if desktop code matches design"
 - When incremental review is needed after partial desktop implementation
 
-# Input Parameters
-
-| Parameter | Required | Description |
-|-----------|----------|-------------|
-| `design_doc_path` | Yes | Path to desktop module design document |
-| `implementation_report_path` | Yes | Path to desktop development report |
-| `source_root` | Yes | Root directory of desktop source code |
-| `platform_id` | Yes | Desktop platform (desktop-tauri, desktop-electron) |
-| `api_contract_path` | No | Path to API contract file |
-| `task_id` | Yes | Task identifier from dispatch context |
-| `previous_review_path` | No | Path to previous review report |
-
 ## AgentFlow Definition
 
 <!-- @agentflow: SKILL.xml -->
 
-> **REQUIRED**: Before executing this workflow, read the XML workflow specification: `speccrew-workspace/docs/rules/agentflow-spec.md`
-
----
-
-## Workflow
-
-### Absolute Constraints
-
-> **Violation = review failure.**
-
-1. **READ-ONLY OPERATION** — NEVER modify source code files.
-2. **FORBIDDEN: Code fixes** — Do NOT attempt to fix issues. Only document them.
-3. **MANDATORY: Actionable output** — PARTIAL/FAIL results MUST include specific "Re-dispatch Guidance".
-4. **INCREMENTAL REVIEW SUPPORT** — Skip items already marked as passed in previous review.
-
-## Step 1: Load Documents
-
-### 1.1 Validate Inputs
-
-Verify all required parameters provided. If any missing → Report error, stop.
-
-### 1.2 Read Design Document
-
-Extract: Module Overview, Process Architecture, IPC Contracts, Native Integration points.
-
-### 1.3 Read Implementation Report
-
-Extract: Completed Files, Implementation Status, Known Issues.
-
-### 1.4 Read API Contract (if provided)
-
-Extract API endpoints for validation against desktop API calls.
-
-## Step 2: File Completeness Check
-
-### 2.1 Build Expected File List
-
-Desktop file categories:
-
-| Category | Pattern | Example |
-|----------|---------|---------|
-| Main Process | `src-tauri/src/**/*.rs` or `main/**/*` | `src-tauri/src/main.rs` |
-| Renderer | `src/**/*` (frontend files) | `src/App.vue` |
-| Preload | `preload/**/*` or `src-tauri/src/preload.rs` | `preload/index.ts` |
-| IPC Handlers | `src-tauri/src/commands/**/*.rs` | `commands/file.rs` |
-| Native Modules | `native/**/*` | `native/fileSystem.ts` |
-
-### 2.2 Scan Actual Files
-
-Use `Glob` to scan `source_root` for implemented files.
-
-### 2.3 Calculate Completeness
-
-Generate completeness matrix and percentage.
-
-## Step 3: Desktop-Specific Compliance Check
-
-### 3.1 Process Separation Validation
-
-| Check | Rule | Severity |
-|-------|------|----------|
-| Main/Renderer Separation | Business logic in main process only | CRITICAL |
-| No Node in Renderer | Renderer has no direct Node.js access | CRITICAL |
-| Context Isolation | contextIsolation enabled | CRITICAL |
-
-### 3.2 IPC Channel Consistency
-
-| Check | Rule | Severity |
-|-------|------|----------|
-| Channel Naming | IPC channels follow naming convention | ERROR |
-| Type Safety | IPC payloads properly typed | ERROR |
-| Channel Registration | All channels registered in preload | ERROR |
-| Bidirectional Safety | No unsafe IPC patterns | CRITICAL |
-
-### 3.3 Security Isolation
-
-| Check | Rule | Severity |
-|-------|------|----------|
-| contextBridge | Uses contextBridge for API exposure | CRITICAL |
-| Preload Script | Preload script properly configured | CRITICAL |
-| CSP Headers | Content Security Policy configured | ERROR |
-| Remote Content | No unsafe remote content loading | CRITICAL |
-
-### 3.4 Native Integration Check
-
-| Check | Rule | Severity |
-|-------|------|----------|
-| File System | File operations in main process only | CRITICAL |
-| System Notifications | Notifications properly implemented | WARN |
-| Native Menus | Menu structure matches design | ERROR |
-| System Tray | Tray implementation if required | ERROR |
-
-### 3.5 Packaging Configuration
-
-| Check | Rule | Severity |
-|-------|------|----------|
-| Build Config | Build configuration complete | ERROR |
-| Assets | Required assets included | ERROR |
-| Signing | Code signing configured (if required) | WARN |
-| Auto-Update | Auto-update mechanism (if required) | WARN |
-
-## Step 4: Generate Review Report
-
-### 4.1 Determine Result
-
-| Result | Criteria |
-|--------|----------|
-| **PASS** | 100% files created, 0 ERROR-level issues |
-| **PARTIAL** | 70-99% files created, or non-critical ERROR issues |
-| **FAIL** | <70% files created, or critical blockers present |
-
-### 4.2 Write Report
-
-Generate report at: `speccrew-workspace/iterations/{number}-{type}-{name}/04.development/{platform_id}/[module]-review-report.md`
-
-Use template from `templates/REVIEW-REPORT-TEMPLATE.md`.
-
-## Step 5: Task Completion Report
-
-```markdown
-## Task Completion Report
-- **Status**: SUCCESS
-- **Task ID**: review-{original_task_id}
-- **Platform**: {platform_id}
-- **Module**: {module_name}
-- **Output Files**: {review_report_path}
-- **Summary**: Review {result}: {completed}/{total} files, {error_count} errors
-```
-
-# Severity Levels
-
-| Level | Definition | Action Required |
-|-------|------------|-----------------|
-| **CRITICAL** | Security vulnerability or sandbox escape risk | Must fix immediately |
-| **ERROR** | Blocking functionality or violating core requirements | Must fix before PASS |
-| **WARN** | Best practice violation or missing documentation | Should fix |
-| **LOW** | Code style or minor optimization suggestion | Optional |
-
-# Key Rules
-
-| Rule | Description |
-|------|-------------|
-| **Read-Only** | NEVER modify any source code |
-| **Security First** | Desktop security is paramount - verify isolation |
-| **Blueprint-Driven** | Validate against design document specifications |
-| **Actionable Output** | PARTIAL/FAIL must include specific fix guidance |
-| **Completeness First** | File existence is primary check before content validation |
-
-# Checklist
-
-- [ ] All required inputs validated
-- [ ] Design document loaded and parsed
-- [ ] File completeness check completed
-- [ ] Main/renderer separation validated
-- [ ] IPC channels checked for consistency
-- [ ] Security isolation verified
-- [ ] Native integration checked
-- [ ] Packaging configuration validated
-- [ ] Review report written with clear verdict
-- [ ] Re-dispatch guidance provided for PARTIAL/FAIL
+> **REQUIRED**: Before executing this workflow, read the XML workflow specification: speccrew-workspace/docs/rules/agentflow-spec.md
+> Then read and execute the XML workflow in SKILL.xml block-by-block as the authoritative execution plan.