---
name: spyn3-data
description: Search, inspect, and answer from business knowledge connected to a SPYN3 workspace through MCP tools or the REST agent gateway. Use when a task requires grounded answers, source discovery, or document retrieval from SPYN3; do not use for changing source data or workspace administration.
---

# SPYN3 Data

Use SPYN3 as the governed evidence layer beneath the current task. Keep the user's
requested output and workflow; this skill controls how workspace evidence is found
and cited, not what the final deliverable must look like.

## Choose the available interface

- When the runtime exposes `search_workspace`, `query_workspace`, `list_sources`,
  or `get_document`, use the MCP workflow in [references/mcp.md](references/mcp.md).
- When an HTTP client is available and `SPYN3_API_URL` plus `SPYN3_API_KEY` are
  already configured, use [references/rest.md](references/rest.md).
- If neither interface is available, state that SPYN3 must be connected or its
  environment variables configured. Never ask the user to paste a secret into
  chat, source code, a command argument that will be logged, or the final answer.

Do not assume a particular agent brand, IDE, shell, or operating system.

## Retrieval workflow

1. Translate the request into one focused evidence question. Preserve exact names,
   identifiers, dates, and constraints.
2. Use `list_sources` only when source coverage is unknown or the user asks what is
   connected. Do not list sources before every search.
3. Search before reading detail. Start with 5 results unless the task needs broader
   coverage. Inspect titles, snippets, source identity, and relevance together.
4. Use a stable `document_id` to retrieve detail only from promising results.
5. Use `query_workspace` or `/agent/query` when synthesis is the job. Use search
   when the user needs raw evidence, comparison, or independent verification.
6. Refine once when results are weak by adding a missing identifier, time range, or
   source term. Do not hide an empty or inconclusive result behind a plausible answer.

## Evidence rules

- Base material claims on returned workspace evidence. Separate evidence from
  inference and label conflicts or uncertainty.
- Cite the returned document title and stable ID. Include source or connector
  identity when it helps the user distinguish records.
- Never invent a document ID, title, URL, score, quotation, or source location.
- A retrieval score ranks candidates; it does not prove that a document is correct,
  current, or authoritative.
- Prefer paraphrase. Quote only when exact wording is material to the request.
- If sources disagree, present the disagreement and relevant dates instead of
  silently choosing one.

## Safety and scope

This skill is read-only. It does not authorize source synchronization, document
writes, connector changes, workspace administration, credential creation, or any
external action. Do not broaden permissions to overcome `401` or `403` responses.

Do not expose Bearer tokens, retrieved secrets, personal data, or sensitive source
content beyond what the user's task requires. Avoid logging authorization headers
or full customer documents. The authenticated credential already determines the
workspace; never ask the model or user to choose a tenant identifier in a request.

## Response shape

Unless the user asks for another format, return:

1. The direct answer or requested artifact.
2. A short `Sources` section containing the supporting title and `document_id` for
   each material source.
3. A one-line limitation only when evidence was missing, stale, conflicting, or
   insufficient.

Keep citations close to the claims they support when the output format permits it.