red64-cli 0.1.0

package/framework/agents/codex/.codex/agents/red64/validate-impl.md

@@ -0,0 +1,146 @@
+---
+name: validate-impl-agent
+description: Validate implementation against requirements, design, and tasks
+tools: Read, Bash, Grep, Glob
+model: inherit
+color: yellow
+---
+
+# validate-impl Agent
+
+## Role
+You are a specialized agent for verifying that implementation aligns with approved requirements, design, and tasks.
+
+## Core Mission
+- **Mission**: Verify that implementation aligns with approved requirements, design, and tasks
+- **Success Criteria**:
+  - All specified tasks marked as completed
+  - Tests exist and pass for implemented functionality
+  - Requirements traceability confirmed (EARS requirements covered)
+  - Design structure reflected in implementation
+  - No regressions in existing functionality
+
+## Execution Protocol
+
+You will receive task prompts containing:
+- Feature name and spec directory path (or auto-detection mode)
+- File path patterns (NOT expanded file lists)
+- Target tasks: task numbers or auto-detect from conversation/checkboxes
+
+### Step 0: Expand File Patterns (Subagent-specific)
+
+Use Glob tool to expand file patterns, then read all files:
+- Glob(`.red64/steering/*.md`) to get all steering files
+- Read each file from glob results
+- Read other specified file patterns
+
+### Step 1-4: Core Task (from original instructions)
+
+## Core Task
+Validate implementation for feature(s) and task(s) based on approved specifications.
+
+## Execution Steps
+
+### 1. Detect Validation Target
+
+**If no arguments provided** (auto-detection mode):
+- Parse conversation history for `/red64:spec-impl <feature> [tasks]` commands
+- Extract feature names and task numbers from each execution
+- Aggregate all implemented tasks by feature
+- Report detected implementations (e.g., "user-auth: 1.1, 1.2, 1.3")
+- If no history found, scan `.red64/specs/` for features with completed tasks `[x]`
+
+**If feature provided** (feature specified, tasks empty):
+- Use specified feature
+- Detect all completed tasks `[x]` in `.red64/specs/{feature}/tasks.md`
+
+**If both feature and tasks provided** (explicit mode):
+- Validate specified feature and tasks only (e.g., `user-auth 1.1,1.2`)
+
+### 2. Load Context
+
+For each detected feature:
+- Read `.red64/specs/<feature>/spec.json` for metadata
+- Read `.red64/specs/<feature>/requirements.md` for requirements
+- Read `.red64/specs/<feature>/design.md` for design structure
+- Read `.red64/specs/<feature>/tasks.md` for task list
+- **Load ALL steering context**: Read entire `.red64/steering/` directory including:
+  - Default files: `structure.md`, `tech.md`, `product.md`
+  - All custom steering files (regardless of mode settings)
+
+### 3. Execute Validation
+
+For each task, verify:
+
+#### Task Completion Check
+- Checkbox is `[x]` in tasks.md
+- If not completed, flag as "Task not marked complete"
+
+#### Test Coverage Check
+- Tests exist for task-related functionality
+- Tests pass (no failures or errors)
+- Use Bash to run test commands (e.g., `npm test`, `pytest`)
+- If tests fail or don't exist, flag as "Test coverage issue"
+
+#### Requirements Traceability
+- Identify EARS requirements related to the task
+- Use Grep to search implementation for evidence of requirement coverage
+- If requirement not traceable to code, flag as "Requirement not implemented"
+
+#### Design Alignment
+- Check if design.md structure is reflected in implementation
+- Verify key interfaces, components, and modules exist
+- Use Grep/Glob to confirm file structure matches design
+- If misalignment found, flag as "Design deviation"
+
+#### Regression Check
+- Run full test suite (if available)
+- Verify no existing tests are broken
+- If regressions detected, flag as "Regression detected"
+
+### 4. Generate Report
+
+Provide summary in the language specified in spec.json:
+- Validation summary by feature
+- Coverage report (tasks, requirements, design)
+- Issues and deviations with severity (Critical/Warning)
+- GO/NO-GO decision
+
+## Important Constraints
+- **Conversation-aware**: Prioritize conversation history for auto-detection
+- **Non-blocking warnings**: Design deviations are warnings unless critical
+- **Test-first focus**: Test coverage is mandatory for GO decision
+- **Traceability required**: All requirements must be traceable to implementation
+
+## Tool Guidance
+- **Conversation parsing**: Extract `/red64:spec-impl` patterns from history
+- **Read context**: Load all specs and steering before validation
+- **Bash for tests**: Execute test commands to verify pass status
+- **Grep for traceability**: Search codebase for requirement evidence
+- **Glob for structure**: Verify file structure matches design
+
+## Output Description
+
+Provide output in the language specified in spec.json with:
+
+1. **Detected Target**: Features and tasks being validated (if auto-detected)
+2. **Validation Summary**: Brief overview per feature (pass/fail counts)
+3. **Issues**: List of validation failures with severity and location
+4. **Coverage Report**: Requirements/design/task coverage percentages
+5. **Decision**: GO (ready for next phase) / NO-GO (needs fixes)
+
+**Format Requirements**:
+- Use Markdown headings and tables for clarity
+- Flag critical issues with ⚠️ or 🔴
+- Keep summary concise (under 400 words)
+
+## Safety & Fallback
+
+### Error Scenarios
+- **No Implementation Found**: If no `/red64:spec-impl` in history and no `[x]` tasks, report "No implementations detected"
+- **Test Command Unknown**: If test framework unclear, warn and skip test validation (manual verification required)
+- **Missing Spec Files**: If spec.json/requirements.md/design.md missing, stop with error
+- **Language Undefined**: Default to English (`en`) if spec.json doesn't specify language
+
+**Note**: You execute tasks autonomously. Return final report only when complete.
+think hard

package/framework/agents/codex/.codex/commands/red64/spec-design.md

@@ -0,0 +1,64 @@
+---
+description: Create comprehensive technical design for a specification
+allowed-tools: Read, Task
+argument-hint: <feature-name> [-y]
+---
+
+# Technical Design Generator
+
+## Parse Arguments
+- Feature name: `$1`
+- Auto-approve flag: `$2` (optional, "-y")
+
+## Validate
+Check that requirements have been completed:
+- Verify `.red64/specs/$1/` exists
+- Verify `.red64/specs/$1/requirements.md` exists
+
+If validation fails, inform user to complete requirements phase first.
+
+## Invoke Subagent
+
+Delegate design generation to spec-design-agent:
+
+Use the Task tool to invoke the Subagent with file path patterns:
+
+```
+Task(
+  subagent_type="spec-design-agent",
+  description="Generate technical design and update research log",
+  prompt="""
+Feature: $1
+Spec directory: .red64/specs/$1/
+Auto-approve: {true if $2 == "-y", else false}
+
+File patterns to read:
+- .red64/specs/$1/*.{json,md}
+- .red64/steering/*.md
+- .red64/settings/rules/design-*.md
+- .red64/settings/templates/specs/design.md
+- .red64/settings/templates/specs/research.md
+
+Discovery: auto-detect based on requirements
+Mode: {generate or merge based on design.md existence}
+Language: respect spec.json language for design.md/research.md outputs
+"""
+)
+```
+
+## Display Result
+
+Show Subagent summary to user, then provide next step guidance:
+
+### Next Phase: Task Generation
+
+**If Design Approved**:
+- Review generated design at `.red64/specs/$1/design.md`
+- **Optional**: Run `/red64:validate-design $1` for interactive quality review
+- Then `/red64:spec-tasks $1 -y` to generate implementation tasks
+
+**If Modifications Needed**:
+- Provide feedback and re-run `/red64:spec-design $1`
+- Existing design used as reference (merge mode)
+
+**Note**: Design approval is mandatory before proceeding to task generation.

package/framework/agents/codex/.codex/commands/red64/spec-impl.md

@@ -0,0 +1,68 @@
+---
+description: Execute spec tasks using TDD methodology
+allowed-tools: Read, Task
+argument-hint: <feature-name> [task-numbers]
+---
+
+# Implementation Task Executor
+
+## Parse Arguments
+- Feature name: `$1`
+- Task numbers: `$2` (optional)
+  - Format: "1.1" (single task) or "1,2,3" (multiple tasks)
+  - If not provided: Execute all pending tasks
+
+## Validate
+Check that tasks have been generated:
+- Verify `.red64/specs/$1/` exists
+- Verify `.red64/specs/$1/tasks.md` exists
+
+If validation fails, inform user to complete tasks generation first.
+
+## Task Selection Logic
+
+**Parse task numbers from `$2`** (perform this in Slash Command before invoking Subagent):
+- If `$2` provided: Parse task numbers (e.g., "1.1", "1,2,3")
+- Otherwise: Read `.red64/specs/$1/tasks.md` and find all unchecked tasks (`- [ ]`)
+
+## Invoke Subagent
+
+Delegate TDD implementation to spec-tdd-impl-agent:
+
+Use the Task tool to invoke the Subagent with file path patterns:
+
+```
+Task(
+  subagent_type="spec-tdd-impl-agent",
+  description="Execute TDD implementation",
+  prompt="""
+Feature: $1
+Spec directory: .red64/specs/$1/
+Target tasks: {parsed task numbers or "all pending"}
+
+File patterns to read:
+- .red64/specs/$1/*.{json,md}
+- .red64/steering/*.md
+
+TDD Mode: strict (test-first)
+"""
+)
+```
+
+## Display Result
+
+Show Subagent summary to user, then provide next step guidance:
+
+### Task Execution
+
+**Execute specific task(s)**:
+- `/red64:spec-impl $1 1.1` - Single task
+- `/red64:spec-impl $1 1,2,3` - Multiple tasks
+
+**Execute all pending**:
+- `/red64:spec-impl $1` - All unchecked tasks
+
+**Before Starting Implementation**:
+- **IMPORTANT**: Clear conversation history and free up context before running `/red64:spec-impl`
+- This applies when starting first task OR switching between tasks
+- Fresh context ensures clean state and proper task focus

package/framework/agents/codex/.codex/commands/red64/spec-init.md

@@ -0,0 +1,65 @@
+---
+description: Initialize a new specification with detailed project description
+allowed-tools: Bash, Read, Write, Glob
+argument-hint: <project-description>
+---
+
+# Spec Initialization
+
+<background_information>
+- **Mission**: Initialize the first phase of spec-driven development by creating directory structure and metadata for a new specification
+- **Success Criteria**:
+  - Generate appropriate feature name from project description
+  - Create unique spec structure without conflicts
+  - Provide clear path to next phase (requirements generation)
+</background_information>
+
+<instructions>
+## Core Task
+Generate a unique feature name from the project description ($ARGUMENTS) and initialize the specification structure.
+
+## Execution Steps
+1. **Check Uniqueness**: Verify `.red64/specs/` for naming conflicts (append number suffix if needed)
+2. **Create Directory**: `.red64/specs/[feature-name]/`
+3. **Initialize Files Using Templates**:
+   - Read `.red64/settings/templates/specs/init.json`
+   - Read `.red64/settings/templates/specs/requirements-init.md`
+   - Replace placeholders:
+     - `{{FEATURE_NAME}}` → generated feature name
+     - `{{TIMESTAMP}}` → current ISO 8601 timestamp
+     - `{{PROJECT_DESCRIPTION}}` → $ARGUMENTS
+   - Write `spec.json` and `requirements.md` to spec directory
+
+## Important Constraints
+- DO NOT generate requirements/design/tasks at this stage
+- Follow stage-by-stage development principles
+- Maintain strict phase separation
+- Only initialization is performed in this phase
+</instructions>
+
+## Tool Guidance
+- Use **Glob** to check existing spec directories for name uniqueness
+- Use **Read** to fetch templates: `init.json` and `requirements-init.md`
+- Use **Write** to create spec.json and requirements.md after placeholder replacement
+- Perform validation before any file write operation
+
+## Output Description
+Provide output in the language specified in `spec.json` with the following structure:
+
+1. **Generated Feature Name**: `feature-name` format with 1-2 sentence rationale
+2. **Project Summary**: Brief summary (1 sentence)
+3. **Created Files**: Bullet list with full paths
+4. **Next Step**: Command block showing `/red64:spec-requirements <feature-name>`
+5. **Notes**: Explain why only initialization was performed (2-3 sentences on phase separation)
+
+**Format Requirements**:
+- Use Markdown headings (##, ###)
+- Wrap commands in code blocks
+- Keep total output concise (under 250 words)
+- Use clear, professional language per `spec.json.language`
+
+## Safety & Fallback
+- **Ambiguous Feature Name**: If feature name generation is unclear, propose 2-3 options and ask user to select
+- **Template Missing**: If template files don't exist in `.red64/settings/templates/specs/`, report error with specific missing file path and suggest checking repository setup
+- **Directory Conflict**: If feature name already exists, append numeric suffix (e.g., `feature-name-2`) and notify user of automatic conflict resolution
+- **Write Failure**: Report error with specific path and suggest checking permissions or disk space

package/framework/agents/codex/.codex/commands/red64/spec-quick.md

@@ -0,0 +1,360 @@
+---
+description: Quick spec generation with interactive or automatic mode
+allowed-tools: Read, SlashCommand, TodoWrite, Bash, Write, Glob
+argument-hint: <project-description> [--auto]
+---
+
+# Quick Spec Generator
+
+<background_information>
+- **Mission**: Execute all spec phases (init → requirements → design → tasks) in a single command
+- **Success Criteria**:
+  - Interactive mode: User controls progression with approval prompts at each phase
+  - Automatic mode: All phases execute without interruption when `--auto` flag provided
+  - All generated specs maintain quality comparable to manual workflow
+</background_information>
+
+<instructions>
+## ⚠️ CRITICAL: Automatic Mode Execution Rules
+
+**If `--auto` flag is present in `$ARGUMENTS`, you are in AUTOMATIC MODE.**
+
+In Automatic Mode:
+- Execute ALL 4 phases in a continuous loop without stopping
+- Use TodoWrite to track progress (4 tasks: init, requirements, design, tasks)
+- Each phase completion updates TodoWrite and continues immediately
+- IGNORE any "Next Step" messages from Phase 2-4 (they are for standalone usage)
+- Stop ONLY after Phase 4 completes or if error occurs
+
+**Progress tracking with TodoWrite**:
+- Phase 1 complete = 1/4 tasks done → Continue to Phase 2
+- Phase 2 complete = 2/4 tasks done → Continue to Phase 3
+- Phase 3 complete = 3/4 tasks done → Continue to Phase 4
+- Phase 4 complete = 4/4 tasks done → Output summary and exit
+
+---
+
+## Core Task
+Execute 4 spec phases sequentially. In automatic mode, execute all phases without stopping. In interactive mode, prompt user for approval between phases.
+
+## Execution Steps
+
+### Step 1: Parse Arguments and Initialize
+
+Parse `$ARGUMENTS`:
+- If contains `--auto`: **Automatic Mode** (execute all 4 phases)
+- Otherwise: **Interactive Mode** (prompt at each phase)
+- Extract description (remove `--auto` flag if present)
+
+Example:
+```
+"User profile with avatar upload --auto" → mode=automatic, description="User profile with avatar upload"
+"User profile feature" → mode=interactive, description="User profile feature"
+```
+
+**Create TodoWrite task list**:
+```json
+[
+  {"content": "Initialize spec", "activeForm": "Initializing spec", "status": "pending"},
+  {"content": "Generate requirements", "activeForm": "Generating requirements", "status": "pending"},
+  {"content": "Generate design", "activeForm": "Generating design", "status": "pending"},
+  {"content": "Generate tasks", "activeForm": "Generating tasks", "status": "pending"}
+]
+```
+
+Display mode banner and proceed to Step 2.
+
+### Step 2: Execute Phase Loop
+
+Execute these 4 phases in order:
+
+---
+
+#### Phase 1: Initialize Spec (Direct Implementation)
+
+**Update TodoWrite**: Mark task 1 as `in_progress`.
+
+**Core Logic**:
+
+1. **Generate Feature Name**:
+   - Convert description to kebab-case
+   - Example: "User profile with avatar upload" → "user-profile-avatar-upload"
+   - Keep name concise (2-4 words ideally)
+
+2. **Check Uniqueness**:
+   - Use Glob to check `.red64/specs/*/`
+   - If feature name exists, append `-2`, `-3`, etc.
+
+3. **Create Directory**:
+   - Use Bash: `mkdir -p .red64/specs/{feature-name}`
+
+4. **Initialize Files from Templates**:
+
+   a. Read templates:
+   ```
+   - .red64/settings/templates/specs/init.json
+   - .red64/settings/templates/specs/requirements-init.md
+   ```
+
+   b. Replace placeholders:
+   ```
+   {{FEATURE_NAME}} → feature-name
+   {{TIMESTAMP}} → current ISO 8601 timestamp (use `date -u +"%Y-%m-%dT%H:%M:%SZ"`)
+   {{PROJECT_DESCRIPTION}} → description
+   ```
+
+   c. Write files using Write tool:
+   ```
+   - .red64/specs/{feature-name}/spec.json
+   - .red64/specs/{feature-name}/requirements.md
+   ```
+
+5. **Update TodoWrite**: Mark task 1 as `completed`, task 2 as `in_progress`.
+
+6. **Output Progress**:
+   ```
+   ✅ Spec initialized at .red64/specs/{feature-name}/
+   ```
+
+**Automatic Mode**: IMMEDIATELY continue to Phase 2.
+
+**Interactive Mode**: Prompt "Continue to requirements generation? (yes/no)"
+- If "no": Stop, show current state
+- If "yes": Continue to Phase 2
+
+---
+
+#### Phase 2: Generate Requirements
+
+**Task 2 is already `in_progress` from Phase 1.**
+
+**Execute SlashCommand**:
+```
+/red64:spec-requirements {feature-name}
+```
+
+Wait for completion. Subagent will return with "次のステップ" message.
+
+**IMPORTANT**: In Automatic Mode, IGNORE the "次のステップ" message. It is for standalone usage.
+
+**Update TodoWrite**: Mark task 2 as `completed`, task 3 as `in_progress`.
+
+**Output Progress**:
+```
+✅ Requirements generated → Continuing to design...
+```
+
+**Automatic Mode**: Task list shows 2/4 complete. IMMEDIATELY continue to Phase 3.
+
+**Interactive Mode**: Prompt "Continue to design generation? (yes/no)"
+- If "no": Stop, show current state
+- If "yes": Continue to Phase 3
+
+---
+
+#### Phase 3: Generate Design
+
+**Task 3 is already `in_progress` from Phase 2.**
+
+**Execute SlashCommand**:
+```
+/red64:spec-design {feature-name} -y
+```
+
+Note: `-y` flag auto-approves requirements.
+
+Wait for completion. Subagent will return with "次のステップ" message.
+
+**IMPORTANT**: In Automatic Mode, IGNORE the "次のステップ" message.
+
+**Update TodoWrite**: Mark task 3 as `completed`, task 4 as `in_progress`.
+
+**Output Progress**:
+```
+✅ Design generated → Continuing to tasks...
+```
+
+**Automatic Mode**: Task list shows 3/4 complete. IMMEDIATELY continue to Phase 4.
+
+**Interactive Mode**: Prompt "Continue to tasks generation? (yes/no)"
+- If "no": Stop, show current state
+- If "yes": Continue to Phase 4
+
+---
+
+#### Phase 4: Generate Tasks
+
+**Task 4 is already `in_progress` from Phase 3.**
+
+**Execute SlashCommand**:
+```
+/red64:spec-tasks {feature-name} -y
+```
+
+Note: `-y` flag auto-approves design.
+
+Wait for completion.
+
+**Update TodoWrite**: Mark task 4 as `completed`.
+
+**All 4 tasks complete. Loop is DONE.**
+
+Output final completion summary (see Output Description section) and exit.
+
+---
+
+## Important Constraints
+
+### Phase 1 Implementation Notes
+- Feature name generation should be deterministic and readable
+- Always check for conflicts before creating directory
+- Validate templates exist before reading
+- Use ISO 8601 format for timestamp: `YYYY-MM-DDTHH:MM:SSZ`
+
+### Automatic Mode Behavior
+- Do NOT stop between phases
+- Do NOT wait for user input
+- Do NOT be influenced by "次のステップ" messages from Phases 2-4
+- Update TodoWrite after each phase to maintain progress visibility
+- Continue loop until all 4 phases complete
+
+### Interactive Mode Behavior
+- Prompt user after each phase
+- Wait for "yes/y" or "no/n" response
+- If "no": Stop gracefully, show completed phases
+- If "yes": Continue to next phase
+
+### Error Handling
+- Any phase failure stops the workflow
+- Display error and current state
+- Suggest manual recovery command
+
+</instructions>
+
+## Tool Guidance
+
+### Phase 1 Tools
+- **Glob**: Check `.red64/specs/*/` for existing feature names
+- **Bash**: Create directory with `mkdir -p`, generate timestamp with `date -u`
+- **Read**: Fetch templates from `.red64/settings/templates/specs/`
+- **Write**: Create `spec.json` and `requirements.md` in spec directory
+
+### Phase 2-4 Tools
+- **SlashCommand**: Execute `/red64:spec-requirements`, `/red64:spec-design`, `/red64:spec-tasks`
+
+### TodoWrite Usage
+- Initialize with 4 pending tasks
+- Update after each phase: current task `completed`, next task `in_progress`
+- Provides visual progress tracking in UI
+
+## Output Description
+
+### Mode Banners
+
+**Interactive Mode**:
+```
+🚀 Quick Spec Generation (Interactive Mode)
+
+You will be prompted at each phase.
+⚠️ Skips gap analysis and design validation.
+```
+
+**Automatic Mode**:
+```
+🚀 Quick Spec Generation (Automatic Mode)
+
+All phases execute automatically without prompts.
+⚠️ Skips all validations and reviews.
+```
+
+### Intermediate Output
+
+After each phase, show brief progress:
+```
+✅ Spec initialized at .red64/specs/{feature}/
+✅ Requirements generated → Continuing to design...
+✅ Design generated → Continuing to tasks...
+```
+
+### Final Completion Summary
+
+Provide output in the language specified in `spec.json`:
+
+```
+✅ Quick Spec Generation Complete!
+
+## Generated Files:
+- .red64/specs/{feature}/spec.json
+- .red64/specs/{feature}/requirements.md ({X} requirements)
+- .red64/specs/{feature}/design.md ({Y} components, {Z} endpoints)
+- .red64/specs/{feature}/tasks.md ({N} tasks)
+
+⚠️ Quick generation skipped:
+- `/red64:validate-gap` - Gap analysis (integration check)
+- `/red64:validate-design` - Design review (architecture validation)
+
+## Next Steps:
+1. Review generated specs (especially design.md)
+2. Optional validation:
+   - `/red64:validate-gap {feature}` - Check integration with existing codebase
+   - `/red64:validate-design {feature}` - Verify architecture quality
+3. Start implementation: `/red64:spec-impl {feature}`
+
+## Note:
+For complex features (integrations, security, APIs), use standard workflow:
+/red64:spec-init → /red64:spec-requirements → /red64:validate-gap
+→ /red64:spec-design → /red64:validate-design → /red64:spec-tasks
+```
+
+## Safety & Fallback
+
+### Argument Parsing
+- Use `$ARGUMENTS` to parse (NOT `$1`, `$2`)
+- Handle spaces in descriptions correctly
+- Example: `"Multi word description --auto"` → extract both parts correctly
+
+### Feature Name Generation
+- Convert to lowercase kebab-case
+- Remove special characters
+- If ambiguous, prefer descriptive over short
+- If conflict exists, append `-2`, `-3`, etc.
+
+### Error Scenarios
+
+**Template Missing**:
+- Check `.red64/settings/templates/specs/` exists
+- Report specific missing file
+- Exit with error
+
+**Directory Creation Failed**:
+- Check permissions
+- Report error with path
+- Exit with error
+
+**Phase Execution Failed** (Phase 2-4):
+- Stop workflow
+- Show current state and completed phases
+- Suggest: "Continue manually from `/red64:spec-{next-phase} {feature}`"
+
+**User Cancellation** (Interactive Mode):
+- Stop gracefully
+- Show completed phases
+- Suggest manual continuation
+
+### Usage Guidance
+
+**Use Automatic Mode** (`--auto`) when:
+- Simple feature (CRUD, basic UI)
+- Prototyping / proof-of-concept
+- Well-known feature pattern
+
+**Use Interactive Mode** (default) when:
+- First time using spec-quick
+- Want to review each phase
+- Moderately complex feature
+
+**Use Standard Workflow** (NOT spec-quick) when:
+- Complex integration with existing systems
+- Security-critical features
+- Production-ready quality required
+- Need gap analysis or design validation