Turn setup intent into the smallest complete working result. Adapt to what the user actually needs. Do not force every setup through schema creation, embeddings, graph, backfill, continuous capture, retrieval code, or agent instructions.

Treat this skill as a decision guide, not a mandatory architecture or ordered checklist. Adapt, reorder, replace, or omit recommended components and numeric defaults when inspected evidence or the user's outcome supports a better design. Numeric defaults are starting points, including sample sizes, result counts, token budgets, recall timing, capture timing, and model rankings.

Keep only safety and correctness boundaries firm: preserve authorization and provenance, keep secrets out of plans and payloads, disclose and approve material effects, use compatible embedding contracts, avoid unsupported public interfaces and invented graph relationships, and test the important selected path before calling it operational.

Activate for broad prompts such as "Help me set up Polygres," contextual prompts such as "look at my conversations and set up Polygres," and detailed technical specifications. Treat examples as illustrations, not required wording.

For a question such as "What can I do with Polygres?", use a personalized recommendation branch. Inspect the accessible current workspace and any uniquely resolved Polygres project with bounded, read-only checks. Look only at the data shape, existing retrieval configuration, and application or agent entry points needed to identify useful opportunities. Then give a short answer that says what was found, leads with the most useful Polygres outcome for this project, and mentions only relevant alternatives. Do not return a generic feature list, create a plan, scaffold files, or mutate anything. End with a direct next step such as:

To proceed, reply: Set up the recommended Polygres pipeline.

Treat that reply or an equivalent acceptance as setup intent. Carry the inspected source, project, outcome, and recommendation into the setup flow without repeating discovery unless the evidence is stale. This acceptance starts setup; it is not mutation approval. Prepare the implementation and show the normal consolidated review before making covered changes.

If the prompt identifies neither a source or inspectable context nor a desired outcome, do not inspect, design, scaffold, or configure yet. Ask one short direction question first:

What would you like Polygres to do, and where is the relevant data? For
example: conversations or agent memory, an existing database, files or an API,
search and retrieval, or connected-data exploration.

Treat a response that identifies a source, an outcome, or both as enough to begin. Infer the remaining reversible details from inspection instead of turning the opening question into a form. Contextual prompts such as "look at my conversations and set up Polygres" and detailed specifications skip this question and proceed immediately.

If the user asks for a generic explanation or design comparison that does not request personalized inspection, use . If they want a usable project, pipeline, memory, search, ingestion, synchronization, or agent integration, continue here.

Do not spend setup time explaining Polygres unless the user asks. Do not read an entire source before a privacy filter exists. Do not stop at a plan or generic scaffold when runnable source-specific code can be produced.

Critical means the answer changes safety or makes the implementation invalid:

Group critical unknowns into one short request. Prefer a reversible default and state it in the review. Use for the initial vague-prompt question or when genuinely blocked; it is not the normal flow for contextual or detailed requests.

Read for schema and graph decisions and for text, embedding, Context, and recall. For semantic retrieval, follow and use after bounded inspection.

Read only the source reference that matches the inspected input:

references/source-chat-agents.md

references/source-databases.md

references/synced-projects.md

references/source-files-and-apis.md

Follow . The generated implementation must use stable source identities, filter before persistence or embedding, write idempotently, checkpoint only after durable success, expose exact capture and retrieval commands when selected, and include focused tests.

Use the public interface appropriate to each workload:

Never apply the standard-project mutation routes to a synced project. Do not probe rows validation, request target database information, or infer that a project API key can call sync control-plane operations.

The single-row contract is available in CLI/SDK and includes , , , and . If the installed client or project does not contain that endpoint version, mark capture , give the exact upgrade requirement, and continue all unaffected setup work. Never infer the endpoint or disguise a bulk import as per-turn capture.

When a bulk import feeds a selected Context collection, reconcile the imported source rows into Context before declaring semantic retrieval operational. The rows API does not delete records; route deletion through an approved source-row deletion path and remove the corresponding Context, text, and graph evidence.

For multi-step work, use and quietly lint the internal plan with . Automatically fix blockers from available evidence; resolve or accept warnings without turning them into user questions. Never make the user read or edit the plan. Use only as a base for selected local files, then add the source-specific runtime. Render the single review with .

Follow . One approval covers the reviewed setup while project, source scope, data egress, destructive effects, and paid processing remain unchanged. Implementation details and harmless local files do not invalidate it. Credentials are always local environment-variable values; inspect presence with , never their contents.

Use to add an idempotent managed block to the relevant or equivalent file. Preserve all user-authored text. Prepare a preview before approval. Modify the active instruction file only after the consolidated review is approved. The block may contain capture, recall, or both according to the selected integration. It must name each selected command, say what is safe to store, describe the selected timing, and state the real guarantee.

Agent instructions are guidance. For guaranteed or retryable capture, also wire and test an application hook, wrapper, outbox, worker, or equivalent runtime. Never store system instructions, retrieved context, credentials, attachments, or tool/environment output unless the user explicitly selected and approved that content.

First prove the selected vertical slice: safe normalization, rejection before egress, idempotent write when applicable, ownership filtering, provenance, and one useful retrieval result. Verify graph or Context readiness only when enabled. Then test update, deletion, retry, resume, reconciliation, and agent integration only when those capabilities were selected.

Report , , or from observed evidence. Name omitted components as intentionally not selected, not missing. Do not claim remote setup, continuous capture, or retrieval works when only local files were generated.