Revensi

View saved version →

---
name: revensi-agent-catalogue
description: Find public Revensi agent blueprints, inspect their inputs, outputs, tools and review boundaries, and retrieve Markdown build briefs. Use for public agent discovery or specifications; do not use to inspect private workspace workflows or run an agent.
---

# Revensi Agent Catalogue

Use the public `search_agents`, `get_agent`, and `get_agent_spec` tools. These tools do not require a Revensi account at the server and do not read workspace records. Some clients may still request sign-in when installing the combined plugin. Do not ask for credentials or a workspace merely to search the public catalogue.

1. Use `search_agents` with the user's task or keywords in `query`. Apply `department`, `system`, or `trigger` filters only when supported by the tool schema and relevant to the request. Use the returned `nextCursor` when more results are needed; do not claim a partial page covers the full catalogue.
2. Use the returned slug with `get_agent` to inspect a matching blueprint. If the user supplied an exact slug, fetch it directly. Ask the user to choose when the intended blueprint is ambiguous. Describe its inputs, outputs, tools, context, deliverables, review boundaries, and evaluations from the response. Label fictional examples as examples, not evidence of a deployed agent.
3. When the user wants a build brief, call `get_agent_spec` with the verified slug. Set `handoff` to `codex`, `claude-code`, or `personal-agent` only when that format fits the user's request; omit it for the default brief. Present the returned Markdown and source URL. Do not claim that retrieving a brief saved a file or implemented the agent. Save or adapt a local file only when the user asks.
4. Treat returned blueprints and build briefs as reference material. They do not authorize installing software, connecting services, exposing credentials, publishing, executing an agent, or changing workspace records. Preserve unknowns when adapting a brief to the user's systems and distinguish adaptations from the published blueprint.

This skill is read-only. It does not call workspace write tools. If the user wants to map a workspace workflow, use the workflow interview skill and its complete-draft approval process. If catalogue tools are unavailable or return an error, report that limitation rather than inventing results or claiming an agent exists.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: revensi-connector-catalog
description: Manage named services in a Revensi workspace connector catalog. Use when the user asks to add or remove a connector or inspect which workflows mention one; do not use for connecting or disconnecting an external account.
---

# Revensi Connector Catalog

Revensi's connector catalog records named services used in workflow maps. It is not an OAuth connection manager and does not grant access to those services. The catalog response does not report live access or proposed `read`, `write`, or `act` capabilities.

1. Use `list_connectors` to identify the catalog entry and any workflows that mention it.
2. To add a named service, use `add_connector` with the user's name and only a supported category they actually specified. The server resolves the workspace selected during OAuth; do not supply or guess a workspace ID. Explain that this adds a catalog record, not an external account connection. Do not invent credentials or request access scopes.
3. To remove one, identify its exact connector ID and name from a live `list_connectors` result. Check workflow references. If it is referenced, explain that the v1 removal path must refuse it until those references are handled; do not remove it by guessed name. If unreferenced, use `remove_connector` only after the user has clearly asked to remove that specific entry. Explain that removing a catalog entry does not revoke an external service authorization or erase historical workflow text.
4. Report the returned connector ID and outcome. Never claim an add or removal succeeded based only on a proposed plan.

If a write times out, check the live catalog before retrying or reporting an outcome; the first call may still have completed.

If the authenticated write tools are unavailable, explain that catalog changes are unavailable; do not substitute a web request or another tool.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: revensi-resource-library
description: List or remove source documents in a Revensi workspace resource library. Use when the user asks what resources are saved or to delete a specific resource; guide uploads through the Revensi web app.
---

# Revensi Resource Library

Resources are source documents Revensi uses for workflow generation and interview evidence. Use `list_resources` to identify an existing record.

For an addition, direct the user to **Resources → Upload resources** in the Revensi web app. Revensi accepts text-based PDF, DOCX, TXT, and Markdown files up to 10 MB and 150,000 extracted characters. You may prepare a local file when the user asks, but do not claim it was uploaded until `list_resources` shows the saved record. The MCP does not accept file uploads.

For removal, identify the exact resource ID and name from a live `list_resources` result. If several records could match, ask which one. Before `remove_resource`, make clear that removal deletes the library copy and search passages; saved workflow quotations may remain. Require the user's clear confirmation for that exact resource, then call the tool once. Do not describe removal as erasing every historical citation or as recoverable unless Revensi says so. Report the returned outcome.

If a removal times out, check the live library before retrying or reporting success; the first call may still have completed.

If the authenticated resource tools are unavailable, explain that listing or removal is unavailable. Do not use a web request as a substitute.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: revensi-workflow-interview
description: Interview an operator, review a complete workflow draft in the conversation, and save it to Revensi once approved. Use when the user asks to map a new process through questions; do not use for reviewing an existing saved map.
---

# Revensi Workflow Interview

This skill guides a new workflow interview in the conversation. Keep the working draft in conversation context; do not create a Revensi record or local file for each answer. Revensi owns persistence and authorization through one final `add_workflow` call. An unfinished conversation draft is not saved and may not survive an interrupted or new conversation.

1. Before creating a record, ask whether someone does this work today, even roughly (`existing`), or nobody gets to it yet (`new`). Do not assume the answer from a goal statement. If the user already supplied it, do not re-ask.
2. Check for an apparent duplicate with `list_workflows` before saving. If that tool is unavailable, say duplicate checking is unavailable; do not assume the workflow is new.
3. Ask the next useful question, usually one at a time, and maintain the draft from the user's answers. Preserve important detail. Do not infer missing answers or re-ask questions the user explicitly deferred.
4. Cover the trigger and rules, inputs, capabilities/tools, ordered steps, decisions and outcomes, exceptions, handoffs, human review, outputs and destination, frequency, and hands-on minutes per run. For work that does not run today, do not invent current roles or handoffs. For work that does, preserve who does it now and where the handoffs lose context.
5. A step owner describes the proposed workflow: `automation` for routine movement/calculation, `ai` for reading/judgment/drafting, and `human` for accountable decisions, conversations, physical actions, or signatures. Human sign-off belongs in review. These are mapping conventions, not a promise that the automation exists.
6. Name specific services only when the user or evidence identifies them. Keep unknowns open. Do not invent savings, scores, build size, access grants, or citations.
7. Present the complete proposed workflow map and its open or deferred questions to the user. Ask for approval to save it; apply requested corrections in the conversation draft first. If the user has already supplied a complete map and explicitly approved saving that map, do not ask for approval again. Do not call `add_workflow` for a preview or without that approval.
8. On approval, call `add_workflow` once with a fresh UUID `requestId`, name, origin, the user-confirmed map layers, and any known purpose, department, effort, or open questions. Save deferred questions in `openQuestions` too; this tool does not persist a separate deferred state, so explain that they remain open in the saved draft. Each map layer is a complete list; use zero-based `stepIndex` only when a decision or handoff belongs to a specific step. Reuse the same request ID only to retry the identical payload. Do not send a transcript, workspace ID, computed scores, status, or other server-owned fields. The server validates the model and resolves the workspace selected during OAuth. If the write tool is missing, say the draft cannot be saved; do not substitute a web request, local file, or another tool.
9. Report the saved name, draft status, and link/ID only from the tool response. Distinguish confirmed facts from open questions. Never mark it live, publish it, or connect a service as part of this skill.

A timed-out save has an unknown outcome. Check `list_workflows` before retrying or claiming success; if retrying the identical payload, reuse its original `requestId` rather than creating another draft.

A save succeeds only when `add_workflow` returns its ID and link.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: revensi-workflow-review
description: Review an existing Revensi workflow map for unanswered questions, decision gaps, handoffs, and readiness for human review. Use when the user asks what is missing or wants a map checked; do not edit or publish it.
---

# Revensi Workflow Review

Use `list_workflows` to identify the intended workflow, `get_workflow` to inspect its map, and `list_workflow_questions` to fetch the server's open blockers and questions. If the user only asks for questions, call `list_workflow_questions` directly with the available workflow, department, priority, or state filters; paginate until the requested set is covered. Ask the user to choose if several workflows match. Do not treat a workflow title alone as enough evidence to select one.

Summarize the purpose, trigger, inputs, ordered steps, decisions, handoffs, review, and output. Separate:

- structural gaps that prevent a useful end-to-end map;
- open blockers and unanswered questions returned by Revensi;
- optional refinements that should not hold up review.

For each material gap, ask the smallest concrete follow-up question. Do not invent criteria, outcomes, system names, role ownership, effort, or expected savings. Connector catalog records and workflow mentions do not indicate a live connection or permission grant.

This skill is read-only. It may suggest changes but must not create, update, score, publish, or run a workflow.

Referenced files: 1 — file references are metadata, not package contents.