@rune-kit/rune 2.1.1

package/skills/test/SKILL.md

@@ -0,0 +1,271 @@
+---
+name: test
+description: "TDD test writer. Writes failing tests FIRST (red), then verifies they pass after implementation (green). Covers unit, integration, and e2e tests."
+metadata:
+  author: runedev
+  version: "0.2.0"
+  layer: L2
+  model: sonnet
+  group: development
+  tools: "Read, Write, Edit, Bash, Glob, Grep"
+---
+
+# test
+
+<HARD-GATE>
+Tests define the EXPECTED BEHAVIOR. They MUST be written BEFORE implementation code.
+If tests pass without implementation → the tests are wrong. Rewrite them.
+The only exception: when retrofitting tests for existing untested code.
+
+THE IRON LAW: Write code before test? DELETE IT. Start over.
+- Do NOT keep it as "reference"
+- Do NOT "adapt" it while writing tests
+- Do NOT look at it to "inform" test design
+- Delete means delete. `git checkout -- <file>` or remove the changes entirely.
+This is not negotiable. This is not optional. "But I already wrote it" is a sunk cost fallacy.
+</HARD-GATE>
+
+## Instructions
+
+### Phase 1: Understand What to Test
+
+1. Read the implementation plan or task description carefully
+2. Use `Glob` to find existing test files: `**/*.test.*`, `**/*.spec.*`, `**/test_*`
+3. Use `Read` on 2-3 existing test files to understand:
+   - Test framework in use
+   - File naming convention (e.g., `foo.test.ts` mirrors `foo.ts`)
+   - Test directory structure (co-located vs `__tests__/` vs `tests/`)
+   - Assertion style and patterns
+4. Use `Glob` to find the source file(s) being tested
+
+```
+TodoWrite: [
+  { content: "Understand scope and find existing test patterns", status: "in_progress" },
+  { content: "Detect test framework and conventions", status: "pending" },
+  { content: "Write failing tests (RED phase)", status: "pending" },
+  { content: "Run tests — verify they FAIL", status: "pending" },
+  { content: "After implementation: verify tests PASS (GREEN phase)", status: "pending" }
+]
+```
+
+### Phase 2: Detect Test Framework
+
+Use `Glob` to find config files and identify the framework:
+
+- `jest.config.*` or `"jest"` key in `package.json` → Jest
+- `vitest.config.*` or `"vitest"` key in `package.json` → Vitest
+- `pytest.ini`, `[tool.pytest.ini_options]` in `pyproject.toml` → pytest
+  - **Async check**: If pytest detected AND source files contain `async def`:
+    - Check if `pytest-asyncio` is in dependencies (`pyproject.toml [project.dependencies]` or `[project.optional-dependencies]`)
+    - Check if `asyncio_mode` is set in `[tool.pytest.ini_options]` (values: `auto`, `strict`, or absent)
+    - If async code exists but no `asyncio_mode` configured → **WARN**: "pytest-asyncio not configured. Async tests may silently pass without executing async code. Recommend adding `asyncio_mode = \"auto\"` to `[tool.pytest.ini_options]` in pyproject.toml."
+- `Cargo.toml` with `#[cfg(test)]` pattern → built-in `cargo test`
+- `*_test.go` files present → built-in `go test`
+- `cypress.config.*` → Cypress (E2E)
+- `playwright.config.*` → Playwright (E2E)
+
+**Verification gate**: Framework identified before writing any test code.
+
+### Phase 3: Write Failing Tests
+
+Use `Write` to create test files following the detected conventions:
+
+1. Mirror source file location: if source is `src/auth/login.ts`, test is `src/auth/login.test.ts`
+2. Structure tests with clear `describe` / `it` blocks (or language equivalent):
+   - `describe('Feature name')`
+     - `it('should [expected behavior] when [condition]')`
+3. Cover all three categories:
+   - **Happy path**: valid inputs, expected success output
+   - **Edge cases**: empty input, boundary values, large input
+   - **Error cases**: invalid input, missing data, network failure simulation
+
+4. Use proper assertions. Do NOT use implementation details — test behavior:
+   - Jest/Vitest: `expect(result).toBe(expected)`
+   - pytest: `assert result == expected`
+   - Rust: `assert_eq!(result, expected)`
+   - Go: `if result != expected { t.Errorf(...) }`
+
+5. For async code: use `async/await` or pytest `@pytest.mark.asyncio`
+
+#### Python Async Tests (pytest-asyncio)
+
+When writing tests for async Python code:
+
+1. **Verify setup before writing tests**:
+   - Confirm `pytest-asyncio` is in project dependencies
+   - Confirm `asyncio_mode` is set in `pyproject.toml` `[tool.pytest.ini_options]` (recommend `"auto"`)
+   - If neither is configured, warn the caller and suggest setup before proceeding
+
+2. **Writing async test functions**:
+   - With `asyncio_mode = "auto"`: just write `async def test_something():` — no decorator needed
+   - With `asyncio_mode = "strict"`: every async test needs `@pytest.mark.asyncio`
+   - Without asyncio_mode set: always use `@pytest.mark.asyncio` decorator explicitly
+
+3. **Async fixtures**:
+   - Use `@pytest_asyncio.fixture` (NOT `@pytest.fixture`) for async setup/teardown
+   - Scope rules: async fixtures default to `function` scope — use `scope="session"` carefully with async
+
+4. **Common pitfalls**:
+   - Tests that `pass` without `await` — they run but don't execute the async path
+   - Missing `pytest-asyncio` makes `async def test_*` silently pass as empty coroutines
+   - Mixing sync and async fixtures can cause event loop errors
+
+### Phase 4: Run Tests — Verify They FAIL (RED)
+
+Use `Bash` to run ONLY the newly created test files (not full suite):
+
+- **Jest**: `npx jest path/to/test.ts --no-coverage`
+- **Vitest**: `npx vitest run path/to/test.ts`
+- **pytest**: `pytest path/to/test_file.py -v` (if async tests and no `asyncio_mode` in config: add `--asyncio-mode=auto`)
+- **Rust**: `cargo test test_module_name`
+- **Go**: `go test ./path/to/package/... -run TestFunctionName`
+
+**Hard gate**: ALL new tests MUST fail at this point.
+
+- If ANY test passes before implementation exists → that test is not testing real behavior. Rewrite it to be stricter.
+- If tests fail with import/syntax errors (not assertion errors) → fix the test code, re-run
+
+### Phase 5: After Implementation — Verify Tests PASS (GREEN)
+
+After `rune:fix` writes implementation code, run the same test command again:
+
+1. ALL tests in the new test files MUST pass
+2. Run the full test suite with `Bash` to check for regressions:
+   - `npm test`, `pytest`, `cargo test`, `go test ./...`
+3. If any test fails: report clearly which test, what was expected, what was received
+4. If an existing test now fails (regression): escalate to `rune:debug`
+
+**Verification gate**: 100% of new tests pass AND 0 regressions in existing tests.
+
+### Phase 6: Coverage Check
+
+After GREEN phase, call `verification` to check coverage threshold (80% minimum):
+
+- If coverage drops below 80%: identify uncovered lines, write additional tests
+- Report coverage gaps with file:line references
+
+## Test Types
+
+| Type | When | Framework | Speed |
+|------|------|-----------|-------|
+| Unit | Individual functions, pure logic | jest/vitest/pytest/cargo test | Fast |
+| Integration | API endpoints, DB operations | supertest/httpx/reqwest | Medium |
+| E2E | Critical user flows | Playwright/Cypress via browser-pilot | Slow |
+| Regression | After bug fixes | Same as unit | Fast |
+
+## Error Recovery
+
+- If test framework not found: ask calling skill to specify, or check `package.json` `devDependencies`
+- If `Write` to test file fails: check if directory exists, create it first with `Bash mkdir -p`
+- If tests error on import (module not found): check that source file path is correct, adjust imports
+- If `Bash` test runner hangs beyond 120 seconds: kill and report as TIMEOUT
+
+## Called By (inbound)
+
+- `cook` (L1): Phase 3 TEST — write tests first
+- `fix` (L2): verify fix passes tests
+- `review` (L2): untested edge case found → write test for it
+- `deploy` (L2): pre-deployment full test suite
+- `preflight` (L2): run targeted regression tests on affected code
+- `surgeon` (L2): verify refactored code
+- `launch` (L1): pre-deployment test suite
+- `safeguard` (L2): writing characterization tests for legacy code
+- `review-intake` (L2): write tests for issues identified during review intake
+
+## Calls (outbound)
+
+- `verification` (L3): Phase 6 — coverage check (80% minimum threshold)
+- `browser-pilot` (L3): Phase 4 — e2e and visual testing for UI flows
+- `debug` (L2): Phase 5 — when existing test regresses unexpectedly
+
+## Anti-Rationalization Table
+
+| Excuse | Reality |
+|---|---|
+| "Too simple to need tests first" | Simple code breaks. Test takes 30 seconds. Write it first. |
+| "I'll write tests after — same result" | Tests-after = "what does this do?" Tests-first = "what SHOULD this do?" Completely different. |
+| "I already wrote the code, let me just add tests" | Iron Law: delete the code. Start over with tests. Sunk cost is not an argument. |
+| "Tests after achieve the same goals" | They don't. Tests-after are biased by the implementation you just wrote. |
+| "It's about spirit not ritual" | Violating the letter IS violating the spirit. Write the test first. |
+| "I mentally tested it" | Mental testing is not testing. Run the command, show the output. |
+| "This is different because..." | It's not. Write the test first. |
+
+## Red Flags — STOP and Start Over
+
+If you catch yourself with ANY of these, delete implementation code and restart with tests:
+
+- Code exists before test file
+- "I already manually tested it"
+- "Tests after achieve the same purpose"
+- "It's about spirit not ritual"
+- "This is different because..."
+- "Let me just finish this, then add tests"
+
+**All of these mean: Delete code. Start over with TDD.**
+
+## Constraints
+
+1. MUST write tests BEFORE implementation code — if tests pass without implementation, they are wrong
+2. MUST cover happy path + edge cases + error cases — not just happy path
+3. MUST run tests to verify they FAIL before implementation exists (RED phase is mandatory)
+4. MUST NOT write tests that test mock behavior instead of real code behavior
+5. MUST achieve 80% coverage minimum — identify and fill gaps
+6. MUST use the project's existing test framework and conventions — don't introduce a new one
+7. MUST NOT say "tests pass" without showing actual test runner output
+8. MUST delete implementation code written before tests — Iron Law, no exceptions
+9. MUST show RED phase output (actual failure) — "I confirmed they fail" without output is REJECTED
+
+## Mesh Gates
+
+| Gate | Requires | If Missing |
+|------|----------|------------|
+| RED Gate | All new tests FAIL before implementation | If any pass, rewrite stricter tests |
+| GREEN Gate | All tests PASS after implementation | Fix code, not tests |
+| Coverage Gate | 80%+ coverage verified via verification | Write additional tests for gaps |
+
+## Output Format
+
+```
+## Test Report
+- **Framework**: [detected]
+- **Files Created**: [list of new test file paths]
+- **Tests Written**: [count]
+- **Status**: RED (failing as expected) | GREEN (all passing)
+
+### Test Cases
+| Test | Status | Description |
+|------|--------|-------------|
+| `test_name` | FAIL/PASS | [what it tests] |
+
+### Coverage
+- Lines: [X]% | Branches: [Y]%
+- Gaps: `path/to/file.ts:42-58` — uncovered branch (error handling)
+
+### Regressions (if any)
+- [existing test that broke, with error details]
+```
+
+## Sharp Edges
+
+Known failure modes for this skill. Check these before declaring done.
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Tests passing before implementation exists | CRITICAL | RED Gate: rewrite stricter tests — passing without code = not testing real behavior |
+| Skipping the RED phase (not confirming FAIL) | HIGH | Run tests, confirm FAIL output before calling cook/fix to implement |
+| Testing mock behavior instead of real code | HIGH | Constraint 4: test what the real code does, not what the mock returns |
+| Coverage below 80% without filling gaps | MEDIUM | Coverage Gate: identify uncovered lines and write additional tests |
+| Introducing a new test framework instead of using existing one | MEDIUM | Constraint 6: detect framework first, use project's existing one always |
+
+## Done When
+
+- Test framework detected from project config files
+- Tests cover happy path + at least 2 edge cases + error case
+- All new tests FAIL (RED phase — actual failure output shown)
+- After implementation: all tests PASS (GREEN phase — actual pass output shown)
+- Coverage ≥80% verified via verification
+- Test Report emitted with framework, test count, RED/GREEN status, and coverage
+
+## Cost Profile
+
+~$0.03-0.08 per invocation. Sonnet for writing tests, Bash for running them. Frequent invocation in TDD workflow.

package/skills/trend-scout/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: trend-scout
+description: Scan market trends, competitor activity, and emerging patterns. Monitors Product Hunt, GitHub Trending, HackerNews, and social platforms.
+metadata:
+  author: runedev
+  version: "0.2.0"
+  layer: L3
+  model: haiku
+  group: knowledge
+  tools: "Read, Glob, Grep, WebFetch, WebSearch"
+---
+
+# trend-scout
+
+## Purpose
+
+Market intelligence and technology trend analysis utility. Receives a topic or market segment, executes targeted searches across trend sources, analyzes competitor activity and community sentiment, and returns structured market intelligence. Stateless — no memory between calls.
+
+## Calls (outbound)
+
+None — pure L3 utility using `WebSearch` tools directly.
+
+## Called By (inbound)
+
+- `brainstorm` (L2): market context for product ideation
+- `marketing` (L2): trend data for positioning and content
+- `autopsy` (L2): identify if tech stack is outdated
+- `autopsy` (L2): check if legacy tech is still maintained
+
+## Execution
+
+### Input
+
+```
+topic: string           — market segment or technology to analyze (e.g., "AI coding assistants", "SvelteKit")
+timeframe: string       — (optional) period of interest, defaults to "2026"
+focus: string           — (optional) narrow the lens: "competitors" | "technology" | "community" | "all"
+```
+
+### Step 1 — Define Scope
+
+Parse the input topic and determine the analysis angle:
+- Product/market: focus on competitors, pricing, user adoption
+- Technology: focus on GitHub activity, npm/pypi downloads, framework adoption
+- Community: focus on Reddit, HN, X/Twitter sentiment
+
+### Step 2 — Search Trends
+
+Execute `WebSearch` with these query patterns:
+- `"[topic] 2026 trends"`
+- `"[topic] vs alternatives 2026"`
+- `"[topic] market share growth"`
+- `"[topic] GitHub trending"` or `"[topic] npm downloads stats"`
+
+Collect results. Identify the most evidence-rich URLs per query.
+
+### Step 3 — Competitor Analysis
+
+Execute `WebSearch` with:
+- `"[topic] competitors comparison"`
+- `"best [topic] tools 2026"`
+- `"[topic] alternative"`
+
+From results, extract:
+- Top 3-5 competitors or alternative solutions
+- Key differentiating features
+- Pricing model if visible
+- User sentiment signals (e.g., "users are switching from X to Y because...")
+
+### Step 4 — Community Sentiment
+
+Execute `WebSearch` with:
+- `"site:reddit.com [topic]"` or `"[topic] reddit discussion"`
+- `"[topic] site:news.ycombinator.com"`
+- `"[topic] GitHub stars"` or `"[topic] downloads per week"`
+
+Extract:
+- Community perception (positive/negative/mixed)
+- Frequently cited pain points
+- Frequently praised features
+- Adoption velocity indicators (star growth, download counts)
+
+### Step 5 — Report
+
+Synthesize all gathered data into the output format below. Note where data is sparse or conflicting.
+
+## Constraints
+
+- Use `WebSearch` only — do not call `WebFetch` unless a specific page has critical data not in snippets
+- Label all data points with their source
+- Do not infer trends from a single data point — note confidence level
+- If the topic is too broad, report what was analyzed and suggest narrowing
+
+## Output Format
+
+```
+## Trend Report: [Topic]
+- **Period**: [timeframe]
+- **Confidence**: high | medium | low
+
+### Trending Now
+- [trend] — evidence: [source/stat]
+- [trend] — evidence: [source/stat]
+
+### Competitors
+| Name | Key Differentiator | Sentiment |
+|------|--------------------|-----------|
+| [A]  | [feature]          | positive / mixed / negative |
+| [B]  | [feature]          | positive / mixed / negative |
+
+### Community Sentiment
+- **Reddit/HN**: [summary]
+- **GitHub activity**: [stars/downloads/issues signal]
+- **Pain points**: [what users complain about]
+
+### Emerging Patterns
+- [pattern] — implication: [what this means for callers]
+
+### Recommendations
+- [actionable insight for the calling skill]
+```
+
+## Sharp Edges
+
+Known failure modes for this skill. Check these before declaring done.
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Inferring trend from a single data point | HIGH | Constraint: note confidence level — single source = low confidence, not a trend |
+| Topic too broad → generic results with no actionable signal | MEDIUM | Report what was analyzed and suggest narrowing; don't fabricate specificity |
+| Skipping competitor analysis (Steps 3 mandatory) | MEDIUM | Competitor analysis is required — callers need positioning context |
+| Calling WebFetch on every search result (excessive cost) | MEDIUM | Constraint: WebSearch only unless a specific page has critical data not in snippets |
+
+## Done When
+
+- Topic scope defined (product/technology/community angle)
+- Trend searches executed with 2026 timeframe
+- Competitor analysis completed (top 3-5 players with differentiators)
+- Community sentiment captured (Reddit/HN/GitHub signals)
+- Confidence level assigned based on evidence quality
+- Trend Report emitted with source citations for every data point
+
+## Cost Profile
+
+~300-600 tokens input, ~200-400 tokens output. Haiku.

package/skills/verification/SKILL.md

@@ -0,0 +1,201 @@
+---
+name: verification
+description: "Universal verification runner. Runs lint, type-check, tests, and build. Use after any code change to verify nothing is broken."
+metadata:
+  author: runedev
+  version: "0.2.0"
+  layer: L3
+  model: haiku
+  group: validation
+  tools: "Read, Bash, Glob, Grep"
+---
+
+# verification
+
+Runs all automated checks to verify code health. Stateless — runs checks and reports results.
+
+## Instructions
+
+### Phase 1: Detect Project Type
+
+Use `Glob` to find project config files:
+
+1. Check for `package.json` → Node.js/TypeScript project
+2. Check for `pyproject.toml` or `setup.py` → Python project
+3. Check for `Cargo.toml` → Rust project
+4. Check for `go.mod` → Go project
+5. Check for `pom.xml` or `build.gradle` → Java project
+
+Use `Read` on the detected config file to find scripts or tool config (e.g., `package.json` scripts block for custom lint/test commands).
+
+```
+TodoWrite: [
+  { content: "Detect project type", status: "in_progress" },
+  { content: "Run lint check", status: "pending" },
+  { content: "Run type check", status: "pending" },
+  { content: "Run test suite", status: "pending" },
+  { content: "Run build", status: "pending" },
+  { content: "Generate verification report", status: "pending" }
+]
+```
+
+### Phase 2: Run Lint
+
+Use `Bash` to run the appropriate linter. If `package.json` has a `lint` script, prefer that:
+
+- **Node.js (npm lint script)**: `npm run lint`
+- **Node.js (no script)**: `npx eslint . --max-warnings 0`
+- **Python**: `ruff check .` (fallback: `flake8 .`)
+- **Rust**: `cargo clippy -- -D warnings`
+- **Go**: `golangci-lint run` (fallback: `go vet ./...`)
+
+If lint fails: record the failure output, mark lint as FAIL, continue to next step. Do NOT stop.
+
+**Verification gate**: Command exits without crashing (even if it reports lint errors — those are FAIL, not errors).
+
+### Phase 3: Run Type Check
+
+Use `Bash`:
+
+- **TypeScript**: `npx tsc --noEmit`
+- **Python**: `mypy .` (fallback: `pyright .`)
+- **Rust**: `cargo check`
+- **Go**: `go vet ./...`
+
+If type check fails: record error count and first 10 error lines, mark as FAIL, continue.
+
+### Phase 4: Run Tests
+
+Use `Bash` to run the test suite. Prefer the project script if available:
+
+- **Node.js (npm test script)**: `npm test`
+- **Vitest**: `npx vitest run`
+- **Jest**: `npx jest --passWithNoTests`
+- **Python**: `pytest -v` (fallback: `python -m unittest discover`)
+- **Rust**: `cargo test`
+- **Go**: `go test ./...`
+
+Record: total tests, passed count, failed count, coverage percentage if output includes it.
+
+If tests fail: record which tests failed (first 20), mark as FAIL, continue to build.
+
+### Phase 5: Run Build
+
+Use `Bash`:
+
+- **Node.js**: check `package.json` for `build` script → `npm run build` (fallback: `npx tsc`)
+- **Python**: check `pyproject.toml` for `[build-system]` section:
+  - If build backend found (setuptools, poetry-core, hatchling, flit-core): `python -m build --no-isolation 2>&1 | head -20` to verify packaging
+  - If `setup.py` exists (legacy): `python setup.py check --strict`
+  - Then always: `pip install -e . --dry-run` to catch broken entry points, missing `__init__.py`, or import path issues
+  - If no `pyproject.toml` and no `setup.py` (scripts-only project): SKIP
+- **Rust**: `cargo build`
+- **Go**: `go build ./...`
+
+If build fails: record first 20 lines of build output, mark as FAIL.
+
+### Phase 6: Generate Report
+
+Compile all results into the structured report. Update all TodoWrite items to completed.
+
+## Error Recovery
+
+- If project type cannot be detected: report "Unknown project type" and skip all checks
+- If a command is not found (e.g., `ruff` not installed): note "tool not installed", mark check as SKIP
+- If a command hangs for more than 60 seconds: kill it, mark check as TIMEOUT, continue
+
+## Calls (outbound)
+
+None — pure runner using Bash for all checks. Does not invoke other skills.
+
+## Called By (inbound)
+
+- `cook` (L1): Phase 6 VERIFY — final check before commit
+- `fix` (L2): validate fix doesn't break existing functionality
+- `test` (L2): validate test coverage meets threshold
+- `deploy` (L2): post-deploy health checks
+- `sentinel` (L2): run security audit tools (npm audit, etc.)
+- `safeguard` (L2): verify safety net is solid before refactoring
+- `db` (L2): run migration in test environment
+- `perf` (L2): run benchmark scripts if configured
+- `skill-forge` (L2): verify newly created skill passes lint/type/build checks
+
+## Output Format
+
+```
+VERIFICATION REPORT
+===================
+Lint:      [PASS/FAIL/SKIP] ([details])
+Types:     [PASS/FAIL/SKIP] ([X errors])
+Tests:     [PASS/FAIL/SKIP] ([passed]/[total], [coverage]%)
+Build:     [PASS/FAIL/SKIP]
+
+Overall:   [PASS/FAIL]
+
+### Failures (if any)
+- Lint: [error details with file:line]
+- Types: [first 5 type errors]
+- Tests: [first 5 failing test names]
+- Build: [first 5 build errors]
+```
+
+## Evidence-Before-Claims Gate
+
+<HARD-GATE>
+An agent MUST NOT claim "done", "fixed", "passing", or "verified" without showing the actual command output that proves it.
+"I ran the tests and they pass" WITHOUT stdout/stderr = UNVERIFIED CLAIM = REJECTED.
+The verification report IS the evidence. No report = no verification happened.
+</HARD-GATE>
+
+### Claim Validation Protocol
+
+When any skill calls verification and then reports results upstream:
+
+1. **Output capture is mandatory** — every Bash command's stdout/stderr must appear in the report
+2. **Pass requires proof** — PASS means "tool ran AND output shows zero errors" (not "tool ran without crashing")
+3. **Silence is not success** — if a command produces no output, note it explicitly ("0 errors, 0 warnings")
+4. **Partial runs are labeled** — if only 2 of 4 checks ran, Overall = INCOMPLETE (not PASS)
+
+### Red Flags — Agent is Lying
+
+| Claim | Without | Verdict |
+|---|---|---|
+| "All tests pass" | Test runner stdout showing pass count | REJECTED — re-run and show output |
+| "No lint errors" | Linter stdout | REJECTED — re-run and show output |
+| "Build succeeds" | Build command stdout | REJECTED — re-run and show output |
+| "I verified it" | Verification Report | REJECTED — run verification skill properly |
+| "Fixed and working" | Before/after test output | REJECTED — show the diff in results |
+
+## Constraints
+
+1. MUST run ALL four checks: lint, type-check, tests, build — not just tests
+2. MUST show actual command output — never claim "all passed" without evidence
+3. MUST report specific failures with file:line references
+4. MUST NOT skip checks because "changes are small"
+5. MUST include stdout/stderr capture in every check result — empty output noted explicitly
+6. MUST mark Overall as INCOMPLETE if any check was skipped without valid reason (tool not installed = valid, "changes are small" = invalid)
+
+## Sharp Edges
+
+Known failure modes for this skill. Check these before declaring done.
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Claiming "all passed" without showing actual command output | CRITICAL | Evidence-Before-Claims HARD-GATE blocks this — stdout/stderr is mandatory |
+| Agent says "verified" without producing Verification Report | CRITICAL | No report = no verification. Re-run the skill properly. |
+| Skipping build because "changes are small" | HIGH | Constraint 4: all four checks mandatory — size of changes doesn't matter |
+| Marking check as PASS when the tool isn't installed | MEDIUM | Mark as SKIP (not PASS) — PASS means the tool ran and reported clean |
+| Stopping after first failure instead of running remaining checks | MEDIUM | Run all checks; aggregate all failures so developer can fix everything at once |
+| Reporting PASS when output has warnings but zero errors | LOW | PASS is correct but note warning count — caller decides if warnings matter |
+
+## Done When
+
+- Project type detected from config files
+- lint, type-check, tests, and build all executed (or SKIP with reason if tool missing)
+- Each check shows actual command output
+- Failures include specific file:line references (not just counts)
+- Verification Report emitted with Overall PASS/FAIL verdict
+
+## Cost Profile
+
+~$0.01-0.03 per run. Haiku + Bash commands. Fast and cheap.