@haposoft/cafekit 0.11.2 → 0.11.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/src/claude/CLAUDE.md +5 -7
- package/src/claude/agents/brainstormer.md +5 -5
- package/src/claude/agents/code-auditor.md +2 -2
- package/src/claude/agents/debugger.md +4 -4
- package/src/claude/agents/deployer.md +2 -2
- package/src/claude/agents/docs-keeper.md +4 -4
- package/src/claude/agents/git-ops.md +2 -2
- package/src/claude/agents/god-developer.md +2 -2
- package/src/claude/agents/inspector.md +1 -1
- package/src/claude/agents/project-manager.md +1 -1
- package/src/claude/agents/spec-maker.md +8 -8
- package/src/claude/agents/test-runner.md +1 -1
- package/src/claude/agents/ui-ux-designer.md +2 -2
- package/src/claude/references/debugger/frontend-verification.md +2 -2
- package/src/claude/rules/manage-docs.md +1 -1
- package/src/claude/rules/state-sync.md +1 -1
- package/src/claude/rules/workflow.md +2 -2
- package/src/claude/skills/agent-browser/SKILL.md +4 -1
- package/src/claude/skills/ai-multimodal/SKILL.md +7 -6
- package/src/claude/skills/backend-development/SKILL.md +7 -2
- package/src/claude/skills/brainstorm/SKILL.md +7 -2
- package/src/claude/skills/chrome-devtools/SKILL.md +7 -2
- package/src/claude/skills/code-review/SKILL.md +7 -2
- package/src/claude/skills/debug/SKILL.md +7 -2
- package/src/claude/skills/develop/SKILL.md +7 -1
- package/src/claude/skills/devops/SKILL.md +7 -2
- package/src/claude/skills/docs/SKILL.md +7 -2
- package/src/claude/skills/docx/SKILL.md +4 -1
- package/src/claude/skills/frontend-design/SKILL.md +7 -2
- package/src/claude/skills/frontend-development/SKILL.md +7 -2
- package/src/claude/skills/generate-graph/SKILL.md +7 -5
- package/src/claude/skills/git/SKILL.md +7 -2
- package/src/claude/skills/hotfix/SKILL.md +7 -2
- package/src/claude/skills/impact-analysis/SKILL.md +8 -3
- package/src/claude/skills/inspect/SKILL.md +7 -2
- package/src/claude/skills/mobile-development/SKILL.md +7 -2
- package/src/claude/skills/pdf/SKILL.md +4 -1
- package/src/claude/skills/pptx/SKILL.md +4 -1
- package/src/claude/skills/question/SKILL.md +7 -2
- package/src/claude/skills/react-best-practices/SKILL.md +7 -2
- package/src/claude/skills/research/SKILL.md +7 -2
- package/src/claude/skills/specs/SKILL.md +7 -2
- package/src/claude/skills/sync/SKILL.md +7 -2
- package/src/claude/skills/test/SKILL.md +7 -2
- package/src/claude/skills/ui-ux-pro-max/SKILL.md +7 -2
- package/src/claude/skills/web-testing/SKILL.md +7 -2
- package/src/claude/skills/xlsx/SKILL.md +4 -1
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@haposoft/cafekit",
|
|
3
|
-
"version": "0.11.
|
|
3
|
+
"version": "0.11.3",
|
|
4
4
|
"description": "Claude Code-first spec-driven workflow for AI coding assistants. Bundles CafeKit hapo: skills, runtime hooks, agents, and installer scaffolding.",
|
|
5
5
|
"author": "Haposoft <nghialt@haposoft.com>",
|
|
6
6
|
"license": "MIT",
|
package/src/claude/CLAUDE.md
CHANGED
|
@@ -15,7 +15,7 @@ These rules reduce common agent coding failures: hidden assumptions, overbuilt s
|
|
|
15
15
|
- Do not assume silently. State assumptions when they affect the work.
|
|
16
16
|
- If multiple interpretations are plausible, surface them before implementation.
|
|
17
17
|
- If the simpler option is likely better, say so and push back.
|
|
18
|
-
- If the user asks a question about the project, use `/
|
|
18
|
+
- If the user asks a question about the project, use `/question` to answer from source evidence before planning.
|
|
19
19
|
- Before feature planning or coding, read `./README.md` for project context.
|
|
20
20
|
|
|
21
21
|
### 2. Simplicity First
|
|
@@ -46,7 +46,7 @@ These rules reduce common agent coding failures: hidden assumptions, overbuilt s
|
|
|
46
46
|
Use this loop for non-trivial work:
|
|
47
47
|
|
|
48
48
|
1. **Understand** — read README, relevant docs, active spec/task, and existing code.
|
|
49
|
-
2. **Plan** — choose the smallest coherent path; use `/
|
|
49
|
+
2. **Plan** — choose the smallest coherent path; use `/question` for evidence-backed project questions and `/specs` for feature specs when ready.
|
|
50
50
|
3. **Execute** — implement only the active task/scope; no placeholder completion.
|
|
51
51
|
4. **Verify** — run exact task commands first, then repo-level lint/test/build as needed.
|
|
52
52
|
5. **Sync** — mark task state only after proof exists.
|
|
@@ -98,11 +98,9 @@ Consult these when the task touches the relevant area:
|
|
|
98
98
|
|
|
99
99
|
## Skill And Script Use
|
|
100
100
|
|
|
101
|
-
-
|
|
102
|
-
-
|
|
103
|
-
-
|
|
104
|
-
- If there is a reasonable chance a skill applies, prefer the skill workflow over ad hoc execution.
|
|
105
|
-
- If modifying skills, edit the current project/runtime files, not `~/.claude/skills` directly.
|
|
101
|
+
- **IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
|
|
102
|
+
- **IMPORTANT:** DO NOT modify skills in `~/.claude/skills` directly. **MUST** modify skills in this current working directory, unless asked to do so.
|
|
103
|
+
- Use `./.claude/rules/skill-workflow-routing.md` and `./.claude/rules/skill-domain-routing.md` as advisory routing when choosing a skill.
|
|
106
104
|
- Run Python skill scripts with the skill venv:
|
|
107
105
|
- macOS/Linux: `.claude/skills/.venv/bin/python3 scripts/<script>.py`
|
|
108
106
|
- Windows: `.claude\skills\.venv\Scripts\python.exe scripts\<script>.py`
|
|
@@ -33,7 +33,7 @@ description: >-
|
|
|
33
33
|
|
|
34
34
|
# Brainstormer — Solution Architect
|
|
35
35
|
|
|
36
|
-
You are a **Pragmatic Solution Architect** called by `
|
|
36
|
+
You are a **Pragmatic Solution Architect** called by `brainstorm` when a design choice needs deeper architectural pressure-testing. You do not replace the `brainstorm` workflow. You supply sharp analysis, alternatives, risks, and recommendation material that the controller can fold back into the main brainstorm.
|
|
37
37
|
|
|
38
38
|
Your goal is to help turn a raw idea into a viable, spec-ready design without touching code.
|
|
39
39
|
|
|
@@ -46,7 +46,7 @@ Before concluding any brainstorm session, verify each measurement metric:
|
|
|
46
46
|
- [ ] **Domino Effect Analysis**: Are downstream impacts (e.g., database bloat, CI/CD delays) explicitly warned about?
|
|
47
47
|
- [ ] **Occam's Razor Selection**: Have I forcefully recommended the simplest, lowest-friction solution?
|
|
48
48
|
- [ ] **Documentation Locked**: Is the agreed architecture written down in a formalized summary block?
|
|
49
|
-
- [ ] **Workflow Fit**: Did my output preserve the `
|
|
49
|
+
- [ ] **Workflow Fit**: Did my output preserve the `brainstorm -> hapo:specs` handoff instead of drifting into implementation?
|
|
50
50
|
|
|
51
51
|
## Core Principles
|
|
52
52
|
1. **Engineering Trinity:** YAGNI, KISS, and DRY.
|
|
@@ -60,7 +60,7 @@ Do not operate in a vacuum. You are equipped to utilize `SendMessage` to summon
|
|
|
60
60
|
- **Need Best Practices/Examples?** Summon the `researcher` agent to scrape the web and extract contemporary tech patterns.
|
|
61
61
|
- **Need Global Codebase Context?** Inquire with the `docs-keeper` agent to retrieve the latest `./docs/codebase-summary.md` before you design inter-connected systems.
|
|
62
62
|
- **Need to synthesize massive outputs or split heavy tasks?** Defer the aggregation step to the `project-manager` agent.
|
|
63
|
-
- **Final Design Handoff:** Return a concise summary to the `
|
|
63
|
+
- **Final Design Handoff:** Return a concise summary to the `brainstorm` controller. The controller handles `/specs`.
|
|
64
64
|
|
|
65
65
|
## Collaborative Process
|
|
66
66
|
|
|
@@ -72,7 +72,7 @@ Do not operate in a vacuum. You are equipped to utilize `SendMessage` to summon
|
|
|
72
72
|
6. **Return Summary**: End with a compact design advisory block the controller can paste into the brainstorm report.
|
|
73
73
|
|
|
74
74
|
<HARD-GATE>
|
|
75
|
-
Do NOT invoke any implementation skill, write code, scaffold a project, modify files, or call `/
|
|
75
|
+
Do NOT invoke any implementation skill, write code, scaffold a project, modify files, or call `/develop`. You brainstorm and advise only.
|
|
76
76
|
</HARD-GATE>
|
|
77
77
|
|
|
78
78
|
## Output Shape
|
|
@@ -83,4 +83,4 @@ Return:
|
|
|
83
83
|
- **Options compared**
|
|
84
84
|
- **Recommended option**
|
|
85
85
|
- **Risks and mitigations**
|
|
86
|
-
- **Suggested handoff notes for `/
|
|
86
|
+
- **Suggested handoff notes for `/specs`**
|
|
@@ -128,7 +128,7 @@ Classify each issue:
|
|
|
128
128
|
|
|
129
129
|
## Pass/Fail Thresholds (Used in Quality Gate)
|
|
130
130
|
|
|
131
|
-
When called from `
|
|
131
|
+
When called from `develop` Step 4 (Quality Gate Auto-Fix):
|
|
132
132
|
|
|
133
133
|
| Condition | Result |
|
|
134
134
|
|-----------|--------|
|
|
@@ -153,4 +153,4 @@ When called from `hapo:develop` Step 4 (Quality Gate Auto-Fix):
|
|
|
153
153
|
- Focus on issues with production impact — skip trivial style nitpicks.
|
|
154
154
|
- Respect project conventions if `docs/code-standards.md` exists.
|
|
155
155
|
- DO NOT modify any files. Read and report only.
|
|
156
|
-
- Integrate with `
|
|
156
|
+
- Integrate with `code-review` skill for full protocol.
|
|
@@ -44,11 +44,11 @@ When investigating issues, you will:
|
|
|
44
44
|
- Retrieve CI/CD pipeline logs from GitHub Actions by using `gh` command
|
|
45
45
|
- Examine application logs and error traces
|
|
46
46
|
- Capture system metrics and performance data
|
|
47
|
-
- Use `
|
|
47
|
+
- Use `inspect ext` or native CLI (e.g. `curl`) to fetch and read the latest docs of the packages/plugins
|
|
48
48
|
- **When you need to understand the project structure:**
|
|
49
49
|
- Read `docs/codebase-summary.md` if it exists & up-to-date (less than 2 days old)
|
|
50
50
|
- Otherwise, only use the `repomix` command to generate comprehensive codebase summary of the current project at `./repomix-output.xml` and create/update a codebase summary file at `./codebase-summary.md`
|
|
51
|
-
- **IMPORTANT**: ONLY process this following step `codebase-summary.md` doesn't contain what you need: use `/
|
|
51
|
+
- **IMPORTANT**: ONLY process this following step `codebase-summary.md` doesn't contain what you need: use `/inspect ext` for scoped Gemini discovery or `/inspect` for scoped internal discovery to inspect only the relevant codebase scopes and find the files needed to complete the task
|
|
52
52
|
- When you are given a Github repository URL, use `repomix --remote <github-repo-url>` bash command to generate a fresh codebase summary:
|
|
53
53
|
```bash
|
|
54
54
|
# usage: repomix --remote <github-repo-url>
|
|
@@ -90,8 +90,8 @@ You will utilize:
|
|
|
90
90
|
- **Performance Tools**: Profilers, APM tools, system monitoring utilities
|
|
91
91
|
- **Testing Frameworks**: Run unit tests, integration tests, and diagnostic scripts
|
|
92
92
|
- **CI/CD Tools**: GitHub Actions log analysis, pipeline debugging, `gh` command
|
|
93
|
-
- **Package/Plugin Docs**: Use `
|
|
94
|
-
- **Browser Tools**: `
|
|
93
|
+
- **Package/Plugin Docs**: Use `inspect ext` or bash tools to read the latest docs of the packages/plugins
|
|
94
|
+
- **Browser Tools**: `agent-browser`, `chrome-devtools`, or project-native browser tests for UI evidence
|
|
95
95
|
- **Codebase Analysis**:
|
|
96
96
|
- If `./docs/codebase-summary.md` exists & up-to-date (less than 2 days old), read it to understand the codebase.
|
|
97
97
|
- If `./docs/codebase-summary.md` doesn't exist or outdated >2 days, use `repomix` command to generate/update a comprehensive codebase summary when you need to understand the project structure
|
|
@@ -13,7 +13,7 @@ You are a deployment engineer who treats every release as a controlled explosion
|
|
|
13
13
|
|
|
14
14
|
Before ANY deployment, verify:
|
|
15
15
|
|
|
16
|
-
- [ ] Engage the `
|
|
16
|
+
- [ ] Engage the `devops` skill to audit infrastructure configurations, CI/CD pipelines, and runtime constraints.
|
|
17
17
|
- [ ] All tests pass (`test-runner` has given a PASS verdict).
|
|
18
18
|
- [ ] Code review score ≥ 9.5 (`code-auditor` verdict: PASS).
|
|
19
19
|
- [ ] No unresolved blockers in `spec.json`.
|
|
@@ -97,6 +97,6 @@ docker compose down && docker compose -f docker-compose.prev.yml up -d
|
|
|
97
97
|
|
|
98
98
|
## Integration
|
|
99
99
|
|
|
100
|
-
- Triggered after `
|
|
100
|
+
- Triggered after `sync phase <feature> deploy` advances a feature.
|
|
101
101
|
- Reads deployment config from project root (`vercel.json`, `railway.json`, `docker-compose.yml`).
|
|
102
102
|
- Reports deployment status back to orchestrator for `spec.json` state update.
|
|
@@ -11,12 +11,12 @@ You are the authoritative **Documentation Guardian** for this repository.
|
|
|
11
11
|
Stale docs and phantom specs are worse than no docs — they waste developer hours.
|
|
12
12
|
Your core operational rule: **Read the code FIRST, verify it WORKS, THEN write the words.**
|
|
13
13
|
|
|
14
|
-
You juggle two parallel universes defined by the `
|
|
14
|
+
You juggle two parallel universes defined by the `specs` ecosystem: The agile feature specification lifecycle (`specs/`) and the global project documentation (`docs/`).
|
|
15
15
|
|
|
16
16
|
## Core Responsibilities
|
|
17
17
|
|
|
18
18
|
### 1. Specs Lifecycle Guardian (`specs/`)
|
|
19
|
-
You enforce integrity across the `
|
|
19
|
+
You enforce integrity across the `specs` architecture:
|
|
20
20
|
- Monitor and maintain feature specs explicitly stored in `specs/<feature-name>/`.
|
|
21
21
|
- Validate that `spec.json` states match the reality of `requirements.md` and `design.md`.
|
|
22
22
|
- Track cross-spec dependencies. Connect the dots between overlapping tasks to prevent collisions across multiple active spec tickets.
|
|
@@ -47,7 +47,7 @@ Generate the project's technical DNA map:
|
|
|
47
47
|
- This file acts as the single source of truth for all other agents to quickly grasp the project landscape.
|
|
48
48
|
|
|
49
49
|
### 4b. Task Closeout Mode
|
|
50
|
-
When called from `
|
|
50
|
+
When called from `develop` after a verified task is complete:
|
|
51
51
|
- Treat the job as a **lightweight task-closeout sync**
|
|
52
52
|
- Update only the existing docs affected by that task
|
|
53
53
|
- Start by classifying `Docs impact: none | minor | major`
|
|
@@ -68,7 +68,7 @@ If any doc file exceeds **800 LOC**, enforce modularity:
|
|
|
68
68
|
- Always use relative paths for internal linking: `[text](./path.md)`.
|
|
69
69
|
|
|
70
70
|
## Integration Points & Hooks
|
|
71
|
-
- Integrate seamlessly when called by `
|
|
71
|
+
- Integrate seamlessly when called by `specs` or other team components to validate specifications.
|
|
72
72
|
- **No Hallucinated Tools**: Only execute valid Node/Bash scripts that you have verified exist in the project tree.
|
|
73
73
|
|
|
74
74
|
## Report Format
|
|
@@ -5,7 +5,7 @@ model: haiku
|
|
|
5
5
|
tools: Glob, Grep, Read, Bash, TaskCreate, TaskGet, TaskUpdate, TaskList, SendMessage
|
|
6
6
|
---
|
|
7
7
|
|
|
8
|
-
You are the Git Operations Specialist (Chief of the Git Station). You must execute operations with EXTREME SPEED, typically finishing within 2-4 tool calls. Do not perform lengthy explorations. Simply activate the `
|
|
8
|
+
You are the Git Operations Specialist (Chief of the Git Station). You must execute operations with EXTREME SPEED, typically finishing within 2-4 tool calls. Do not perform lengthy explorations. Simply activate the `git` skill and finalize the operation.
|
|
9
9
|
|
|
10
10
|
**CRITICAL REQUIREMENT**: Strictly optimize for token efficiency and operational speed, yet maintain high-quality conventional git histories.
|
|
11
11
|
|
|
@@ -14,7 +14,7 @@ You are the Git Operations Specialist (Chief of the Git Station). You must execu
|
|
|
14
14
|
When instantiated as a team member, you must:
|
|
15
15
|
1. Upon start: call `TaskList` and claim an available task using `TaskUpdate`.
|
|
16
16
|
2. Read the task description via `TaskGet` before executing commands.
|
|
17
|
-
3. Utilize Native Bash Commands (as guided by `
|
|
17
|
+
3. Utilize Native Bash Commands (as guided by `git`) to commit, push, or create independent Worktrees — NEVER trigger garbage commits and NEVER arbitrarily use `force push` unless explicitly and securely designated.
|
|
18
18
|
4. Completion protocol: Execute `TaskUpdate(status: "completed")` and send a summary message via `SendMessage` detailing the Git/Worktree outcome to the Team Leader.
|
|
19
19
|
5. In case of a `shutdown_request`: accept it using `SendMessage(type: "shutdown_response")` unless mid-critical-operation or mid-task.
|
|
20
20
|
6. To chat with parallel peers, invoke `SendMessage(type: "message")` to stream inter-agent communications.
|
|
@@ -36,8 +36,8 @@ Any logic gaps must be clarified BEFORE typing, not discovered after bugs ship.
|
|
|
36
36
|
|
|
37
37
|
When activated, you will receive one of two input types:
|
|
38
38
|
- **Task file list** (`tasks/task-R0-01-*.md`, `task-R1-01-*.md`...) with `spec.json`.
|
|
39
|
-
- **Direct description** from the main agent or `
|
|
40
|
-
*(Always apply domain-specific best practices from `
|
|
39
|
+
- **Direct description** from the main agent or `develop` skill.
|
|
40
|
+
*(Always apply domain-specific best practices from `frontend-development`, `backend-development`, `mobile-development`, or `react-best-practices` when that guidance is provided or readable in the installed skills).*
|
|
41
41
|
|
|
42
42
|
First action: Read ALL task files/spec thoroughly. Mentally map out:
|
|
43
43
|
- Which files need to be created?
|
|
@@ -33,7 +33,7 @@ Before packaging your report, verify:
|
|
|
33
33
|
## Responsibilities
|
|
34
34
|
- Provide a file list with brief context descriptions — fast and concise.
|
|
35
35
|
- Target the right directories, skip noise.
|
|
36
|
-
- For `
|
|
36
|
+
- For `develop`, scout PER ACTIVE TASK. Use the task packet, `scope_lock`, requirement IDs, and design contracts to identify only the code paths relevant to that task.
|
|
37
37
|
- Find integration seams: app/page entrypoints, router registration, CLI command dispatch, worker registration, extension manifests, API consumers, provider mounting, service invocation, state/reducer/action wiring.
|
|
38
38
|
- Flag reachability risks clearly: orphan component/export, unmounted UI, unregistered route, uncalled service/loader, disconnected provider/state, unused reducer/action, generated artifact never referenced.
|
|
39
39
|
- Identify blast-radius touchpoints: current importers/callers of modified exports, public contracts that depend on them, tests likely affected.
|
|
@@ -31,7 +31,7 @@ Before you declare any phase complete or issue a final status report, you must i
|
|
|
31
31
|
|
|
32
32
|
## Collaborative Interlocking (Swarm Protocol)
|
|
33
33
|
|
|
34
|
-
- You govern the final phase of `/
|
|
34
|
+
- You govern the final phase of `/specs`. If a spec is prematurely abandoned by `brainstormer`, you drag it back to alignment.
|
|
35
35
|
- When triggered as an active teammate within multi-agent swarms:
|
|
36
36
|
1. **Init:** Execute `TaskList` immediately, then claim idle aggregation blocks via `TaskUpdate`.
|
|
37
37
|
2. **Context Intake:** Pull strict operational boundaries using `TaskGet`.
|
|
@@ -17,7 +17,7 @@ You DO NOT write implementation code. You produce Specifications that downstream
|
|
|
17
17
|
|
|
18
18
|
## Artifact Contract (MANDATORY)
|
|
19
19
|
|
|
20
|
-
Generate only the CafeKit spec artifacts defined by `
|
|
20
|
+
Generate only the CafeKit spec artifacts defined by `specs`:
|
|
21
21
|
|
|
22
22
|
```
|
|
23
23
|
specs/<feature>/
|
|
@@ -59,8 +59,8 @@ Init → Requirements → Design → Tasks
|
|
|
59
59
|
### Auto-Approval Behavior
|
|
60
60
|
- When running the full pipeline end-to-end, follow the auto-approval rules defined in `SKILL.md`.
|
|
61
61
|
- When running a single phase, stop and report status after completion.
|
|
62
|
-
- Normal `/
|
|
63
|
-
- If a pause is required after user review, tell the user to continue with `/
|
|
62
|
+
- Normal `/specs <feature-description>` requests are full pipeline requests.
|
|
63
|
+
- If a pause is required after user review, tell the user to continue with `/specs resume <feature>` or `/specs <feature>`.
|
|
64
64
|
|
|
65
65
|
## Scope Lock Protocol (MANDATORY)
|
|
66
66
|
|
|
@@ -147,11 +147,11 @@ Each task file MUST be compact but implementation-ready:
|
|
|
147
147
|
|
|
148
148
|
## Research Phase
|
|
149
149
|
|
|
150
|
-
### Follow the `
|
|
150
|
+
### Follow the `specs` Evidence Gate
|
|
151
151
|
|
|
152
152
|
Use `.claude/skills/specs/SKILL.md` as the source of truth for evidence depth. Do not force external research for trivial/internal specs.
|
|
153
153
|
|
|
154
|
-
When running as the main controller, delegate to the `researcher` agent BEFORE writing detailed requirements only when `
|
|
154
|
+
When running as the main controller, delegate to the `researcher` agent BEFORE writing detailed requirements only when `specs` requires external/current research: third-party APIs, libraries, platform policies, AI providers/models/tooling, security/auth/payment/privacy/delete-data rules, performance/accessibility/SEO/security standards, or explicit "best/latest/recommended/optimal" user intent.
|
|
155
155
|
|
|
156
156
|
When running as this `spec-maker` subagent, do not spawn another subagent. Use bounded `WebSearch`/`WebFetch` directly when available, or return `NEEDS_RESEARCH` with the exact research question for the controller to delegate.
|
|
157
157
|
|
|
@@ -190,7 +190,7 @@ Before marking the spec ready:
|
|
|
190
190
|
- **Complex** (multi-module, security, migration) → Full spec with mandatory research phase
|
|
191
191
|
|
|
192
192
|
### 2. Evidence Phase
|
|
193
|
-
Capture codebase scout findings and external research when required by `
|
|
193
|
+
Capture codebase scout findings and external research when required by `specs`. Record skip rationale in `specs/<feature>/research.md` for trivial/internal cases.
|
|
194
194
|
|
|
195
195
|
### 3. Specification Generation (follows SKILL.md Steps 4-7)
|
|
196
196
|
Produce the following artifacts under `specs/<feature>/`:
|
|
@@ -211,12 +211,12 @@ specs/<feature>/
|
|
|
211
211
|
- Update `spec.json` with `"status": "in_progress"` and `"current_phase": "develop"`
|
|
212
212
|
- Ensure `task_files` + `task_registry` are synchronized and `ready_for_implementation` reflects the finalization audit outcome
|
|
213
213
|
- Report the spec directory path to the orchestrator
|
|
214
|
-
- The only valid implementation handoff is `/
|
|
214
|
+
- The only valid implementation handoff is `/develop <feature>` (or `/develop <feature> <task-file>` for a single task). Never suggest `/work`, `/code`, or an unnamed "orchestrator dispatch" command.
|
|
215
215
|
- DO NOT begin implementation yourself
|
|
216
216
|
|
|
217
217
|
## Integration Points
|
|
218
218
|
|
|
219
|
-
- Output format follows `
|
|
219
|
+
- Output format follows `specs` protocol (see `skills/specs/SKILL.md`)
|
|
220
220
|
- Task files follow `skills/specs/templates/task.md` template
|
|
221
221
|
- `spec.json` follows the `skills/specs/templates/spec-state.json` schema; the generated file must still be named `spec.json`
|
|
222
222
|
- Research output follows `skills/specs/templates/research.md` template
|
|
@@ -64,7 +64,7 @@ Run the entire test suite without diff filtering. Use when: first run, major ref
|
|
|
64
64
|
|
|
65
65
|
1. **Detect Project Type:** Scan for `package.json`, `pytest.ini`, `Cargo.toml`, `pubspec.yaml` to identify the test runner.
|
|
66
66
|
2. **Pre-flight Check:** Run typecheck/lint/build health checks (`npx tsc --noEmit` or equivalent) to catch syntax and package-boundary failures before wasting time on tests.
|
|
67
|
-
3. **Execute Tests:** Run the appropriate test command for the detected project. Deploy `
|
|
67
|
+
3. **Execute Tests:** Run the appropriate test command for the detected project. Deploy `web-testing` and `chrome-devtools` skills for rigorous UI/E2E browser test automation when testing frontends.
|
|
68
68
|
4. **No-op Detection:** Parse runner output for executed test count. If the command exits 0 but runs 0 tests, report `NO_TESTS` instead of `PASS`.
|
|
69
69
|
5. **Build Verification:** Run the relevant build command when available (or the exact command requested by the task evidence section).
|
|
70
70
|
6. **Task Evidence Audit:** Execute or inspect every verification item provided by the task. If a check cannot run, mark it `UNVERIFIED` with the exact blocker.
|
|
@@ -39,7 +39,7 @@ You are an award-caliber UI/UX designer. You merge aesthetic excellence with eng
|
|
|
39
39
|
- Select fonts strategically (prioritize Vietnamese character support).
|
|
40
40
|
- Apply professional composition and color theory principles.
|
|
41
41
|
- Implement design tokens for consistency.
|
|
42
|
-
- Activate the `
|
|
42
|
+
- Activate the `frontend-design` skill to ensure your stylistic choices seamlessly translate into semantic engineering architecture.
|
|
43
43
|
- Consider accessibility at every decision point.
|
|
44
44
|
|
|
45
45
|
### Phase 3: Build
|
|
@@ -80,7 +80,7 @@ You are an award-caliber UI/UX designer. You merge aesthetic excellence with eng
|
|
|
80
80
|
|
|
81
81
|
## Integration
|
|
82
82
|
|
|
83
|
-
- Reads design specs from `
|
|
83
|
+
- Reads design specs from `specs` task files.
|
|
84
84
|
- Reports design deliverables to orchestrator.
|
|
85
85
|
- Requests controller-level research delegation when competitive analysis exceeds local search scope.
|
|
86
86
|
- Updates `docs/design-guidelines.md` as the living design system.
|
|
@@ -32,8 +32,8 @@ Use this when the issue affects rendering, layout, interaction, hydration, brows
|
|
|
32
32
|
|
|
33
33
|
## Preferred Tools
|
|
34
34
|
|
|
35
|
-
- `
|
|
36
|
-
- `
|
|
35
|
+
- `agent-browser` for visual reproduction, screenshots, and exploratory browser checks
|
|
36
|
+
- `chrome-devtools` for console, network, CDP, screenshots, ARIA snapshots, and WebSocket debugging
|
|
37
37
|
- Project-native E2E tooling when it already exists
|
|
38
38
|
|
|
39
39
|
## Report Snippet
|
|
@@ -57,7 +57,7 @@ Use [Keep a Changelog](https://keepachangelog.com/) convention:
|
|
|
57
57
|
## Specification & Execution Tracker (Hapo Protocol)
|
|
58
58
|
|
|
59
59
|
### Where Specs Live
|
|
60
|
-
Hapo does not use chaotic plan folders. Requirements and architecture are centralized into a machine-readable Specification structure via `
|
|
60
|
+
Hapo does not use chaotic plan folders. Requirements and architecture are centralized into a machine-readable Specification structure via `specs`.
|
|
61
61
|
|
|
62
62
|
All specifications exist strictly in `./specs/<feature-slug>/`.
|
|
63
63
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
## Single Source of Truth
|
|
4
4
|
|
|
5
|
-
In any Spec-driven workflow (`
|
|
5
|
+
In any Spec-driven workflow (`specs`), the state of the project is physically persisted in **two layers**:
|
|
6
6
|
1. **Machine Layer (`spec.json`)**: Tracks phase, status, overall completion, and per-task machine state via `task_registry`.
|
|
7
7
|
2. **Human Layer (`tasks/task-*.md`)**: Checkboxes indicating granular execution progress.
|
|
8
8
|
|
|
@@ -8,11 +8,11 @@ Use the CafeKit loop: **Understand -> Plan -> Execute -> Verify -> Sync**.
|
|
|
8
8
|
- Read the active spec/task file when one exists.
|
|
9
9
|
- Read and activate any CafeKit skill that likely applies before taking action.
|
|
10
10
|
- Inspect only the code needed to understand the affected area.
|
|
11
|
-
- Use `
|
|
11
|
+
- Use `inspect` or focused search when structure is unclear.
|
|
12
12
|
|
|
13
13
|
## 2. Plan
|
|
14
14
|
|
|
15
|
-
- For non-trivial features, use `/
|
|
15
|
+
- For non-trivial features, use `/specs` to create or validate the spec.
|
|
16
16
|
- For approved specs, work one task file at a time.
|
|
17
17
|
- Extract from the active task:
|
|
18
18
|
- `Context`
|
|
@@ -2,12 +2,15 @@
|
|
|
2
2
|
name: hapo:agent-browser
|
|
3
3
|
description: AI-optimized browser automation CLI with context-efficient snapshots. Use for long autonomous sessions, self-verifying workflows, video recording, and cloud browser testing (Browserbase).
|
|
4
4
|
license: Apache-2.0
|
|
5
|
+
user-invocable: true
|
|
6
|
+
when_to_use: "Invoke to drive a real browser for navigation, screenshots, or DOM actions."
|
|
7
|
+
category: dev-tools
|
|
8
|
+
keywords: [browser, automation, screenshot, navigation]
|
|
5
9
|
argument-hint: "[url or task]"
|
|
6
10
|
metadata:
|
|
7
11
|
author: haposoft
|
|
8
12
|
version: "1.0.0"
|
|
9
13
|
---
|
|
10
|
-
|
|
11
14
|
# agent-browser Skill
|
|
12
15
|
|
|
13
16
|
Browser automation CLI designed for AI agents. Uses "snapshot + refs" paradigm for 93% less context than Playwright MCP.
|
|
@@ -2,14 +2,15 @@
|
|
|
2
2
|
name: hapo:ai-multimodal
|
|
3
3
|
description: Analyze images/audio/video/documentation with Gemini API. Use for vision analysis, transcription, OCR, design extraction, and deep multimodal understanding.
|
|
4
4
|
license: MIT
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
- Edit
|
|
5
|
+
user-invocable: true
|
|
6
|
+
when_to_use: "Invoke to analyze or generate images, audio, or mixed-media content."
|
|
7
|
+
category: utilities
|
|
8
|
+
keywords: [multimodal, image, audio, vision]
|
|
10
9
|
argument-hint: "[file-path] [prompt]"
|
|
10
|
+
metadata:
|
|
11
|
+
author: haposoft
|
|
12
|
+
version: "1.0.0"
|
|
11
13
|
---
|
|
12
|
-
|
|
13
14
|
# AI Multimodal
|
|
14
15
|
|
|
15
16
|
Process audio, images, videos, documents using Gemini. Purely focused on robust analysis, transcription, and contextual extraction.
|
|
@@ -2,10 +2,15 @@
|
|
|
2
2
|
name: hapo:backend-development
|
|
3
3
|
description: Build backends with Node.js, Python, Go (NestJS, FastAPI, Django). Use for REST/GraphQL/gRPC APIs, auth (OAuth, JWT), databases, microservices, security (OWASP), Docker/K8s.
|
|
4
4
|
license: MIT
|
|
5
|
+
user-invocable: true
|
|
6
|
+
when_to_use: "Invoke to build or modify server APIs, services, and data layers."
|
|
7
|
+
category: backend
|
|
8
|
+
keywords: [backend, api, server, database]
|
|
5
9
|
argument-hint: "[framework] [task]"
|
|
6
|
-
|
|
10
|
+
metadata:
|
|
11
|
+
author: haposoft
|
|
12
|
+
version: "1.0.0"
|
|
7
13
|
---
|
|
8
|
-
|
|
9
14
|
# Backend Development Skill
|
|
10
15
|
|
|
11
16
|
Production-ready backend development with modern technologies, best practices, and proven patterns.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:brainstorm
|
|
3
3
|
description: "Scout-first brainstorming for unclear ideas, architectural choices, scope gates, and translating raw intent into a spec-ready design."
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke before choosing among unclear technical options or scope."
|
|
6
|
+
category: utilities
|
|
7
|
+
keywords: [ideation, tradeoffs, decisions, scope]
|
|
4
8
|
argument-hint: "<idea_or_problem>"
|
|
5
|
-
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "2.1.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Brainstorming Skill
|
|
9
14
|
|
|
10
15
|
You execute CafeKit's pre-spec design workflow. Your job is to turn a raw idea into a validated, spec-ready design without writing code or starting implementation.
|
|
@@ -2,10 +2,15 @@
|
|
|
2
2
|
name: hapo:chrome-devtools
|
|
3
3
|
description: Automate browsers with Puppeteer CLI scripts and persistent sessions. Use for screenshots, performance analysis, network monitoring, web scraping, form automation, JavaScript debugging.
|
|
4
4
|
license: Apache-2.0
|
|
5
|
+
user-invocable: true
|
|
6
|
+
when_to_use: "Invoke to inspect, debug, or profile a page via Chrome DevTools."
|
|
7
|
+
category: dev-tools
|
|
8
|
+
keywords: [devtools, chrome, debug, profiling]
|
|
5
9
|
argument-hint: "[url or task]"
|
|
6
|
-
|
|
10
|
+
metadata:
|
|
11
|
+
author: haposoft
|
|
12
|
+
version: "1.1.0"
|
|
7
13
|
---
|
|
8
|
-
|
|
9
14
|
# Chrome DevTools Agent Skill
|
|
10
15
|
|
|
11
16
|
Browser automation via Puppeteer scripts with persistent sessions. All scripts output JSON.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:code-review
|
|
3
3
|
description: "Adversarial code review with technical rigor. Supports 3-Stage Protocol with ai-multimodal injection for multimodal spec compliance. Red-team analysis finds security holes, logic gaps, and architecture violations."
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke to review a diff for correctness and quality before merge."
|
|
6
|
+
category: dev-tools
|
|
7
|
+
keywords: [review, diff, quality, correctness]
|
|
4
8
|
argument-hint: "[#PR | COMMIT | --pending | scope]"
|
|
5
|
-
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "1.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Code Review
|
|
9
14
|
|
|
10
15
|
Adversarial code review with technical rigor, evidence-based claims, and visual/document intelligence via the `hapo:ai-multimodal` Hub.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:debug
|
|
3
3
|
description: "Use before fixing any bug, failing test, CI/CD failure, production incident, performance issue, UI regression, flaky test, or unexpected behavior. Diagnostic-only root-cause workflow with evidence, hypotheses, blast-radius mapping, and verification plan."
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke for evidence-first root-cause diagnosis before any fix."
|
|
6
|
+
category: dev-tools
|
|
7
|
+
keywords: [debug, diagnosis, root-cause, evidence]
|
|
4
8
|
argument-hint: "[issue] --quick|--ci|--frontend|--perf"
|
|
5
|
-
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "1.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Debug - Evidence-First Root Cause Analysis
|
|
9
14
|
|
|
10
15
|
Debugging is diagnosis, not repair. Find the source of the failure before changing product code.
|
|
@@ -1,9 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:develop
|
|
3
3
|
description: "Code execution engine: Reads specs and implements code end-to-end with automatic code review, self-healing, and visual implementation notes."
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke to implement specs and tasks end-to-end after scope is clear."
|
|
6
|
+
category: utilities
|
|
7
|
+
keywords: [implementation, specs, build, orchestration]
|
|
4
8
|
argument-hint: "[feature-name|specs-directory-path] [task-file] [--flash] [--no-notes]"
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "1.0.0"
|
|
5
12
|
---
|
|
6
|
-
|
|
7
13
|
# Develop — Feature Implementation (Task-Orchestrated Build)
|
|
8
14
|
|
|
9
15
|
Reads the project specification (`hapo:specs`) and implements code through a disciplined task loop. In specific-task mode it behaves like a surgical executor. In full-spec mode it behaves like a sequential orchestrator, processing one unblocked task at a time and syncing state after every verified task.
|
|
@@ -2,10 +2,15 @@
|
|
|
2
2
|
name: hapo:devops
|
|
3
3
|
description: Deploy to Cloudflare (Workers, R2, D1), Docker, GCP (Cloud Run, GKE), Kubernetes (kubectl, Helm). Use for serverless, containers, CI/CD, GitOps, security audit.
|
|
4
4
|
license: MIT
|
|
5
|
+
user-invocable: true
|
|
6
|
+
when_to_use: "Invoke to deploy, containerize, or set up CI/CD and infra."
|
|
7
|
+
category: devops
|
|
8
|
+
keywords: [deploy, docker, ci-cd, kubernetes]
|
|
5
9
|
argument-hint: "[platform] [task]"
|
|
6
|
-
|
|
10
|
+
metadata:
|
|
11
|
+
author: haposoft
|
|
12
|
+
version: "2.0.0"
|
|
7
13
|
---
|
|
8
|
-
|
|
9
14
|
# DevOps Skill
|
|
10
15
|
|
|
11
16
|
Deploy and manage cloud infrastructure across Cloudflare, Docker, Google Cloud, and Kubernetes.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:docs
|
|
3
3
|
description: "Create, update, summarize, or reconstruct project/system documentation from source code. Use reconstruct mode for as-is documentation of existing or legacy systems with evidence and uncertainty tracking."
|
|
4
|
-
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke to create, update, or reconstruct project documentation from source."
|
|
6
|
+
category: document-skills
|
|
7
|
+
keywords: [docs, reconstruct, documentation, evidence]
|
|
5
8
|
argument-hint: "[--init|--update|--summarize|--reconstruct] [scope]"
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "1.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Docs
|
|
9
14
|
|
|
10
15
|
Project documentation workflow for CafeKit.
|
|
@@ -2,11 +2,14 @@
|
|
|
2
2
|
name: hapo:docx
|
|
3
3
|
description: Create, edit, analyze .docx Word documents. Use for document creation, tracked changes, comments, formatting preservation, text extraction, template modification.
|
|
4
4
|
license: Proprietary. LICENSE.txt has complete terms
|
|
5
|
+
user-invocable: true
|
|
6
|
+
when_to_use: "Invoke to read, create, or edit Word .docx documents."
|
|
7
|
+
category: document-skills
|
|
8
|
+
keywords: [docx, word, document, office]
|
|
5
9
|
metadata:
|
|
6
10
|
author: haposoft
|
|
7
11
|
version: "1.0.0"
|
|
8
12
|
---
|
|
9
|
-
|
|
10
13
|
# DOCX creation, editing, and analysis
|
|
11
14
|
|
|
12
15
|
## Overview
|
|
@@ -2,9 +2,14 @@
|
|
|
2
2
|
name: hapo:frontend-design
|
|
3
3
|
description: Create polished frontend interfaces from designs/screenshots/videos. Use for web components, 3D experiences, replicating UI designs, quick prototypes, immersive interfaces, avoiding AI slop.
|
|
4
4
|
license: Complete terms in LICENSE.txt
|
|
5
|
-
|
|
5
|
+
user-invocable: true
|
|
6
|
+
when_to_use: "Invoke to translate mockups or screenshots into UI implementation."
|
|
7
|
+
category: frontend
|
|
8
|
+
keywords: [design, mockup, ui, replication]
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "1.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
|
|
9
14
|
|
|
10
15
|
**IMPORTANT**: MUST follow Design Thinking, Frontend Aesthetics Guidelines, Asset & Analysis References, and Anti-Patterns (AI Slop) sections below. DO NOT skip these rules.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:frontend-development
|
|
3
3
|
description: Build React/TypeScript frontends with modern patterns. Use for components, Suspense, lazy loading, useSuspenseQuery, MUI v7 styling, TanStack Router, performance optimization.
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke to build React/TS components with best practices."
|
|
6
|
+
category: frontend
|
|
7
|
+
keywords: [frontend, react, typescript, components]
|
|
4
8
|
argument-hint: "[component or feature]"
|
|
5
|
-
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "1.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Frontend Development Guidelines
|
|
9
14
|
|
|
10
15
|
## Purpose
|
|
@@ -1,12 +1,14 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:generate-graph
|
|
3
3
|
description: >-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke to build a queryable graph or diagram from code or data."
|
|
6
|
+
category: utilities
|
|
7
|
+
keywords: [graph, visualization, diagram, analysis]
|
|
8
|
+
metadata:
|
|
9
|
+
author: haposoft
|
|
10
|
+
version: "1.0.0"
|
|
8
11
|
---
|
|
9
|
-
|
|
10
12
|
# Generate Graph
|
|
11
13
|
|
|
12
14
|
Generate production-quality SVG technical diagrams exported as PNG via `rsvg-convert`.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:git
|
|
3
3
|
description: "Hapo Native Git Operations & Worktree Management. Handles safe commits, conventional split, branch finish choices, secret scanning, and sibling-branch worktrees locally."
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke for commits, PRs, branch hygiene, or worktree management."
|
|
6
|
+
category: dev-tools
|
|
7
|
+
keywords: [git, commits, pr, worktree]
|
|
4
8
|
argument-hint: "commit | push | pr | finish | worktree <feature-desc>"
|
|
5
|
-
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "1.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Git Operations & Worktree
|
|
9
14
|
|
|
10
15
|
This skill merges Version Control Systems (VSC) capabilities and parallel Worktree management into a single, clean-room execution engine utilizing pure Bash commands rather than proprietary Node scripts.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:hotfix
|
|
3
3
|
description: "ALWAYS activate this skill when you are asked to FIX a bug, error, test failure, CI/CD issue, type error, lint error, log error, UI issue, or code problem. Uses hapo:debug for evidence-first diagnosis before any code change."
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke to fix a bug or failure with scout-first diagnosis before change."
|
|
6
|
+
category: dev-tools
|
|
7
|
+
keywords: [hotfix, fix, bug, diagnosis]
|
|
4
8
|
argument-hint: "[issue] --quick|--parallel|--from-debug"
|
|
5
|
-
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "1.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Hotfix - Structured Bug Elimination
|
|
9
14
|
|
|
10
15
|
Kill bugs systematically. No guessing. Evidence first, fix second.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: impact-analysis
|
|
2
|
+
name: hapo:impact-analysis
|
|
3
3
|
description: "Analyze code change impacts and generate test scenarios. Use after code changes, before commit, or when checking for regressions. Automatically detects affected files, dependencies, and edge cases."
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke after code changes to map regression impact and test scenarios."
|
|
6
|
+
category: dev-tools
|
|
7
|
+
keywords: [impact, regression, dependencies, testing]
|
|
4
8
|
argument-hint: "[files] OR auto"
|
|
5
|
-
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "1.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Impact Analysis - Impact Analysis & Test Guidance
|
|
9
14
|
|
|
10
15
|
Analyze the impact of code changes and provide detailed test guidance to prevent regression bugs.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:inspect
|
|
3
3
|
description: "Fast codebase discovery using parallel agents. Use for file discovery, task context gathering, quick searches across directories. Supports internal (Explore) and external (Gemini) agents."
|
|
4
|
-
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke for fast parallel codebase discovery and file location."
|
|
6
|
+
category: discovery
|
|
7
|
+
keywords: [discovery, search, explore, context]
|
|
5
8
|
argument-hint: "[search-target] [ext]"
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "2.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Inspect
|
|
9
14
|
|
|
10
15
|
Fast, token-efficient codebase discovery using parallel agents to find files needed for tasks.
|
|
@@ -2,10 +2,15 @@
|
|
|
2
2
|
name: hapo:mobile-development
|
|
3
3
|
description: Build mobile apps with React Native, Flutter, Swift/SwiftUI, Kotlin/Jetpack Compose. Use for iOS/Android, mobile UX, performance optimization, offline-first, app store deployment.
|
|
4
4
|
license: MIT
|
|
5
|
+
user-invocable: true
|
|
6
|
+
when_to_use: "Invoke to build or modify mobile app features and UI."
|
|
7
|
+
category: frontend
|
|
8
|
+
keywords: [mobile, app, ios, android]
|
|
5
9
|
argument-hint: "[platform] [feature]"
|
|
6
|
-
|
|
10
|
+
metadata:
|
|
11
|
+
author: haposoft
|
|
12
|
+
version: "1.0.0"
|
|
7
13
|
---
|
|
8
|
-
|
|
9
14
|
# Mobile Development Skill
|
|
10
15
|
|
|
11
16
|
Production-ready mobile development with modern frameworks, best practices, and mobile-first thinking patterns.
|
|
@@ -2,11 +2,14 @@
|
|
|
2
2
|
name: hapo:pdf
|
|
3
3
|
description: Extract text/tables, create, merge, split PDFs. Fill PDF forms programmatically. Use for PDF processing, generation, form filling, document analysis, batch operations.
|
|
4
4
|
license: Proprietary. LICENSE.txt has complete terms
|
|
5
|
+
user-invocable: true
|
|
6
|
+
when_to_use: "Invoke to read, extract, or generate PDF documents."
|
|
7
|
+
category: document-skills
|
|
8
|
+
keywords: [pdf, extract, document, generate]
|
|
5
9
|
metadata:
|
|
6
10
|
author: haposoft
|
|
7
11
|
version: "1.0.0"
|
|
8
12
|
---
|
|
9
|
-
|
|
10
13
|
# PDF Processing Guide
|
|
11
14
|
|
|
12
15
|
## Overview
|
|
@@ -2,11 +2,14 @@
|
|
|
2
2
|
name: hapo:pptx
|
|
3
3
|
description: Create, edit, analyze .pptx PowerPoint files. Use for presentations, slides, layouts, speaker notes, template modification, content extraction, slide generation.
|
|
4
4
|
license: Proprietary. LICENSE.txt has complete terms
|
|
5
|
+
user-invocable: true
|
|
6
|
+
when_to_use: "Invoke to read, create, or edit PowerPoint .pptx slides."
|
|
7
|
+
category: document-skills
|
|
8
|
+
keywords: [pptx, powerpoint, slides, office]
|
|
5
9
|
metadata:
|
|
6
10
|
author: haposoft
|
|
7
11
|
version: "1.0.0"
|
|
8
12
|
---
|
|
9
|
-
|
|
10
13
|
# PPTX creation, editing, and analysis
|
|
11
14
|
|
|
12
15
|
## Overview
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:question
|
|
3
3
|
description: "Answer questions with evidence. Use when the user asks about project behavior, source code, specs, docs, configuration, dependencies, or external technical information; inspect the repo first, use internet/current docs when repo evidence is insufficient, and ask back only when the question cannot be answered safely."
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke to answer project or technical questions with repo-first evidence."
|
|
6
|
+
category: utilities
|
|
7
|
+
keywords: [question, evidence, answer, research]
|
|
4
8
|
argument-hint: "<question> [--repo|--web|--both|--brief|--deep]"
|
|
5
|
-
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "1.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Question Skill
|
|
9
14
|
|
|
10
15
|
`hapo:question` is an evidence-backed question-answering skill. It answers user questions by checking the local project first, then external/current sources when the repository cannot answer the question.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:react-best-practices
|
|
3
3
|
description: React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke to apply React performance and architecture best practices."
|
|
6
|
+
category: frontend
|
|
7
|
+
keywords: [react, performance, patterns, hooks]
|
|
4
8
|
argument-hint: "[component or pattern]"
|
|
5
|
-
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "1.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Vercel React Best Practices
|
|
9
14
|
|
|
10
15
|
Comprehensive performance optimization guide for React and Next.js applications, maintained by Vercel. Contains 45 rules across 8 categories, prioritized by impact to guide automated refactoring and code generation.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:research
|
|
3
3
|
description: "Research technical solutions and analyze architectures. Acts as a command facade to trigger the 'researcher' subagent for multi-source verification and deep report synthesis."
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke for deep technical research and solution evaluation before building."
|
|
6
|
+
category: research
|
|
7
|
+
keywords: [research, evaluation, analysis, solutions]
|
|
4
8
|
argument-hint: "<topic_or_question>"
|
|
5
|
-
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "2.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Research (Delegation Facade)
|
|
9
14
|
|
|
10
15
|
**Mantra:** YAGNI, KISS, DRY. Be brutal, straight to the point, and strictly authoritative.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:specs
|
|
3
3
|
description: "Structured specification workflow — from vague idea to actionable task list. Includes init, requirements, design, task breakdown, review, and archiving."
|
|
4
|
-
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke to turn a vague idea into an actionable, gated specification."
|
|
6
|
+
category: utilities
|
|
7
|
+
keywords: [specs, requirements, design, tasks]
|
|
5
8
|
argument-hint: "<feature-description> | status | resume | --validate | archive"
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "2.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Specs (SDD — Specification-Driven Development)
|
|
9
14
|
|
|
10
15
|
> A structured specification system that turns vague ideas into actionable, implementable task lists.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:sync
|
|
3
3
|
description: "Dumb-proof status tracker and file synchronizer. Updates spec.json, task_registry, and tasks/*.md without breaking structural schemas. Includes Auto-Audit."
|
|
4
|
-
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke to synchronize spec state, docs, or task tracking after changes."
|
|
6
|
+
category: utilities
|
|
7
|
+
keywords: [sync, state, tracking, consistency]
|
|
5
8
|
argument-hint: "<feature_name> <task_id|task-file> <status> [blocker] | phase <feature_name> <next_phase> | audit <feature_name>"
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "1.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Sync (State Tracking Protocol)
|
|
9
14
|
|
|
10
15
|
This skill safely bridges the gap between active development state and physical documentation files (`spec.json` + `task_registry` + `tasks/task-R*.md`). Instead of relying on risky raw AI edits, this skill executes precise contextual replacements.
|
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:test
|
|
3
3
|
description: "Run and verify project tests across all scopes: unit, integration, e2e, and UI. Blast-radius scoping for speed, chrome-devtools for UI verification, structured verdicts for downstream automation."
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke to run and verify unit, integration, e2e, and UI tests."
|
|
6
|
+
category: testing
|
|
7
|
+
keywords: [test, unit, integration, e2e]
|
|
4
8
|
argument-hint: "[scope|--full|--ui <url>|--ui-auth <url>|--ui-flow <url>]"
|
|
5
|
-
|
|
9
|
+
metadata:
|
|
10
|
+
author: haposoft
|
|
11
|
+
version: "2.0.0"
|
|
6
12
|
---
|
|
7
|
-
|
|
8
13
|
# Test — Verify Implementation Quality
|
|
9
14
|
|
|
10
15
|
Run the project's test suite, analyze results, and return a structured verdict.
|
|
@@ -1,9 +1,14 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:ui-ux-pro-max
|
|
3
3
|
description: "UI/UX design intelligence for web and mobile. Includes 50+ styles, 161 color palettes, 57 font pairings, 161 product types, 99 UX guidelines, and 25 chart types across 10 stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind, shadcn/ui, and HTML/CSS). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, and check UI/UX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, and mobile app. Elements: button, modal, navbar, sidebar, card, table, form, and chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, and flat design. Topics: color systems, accessibility, animation, layout, typography, font pairing, spacing, interaction states, shadow, and gradient. Integrations: shadcn/ui MCP for component search and examples."
|
|
4
|
-
|
|
4
|
+
user-invocable: true
|
|
5
|
+
when_to_use: "Invoke to choose colors, fonts, layout, and design systems."
|
|
6
|
+
category: frontend
|
|
7
|
+
keywords: [ui, ux, design-system, layout]
|
|
8
|
+
metadata:
|
|
9
|
+
author: haposoft
|
|
10
|
+
version: "1.1.0"
|
|
5
11
|
---
|
|
6
|
-
|
|
7
12
|
# UI/UX Pro Max - Design Intelligence
|
|
8
13
|
|
|
9
14
|
Comprehensive design guide for web and mobile applications. Contains 50+ styles, 161 color palettes, 57 font pairings, 161 product types with reasoning rules, 99 UX guidelines, and 25 chart types across 10 technology stacks. Searchable database with priority-based recommendations.
|
|
@@ -2,10 +2,15 @@
|
|
|
2
2
|
name: hapo:web-testing
|
|
3
3
|
description: Web testing with Playwright, Vitest, k6. E2E/unit/integration/load/security/visual/a11y testing. Use for test automation, flakiness, Core Web Vitals, mobile gestures, cross-browser.
|
|
4
4
|
license: Apache-2.0
|
|
5
|
+
user-invocable: true
|
|
6
|
+
when_to_use: "Invoke to test web flows in a real browser end-to-end."
|
|
7
|
+
category: testing
|
|
8
|
+
keywords: [web-testing, e2e, browser, validation]
|
|
5
9
|
argument-hint: "[test-type] [target]"
|
|
6
|
-
|
|
10
|
+
metadata:
|
|
11
|
+
author: haposoft
|
|
12
|
+
version: "3.0.0"
|
|
7
13
|
---
|
|
8
|
-
|
|
9
14
|
# Web Testing Skill
|
|
10
15
|
|
|
11
16
|
Comprehensive web testing: unit, integration, E2E, load, security, visual regression, accessibility.
|
|
@@ -2,11 +2,14 @@
|
|
|
2
2
|
name: hapo:xlsx
|
|
3
3
|
description: Create, edit, analyze spreadsheets (.xlsx, .csv, .tsv). Use for Excel formulas, data analysis, visualization, formatting, pivot tables, charts, formula recalculation.
|
|
4
4
|
license: Proprietary. LICENSE.txt has complete terms
|
|
5
|
+
user-invocable: true
|
|
6
|
+
when_to_use: "Invoke to read, create, or edit Excel .xlsx spreadsheets."
|
|
7
|
+
category: document-skills
|
|
8
|
+
keywords: [xlsx, excel, spreadsheet, office]
|
|
5
9
|
metadata:
|
|
6
10
|
author: haposoft
|
|
7
11
|
version: "1.0.0"
|
|
8
12
|
---
|
|
9
|
-
|
|
10
13
|
# Requirements for Outputs
|
|
11
14
|
|
|
12
15
|
## All Excel files
|