create-harness-vibe-coding 0.8.7 → 0.8.9

package/templates/optional/skills/python-backend/.claude/skills/python-backend/SKILL.md

@@ -1,40 +1,40 @@
----
-name: python-backend
-description: Python backend workflow for API changes, service logic, FastAPI-style routes, and unittest or pytest verification.
----
-
-# Python Backend
-
-## When To Use
-
-Use this skill when changing Python API routes, service logic, persistence boundaries, background jobs, or backend tests.
-
-## Docs To Load
-
-- `Harness/workflows/python-backend.md`
-- `Harness/PROGRESS.md` and current task `tasks/<id>/PLAN.md`
-- Project backend README, API docs, dependency files, and test configuration.
-
-## Required Inputs
-
-- Target behavior, endpoint, service, or bug.
-- Existing test command and runtime setup.
-- Database, environment variable, or fixture constraints.
-
-## Allowed Writes
-
-- Python source, tests, fixtures, and backend docs in the task scope.
-- Local evidence artifacts such as test output snippets.
-- Current task `tasks/<id>/PLAN.md` when the task requires plan tracking.
-
-## Output Format
-
-Return files changed, API or behavior summary, tests run, important logs, migration/config notes, and remaining risks.
-
-## PROGRESS.md & Task PLAN.md Updates
-
-Update `Harness/tasks/<task-id>/PLAN.md` only when executing a tracked plan item or recording required validation evidence.
-
-## dispatch.md Usage
-
-Use `Harness/dispatch.md` for separable backend work such as API implementation, database changes, and test coverage.
+---
+name: python-backend
+description: Python backend workflow for API changes, service logic, FastAPI-style routes, and unittest or pytest verification.
+---
+
+# Python Backend
+
+## When To Use
+
+Use this skill when changing Python API routes, service logic, persistence boundaries, background jobs, or backend tests.
+
+## Docs To Load
+
+- `Harness/workflows/python-backend.md`
+- `Harness/PROGRESS.md` and current task `tasks/<id>/PLAN.md`
+- Project backend README, API docs, dependency files, and test configuration.
+
+## Required Inputs
+
+- Target behavior, endpoint, service, or bug.
+- Existing test command and runtime setup.
+- Database, environment variable, or fixture constraints.
+
+## Allowed Writes
+
+- Python source, tests, fixtures, and backend docs in the task scope.
+- Local evidence artifacts such as test output snippets.
+- Current task `tasks/<id>/PLAN.md` when the task requires plan tracking.
+
+## Output Format
+
+Return files changed, API or behavior summary, tests run, important logs, migration/config notes, and remaining risks.
+
+## PROGRESS.md & Task PLAN.md Updates
+
+Update `Harness/tasks/<task-id>/PLAN.md` only when executing a tracked plan item or recording required validation evidence.
+
+## dispatch.md Usage
+
+Use `Harness/dispatch.md` for separable backend work such as API implementation, database changes, and test coverage.

package/templates/optional/skills/python-backend/Harness/workflows/python-backend.md

@@ -1,34 +1,34 @@
-# Python Backend Workflow
-
-## Required Evidence
-
-- Python executable, version, and dependency manager detected.
-- Unit/integration test command and result.
-- API smoke evidence for changed endpoints when applicable.
-- Migration, fixture, or environment assumptions.
-
-## Common Commands
-
-```powershell
-python --version
-py --version
-python3 --version
-python -m unittest discover -s tests
-py -m unittest discover -s tests
-python3 -m unittest discover -s tests
-python -m pytest
-python -m pytest tests
-uv run pytest
-poetry run pytest
-python -m uvicorn app.main:app --reload
-```
-
-Prefer commands already documented by the project. When no project-specific command is documented, detect an available Python executable in the current shell (`python`, then `py`, then `python3`) and run the matching `-m unittest discover -s tests` or pytest command. `unittest` is first-class for standard-library test suites; do not require pytest when the project already uses unittest.
-
-## Fallback
-
-If unittest, pytest, or the app runner is unavailable, run targeted Python modules, import checks, or framework-specific tests that already exist. Do not create or install a new backend stack without approval.
-
-## Windows Notes
-
-Virtual environment activation is usually `.\\.venv\\Scripts\\Activate.ps1`. If script execution is blocked, use the environment's Python executable directly, for example `.\\.venv\\Scripts\\python.exe -m unittest discover -s tests` or `.\\.venv\\Scripts\\python.exe -m pytest`.
+# Python Backend Workflow
+
+## Required Evidence
+
+- Python executable, version, and dependency manager detected.
+- Unit/integration test command and result.
+- API smoke evidence for changed endpoints when applicable.
+- Migration, fixture, or environment assumptions.
+
+## Common Commands
+
+```powershell
+python --version
+py --version
+python3 --version
+python -m unittest discover -s tests
+py -m unittest discover -s tests
+python3 -m unittest discover -s tests
+python -m pytest
+python -m pytest tests
+uv run pytest
+poetry run pytest
+python -m uvicorn app.main:app --reload
+```
+
+Prefer commands already documented by the project. When no project-specific command is documented, detect an available Python executable in the current shell (`python`, then `py`, then `python3`) and run the matching `-m unittest discover -s tests` or pytest command. `unittest` is first-class for standard-library test suites; do not require pytest when the project already uses unittest.
+
+## Fallback
+
+If unittest, pytest, or the app runner is unavailable, run targeted Python modules, import checks, or framework-specific tests that already exist. Do not create or install a new backend stack without approval.
+
+## Windows Notes
+
+Virtual environment activation is usually `.\\.venv\\Scripts\\Activate.ps1`. If script execution is blocked, use the environment's Python executable directly, for example `.\\.venv\\Scripts\\python.exe -m unittest discover -s tests` or `.\\.venv\\Scripts\\python.exe -m pytest`.

package/templates/optional/skills/ts-react-frontend/.claude/skills/ts-react-frontend/SKILL.md

@@ -1,43 +1,43 @@
----
-name: ts-react-frontend
-description: TypeScript React frontend workflow for components, state, routing, typecheck, tests, builds, and browser smoke evidence.
----
-
-# TypeScript React Frontend
-
-## When To Use
-
-Use this skill when changing React components, hooks, routes, client state, styling, build configuration, or frontend tests.
-For user-visible changes, typecheck, build, and unit tests are not enough; include real-browser smoke or screenshot evidence before claiming acceptance.
-
-## Docs To Load
-
-- `Harness/workflows/ts-react-frontend.md`
-- `Harness/PROGRESS.md` and current task `tasks/<id>/PLAN.md`
-- Existing frontend README, package scripts, design system, and test setup.
-
-## Required Inputs
-
-- Screen, component, or flow being changed.
-- Expected behavior and acceptance criteria.
-- Existing package manager and verification commands.
-- Selector contract: stable accessible labels/roles and `data-testid` hooks for critical inputs, buttons, filters, rows, empty/error/loading states, and other targetable UI states.
-
-## Allowed Writes
-
-- Frontend source, styles, tests, and focused docs in task scope.
-- Generated evidence such as screenshots or test reports in existing artifact paths.
-- Current task `tasks/<id>/PLAN.md` when tracking a plan item.
-
-## Output Format
-
-Return changed files, UI behavior summary, commands run, browser or test evidence, and unresolved risks.
-Include selectors added or verified for CDP/Playwright/manual checks.
-
-## PROGRESS.md & Task PLAN.md Updates
-
-Update `Harness/tasks/<task-id>/PLAN.md` only when executing a tracked task or recording required validation evidence.
-
-## dispatch.md Usage
-
-Use `Harness/dispatch.md` when independent frontend tasks can run in parallel, such as components, tests, and browser checks.
+---
+name: ts-react-frontend
+description: TypeScript React frontend workflow for components, state, routing, typecheck, tests, builds, and browser smoke evidence.
+---
+
+# TypeScript React Frontend
+
+## When To Use
+
+Use this skill when changing React components, hooks, routes, client state, styling, build configuration, or frontend tests.
+For user-visible changes, typecheck, build, and unit tests are not enough; include real-browser smoke or screenshot evidence before claiming acceptance.
+
+## Docs To Load
+
+- `Harness/workflows/ts-react-frontend.md`
+- `Harness/PROGRESS.md` and current task `tasks/<id>/PLAN.md`
+- Existing frontend README, package scripts, design system, and test setup.
+
+## Required Inputs
+
+- Screen, component, or flow being changed.
+- Expected behavior and acceptance criteria.
+- Existing package manager and verification commands.
+- Selector contract: stable accessible labels/roles and `data-testid` hooks for critical inputs, buttons, filters, rows, empty/error/loading states, and other targetable UI states.
+
+## Allowed Writes
+
+- Frontend source, styles, tests, and focused docs in task scope.
+- Generated evidence such as screenshots or test reports in existing artifact paths.
+- Current task `tasks/<id>/PLAN.md` when tracking a plan item.
+
+## Output Format
+
+Return changed files, UI behavior summary, commands run, browser or test evidence, and unresolved risks.
+Include selectors added or verified for CDP/Playwright/manual checks.
+
+## PROGRESS.md & Task PLAN.md Updates
+
+Update `Harness/tasks/<task-id>/PLAN.md` only when executing a tracked task or recording required validation evidence.
+
+## dispatch.md Usage
+
+Use `Harness/dispatch.md` when independent frontend tasks can run in parallel, such as components, tests, and browser checks.

package/templates/optional/skills/ts-react-frontend/Harness/workflows/ts-react-frontend.md

@@ -1,35 +1,35 @@
-# TypeScript React Frontend Workflow
-
-## Required Evidence
-
-- Package manager and scripts detected.
-- Typecheck, lint, test, or build results according to project conventions.
-- Real-browser smoke or screenshot evidence for user-visible changes.
-- Console/runtime error check result for the changed screen or flow.
-- Notes on responsive behavior and important interaction states.
+# TypeScript React Frontend Workflow
+
+## Required Evidence
+
+- Package manager and scripts detected.
+- Typecheck, lint, test, or build results according to project conventions.
+- Real-browser smoke or screenshot evidence for user-visible changes.
+- Console/runtime error check result for the changed screen or flow.
+- Notes on responsive behavior and important interaction states.
 - Stable accessible labels/roles and stable test selectors such as `data-testid` are required for critical UI controls and states: inputs, buttons, filters, rows, empty/error/loading states.
-
-Typecheck, build, and unit tests are necessary signals but are not enough for user-visible React changes. Before claiming UI acceptance, load the app in a real browser by Playwright, Chrome DevTools/CDP, or a documented manual run and capture screenshot/trace/console evidence.
-For TS/React UI work, capture the selector contract in the feature doc before implementation so tests and manual checks can target stable selectors instead of component internals or brittle DOM paths.
-
-## Common Commands
-
-```powershell
-npm run typecheck
-npm run lint
-npm test
-npm run build
-npm run dev
-pnpm test
-yarn test
-```
-
-Use the package manager and scripts already present in the repository.
-
-## Fallback
-
-If no formal checks exist, run the closest available build or dev command, inspect the changed UI manually, and document the missing automation. Do not add dependencies unless the task requires it and the user approves.
-
-## Windows Notes
-
-Use PowerShell syntax for environment variables: `$env:VITE_API_URL='http://localhost:8000'; npm run dev`. Quote paths and prefer package scripts over shell-specific command chains.
+
+Typecheck, build, and unit tests are necessary signals but are not enough for user-visible React changes. Before claiming UI acceptance, load the app in a real browser by Playwright, Chrome DevTools/CDP, or a documented manual run and capture screenshot/trace/console evidence.
+For TS/React UI work, capture the selector contract in the feature doc before implementation so tests and manual checks can target stable selectors instead of component internals or brittle DOM paths.
+
+## Common Commands
+
+```powershell
+npm run typecheck
+npm run lint
+npm test
+npm run build
+npm run dev
+pnpm test
+yarn test
+```
+
+Use the package manager and scripts already present in the repository.
+
+## Fallback
+
+If no formal checks exist, run the closest available build or dev command, inspect the changed UI manually, and document the missing automation. Do not add dependencies unless the task requires it and the user approves.
+
+## Windows Notes
+
+Use PowerShell syntax for environment variables: `$env:VITE_API_URL='http://localhost:8000'; npm run dev`. Quote paths and prefer package scripts over shell-specific command chains.

package/templates/optional/skills/ui-ux-review/.claude/skills/ui-ux-review/SKILL.md

@@ -1,40 +1,40 @@
----
-name: ui-ux-review
-description: Screenshot-driven UI and UX review for responsive behavior, accessibility, visual polish, and task clarity.
----
-
-# UI/UX Review
-
-## When To Use
-
-Use this skill when reviewing or changing user-facing screens, layouts, visual hierarchy, interaction states, accessibility, or responsive behavior.
-
-## Docs To Load
-
-- `Harness/workflows/ui-ux-review.md`
-- `Harness/PROGRESS.md` and current task `tasks/<id>/PLAN.md`
-- Existing design system, component, or style documentation.
-
-## Required Inputs
-
-- Screens, routes, or components under review.
-- Target users and primary tasks.
-- Breakpoints, themes, and accessibility expectations.
-
-## Allowed Writes
-
-- UI code and style files already in scope for the task.
-- Screenshot or audit artifacts in existing evidence folders.
-- Current task `tasks/<id>/PLAN.md` when the review is part of a tracked plan.
-
-## Output Format
-
-Return prioritized findings with file or screen references, evidence, recommended fixes, commands run, and residual risks.
-
-## PROGRESS.md & Task PLAN.md Updates
-
-Update current task `tasks/<id>/PLAN.md` only for tracked review tasks or when recording required evidence.
-
-## dispatch.md Usage
-
-Use `Harness/dispatch.md` only for independent review streams such as separate routes or breakpoints.
+---
+name: ui-ux-review
+description: Screenshot-driven UI and UX review for responsive behavior, accessibility, visual polish, and task clarity.
+---
+
+# UI/UX Review
+
+## When To Use
+
+Use this skill when reviewing or changing user-facing screens, layouts, visual hierarchy, interaction states, accessibility, or responsive behavior.
+
+## Docs To Load
+
+- `Harness/workflows/ui-ux-review.md`
+- `Harness/PROGRESS.md` and current task `tasks/<id>/PLAN.md`
+- Existing design system, component, or style documentation.
+
+## Required Inputs
+
+- Screens, routes, or components under review.
+- Target users and primary tasks.
+- Breakpoints, themes, and accessibility expectations.
+
+## Allowed Writes
+
+- UI code and style files already in scope for the task.
+- Screenshot or audit artifacts in existing evidence folders.
+- Current task `tasks/<id>/PLAN.md` when the review is part of a tracked plan.
+
+## Output Format
+
+Return prioritized findings with file or screen references, evidence, recommended fixes, commands run, and residual risks.
+
+## PROGRESS.md & Task PLAN.md Updates
+
+Update current task `tasks/<id>/PLAN.md` only for tracked review tasks or when recording required evidence.
+
+## dispatch.md Usage
+
+Use `Harness/dispatch.md` only for independent review streams such as separate routes or breakpoints.

package/templates/optional/skills/ui-ux-review/Harness/workflows/ui-ux-review.md

@@ -1,26 +1,26 @@
-# UI/UX Review Workflow
-
-## Required Evidence
-
-- Screenshots for desktop and mobile views.
-- Notes on layout, typography, interaction states, accessibility, and empty/loading/error states.
-- Any automated accessibility, lint, or visual test output available in the project.
-
-## Common Commands
-
-```powershell
-npm run dev
-npm run lint
-npm run test
-npx playwright test
-```
-
-Use the project's existing commands first. Browser screenshots may come from Playwright, CDP, framework tooling, or manual capture.
-
-## Fallback
-
-When automation is unavailable, inspect the running UI manually at representative viewport sizes and document findings with screenshots. Avoid adding design or test dependencies without approval.
-
-## Windows Notes
-
-PowerShell does not support POSIX inline environment variables. Use `$env:NAME='value'; command` and quote screenshot paths with spaces.
+# UI/UX Review Workflow
+
+## Required Evidence
+
+- Screenshots for desktop and mobile views.
+- Notes on layout, typography, interaction states, accessibility, and empty/loading/error states.
+- Any automated accessibility, lint, or visual test output available in the project.
+
+## Common Commands
+
+```powershell
+npm run dev
+npm run lint
+npm run test
+npx playwright test
+```
+
+Use the project's existing commands first. Browser screenshots may come from Playwright, CDP, framework tooling, or manual capture.
+
+## Fallback
+
+When automation is unavailable, inspect the running UI manually at representative viewport sizes and document findings with screenshots. Avoid adding design or test dependencies without approval.
+
+## Windows Notes
+
+PowerShell does not support POSIX inline environment variables. Use `$env:NAME='value'; command` and quote screenshot paths with spaces.