prompt-engineering-patterns

name	prompt-engineering-patterns
description	This skill should be used when rewriting a vague or imperative prompt into a declarative, exhaustive, verification-driven one — expanding scope, injecting test/lint/build verification commands, defining completion criteria, or auditing UI and cross-cutting changes for full coverage. Contains exhaustiveness rules, verification patterns, and anti-patterns to fix.

Prompt Engineering Patterns

Core Principle: Declarative Over Imperative (Commandment X)

Rewrite prompts to describe the OUTCOME, not the steps.

Bad: "Go to the auth page, check if the login form works, then check the signup form" Good: "Verify all authentication flows work correctly — login, signup, password reset, session expiration — across all auth-related routes"

Bad: "Read the API file and check for errors" Good: "Find and fix all API endpoint errors: broken routes, unhandled exceptions, missing validation, incorrect status codes"

The model finds creative solutions when you don't constrain the approach. Define what "done" looks like.

Pattern 1: Exhaustive Scope

Prevent the AI from stopping at the first instance. Force enumeration.

Inject:

• "Enumerate ALL [pages/routes/files/components/endpoints] that match this criteria before starting work"
• "Create a checklist of everything to verify. Work through each item. Do not skip any"
• "Do not consider this task complete until every item on the checklist has been addressed and verified"

For web projects:

• "List all routes from the router configuration. Check each one, not just the obvious ones"
• "Include error pages, loading states, empty states, and edge-case views"

For APIs:

• "List all endpoints. Test each with valid input, invalid input, missing auth, and edge cases"

For codebases:

• "Search the entire codebase, not just the obvious directories. Check tests, scripts, configs, and generated files"

Pattern 2: Verification Loop (Commandment II)

Every change must be verified. Inject a feedback loop.

Inject:

• "After making changes, run the project's test suite, linter, and build. Fix any failures before moving on"
• "If E2E tests exist (Playwright, Cypress, etc.), run them against every affected route"
• "If no tests exist for the changed code, write them before considering the task done"

Verification order: build → lint → typecheck → unit tests → E2E tests

Iteration rule: "If a verification step fails, fix the issue and re-run. Max 3 attempts per step. If still failing after 3 attempts, report the issue clearly instead of moving on silently"

Pattern 3: Project-Aware Context

Detect the project type and inject relevant specifics.

Detection signals:

• package.json → Node.js project. Check scripts for test/build/lint commands
• next.config.* / app/ or pages/ → Next.js. Routes matter. Check all pages
• playwright.config.* or cypress.config.* → E2E is available. Must use it
• go.mod → Go project. go test ./..., go vet ./...
• Cargo.toml → Rust. cargo test, cargo clippy
• pyproject.toml / pytest.ini → Python. pytest, type checking
• docker-compose.yml → Multi-service. Consider cross-service impacts
• .github/workflows/ → CI exists. Reference what CI checks

Inject the detected verification commands explicitly so the AI knows exactly what to run.

Pattern 4: UI Verification

When the task involves UI changes, force comprehensive visual verification.

Inject:

• "After UI changes, verify ALL pages/views that could be affected — not just the one you modified"
• "Check shared components: if you changed a Button, Header, or Layout component, verify every page that uses it"
• "Verify responsive behavior: desktop, tablet, and mobile viewports"
• "Check light and dark mode if the project supports themes"
• "Verify loading states, error states, empty states, and edge cases (long text, missing images, etc.)"
• "If Playwright is configured, run visual regression tests"

Pattern 5: No Premature Completion

Prevent the AI from declaring "done" too early.

Inject:

• "Before declaring this task complete, review your checklist and confirm every item is addressed"
• "Run ALL verification commands one final time to confirm nothing is broken"
• "If you find issues during final verification, fix them — do not just report them"
• "List what you verified and the result of each verification"

Pattern 6: Cross-Cutting Concerns

For tasks that touch shared code, force impact analysis.

Inject:

• "Before modifying shared code, search for all usages across the codebase"
• "List every file that imports or uses the code you're about to change"
• "After changes, verify each consumer still works correctly"
• "Check for breaking changes in public APIs, exported types, and shared interfaces"

Prompt Structure Template

The improved prompt should follow this structure:

## Task
[Declarative description of what needs to be accomplished]

## Scope
[Explicit enumeration of what to check/change — routes, files, components, endpoints]

## Process
[How to approach — checklist-first, then execute]

## Verification
[Exact commands to run, in order, with iteration rules]

## Completion Criteria
[Measurable definition of "done" — what must be true before this task is complete]

Anti-Patterns to Fix

When you see these in the original prompt, fix them:

Original	Problem	Fix
"check the site"	Vague scope	Enumerate all routes/pages
"fix the bug"	No verification	Add test + verification loop
"update the UI"	No cross-check	Add affected-pages verification
"make it work"	No success criteria	Define measurable "done"
"look at the code"	Imperative	Rewrite as outcome
"do X then Y then Z"	Step-by-step micromanagement	Describe the goal, not the steps
No mention of tests	Missing feedback loop	Add verification commands