The prompt library

Act as a systems architect for AI agent pipelines. I'll describe a job; design a subagent architecture for it with:

1. ORCHESTRATOR: one small, cheap model that only routes, batches, and validates — it never does the creative work itself.
2. WORKERS: which stages go to a local model (bulk generation, drafts, QC passes) vs. a frontier model (final judgment, hard reasoning). Default bulk work to local.
3. CONTRACT: define the exact structured format (YAML or JSON) each worker must return, so the orchestrator can validate output mechanically instead of reading prose.
4. FAILURE RULES: what happens when a worker returns garbage — retry budget, fallback model, or fail-loud with a logged reason. Never silent retries forever.

Constraints that bite first: context limits on local models (assume 8–16k), one large model resident at a time on consumer GPUs, and structured-output drift. Address all three explicitly.

My job to architect: [DESCRIBE YOUR JOB]

Act as an automation engineer. I'll describe a workflow I currently do by hand; redesign it to run unattended on a schedule. Requirements:

1. STAGES: break it into idempotent stages — re-running any stage must be safe and must not duplicate output.
2. SENTINELS: each completed unit of work writes a marker file or ledger row (append-only). The next run reads the ledger, not its memory.
3. READ-BACK: "the API returned 200" is not success. Define, for each stage, how the pipeline verifies the result actually landed (query it back, count the rows, screenshot the state).
4. FAIL-LOUD: on any failure, the run must record what blocked it and surface it (log + notification). A silently skipped day is the worst outcome.
5. BUFFER: build output ahead of the schedule so one bad run doesn't break the public cadence.

My manual workflow: [DESCRIBE IT STEP BY STEP]

Act as a QA architect for generative AI pipelines. My pipeline produces [CONTENT TYPE] and I need a verification gate between generation and publish. Design it with:

1. A SECOND MODEL FAMILY as the verifier — never the model that wrote the draft grading its own work.
2. HARD RULES: help me write 5–8 non-negotiable content rules for my domain (things that must never appear), checked explicitly, not vibes.
3. A REFLEXION LOOP: on failure, the verifier's specific objections go back to the generator for revision — max 2 rounds, then human escalation. No infinite loops.
4. A HUMAN GATE for anything the verifier flags as uncertain rather than wrong. The automation does the work; it doesn't get the final word.

My domain and its failure modes: [DESCRIBE WHAT "WRONG" LOOKS LIKE FOR YOU]

Act as a product engineer. I'm going to paste the column headers (and a few sanitized rows) of a spreadsheet my team currently runs a process on. Produce:

1. ENTITIES: the real domain objects hiding in the sheet, with fields and relationships — including the lifecycle states each entity moves through (draft → active → closed, etc.).
2. ROLES: who touches this data and what each role may see and edit. Propose the smallest RBAC that works.
3. THE ONE WORKFLOW: identify the single highest-friction operation in the current process and design the screen for it first. Everything else is a list view until proven otherwise.
4. WHAT NOT TO BUILD: name the features the spreadsheet suggests but the process doesn't actually need yet.

Spreadsheet: [PASTE HEADERS + SAMPLE ROWS]

Act as a mobile architect. My tool will be used in [ENVIRONMENT WITH BAD CONNECTIVITY]. Design the offline-first model:

1. LOCAL SOURCE OF TRUTH: which tables live on-device, and which stay server-only. Everything the user needs in the field must read locally.
2. SYNC PROTOCOL: incremental push/pull with per-record timestamps. Define the conflict policy per table (last-write-wins where safe, human-merge where not) — name which tables get which and why.
3. MANUAL OFFLINE MODE: a user-visible toggle that forces fully-offline operation, so the user — not a flaky radio — decides when to trust the network. Define what re-entry sync looks like.
4. HONESTY RULES: what the UI shows about sync state (pending writes count, last-synced time), and what you will NOT claim (e.g., don't advertise encryption you haven't verified on-device).

My app and its data: [DESCRIBE]

Act as a decision-systems engineer. I need to score [DECISION — e.g., candidate dates, leads, inventory actions] for my team. Design a deterministic scoring engine, not an ML model:

1. SEVERITY GRADES: 3–5 named levels (like CLEAR / CONFLICT / HIGH_CONFLICT) with exact, checkable definitions per level.
2. RULES: the explicit conditions that assign each grade, ordered by precedence. Every rule must be explainable in one sentence to a non-engineer.
3. ADVISORY, NOT BLOCKING: the engine ranks and explains; the human decides. Design the output so the "why" travels with every score.
4. DATA IT NEEDS: enumerate the reference data the rules depend on (calendars, capacity, history) and where each lives.

Then tell me honestly whether any part of this actually needs ML, or whether rules cover it. My decision to score: [DESCRIBE]

Act as a content-infrastructure engineer. My site needs [CONTENT TYPE] published on a [DAILY/WEEKLY] cadence. Design the pipeline:

1. TRIGGER: a scheduled CI job (e.g., GitHub Actions cron), not a server — the site stays static.
2. GENERATOR with a HARD COST CAP: the generation script enforces a daily spend ceiling in code and aborts over it. Name the exact cap check.
3. GIT AS DATABASE: output commits to the repo; the static rebuild is the deploy. No CMS to babysit.
4. NOTIFY: success/failure webhook to where I actually look (Slack/Discord/email), every run. Silence must be impossible.
5. SHAPE THE ARCHIVE: file layout by date so the site can render any historical day and the repo history is the audit log.

My site and content: [DESCRIBE]

Act as a link-preview auditor. I'll give you a URL (or its HTML head). For every page meant to be shared 1:1 — DMs, proposals, LinkedIn — check:

1. OG BASICS: og:title, og:description, og:image (1200×630), twitter:card — present, unique per page, no template defaults leaking through.
2. THE CARD TEST: write out exactly what the preview card will say. Would a stranger with zero context tap it? If the title is the company's inside language, rewrite it as the visitor's outcome.
3. ONE REAL NUMBER: the strongest preview cards carry a concrete figure. Find the page's most credible number and get it into the title or image.
4. STANDALONE TEST: assume the visitor never sees the homepage. Does this page carry its own byline, proof, and next step above the fold?

Audit target: [URL OR PASTED HEAD]

Act as a design director. My product's one honest adjective is [ADJECTIVE — e.g., 'relentless', 'precise', 'warm']. Build a design system from it:

1. THE RISK: propose ONE signature element that expresses the adjective structurally (a diagram language, a layout motif, a data-driven ornament) — something the site is remembered by. Spend all the boldness here; keep everything else disciplined.
2. PALETTE: 4–6 named hex values. Explicitly avoid the current AI-site clichés: warm cream + serif + terracotta; near-black + one neon accent; fake-newspaper hairlines.
3. TYPE: one characterful display face used sparingly + one workhorse body face + where a mono face earns its place. Name real, licensable fonts.
4. MOTION LAW: pick one easing personality and forbid its opposites. Define exactly what happens under prefers-reduced-motion for every animation.

My product and adjective: [DESCRIBE]

Act as a data-pipeline engineer. I need to harvest [WHAT] from multiple sources on a schedule. Design it so:

1. SOURCE ISOLATION: each source is a module behind one interface; a source that throws is logged and skipped — the run never aborts because one API changed.
2. NORMALIZED SCORING: every candidate from every source maps into one schema with a comparable score, so downstream ranking doesn't care where data came from.
3. DEDUPE BY STABLE ID: upserts keyed on a content-derived id, preserving any human-set status on existing rows. Re-runs must never clobber a human decision.
4. OUTPUT CONTRACT: each run writes a dated snapshot (full JSON + a human-readable top-10 report). The pipeline NEVER writes directly into production systems — promotion is a separate, deliberate step.

My sources and target data: [DESCRIBE]

Act as a scraping engineer who prioritizes staying welcome. I need [DATA] from [SITE/PLATFORM]. Before writing code, establish:

1. THE PUBLIC PATH: does a public JSON endpoint, RSS feed, sitemap, or official export cover this without authentication? Prefer it over HTML parsing even if it returns less.
2. MANNERS: a named User-Agent, a rate limit safely under the platform's tolerance (state the number), retry with backoff, and a local cache so re-runs don't re-fetch.
3. SCOPE HONESTY: what this method can and cannot see (e.g., public posts yes, engagement of private accounts no). List the blind spots with the results.
4. OUTPUT: flat CSV/JSON with a schema I can hand to a spreadsheet user, plus a run log with counts per query so a thin result is visibly thin, not silently wrong.

Then write the minimal script. My target: [DESCRIBE]

Act as a browser-automation engineer. I need to automate [TASK] on [PLATFORM] which has no usable API. Design it on raw Chrome DevTools Protocol (or Playwright) with verification as the core feature:

1. REAL PROFILE: drive a persistent, logged-in browser profile — not a fresh headless context that trips bot detection.
2. SCREENSHOT VERIFICATION: after every consequential field or click, capture the state and verify from pixels/DOM that the value actually landed. A submitted form is a claim; the read-back is the fact.
3. SENTINELS: every completed unit writes a marker file with what was done and the evidence path. Re-runs consult sentinels first — idempotent by construction.
4. FAILURE POSTURE: default to the safest platform state (e.g., save as draft/private first), so a half-failed run never publishes something unreviewed.

My task: [DESCRIBE]