@vyuhlabs/dxkit 2.4.8 → 2.5.0

package/templates/.claude/agents/onboarding.md

@@ -22,7 +22,7 @@ Read these first for context (skip any that don't exist):
 - `.claude/skills/learned/references/gotchas.md` — Known gotchas
 - `.claude/skills/learned/references/conventions.md` — Team conventions
 - `README.md` — Project readme
-- `package.json`, `go.mod`, `pyproject.toml`, `*.csproj` — Dependencies
+- `package.json`, `go.mod`, `pyproject.toml`, `*.csproj`, `Cargo.toml`, `Gemfile` — Dependencies
 
 ## How to Help
 
@@ -48,9 +48,10 @@ Prioritize by learning order:
 5. Tests — how things are verified
 
 ### If asked about setup/environment:
-1. Check for Makefile, docker-compose.yml, package.json scripts
-2. Walk through the setup process step by step
-3. Warn about common setup issues from gotchas.md
+1. Check for the standard entry points: `package.json` scripts, `docker-compose.yml`, `.devcontainer/`, language-specific build files
+2. Walk through the setup process step by step (clone → install deps → run the dev/test command shown in README)
+3. If the repo has dxkit installed, point them at `/doctor` for environment validation
+4. Warn about common setup issues from gotchas.md
 
 ## Rules
 

package/templates/.claude/agents-available/codebase-explorer.md

@@ -21,7 +21,7 @@ Explore this repository and generate a thorough understanding of:
 
 ### Phase 1: Orientation (broad scan)
 1. `Glob("**/*")` to see the directory tree
-2. Read top-level config files: `package.json`, `go.mod`, `pyproject.toml`, `*.csproj`, `Cargo.toml`, `Makefile`, `docker-compose.yml`
+2. Read top-level config files: `package.json`, `go.mod`, `pyproject.toml`, `*.csproj`, `Cargo.toml`, `Gemfile`, `pom.xml`, `build.gradle`, `docker-compose.yml`, `.devcontainer/`
 3. Read `README.md` if it exists
 4. Identify what languages, frameworks, and tools are in use
 

package/templates/.claude/agents-available/debugger.md

@@ -17,7 +17,7 @@ You are a debugging specialist. You trace root causes systematically, never gues
 
 ## Tools
 
-- Use `Bash` to run tests and reproduce failures: `make test`, `pytest -x`, `go test -run TestName -v`
+- Use `Bash` to run tests and reproduce failures with the project's native test runner (`npm test`, `pytest -x`, `go test -run TestName -v`, `dotnet test`, `cargo test`, etc.)
 - Use `Grep` to trace function calls, error messages, and variable usage
 - Use `Read` to examine the code around the failure point
 
@@ -26,4 +26,4 @@ You are a debugging specialist. You trace root causes systematically, never gues
 - Do not modify source code — diagnose and report only
 - Do not guess — if you're unsure, gather more evidence
 - Do not run destructive commands (no `rm`, `drop`, `reset`)
-- **NEVER read `.env` files** — if you suspect a config issue, use `make secrets-show`
+- **NEVER read `.env` files** — if you suspect a config issue, grep for the variable name only

package/templates/.claude/agents-available/health-auditor.md

@@ -47,10 +47,10 @@ You are a codebase health auditor. Your job is to give an honest, comprehensive
 - **Score: 0-10**
 
 ### 6. Developer Experience
-- Check for Makefile/scripts/package.json scripts (easy to run?)
+- Check for `package.json` scripts, project-specific run/test scripts (easy to run?)
 - Check for Docker/devcontainer setup
 - Check for CI/CD configuration
-- Check for pre-commit hooks
+- Check for pre-commit/pre-push hooks (`.githooks/` or equivalent)
 - **Score: 0-10**
 
 ## Output Format

package/templates/.claude/commands/doctor.md

@@ -2,20 +2,28 @@
 description: Diagnose development environment issues
 ---
 
-Diagnose this development environment. Check for common issues:
+Diagnose this development environment.
 
-## Checks
+## Step 1: dxkit doctor
 
-1. **Git**: `git --version` and repo status
-2. **Node** (if package.json): `node --version`, `npm --version`, check if `node_modules/` exists
-3. **Python** (if pyproject.toml): `python3 --version`, check virtual env, check if deps installed
-4. **Go** (if go.mod): `go version`, check if modules downloaded
-5. **C#** (if .csproj): `dotnet --version`
-6. **Rust** (if Cargo.toml): `rustc --version`, `cargo --version`
-7. **Docker** (if docker-compose.yml): `docker --version`, check if running
-8. **Make** (if Makefile): `make --version`
-9. **Claude Code DX**: check `.claude/` directory, `CLAUDE.md`, `.vyuh-dxkit.json`
+Run dxkit's own health check first — it covers tool availability (gitleaks, semgrep, cloc, etc.), `.claude/` install state, and hook configuration:
 
-If `Makefile` exists with `doctor` target, run `make doctor` instead.
+```bash
+npx vyuh-dxkit doctor 2>/dev/null
+```
+
+If the command isn't available, fall back to Step 2.
+
+## Step 2: Environment checks
+
+1. **Git**: `git --version` and `git status`
+2. **Node** (if `package.json`): `node --version` / `npm --version`; is `node_modules/` populated?
+3. **Python** (if `pyproject.toml`): `python3 --version`; virtual env activated? deps installed?
+4. **Go** (if `go.mod`): `go version`; modules downloaded?
+5. **.NET** (if `*.csproj`): `dotnet --version`
+6. **Rust** (if `Cargo.toml`): `rustc --version` / `cargo --version`
+7. **Docker** (if `docker-compose.yml`): `docker --version`; daemon running?
+8. **Hooks active**: `git config core.hooksPath` should report `.githooks` if dxkit hooks are installed
+9. **dxkit install**: `.claude/`, `CLAUDE.md`, `.vyuh-dxkit.json` present?
 
 Report any issues found and provide remediation steps.

package/templates/.claude/skills/build/SKILL.md.template

@@ -5,84 +5,76 @@ description: Build code, compile binaries, install dependencies, clean artifacts
 
 # Build
 
-## Commands
-- `make build` - Build all services
-- `make clean` - Remove build artifacts (bin/, pyc, coverage, tmp/)
-- `make dev` - Start all services (docker-compose up)
-- `make stop` - Stop all services (docker-compose down)
-
 {{#IF_PYTHON}}
-## Python Build
+## Python
 
-Python services use editable installs:
+Editable installs for development:
 ```bash
-pip install -e services/python/<service-name>/
+pip install -e <package-dir>/
 ```
 
 Build checks:
 - Syntax: `python3 -m py_compile <file>`
 - Types: `mypy src/`
-- Package: `python3 -m build` (if pyproject.toml has build-system)
+- Package: `python3 -m build` (if `pyproject.toml` has `build-system`)
 {{/IF_PYTHON}}
 
 {{#IF_GO}}
-## Go Build
+## Go
 
-Go services compile to `bin/`:
 ```bash
-go build -o bin/<service-name> ./services/go/<service-name>/
+go build ./...           # build everything
+go build -o bin/<name>   # build a specific binary to bin/
 ```
 
 Build flags:
 - `CGO_ENABLED=0` for static binaries (container-friendly)
-- `-ldflags="-s -w"` to strip debug info (smaller binary)
+- `-ldflags="-s -w"` to strip debug info
 - `GOOS=linux GOARCH=amd64` for cross-compilation
 {{/IF_GO}}
 
 {{#IF_NODE}}
-## Node.js Build
+## Node.js
 
 ```bash
-npm install          # install dependencies
-npm run build        # compile TypeScript / bundle
+npm install              # install dependencies
+npm run build            # compile TypeScript / bundle
 ```
 {{/IF_NODE}}
 
 {{#IF_NEXTJS}}
-## Next.js Build
+## Next.js
 
 ```bash
 cd frontend
 npm install
-npm run build        # production build (checks for errors)
-npm run dev          # development server
+npm run build            # production build (catches TS + import errors)
+npm run dev              # development server
 ```
-
-The build step catches TypeScript errors and missing imports — run it before deploying.
 {{/IF_NEXTJS}}
 
 {{#IF_RUST}}
-## Rust Build
+## Rust
 
 ```bash
-cargo build              # debug build
-cargo build --release    # optimized build
+cargo build              # debug
+cargo build --release    # optimized
 ```
 {{/IF_RUST}}
 
 {{#IF_CSHARP}}
-## C# Build
+## C#
 
 ```bash
-dotnet restore                       # restore NuGet packages
-dotnet build                         # debug build
-dotnet build --configuration Release # release build
+dotnet restore                       # NuGet packages
+dotnet build                         # debug
+dotnet build --configuration Release # release
 dotnet publish -c Release -o out/    # publish for deployment
 ```
 {{/IF_CSHARP}}
 
 {{#IF_DOCKER}}
-## Docker Build
+## Docker
 
 ```bash
 docker-compose build              # build all services

package/templates/.claude/skills/deploy/SKILL.md.template

@@ -5,39 +5,21 @@ description: Deploy services, release to production, push to cloud. Use when ask
 
 # Deployment
 
-## Commands
-- `make deploy` - Deploy services (configure deployment target first)
-- `make build` - Build before deploying
-- `make check` - Run full validation before deploying
+## Pre-deployment checklist
 
-## Pre-Deployment Checklist
-- [ ] `make check` passes (quality + tests + validation)
+- [ ] `/quality` and `/test` pass
 - [ ] All changes committed and pushed
 - [ ] PR reviewed and approved
-{{#IF_INFISICAL}}
-- [ ] Secrets pulled: `make secrets-pull`
-{{/IF_INFISICAL}}
 - [ ] No hardcoded secrets in code or config
 
-## Deployment Safety
+## Deployment safety
 
 **CRITICAL: Never auto-approve destructive deployment operations.**
 
 - Always preview/dry-run before applying changes
 - Require explicit user confirmation for production deployments
 - Never force-push or skip CI checks before deploying
-{{#IF_INFISICAL}}
-
-## Secrets for Deployment
-
-Pull secrets before deploying:
-```bash
-make secrets-pull     # fetch from Infisical to .env
-make secrets-show     # verify configuration (masked values)
-```
-
-**Never pass secrets as CLI arguments** — use environment variables or secret managers.
-{{/IF_INFISICAL}}
+- Never pass secrets as CLI arguments — use environment variables or secret managers
 
 {{#IF_GCLOUD}}
 ## Google Cloud Deployment
@@ -122,9 +104,7 @@ For Docker, use multi-stage builds:
 
 ## CI/CD
 
-CI pipeline (`.github/workflows/ci.yml`) runs automatically on PR:
-- Validation, quality checks, tests per enabled language
-- Coverage enforcement at {{COVERAGE_THRESHOLD}}%
+Set up the project's CI pipeline so it runs the same checks as `/quality` and `/test` on every PR.
 
 ## Gotchas
 

package/templates/.claude/skills/doctor/SKILL.md

@@ -3,52 +3,29 @@ name: doctor
 description: Diagnose and fix development environment issues. Use when setup fails, tools are missing, the environment is broken, or something is misconfigured.
 ---
 
-# Doctor & Setup
-
-## Commands
-- `make doctor` - Diagnose common setup issues (checks files, toolchains, config)
-- `make setup` - Interactive setup for new developers
-- `make info` - Show project configuration dashboard
-- `make config` - Interactive configuration editor
-
-## What Doctor Checks
-1. Core files (`.project.yaml`, `Makefile`, `.project/`)
-2. YAML syntax validation
-3. Language toolchain versions (Python, Go, Node, Rust)
-4. Quality tools installation (linters, formatters)
-5. Pre-commit hook configuration
-6. Git configuration
-7. Docker/Docker Compose availability
-8. Service health (if infrastructure enabled)
-
-## Common Issues & Fixes
-
-### Missing tools
-```bash
-make doctor    # identify what's missing
-make setup     # re-run interactive setup
-```
-
-### Config out of sync
-```bash
-make sync          # re-sync .project.yaml to language files
-make sync-preview  # preview changes first (dry run)
-```
-
-### Pre-commit failures
-```bash
-make fix       # auto-fix all issues
-make check     # verify everything passes
-```
-
-### Build failures after config change
-```bash
-make sync      # sync config
-make clean     # clean artifacts
-make build     # rebuild
-```
+# Doctor
+
+## Diagnose
+
+Walk through this checklist when something feels off:
+
+1. **Git**: `git --version`, working tree clean?
+2. **Language toolchains** (only for languages present in this repo):
+   - Node: `node --version` / `npm --version`; `node_modules/` populated?
+   - Python: `python3 --version`; virtual env activated? deps installed?
+   - Go: `go version`; modules downloaded?
+   - .NET: `dotnet --version`
+   - Rust: `rustc --version` / `cargo --version`
+3. **Docker** (if `docker-compose.yml` present): `docker --version`; daemon running?
+4. **dxkit health**: `npx vyuh-dxkit doctor` — verifies dxkit-managed tools (gitleaks, semgrep, cloc, etc.) and the `.claude/` install
+5. **Hooks active**: `git config core.hooksPath` should report `.githooks` if hooks are installed
+
+## Fix
+
+- Missing dxkit tools: `npx vyuh-dxkit tools install`
+- Stale `node_modules/`: `rm -rf node_modules && npm install`
+- Hooks not firing: `git config core.hooksPath .githooks`
 
 ## Environment
-- DevContainer-based (see `.devcontainer/`)
-- `post-create.sh` runs automatically on container creation
-- All tools installed via devcontainer features or post-create script
+
+If the repo has `.devcontainer/`, the canonical environment is the container — open in a devcontainer-aware editor (VS Code "Reopen in Container", Codespaces) instead of fighting host-machine setup.

package/templates/.claude/skills/gcloud/SKILL.md

@@ -11,9 +11,9 @@ paths:
 # Google Cloud (gcloud)
 
 ## Setup
-- **Auth:** `gcloud auth login` (configured during `make setup`)
-- **Project:** Set in `.env` as `GOOGLE_CLOUD_PROJECT`
-- **SDK:** Installed via devcontainer post-create script
+- **Auth:** `gcloud auth login`
+- **Project:** set via `gcloud config set project <id>` or the `GOOGLE_CLOUD_PROJECT` env var
+- **SDK:** install from https://cloud.google.com/sdk (devcontainer users get it via the post-create script)
 
 ## Common Commands
 
@@ -42,12 +42,12 @@ gcloud logging read "severity>=ERROR" --limit=20 --format=json
 
 ## Integration with Secrets
 
-GCP project ID is stored in `.env`:
+GCP project ID is typically set as an environment variable:
 ```
 GOOGLE_CLOUD_PROJECT=my-project-id
 ```
 
-Use `make secrets-pull` to fetch GCP-related secrets from Infisical.
+Source it from a secret store (Infisical, Doppler, GitHub Secrets) rather than committing to `.env`.
 
 ## Security — CRITICAL
 

package/templates/.claude/skills/learned/SKILL.md

@@ -10,7 +10,7 @@ It is updated during session-end checkpoints.
 
 ## How This Works
 
-1. During `make session-end`, the checkpoint process reviews the session
+1. During `/session-end` (or anytime via `/learn`), the conversation is reviewed for learnings
 2. Any new gotchas, patterns, or conventions are appended to the reference files
 3. Over time, this becomes the most valuable skill — real failure points and patterns
 

package/templates/.claude/skills/pulumi/SKILL.md

@@ -12,8 +12,8 @@ paths:
 # Pulumi (Infrastructure as Code)
 
 ## Setup
-- **Auth:** `pulumi login` (configured during `make setup`)
-- **SDK:** Installed via devcontainer post-create script
+- **Auth:** `pulumi login`
+- **SDK:** install from https://www.pulumi.com/docs/install/ (devcontainer users get it via the post-create script)
 - **Path:** `~/.pulumi/bin/pulumi`
 
 ## Core Workflow

package/templates/.claude/skills/quality/SKILL.md.template

@@ -5,28 +5,12 @@ description: Run code quality checks, linting, formatting, and auto-fixing. Use
 
 # Code Quality
 
-## Commands
-- `make quality` - Run all quality checks (report: `tmp/reports/quality-report.md`)
-- `make quality-fix` - Auto-fix all fixable issues
-- `make lint` - Lint only
-- `make format` - Format all code
-- `make fix` - Fix + format (shorthand)
-- `make check` - Full pre-commit check (validate + quality + test)
-- `make format-check` - Check formatting without modifying
-
-## Quality Presets
-- `make quality-strict` - 90% coverage, all checks
-- `make quality-standard` - 80% coverage (default)
-- `make quality-relaxed` - 50% coverage
-- `make quality-off` - Disable checks
-- `make quality-config` - Show current settings
+Run `/quality` for the full deterministic report (lint + format + slop + duplication metrics).
 
 {{#IF_PYTHON}}
 ## Python
 
-**Tools:** ruff (lint + format), mypy (types)
-**Config:** `ruff.toml`, `pyproject.toml`
-**Script:** `.project/scripts/quality/lint-python.sh`
+**Tools**: ruff (lint + format), mypy (types)
 
 Common fixes:
 ```bash
@@ -35,16 +19,13 @@ ruff format .
 mypy src/
 ```
 
-Key ruff rules: pycodestyle (E), pyflakes (F), isort (I), mccabe (C90), bugbear (B).
-Per-file ignores configured in `ruff.toml` for tests (assertions, fixtures).
+Key ruff rule groups: pycodestyle (E), pyflakes (F), isort (I), mccabe (C90), bugbear (B).
 {{/IF_PYTHON}}
 
 {{#IF_GO}}
 ## Go
 
-**Tools:** golangci-lint (27 linters), gofmt, goimports
-**Config:** `.golangci.yml`
-**Script:** `.project/scripts/quality/lint-go.sh`
+**Tools**: golangci-lint, gofmt, goimports
 
 Common fixes:
 ```bash

package/templates/.claude/skills/review/SKILL.md.template

@@ -5,13 +5,14 @@ description: Review code for quality, security, and patterns. Use when asked to
 
 # Code Review
 
-## Quick Check
-Run `make check` first — it validates, lints, tests, and checks docs in one command.
+## Quick check
+
+Run `/quality` and `/test` first — they cover lint, format, slop, duplication, and test results.
 
 ## Review Checklist
 
 ### 1. Quality
-- [ ] `make quality` passes
+- [ ] `/quality` passes
 - [ ] Coverage meets threshold ({{COVERAGE_THRESHOLD}}%)
 - [ ] No suppressed lint rules without justification
 

package/templates/.claude/skills/scaffold/SKILL.md.template

@@ -5,17 +5,7 @@ description: Scaffold new code — services, packages, modules, components. Use
 
 # Code Scaffolding
 
-## Project Structure
-- `.project.yaml` - Central config (edit via `make config`, view via `make info`)
-- `.project/` - Framework tooling and scripts
-- `.ai/` - AI session management and checkpoints
-
-## Language Management
-- `make lang-list` - Show enabled languages
-- `make lang-add LANG=<name>` - Enable a language
-- `make lang-remove LANG=<name>` - Disable a language
-- `make sync` - Sync `.project.yaml` to language config files
-- `make sync-preview` - Preview sync changes (dry run)
+Match existing layout and patterns when adding new code. Read a few neighboring files in the same area before creating new ones — naming, error handling, and test placement should look like the rest of the codebase.
 
 {{#IF_PYTHON}}
 ## Python Structure
@@ -117,7 +107,7 @@ tests/<ProjectName>.Tests/
 - xUnit + Moq for testing
 {{/IF_CSHARP}}
 
-## After Scaffolding
-1. Run `make sync` to update config files
-2. Run `make doctor` to verify setup
-3. Run `make test` to confirm everything works
+## After scaffolding
+
+1. Add tests next to the new code (mirroring how the rest of the codebase locates them)
+2. Run `/test` and `/quality` to confirm nothing regressed

package/templates/.claude/skills/secrets/SKILL.md

@@ -12,28 +12,27 @@ paths:
 
 # Secrets Management (Infisical)
 
-## Commands
-- `make secrets-pull` - Pull secrets from Infisical to `.env`
-- `make secrets-show` - Show Infisical configuration (**no secrets displayed**)
-- `make setup` - Configure Infisical during initial setup
+## How it works
 
-## How It Works
 1. Infisical stores secrets centrally (encrypted, access-controlled)
-2. `make secrets-pull` fetches secrets and merges into `.env`
+2. `infisical run -- <command>` or `infisical export --format=dotenv > .env` pulls them into the local environment
 3. `.env` is gitignored — **never commit secrets**
 
 ## Configuration
-Required in `.env` (set during `make setup`):
-- `INFISICAL_TOKEN` - Authentication token
-- `INFISICAL_PROJECT_ID` - Project identifier
-- `INFISICAL_ENV` - Environment (default: `dev`)
 
-## Checking Configuration
-Always use `make secrets-show` — it displays config keys without values:
-```
-INFISICAL_PROJECT_ID=abc123
-INFISICAL_ENV=dev
-INFISICAL_TOKEN=***configured***
+Authenticate via `infisical login`. Per-project config typically lives in `.infisical.json` (project ID + environment).
+
+Required environment variables (set during initial project bootstrap):
+- `INFISICAL_TOKEN` — auth token (for headless/CI usage)
+- `INFISICAL_PROJECT_ID` — project identifier
+- `INFISICAL_ENV` — environment (default: `dev`)
+
+## Checking configuration
+
+Look at the variable names without their values:
+
+```bash
+infisical secrets --plain | cut -d= -f1
 ```
 
 ## Security — CRITICAL
@@ -43,10 +42,10 @@ INFISICAL_TOKEN=***configured***
 3. **NEVER include secrets** in session checkpoints or skill files
 4. **NEVER pass secrets as CLI arguments** — they appear in process lists
 5. **NEVER commit** `.env`, `.env.*`, or `.env.secrets`
-6. Use `make secrets-show` to verify configuration without exposing values
-7. If a secret is accidentally exposed, rotate it immediately
+6. If a secret is accidentally exposed, rotate it immediately
 
 ## Troubleshooting
-- Token expired → re-authenticate via `make setup`
-- Pull fails → check `make secrets-show` for config, verify token permissions
-- Missing env var → check if it exists in Infisical project, correct environment
+
+- Token expired → re-run `infisical login`
+- Pull fails → check the project ID and environment, verify token permissions
+- Missing variable → confirm it exists in the right Infisical environment

package/templates/.claude/skills/session/SKILL.md

@@ -6,38 +6,27 @@ description: Manage AI development sessions — start, checkpoint, commit, push,
 # Session Management
 
 ## Workflow
-1. `make session-start` - Start session (finds last checkpoint, generates prompts)
-2. Work on your task using step-by-step development
-3. `make session-end` - Create checkpoint document
-4. `make session-commit` - Commit with quality checks
-5. `make session-push` - Push to remote
-6. `make session-pr` - Create PR with auto-generated content
-
-## Key Files
-- `.ai/prompts/session-start.md` - Planning prompt template
-- `.ai/prompts/session-end.md` - Checkpoint creation guide
-- `.ai/prompts/step-by-step.md` - Step-by-step development guide
-- `.ai/templates/session-checkpoint-template.md` - Checkpoint structure
+
+1. `/session-start` — review prior checkpoints + plan the session
+2. Work on the task
+3. `/session-end` — capture a checkpoint
+4. Commit + push via git directly
 
 ## Checkpoints
-- Stored in: `.ai/sessions/<developer>/<date>/session-<N>.md`
-- Auto-numbered per day
-- Include: accomplishments, files, decisions, next steps, AI context
-
-## Checkpoint Quality
-A good checkpoint is specific, not vague:
-- **Bad:** "worked on the client"
-- **Good:** "Implemented PolygonClient with 3 endpoints, added 15 unit tests, all passing"
-
-## Skill Evolution (during session-end)
-After creating the checkpoint, review the session for learnings:
-- Append gotchas to `.claude/skills/learned/references/gotchas.md`
-- Append conventions to `.claude/skills/learned/references/conventions.md`
-- Update area-specific gotchas in `.claude/skills/<area>/references/gotchas.md`
-- **Create new skills** if a distinct domain/workflow emerged (new `.claude/skills/<name>/SKILL.md`)
 
-**NEVER include secret values in checkpoints or skill files.**
+- Stored in `.ai/sessions/<developer>/<date>/session-<N>.md` (auto-numbered per day)
+- Include: accomplishments (specific, not vague), files changed, decisions, next steps, AI context
+
+A good checkpoint is specific:
+- **Bad**: "worked on the client"
+- **Good**: "Implemented PolygonClient with 3 endpoints, added 15 unit tests, all passing"
+
+## Skill evolution (during `/session-end`)
 
-## Tips
-- `SKIP_VERIFY=1` on session-commit/push to bypass quality checks for WIP
-- `BASE=main` on session-pr to override base branch
+Review the session for learnings and append to:
+- `.claude/skills/learned/references/gotchas.md` — surprising behaviors, edge cases
+- `.claude/skills/learned/references/conventions.md` — patterns the team converged on
+
+Create new skills (`.claude/skills/<name>/SKILL.md`) when a distinct domain/workflow emerges.
+
+**NEVER include secret values in checkpoints or skill files.**

package/templates/.claude/skills/test/SKILL.md.template

@@ -18,13 +18,7 @@ paths:
 
 # Testing
 
-## Commands
-- `make test` - Run all tests (report: `tmp/reports/test-report.md`)
-- `make test-unit` - Fast unit tests only (no coverage)
-- `make test-quick` - Alias for test-unit
-- `make test-integration` - Integration tests only
-- `make test-coverage` - Detailed coverage report
-- Coverage threshold: **{{COVERAGE_THRESHOLD}}%**
+**Coverage threshold**: {{COVERAGE_THRESHOLD}}%
 
 {{#IF_PYTHON}}
 ## Python