architecture-review
Reviews a technical proposal before implementation. Use for designs, RFCs, ADRs, architecture proposals, and issues that define how a system change should…
Proves that a code change meets its acceptance criteria. Uses focused automated checks and a real browser for browser-facing work. Use to test or verify a diff, branch, PR, URL, or user flow.
$ npx -y skills add owainlewis/blueprint --skill test --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/testContext preview
The summary Claude sees to decide when to auto-load this skill.
Proves that a code change meets its acceptance criteria. Uses focused automated checks and a real browser for browser-facing work. Use to test or verify a diff, branch, PR, URL, or user flow.
name: test description: "Proves that a code change meets its acceptance criteria. Uses focused automated checks and a real browser for browser-facing work. Use to test or verify a diff, branch, PR, URL, or user flow." user-invocable: true argument-hint: "<task, acceptance criteria, diff, branch, PR, URL, or flow>"
Prove the behavior that matters. A passing build or a source-code reading can support the proof, but neither proves a user-visible flow.
1. Read the task, its source design when present, changed code, existing tests, and repository instructions. Acceptance criteria come from the task or approved design. Preserve their wording and `AC-n` or `INV-n` IDs. Never rewrite criteria to match the code. 2. Map every acceptance criterion, cited invariant, and affected failure path to proof by ID. Test changed behavior and behavior a refactor must preserve. 3. If automated tests cannot exercise the affected behavior, explain why and give other evidence. 4. Add or update focused tests where proof is missing. Assertions should fail when the changed behavior breaks. 5. Assert behavior a user or caller can observe unless the test targets a documented internal contract. Keep setup and assertions no more complex than the scenario. 6. Run the narrowest checks that exercise the changed behavior and affected interfaces. Run wider checks when shared behavior or interfaces changed. 7. When browser-rendered behavior changes, start the documented app and check the required flows and affected failures in a real browser.
8. Report each `AC-n`, `INV-n`, or task criterion as pass, fail, or unverified. Include the command, browser flow, or other evidence.
Report each criterion in this shape:
Criterion: <ID or exact wording> Result: Pass / Fail / Unverified Evidence: <command, browser flow, or artifact> Gap: <what remains unknown, or None>
Lead with failures and unverified criteria. Do not hide them below passing checks.
Design. Plan. Build. Validate. Blueprint gives coding agents ten focused skills. They cover understanding existing code, deciding what to build, and delivering reviewed pull requests.
Reviews a technical proposal before implementation. Use for designs, RFCs, ADRs, architecture proposals, and issues that define how a system change should…
Creates or updates root ARCHITECTURE.md from verified implementation. Use when a repository needs current architecture documentation or a structural change…
Coordinates a large batch of GitHub issues through separate Codex worker threads, tested pull requests, review loops, and gated merges. Use when the user asks…
Writes a proposed design covering requirements, user experience, technical choices, and proof. Use when important product or technical choices must be settled…
Generates a polished, static HTML reading view from an existing Markdown PRD or technical design. Use when a user asks to render, present, visualize, or make a…
Makes existing code easier to understand without changing behavior. Use to simplify structure, remove duplication or dead code, improve names, or remove…