---
name: check-setup
description: Use right after installing claude-workflow into a project, or when the workflow behaves oddly. Verifies the template was fully customized — no leftover placeholders, stray personal paths, or unwired hooks.
---

# Check Setup

Verify a fresh claude-workflow install is correctly customized before relying on it. The whole workflow assumes placeholders were filled in and hooks were wired — this skill catches the cases where they weren't.

## Steps

1. **Scan for unreplaced placeholders.** Search the tracked files for angle-bracket tokens that should have been filled in:
   - Grep for `<your-` and `<angle-bracket>` across `CLAUDE.md` and `.claude/`.
   - Expected after setup: zero matches in `CLAUDE.md`. (The README/QUICKSTART legitimately mention placeholders as instructions — only flag `CLAUDE.md` and skill/rule files.)

2. **Scan for stray personal paths.** Search for absolute paths that belong to whoever last edited the template, not the current user:
   - Grep for `C:\Users\`, `/Users/`, and `/home/` inside `.claude/` and `CLAUDE.md`.
   - Any hit is a portability bug — report the file and line.

3. **Confirm the core files exist:**
   - `CLAUDE.md`, `lessons.md` at project root
   - `.claude/settings.json` (hooks wired)
   - `.claude/hooks/context-monitor.py` and `.claude/hooks/pre-commit-checks.py`
   - `.claude/rules/` has the four rule files

4. **Confirm the hooks are wired.** Read `.claude/settings.json` and verify both hooks are referenced. If the user keeps hooks in `.claude/settings.local.json` instead, check there. If neither references the hooks, tell the user they're shipped but inactive.

5. **Confirm CLAUDE.md commands are real.** Check that the Test and Lint commands in `CLAUDE.md` are filled in with actual commands (not the `<your-test-command>` placeholder). If still placeholders, the test-before-commit gate can't run.

6. **Secret-hygiene quick check:**
   - Confirm `.gitignore` exists and covers `.env` and `.claude/settings.local.json`.
   - Note whether `gitleaks` is installed locally (`gitleaks version`). If not, tell the user the local `/done` scan will warn and continue (the CI gitleaks workflow remains the enforcing gate), and recommend installing it so secrets are caught before they leave the machine.

## Report Format

Plain English. For each check: ✅ pass, or ⚠️ with the exact file/line and the one-line fix. End with a short verdict:

- **Ready** — everything customized, hooks wired, commands real.
- **Needs attention** — list the specific items to fix, in order.

Keep it scannable. The user installed this to get working, not to read an audit.

## Rules

- Read-only. Do not edit anything — report findings and let the user decide.
- Don't flag the README/QUICKSTART for containing placeholder *examples*; those are documentation.
- If a check can't run (tool missing, file absent), say so honestly rather than guessing.