Data & APIs

Exact prompt

Design a stable API contract for the capability below using the supplied system context. Do not invent existing endpoints, data, or infrastructure.

Capability and consumer needs:
{{capability_context}}

Existing system and conventions:
{{system_context}}

Constraints and quality requirements:
{{constraints}}

Instructions:
1. Define the resource or operation boundary, consumer goals, ownership, and what remains outside the interface.
2. Specify request fields, types, required conditions, defaults, validation, normalization, size limits, and sensitive-data handling.
3. Specify success and error responses with stable machine codes, actionable messages, retry semantics, and correlation information.
4. Define authentication, authorization, tenancy, rate limits, idempotency, pagination, ordering, filtering, concurrency, and consistency only where relevant.
5. Include versioning, additive evolution, deprecation, backward compatibility, and consumer-migration expectations.
6. Describe observability without logging secrets, tokens, or unnecessary personal data.
7. Provide contract tests for happy paths, boundaries, invalid input, permissions, retries, duplicates, and compatibility.

Return assumptions, the proposed contract, examples using synthetic values, error matrix, evolution policy, and verification plan. Mark open architecture decisions instead of fabricating repository behavior.

Replace before use

Capability and consumers{{capability_context}}

The user outcome, operations, known consumers, usage patterns, and business rules.

System context{{system_context}}

Current interfaces, schemas, framework conventions, ownership, deployment, and dependency constraints.

Constraints and quality requirements{{constraints}}

Security, privacy, latency, scale, consistency, compatibility, compliance, and operational boundaries.

Exact prompt

Review this third-party API integration against the supplied provider documentation and repository context. Treat missing evidence as an open question.

Integration code and flow:
{{integration_context}}

Provider contract and limits:
{{provider_contract}}

Security, privacy, and operational requirements:
{{requirements}}

Instructions:
1. Trace data from input through transformation, request, response, storage, logging, retries, and user-visible outcomes.
2. Check endpoints, methods, headers, schemas, types, units, time zones, pagination, ordering, versioning, and documented limits.
3. Review credential acquisition, storage, scoping, rotation, redaction, and server-versus-client boundaries without exposing secret values.
4. Analyze timeout, cancellation, retry, backoff, idempotency, duplicate, partial-success, quota, provider-outage, and malformed-response behavior.
5. Identify personal or confidential data, purpose, minimization, consent, residency, retention, deletion, and subprocessors where supplied evidence permits.
6. Check observability, alerts, feature controls, fallback behavior, contract tests, and provider-change detection.
7. Separate blocking defects from documentation gaps and optional resilience improvements.

Return a data-flow summary, prioritized findings, failure matrix, provider questions, and focused test plan. Do not call the provider, rotate keys, modify data, or claim compliance.

Replace before use

Integration code and flow{{integration_context}}

Relevant code, architecture, data flow, environments, consumers, and current behavior.

Provider contract{{provider_contract}}

Current official documentation excerpts, version, quotas, errors, policies, and change notices.

Security and operational requirements{{requirements}}

Data classification, authentication, availability, privacy, retention, monitoring, and recovery rules.

Exact prompt

Investigate the data-quality anomaly below using read-only evidence first. Separate a real-world change from instrumentation, pipeline, query, and interpretation problems.

Observed anomaly and impact:
{{anomaly_context}}

Data definitions and lineage:
{{data_context}}

Available evidence and access limits:
{{evidence_context}}

Instructions:
1. Restate the metric or field definition, grain, population, time zone, freshness expectation, and comparison baseline.
2. Verify when the anomaly first appears and whether it affects sources, raw ingestion, transformations, models, queries, dashboards, exports, or only one view.
3. Check schema changes, nulls, duplicates, late data, backfills, joins, filters, units, rounding, identity resolution, sampling, and deployment timing.
4. Rank hypotheses by evidence and name one read-only discriminating query or check for each.
5. Use bounded date ranges and aggregate or synthetic output; avoid returning personal records or unrestricted scans.
6. Preserve evidence and define criteria for quarantining, correcting, backfilling, or communicating affected data.
7. Put updates, deletes, backfills, and destructive maintenance behind explicit owner approval, backups, exact target checks, dry runs, row-count bounds, and rollback.

Return a definition check, lineage map, hypothesis table, safe diagnostic queries, impact assessment, and guarded remediation plan. Do not execute queries or mutate data.

Replace before use

Anomaly and impact{{anomaly_context}}

The observed change, affected metric or data, dates, baselines, users, and decision impact.

Definitions and lineage{{data_context}}

Metric definitions, schemas, sources, transformations, schedules, ownership, and expected quality rules.

Evidence and access limits{{evidence_context}}

Sanitized logs, query results, changes, incidents, allowed environments, permissions, and privacy constraints.

Exact prompt

Plan a reversible data migration for the change below. Provide reviewable templates and checkpoints, not executable production instructions.

Current and target data models:
{{model_context}}

Consumers and operational context:
{{consumer_context}}

Constraints, volume, and recovery evidence:
{{migration_constraints}}

Instructions:
1. Define invariants, ownership, source of truth, affected records, consumers, writers, readers, indexes, constraints, and retention obligations.
2. Choose an expand-migrate-contract sequence or explain why another staged approach is safer.
3. Preserve compatibility during mixed-version operation and identify dual-read, dual-write, backfill, or synchronization hazards.
4. Design an idempotent, resumable, rate-limited backfill with explicit scope, checkpointing, row bounds, concurrency controls, and dead-letter handling.
5. Specify preflight counts, sampling, checksums, reconciliation, application behavior, performance, and business-level validation.
6. Define pause, rollback, roll-forward, restore, and irreversible cutoff points with owners and authorization.
7. Use placeholders for connection details and keep delete, truncate, drop, overwrite, and unrestricted update operations out of normal steps.

Return the phased plan, compatibility matrix, bounded pseudocode or query templates, validation suite, observability, recovery plan, and sign-off checklist. Do not connect to a database or execute writes.

Replace before use

Current and target models{{model_context}}

Schemas, data meaning, invariants, source of truth, desired change, and known quality issues.

Consumers and operations{{consumer_context}}

Readers, writers, versions, jobs, APIs, dashboards, owners, deployments, and support expectations.

Constraints and recovery evidence{{migration_constraints}}

Volume, rate limits, downtime, privacy, retention, backups, restore results, permissions, and change windows.