@haposoft/cafekit 0.8.16 → 0.9.0

package/src/antigravity/workflows/spec-tasks.md

@@ -1,156 +0,0 @@
----
-description: Generate implementation tasks for a specification
-allowed-tools: Glob, Grep, Read, Write, Edit, WebSearch, WebFetch
-argument-hint: <feature-name> [-y] [--sequential]
----
-
-# Implementation Tasks Generator
-
-<background_information>
-- **Mission**: Generate detailed, actionable implementation tasks that translate technical design into executable work items
-- **Success Criteria**:
-  - All requirements mapped to specific tasks
-  - Tasks properly sized (1-3 hours each)
-  - Clear task progression with proper hierarchy
-  - Natural language descriptions focused on capabilities
-</background_information>
-
-<instructions>
-## Core Task
-Generate implementation tasks for feature **$ARGUMENTS** based on approved requirements and design.
-
-## Execution Steps
-
-### Step 0: Validate Phase State (Plan-Style Gate)
-
-- Read `.specs/$ARGUMENTS/spec.json` first
-- If feature directory or `spec.json` is missing: stop and instruct user to run `/spec-init <project-description>`, `/spec-requirements <feature-name>`, and `/spec-design <feature-name>` first
-- If design has not been generated yet (phase before design): stop and instruct user to run `/spec-design $ARGUMENTS`
-- If `phase` is already `tasks-generated`: explain tasks phase already exists and only continue for explicit regeneration/merge intent
-
-### Step 1: Load Context
-
-**Read all necessary context**:
-- `.specs/$ARGUMENTS/spec.json`, `requirements.md`, `design.md`
-- `.specs/$ARGUMENTS/tasks.md` (if exists, for merge mode)
-- `.specs/$ARGUMENTS/research.md` (if exists, includes validation log)
-- **Entire `.specs/steering/` directory** for complete project memory (if exists)
-- **Load project docs context (Plan-style quality gate)** when available:
-  - `docs/codebase-summary.md`
-  - `docs/code-standards.md`
-  - `docs/system-architecture.md`
-  - `docs/project-overview-pdr.md`
-- If any docs file is missing, continue and mention missing context in execution output (do not block generation)
-
-**Validate approvals**:
-- If `-y` flag provided: Auto-approve requirements and design in spec.json
-- Otherwise: Verify both approved (stop if not, see Safety & Fallback)
-- **Backward compatibility fallback (older specs):**
-  - If `validation` object is missing, treat validation status as `not-run`
-  - If `design_context` object is missing, treat `validation_recommended` as `false`
-- If `spec.json.validation.status == "completed"`, treat validation as satisfied
-- If validation is missing and `design_context.validation_recommended == true`, warn user to run `/spec-validate $ARGUMENTS` before continuing (do not hard-block)
-- Determine sequential mode based on presence of `--sequential`
-
-### Step 2: Generate Implementation Tasks
-
-**Load generation rules and template**:
-- Read `{{SKILLS_DIR}}/specs/rules/tasks-generation.md` for principles
-- If `sequential` is **false**: Read `{{SKILLS_DIR}}/specs/rules/tasks-parallel-analysis.md` for parallel judgement criteria
-- Read `{{SKILLS_DIR}}/specs/templates/tasks.md` for format (supports `(P)` markers)
-
-**Generate task list following all rules**:
-- Use language specified in spec.json
-- Map all requirements to tasks
-- When documenting requirement coverage, list numeric requirement IDs only (comma-separated) without descriptive suffixes, parentheses, translations, or free-form labels
-- Ensure all design components included
-- Verify task progression is logical and incremental
-- Collapse single-subtask structures by promoting them to major tasks and avoid duplicating details on container-only major tasks (use template patterns accordingly)
-- Apply `(P)` markers to tasks that satisfy parallel criteria (omit markers in sequential mode)
-- Mark optional test coverage subtasks with `- [ ]*` only when they strictly cover acceptance criteria already satisfied by core implementation and can be deferred post-MVP
-- If existing tasks.md found, merge with new content
-
-### Step 3: Finalize
-
-**Write and update**:
-- Create/update `.specs/$ARGUMENTS/tasks.md`
-- Update spec.json metadata:
-  - Set `phase: "tasks-generated"`
-  - Set `approvals.tasks.generated: true, approved: false`
-  - Set `approvals.requirements.approved: true`
-  - Set `approvals.design.approved: true`
-  - Update `updated_at` timestamp
-
-## Critical Constraints
-- **Follow rules strictly**: All principles in tasks-generation.md are mandatory
-- **Natural Language**: Describe what to do, not code structure details
-- **Complete Coverage**: ALL requirements must map to tasks
-- **Maximum 2 Levels**: Major tasks and sub-tasks only (no deeper nesting)
-- **Sequential Numbering**: Major tasks increment (1, 2, 3...), never repeat
-- **Task Integration**: Every task must connect to the system (no orphaned work)
-</instructions>
-
-## Tool Guidance
-- **Read first**: Load all context, rules, and templates before generation
-- **Write last**: Generate tasks.md only after complete analysis and verification
-
-## Output Description
-
-Provide brief summary in the language specified in spec.json:
-
-1. **Status**: Confirm tasks generated at `.specs/$ARGUMENTS/tasks.md`
-2. **Task Summary**: 
-   - Total: X major tasks, Y sub-tasks
-   - All Z requirements covered
-   - Average task size: 1-3 hours per sub-task
-3. **Quality Validation**:
-   - ✅ All requirements mapped to tasks
-   - ✅ Task dependencies verified
-   - ✅ Testing tasks included
-4. **Next Action**: Review tasks and proceed when ready
-
-**Format**: Concise (under 200 words)
-
-## Safety & Fallback
-
-### Error Scenarios
-
-**Requirements or Design Not Approved**:
-- **Stop Execution**: Cannot proceed without approved requirements and design
-- **User Message**: "Requirements and design must be approved before task generation"
-- **Suggested Action**: "Run `/spec-tasks $ARGUMENTS -y` to auto-approve both and proceed"
-
-**Missing Requirements or Design**:
-- **Stop Execution**: Both documents must exist
-- **User Message**: "Missing requirements.md or design.md at `.specs/$ARGUMENTS/`"
-- **Suggested Action**: "Complete requirements and design phases first"
-
-**Incomplete Requirements Coverage**:
-- **Warning**: "Not all requirements mapped to tasks. Review coverage."
-- **User Action Required**: Confirm intentional gaps or regenerate tasks
-
-**Template/Rules Missing**:
-- **User Message**: "Template or rules files missing in `{{SKILLS_DIR}}/specs/`"
-- **Fallback**: Use inline basic structure with warning
-- **Suggested Action**: "Check repository setup or restore template files"
-
-**Missing Numeric Requirement IDs**:
-- **Stop Execution**: All requirements in requirements.md MUST have numeric IDs. If any requirement lacks a numeric ID, stop and request that requirements.md be fixed before generating tasks.
-
-### Next Phase: Implementation
-
-**Before Starting Implementation**:
-- **IMPORTANT**: Clear conversation history and free up context before running `/code`
-- This applies when starting first task OR switching between tasks
-- Fresh context ensures clean state and proper task focus
-
-**If Tasks Approved**:
-- Execute coding pass from approved spec tasks: `/code $ARGUMENTS`
-- After coding, run `/test` then `/review`
-- Repeat in small passes and clear context between iterations when needed
-
-**If Modifications Needed**:
-- Provide feedback and re-run `/spec-tasks $ARGUMENTS`
-- Existing tasks used as reference (merge mode)
-
-**Note**: Continue with `/test` then `/review` after `/code` to complete the workflow.

package/src/antigravity/workflows/spec-validate.md

@@ -1,106 +0,0 @@
----
-description: Validate design decisions with interview questions before task generation
-allowed-tools: Read, Write, Edit, Glob, AskUserQuestion
-argument-hint: <feature-name>
----
-
-# Specification Validation Interview
-
-<background_information>
-- **Mission**: Validate critical design decisions, assumptions, and trade-offs before generating implementation tasks.
-- **Success Criteria**:
-  - Ask targeted, concrete questions about high-impact decisions
-  - Record answers in spec artifacts for future traceability
-  - Update spec metadata to reflect validation status
-</background_information>
-
-<instructions>
-## Core Task
-Run a structured interview for feature **$ARGUMENTS** and persist decisions.
-
-## Execution Steps
-
-### Step 0: Resolve & Validate State
-- Require `$ARGUMENTS` as feature name
-- Read `.specs/$ARGUMENTS/spec.json`
-- Stop with guidance if spec does not exist
-- Ensure `requirements.md` and `design.md` exist before validation
-
-### Step 1: Load Validation Context
-Read:
-- `.specs/$ARGUMENTS/spec.json`
-- `.specs/$ARGUMENTS/requirements.md`
-- `.specs/$ARGUMENTS/design.md`
-- `.specs/$ARGUMENTS/research.md` (if exists)
-
-Extract decision points around:
-- architecture and boundaries
-- assumptions and defaults
-- integration risks
-- scope and sequencing
-- testing/security/performance trade-offs
-
-### Step 2: Determine Question Budget
-Use injected session validation settings when available (`Validation: mode=X, questions=MIN-MAX`).
-- If unavailable, use 3-6 questions
-- Ask only meaningful questions that can change implementation
-- Each question must have 2-4 concrete options
-
-### Step 3: Interview User
-Use `AskUserQuestion` in batches (max 4 questions per call).
-Rules:
-- Include one recommended option when a safe default exists
-- Keep options mutually exclusive
-- Do not ask redundant questions
-
-### Step 4: Persist Validation Log
-Append to `.specs/$ARGUMENTS/research.md` under `## Validation Log`.
-If section missing, create it.
-
-Session format:
-```markdown
-## Validation Log
-
-### Session N — YYYY-MM-DD
-- Questions asked: X
-
-1. [Category] Question text
-   - Options: A | B | C
-   - Answer: ...
-   - Rationale: why this decision matters
-
-#### Confirmed Decisions
-- ...
-
-#### Follow-up Actions
-- [ ] ...
-```
-
-### Step 5: Update Metadata
-Update `.specs/$ARGUMENTS/spec.json`:
-- `approvals.requirements.approved: true`
-- `approvals.design.approved: true`
-- `validation.last_validated_at: <ISO timestamp>`
-- `validation.questions_asked: <number>`
-- `validation.status: "completed"`
-- increment `validation.session_count` (initialize to 1 if absent)
-- update `updated_at`
-
-## Constraints
-- Keep input/output contract of existing `spec-*` commands unchanged
-- Validation must be traceable and append-only (never overwrite old sessions)
-- Ask fewer questions when artifact is simple; quality over quantity
-</instructions>
-
-## Output Description
-Provide concise summary:
-1. Validation status and files updated
-2. Number of questions asked
-3. Top confirmed decisions
-4. Recommended next command:
-   - `/spec-tasks $ARGUMENTS` when ready
-
-## Safety & Fallback
-- Missing spec/design artifacts: stop and instruct the exact preceding command
-- Empty decision surface: ask only 1-2 high-value confirmation questions
-- Write failure: report exact path and retry guidance

package/src/antigravity/workflows/test.md

@@ -1,13 +0,0 @@
----
-description: Run project tests and report failures concisely.
-allowed-tools: Bash, Read, Grep
-argument-hint: [scope]
----
-
-# /test
-
-Run the project's test command and report:
-- total passed/failed
-- failing test names
-- root cause hints
-- next fix action