@haposoft/cafekit 0.3.11 → 0.4.0

package/src/common/skills/spec-requirements/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: hapo:spec-requirements
+description: Generate EARS requirements with scope-lock checks. Use after hapo:spec-init in Claude Code.
+version: 1.0.0
+argument-hint: <feature-name>
+---
+
+# Hapo Spec Requirements
+
+Generate complete, testable requirements from the initialized spec description.
+
+## Usage
+
+```bash
+/hapo:spec-requirements <feature-name>
+```
+
+## Load First
+
+- `references/requirements-workflow.md`
+- `.claude/skills/specs/rules/ears-format.md`
+- `.claude/skills/specs/templates/requirements.md`
+
+## Execute
+
+1. Read `.specs/$ARGUMENTS/spec.json` first.
+2. Stop if the spec folder is missing and tell the user to run `/hapo:spec-init` first.
+3. Stop if requirements are already past this phase unless the user clearly wants regeneration.
+4. Read:
+   - `.specs/$ARGUMENTS/spec.json`
+   - `.specs/$ARGUMENTS/requirements.md`
+   - `.specs/steering/` when present
+   - project docs under `docs/` when present
+5. Respect `scope_lock` strictly. Keep new requirements inside `in_scope`. Move nearby but unapproved ideas to deferred or out-of-scope notes.
+6. Analyze the existing codebase when this is an enhancement, not a greenfield feature.
+7. Generate requirements in EARS format only. Focus on what the system shall do, not how to build it.
+8. Normalize requirement headings to numeric IDs if needed.
+9. Update `spec.json` phase and timestamps after writing the document.
+
+## Output
+
+Return:
+- 3-5 bullet summary of requirement areas
+- deferred or out-of-scope topics
+- confirmation that `requirements.md` and `spec.json` were updated
+- next command: `/hapo:spec-design $ARGUMENTS`
+
+## Rules
+
+- Use EARS syntax for acceptance criteria.
+- Keep requirements testable and verifiable.
+- Ask at most 1-2 focused clarification questions when scope is ambiguous.
+- If templates or rules are missing, report the exact missing file.
+
+## Related
+
+- Command: `/spec-requirements`
+- Previous skill: `/hapo:spec-init`
+- Next skill: `/hapo:spec-design $ARGUMENTS`

package/src/common/skills/spec-requirements/references/requirements-workflow.md

@@ -0,0 +1,36 @@
+# Requirements Workflow
+
+## Goal
+
+Generate requirement statements that stay inside the initialized scope and can be verified later.
+
+## Sequence
+
+1. Read `spec.json` first.
+2. Read the current `requirements.md` seed content.
+3. Load steering and `docs/` context when available.
+4. Read shared rules from `.claude/skills/specs/rules/ears-format.md`.
+5. Filter candidate requirement areas through `scope_lock`.
+6. Write requirements in EARS format.
+7. Update phase metadata.
+
+## EARS reminder
+
+- Event-driven: `When ... the system shall ...`
+- State-driven: `While ... the system shall ...`
+- Unwanted: `If ... the system shall ...`
+- Optional: `Where ... the system shall ...`
+- Ubiquitous: `The system shall ...`
+
+## Scope rules
+
+- Keep only what matches `scope_lock.in_scope`.
+- Do not promote adjacent ideas automatically.
+- Put unapproved expansions into deferred or out-of-scope notes.
+
+## Output checklist
+
+- Numeric requirement headings
+- Testable acceptance criteria
+- No implementation details
+- Next step points to design

package/src/common/skills/spec-tasks/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: hapo:spec-tasks
+description: Break approved design into executable tasks with requirement mapping. Use after hapo:spec-design in Claude Code.
+version: 1.0.0
+argument-hint: <feature-name>
+---
+
+# Hapo Spec Tasks
+
+Turn approved requirements and design into a task list that can be implemented incrementally.
+
+## Usage
+
+```bash
+/hapo:spec-tasks <feature-name>
+```
+
+## Load First
+
+- `references/task-sizing.md`
+- `.claude/skills/specs/rules/tasks-generation.md`
+- `.claude/skills/specs/templates/tasks.md`
+
+## Execute
+
+1. Read `.specs/$ARGUMENTS/spec.json` first.
+2. Stop if `requirements.md` or `design.md` is missing.
+3. Read:
+   - `.specs/$ARGUMENTS/spec.json`
+   - `.specs/$ARGUMENTS/requirements.md`
+   - `.specs/$ARGUMENTS/design.md`
+   - `.specs/$ARGUMENTS/tasks.md` when it exists
+   - `.specs/$ARGUMENTS/research.md` when it exists
+4. Respect `scope_lock` and use only valid in-scope numeric requirement IDs.
+5. Generate tasks that are small, ordered, and incremental.
+6. Keep a maximum of two levels: major tasks and sub-tasks.
+7. Remove or defer tasks that only map to out-of-scope work.
+8. Write `.specs/$ARGUMENTS/tasks.md`.
+9. Update `spec.json` phase and task generation metadata.
+
+## Output
+
+Return:
+- task generation status and file path
+- total major tasks and sub-tasks
+- confirmation that all in-scope requirements are covered
+- next command: `/hapo:code $ARGUMENTS`
+
+## Rules
+
+- Every task must map to at least one valid numeric requirement ID.
+- Keep sub-tasks sized for short implementation passes.
+- Do not introduce new scope during task generation.
+- If requirement IDs are invalid or missing, stop and report it.
+
+## Related
+
+- Command: `/spec-tasks`
+- Previous skill: `/hapo:spec-design`
+- Next skill: `/hapo:code $ARGUMENTS`

package/src/common/skills/spec-tasks/references/task-sizing.md

@@ -0,0 +1,36 @@
+# Task Sizing
+
+## Goal
+
+Produce tasks small enough for incremental delivery and review.
+
+## Good task size
+
+Target sub-tasks that fit one focused implementation pass.
+
+## Rules
+
+- Every task maps to valid numeric requirement IDs.
+- Keep only two levels: major tasks and sub-tasks.
+- Prefer capability-based task names, not file-dump checklists.
+- Remove tasks that only serve out-of-scope work.
+
+## Good examples
+
+- Add theme state provider
+- Persist theme selection
+- Update navigation to expose toggle
+- Add tests for preference persistence
+
+## Bad examples
+
+- Build entire auth system
+- Refactor everything first
+- Add optional analytics that was never approved
+
+## Ordering
+
+1. foundations
+2. feature behavior
+3. integration points
+4. tests and cleanup

package/src/common/skills/test/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: hapo:test
+description: Run project tests after hapo:code and report failures concisely.
+version: 1.0.0
+argument-hint: [scope]
+---
+
+# Hapo Test
+
+Run the relevant test command for the current project and summarize the result.
+
+## Usage
+
+```bash
+/hapo:test
+/hapo:test <scope>
+```
+
+## Execute
+
+1. Detect the project test command from the current repo.
+2. Run the relevant tests for the recent changes or requested scope.
+3. Report:
+   - total passed and failed
+   - failing test names
+   - likely root cause
+   - next fix action
+4. If tests fail, do not hide failures. Point back to the failing area.
+
+## Rules
+
+- Prefer the smallest meaningful test scope first.
+- Keep the report concise.
+- Do not claim success when tests were not run.
+
+## Related
+
+- Command: `/test`
+- Previous skill: `/hapo:code`
+- Next skill: `/hapo:review`