AI agent prompts

       You are acting as a senior engineer integrating a read-only API Butler GET endpoint into my codebase. Phase 1 — Questions before code. Do not write implementation yet. Ask me exactly 2–3 precise questions you need answered to proceed safely. Strong candidates: - The exact GET URL and whether this API requires X-API-Key (required vs optional in API Butler dashboard) - Which route, layout, or component should own this data (or confirm the best insertion point after a quick scan) - Expected UX for loading / empty / error (and whether pagination or column filters from query params matter for this screen) Wait for my answers. If something critical is still ambiguous, ask one follow-up—still no code until resolved. Phase 2 — Implementation (after I reply). - Use GET only against API Butler; response JSON uses "data" (array of row objects) and "meta" with limit, offset, count, total - Implement loading, empty, and error paths; surface HTTP status and a safe snippet of error body when useful—never fail silently - Reuse existing HTTP utilities, env/config patterns, and UI primitives (tables, lists, cards); extend types at the boundary if TypeScript is already in use - Respect caching boundaries (SSR vs client vs React Server Components): choose what matches this repo’s conventions Negative prompts — do not: - Refactor unrelated packages, rename routes globally, or upgrade tooling “while we’re here” - Introduce Redux, Zustand, TanStack Query, etc., unless the project already depends on them - Treat the endpoint as writable (no POST/PATCH assumptions), invent pagination totals, or hardcode fixture rows without my explicit OK - Commit secrets, print API keys in logs, or embed keys in client bundles without discussing exposure risk Tests: add or extend coverage only where this repo already has a runner and similar specs for data-fetch or UI. 
    

       You are working in my repository on the current branch as a senior engineer. Goal: integrate an API Butler GET endpoint as a read-only JSON source ("data" + "meta" per API Butler docs). Phase 1 — No edits yet. Skim structure enough to ask informed questions, then ask me exactly 2–3 targeted questions before coding. Prefer topics such as: - Confirm GET URL + whether X-API-Key is required for my API - Which existing component or route should display this data (propose a default if you find an obvious owner) - Error UX (toast vs inline) and whether we should wire limit/offset from "meta" into pagination controls Stop until I answer. Phase 2 — Implement with a minimal diff. - Mirror existing data-fetch patterns (hooks, loaders, server actions—whatever this codebase uses) - GET only; forward X-API-Key when required; handle abort/cancellation if sibling code already does for navigations - Loading / empty / error states consistent with neighboring screens Negative prompts — do not: - Sweep formatting changes, dependency bumps, or broad component rewrites in the same PR - Add parallel fetch stacks or state libraries not already in package.json - Strip query parameters, silently retry without backoff strategy, or swallow errors with empty catch blocks - Check in credentials or todo-comment shortcuts like “paste key here” in tracked files Ship tests only if the repo already has patterns for this layer. 
    

       You are pairing with me via Claude Code on a production-minded integration. Objective: read-only consumption of an API Butler GET endpoint ("data" array + "meta" pagination object). Phase 1 — Planning hygiene. Before filesystem edits, ask me 2–3 crisp questions you genuinely need (endpoint + auth mode + surface area / UX expectations are typical). Optionally note assumptions you will make if I stay silent on something non-critical—but still ask the 2–3 upfront. Phase 2 — Deliverables after my replies. - Draft a brief execution plan (files, steps, risks), then implement in small commits or logical chunks - Wire GET + headers correctly; centralize URL/key handling consistent with how secrets already flow here - Provide resilient parsing: guard malformed JSON, surface actionable errors to the UI layer Negative prompts — do not: - Perform speculative migrations, lint/format entire trees, or redesign unrelated UX - Add heavyweight observability or mock servers unless I request them - Misrepresent API Butler as CRUD—this task is read-only GET semantics only Verification: run the existing test and build scripts if present; fix failures you caused. 
    

       Senior-engineer task: integrate an API Butler read-only GET endpoint into my codebase. Phase 1 — Ask 2–3 blocking questions (endpoint URL + X-API-Key requirement + target UI location/error handling). No code until I respond. Phase 2 — Minimal integration. - GET JSON; consume "data" rows and "meta" totals/pagination fields - Loading / error / empty UX aligned with nearby components - Reuse project HTTP helpers and typing conventions Negative prompts — do not: - Expand scope into authentication redesigns, caching layers, or unrelated bugfixes - Add dependencies unless unavoidable and already aligned with repo norms - Fake successful responses when the network fails Run existing automated tests if the workflow is obvious from package scripts. 
    

       React / Next.js integration for an API Butler GET endpoint (read-only). Phase 1 — Ask me 2–3 questions before coding: full GET URL + X-API-Key requirement, whether this ships in a Client Component / hook vs a Server Component / route handler, and how errors should surface. Phase 2 — Match our stack. - Use the project’s fetch wrapper or native fetch with consistent base URLs and env vars for secrets - Render list/table from "data"; expose pagination or “load more” only if we agree it belongs in this slice—derive limits from "meta" - Respect suspense / streaming patterns only if already idiomatic here Negative prompts — do not: - Toggle experimental Next flags, relocate routes wholesale, or replace styling systems - Introduce global providers solely for this fetch unless that mirrors existing architecture - Client-bundle secrets without calling out the exposure tradeoff Tests follow existing React Testing Library / Playwright conventions if present. 
    

       Vue / Nuxt integration for an API Butler GET endpoint (read-only). Phase 1 — Ask 2–3 clarifiers first: endpoint + auth, target page/component, and whether this must run SSR/ISR or strictly client-side. Phase 2 — Follow repo norms. - Prefer composables, useFetch/useAsyncData, or existing API plugins—do not invent a parallel HTTP layer - Bind "data" into lists/tables; wire pagination state only after we agree it’s in scope - Preserve hydration safety and existing Pinia/composable boundaries Negative prompts — do not: - Rewrite layouts, middleware, or i18n plumbing opportunistically - Stuff secrets into nuxt.config public runtime config without justification - Strip error details needed during development unless production masking already exists project-wide 
    

       Plain JavaScript module task: expose a small API Butler GET client for read-only JSON ("data" + "meta"). Phase 1 — Ask 2–3 setup questions: base URL + headers strategy, consumer expectations (Promise vs callbacks), and how callers should observe loading/errors. Phase 2 — Ship a focused module. - Abort-friendly fetch if siblings use AbortController; typed JSDoc if the codebase relies on it - Normalize errors into { ok: false, status, message } or match existing error helpers Negative prompts — do not: - Polyfill entire platforms or add bundlers just for this helper - Mutate global namespaces or monkey-patch fetch unless that’s already house style - Silence network failures—always propagate meaningful errors upward