Master Agent Enforcement Prompt
Use at the start of a serious coding-agent session when the agent must obey repository rules, evidence discipline, and release-honesty constraints.
Static, crawlable catalogue
Browse every asset without relying on JavaScript. Use the interactive library to search, preview and copy complete agent-ready bodies.
40 prompt assets
Use at the start of a serious coding-agent session when the agent must obey repository rules, evidence discipline, and release-honesty constraints.
Use when a feature, bug fix, refactor, or documentation change must be implemented with proof before any success claim.
Use after an agent claims success and you need to test whether the claim is real, exaggerated, or unsupported.
Use before implementation or review when hidden assumptions could change architecture, UX, security, or release judgement.
Use when an answer sounds confident but evidence quality varies across code, UI, tests, or documentation.
Use when docs, tests, UI, code, README, or release language may disagree.
Use before merge, release, or large refactor to imagine failure and prevent avoidable blind spots.
Use when the task is at risk of scope creep, hidden dependencies, or accidental redesign.
Use when a requested fix must avoid broad rewrites, unrelated styling, or unnecessary dependency changes.
Use at the beginning of work on an unfamiliar repository, template pack, or docs/product system.
Use for new feature work that needs design, code, tests, docs, and release evidence kept aligned.
Use when a symptom is known but the actual cause, blast radius, and regression risk must be proven.
Use after any implementation that might break adjacent behaviour, shared contracts, or existing user paths.
Use for maintainability, structure, dead-code, duplication, and readability review.
Use when a change may violate boundaries, patterns, ownership, or long-term design constraints.
Use when removing unused files, branches, exports, styles, docs, tests, or generated artefacts.
Use when improving structure without intentionally changing behaviour.
Use when request/response shapes, public functions, schemas, integrations, or API docs may change.
Use when data origin, transformation, persistence, display, export, or logging must be understood.
Use for frontend or application state that may become stale, inconsistent, duplicated, or race-prone.
Use when a UI must be inspected for hierarchy, grouping, spacing, layout, and real rendered structure.
Use before accepting a UI that must look polished, readable, aligned, and professionally finished.
Use when components, tokens, typography, icons, spacing, and interaction states must remain consistent.
Use when layouts must survive mobile, tablet, desktop, long content, and constrained viewport states.
Use for buttons, forms, menus, tables, cards, dialogs, navigation, and other interactive UI states.
Use when interactive surfaces must be navigable without a mouse and must avoid keyboard traps.
Use when a specific accessibility issue must be fixed without fake pass language or harmful ARIA patches.
Use when dynamic UI, forms, icon controls, modals, route changes, or live regions may confuse assistive technology users.
Use when findings need a careful mapping to WCAG 2.2 success criteria and severity without overstating certainty.
Use when icon buttons, compact actions, menus, or toolbar controls may lack clear names or affordances.
Use when designing browser tests for real user behaviour, accessibility checks, and stable selectors.
Use when tests pass but may be shallow, flaky, over-mocked, or unrelated to real risk.
Use before final handoff, merge approval, release note creation, or claim publication.
Use when docs, guides, examples, or site copy may promise more than the implementation proves.
Use when a README needs to become a useful product entry point, not just a file list.
Use when turning repository files into a public template hub with copy actions, categories, examples, and low-friction navigation.
Use when a change touches actors, permissions, data, integration, exports, admin features, or sensitive operations.
Use when environment variables, tokens, credentials, logs, CI, config, or integrations may expose secrets.
Use when work needs useful logs, metrics, traces, alerts, or operational evidence without privacy leakage.
Use as the final review prompt before merge or publication when all evidence must be consolidated.
30 skill assets
Use when converting a task request into a bounded, reviewable scoping packet.
Use when the agent needs a safe implementation plan before editing.
Use when the repository structure, authority files, and scripts must be understood before change.
Use when gathering proof for implementation, review, documentation, or release claims.
Use when command results, manual checks, and skipped checks must be reported cleanly.
Use when the answer must disclose incomplete, unverified, risky, or weaker-than-requested work.
Use when screenshots or rendered UI must be audited for defects and state mismatches.
Use when inspecting semantic structure, names, keyboard behaviour, and user impact.
Use when translating accessibility findings into WCAG 2.2 references and remediation evidence.
Use when interactive flows must be tested by keyboard.
Use when browser tests fail, flake, or need meaningful behaviour assertions.
Use when a bug fix or feature needs tests that would catch future breakage.
Use when reviewing a diff for correctness, maintainability, and evidence.
Use when structural improvement is needed but behaviour must stay stable.
Use when deciding whether files, exports, branches, styles, or docs are unused.
Use when reviewing boundaries, ownership, coupling, and long-term maintainability.
Use when API shapes, schemas, callers, and docs must be reconciled.
Use when reviewing trust boundaries, permissions, secrets, data handling, and abuse paths.
Use when tokens, env vars, logs, config, or CI may expose secrets.
Use when personal, tenant, customer, analytics, export, or audit data may be collected or exposed.
Use when docs must be checked against implementation and repository reality.
Use when release notes must represent verified behaviour and known limitations.
Use when README needs a clearer user journey, catalogue, and verification instructions.
Use when organising many templates into categories, starter packs, and discoverable metadata.
Use when the public site must serve templates clearly on GitHub Pages.
Use when prompts must be immediately usable by agents without vague placeholders.
Use when prompts or workflows need stronger controls against shortcuts and overclaiming.
Use when assessing whether prompts produce reliable, honest, and useful agent output.
Use when work requires a live list of risks, owners, mitigations, and verification gaps.
Use when packaging an upgraded repository, template system, or release bundle.
30 contract assets
Use as the top-level acceptance rule against fake completion.
Use when every claim must be traceable to inspected files, behaviour, commands, or manual evidence.
Use to reject hidden scope expansion, accidental redesign, or unrelated changes.
Use when assumptions must be named before they influence implementation or review.
Use when commands, manual checks, and evidence gaps define acceptance.
Use when tests must prove user or system behaviour rather than shallow implementation details.
Use for UI work that must preserve semantic structure, keyboard access, and WCAG-aligned reasoning.
Use for menus, dialogs, forms, tables, navigation, and custom controls.
Use for icon controls, form controls, composite widgets, and dynamic UI.
Use before accepting visual UI changes.
Use when UI must follow reusable components, tokens, and interaction patterns.
Use when layout must remain usable across viewports and content lengths.
Use for maintainability and structural acceptance.
Use when module, layer, dependency, or ownership boundaries matter.
Use for behaviour-preserving structural change.
Use when removing apparently unused files, exports, branches, or docs.
Use when docs, examples, and guides must match real implementation.
Use for README updates, public pages, and repository positioning.
Use before merge, publication, release note approval, or public handoff.
Use when permissions, identities, integrations, data, or sensitive operations change.
Use for environment variables, credentials, CI, logs, tokens, and configuration.
Use for personal, tenant, analytics, export, retention, or audit data.
Use when adding or changing logs, metrics, traces, or alerts.
Use when adding, changing, or reviewing failures, retries, fallbacks, and messages.
Use when claims or changes affect performance, rendering cost, API use, or bundle weight.
Use before adding packages, frameworks, tools, or external services.
Use when public API, schema, route, exported function, or integration behaviour may change.
Use when packaging branch changes, commits, generated files, or merge handoffs.
Use for this repository’s prompt, skill, and contract assets.
Use when agent handoffs must be structured, inspectable, and easy to review.