mirror of
https://github.com/MODSetter/SurfSense.git
synced 2026-05-08 23:32:40 +02:00
feat: updated agent harness
This commit is contained in:
parent
9ec9b64348
commit
31a372bb84
139 changed files with 12583 additions and 1111 deletions
|
|
@ -0,0 +1 @@
|
|||
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
name: email-drafting
|
||||
description: Draft an email matching the user's voice, with structured intent and CTA
|
||||
allowed-tools: search_surfsense_docs
|
||||
---
|
||||
|
||||
# Email drafting
|
||||
|
||||
## When to use this skill
|
||||
"Draft an email to ...", "reply to this thread", "write a follow-up to X". Plain "summarize the email" is **not** in scope — that's a comprehension task.
|
||||
|
||||
## Voice
|
||||
Search the KB for prior emails from the user to similar audiences (same recipient, same topic class). Mirror tone, opening style, sign-off, and length distribution. If there is no precedent, default to: warm, direct, no filler, short paragraphs, one clear ask.
|
||||
|
||||
## Required structure
|
||||
Every draft includes, in this order:
|
||||
|
||||
1. **Subject line** — concrete, ≤ 8 words, no clickbait, no `Re:` unless replying.
|
||||
2. **Opening (1 sentence)** — context the recipient already shares; never restate what they wrote unless the thread is long.
|
||||
3. **Body** — the actual point in one short paragraph. Bullets only if there are >3 discrete items.
|
||||
4. **Single explicit CTA** — what you want the recipient to do, with a soft deadline if relevant.
|
||||
5. **Sign-off** — match the user's prior closing style.
|
||||
|
||||
## Always offer alternatives
|
||||
End your message with: "Want me to make it shorter, more formal, or add a different angle?" — give the user one obvious next step.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
name: kb-research
|
||||
description: Structured approach to finding and synthesizing information from the user's knowledge base
|
||||
allowed-tools: search_surfsense_docs, scrape_webpage, read_file, ls_tree, grep, web_search
|
||||
---
|
||||
|
||||
# Knowledge-base research
|
||||
|
||||
## When to use this skill
|
||||
- The user asks "find/look up/research" something specifically inside their knowledge base.
|
||||
- The user references documents, notes, repos, or connector data they expect to exist already.
|
||||
- A multi-document synthesis is required (e.g., "summarize what we've discussed about X across all my notes").
|
||||
|
||||
## Plan
|
||||
1. Decompose the user's question into 2-4 specific, citation-worthy sub-questions.
|
||||
2. For each sub-question, run **one** targeted KB search (focused on terms the user would have written, not synonyms). Open the most relevant 2-3 documents fully via `read_file` if their excerpts are too short.
|
||||
3. Use `grep` to find supporting passages in long files instead of re-reading them end to end.
|
||||
4. Cite every claim with `[citation:chunk_id]` exactly as the chunk tag specifies.
|
||||
|
||||
## What good output looks like
|
||||
- Short paragraphs with inline citations.
|
||||
- Quoted phrases when wording matters.
|
||||
- An explicit "Not found in your knowledge base" callout when a sub-question has no support — never fabricate.
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
---
|
||||
name: meeting-prep
|
||||
description: Pull together briefing materials before a scheduled meeting
|
||||
allowed-tools: search_surfsense_docs, web_search, scrape_webpage, read_file
|
||||
---
|
||||
|
||||
# Meeting preparation
|
||||
|
||||
## When to use this skill
|
||||
The user mentions an upcoming meeting, call, or interview and asks you to "prep", "brief me", "pull background", or "what do I need to know about X before tomorrow".
|
||||
|
||||
## Output structure
|
||||
Always produce these sections (omit any with no signal — don't pad):
|
||||
|
||||
1. **Attendees & context** — who's in the room, their roles, what they care about. Pull from KB notes about prior interactions; supplement with public profile facts via `web_search` when names or companies are unfamiliar.
|
||||
2. **Open threads** — outstanding action items, unresolved decisions, last-mentioned blockers from prior conversation history.
|
||||
3. **Recent moves** — within the last 30 days: relevant launches, hires, news. Cite KB chunks when present, otherwise external sources.
|
||||
4. **Suggested questions** — 3-5 questions the user could ask, tailored to the open threads and the attendees' likely priorities.
|
||||
|
||||
## Source ordering
|
||||
- Always check the user's KB **first** for prior meeting notes, internal docs, or Slack threads about these attendees.
|
||||
- Only fall back to `web_search` for *publicly verifiable* facts — never to fabricate a participant's preferences or relationships.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
name: report-writing
|
||||
description: How to scope, draft, and revise a Markdown report artifact via generate_report
|
||||
allowed-tools: generate_report, search_surfsense_docs, read_file
|
||||
---
|
||||
|
||||
# Report writing
|
||||
|
||||
## When to use this skill
|
||||
The user explicitly requests a deliverable: "write a report on …", "draft a memo", "produce a brief", "expand the previous report". A creation or modification verb pointed at an artifact is required (see `generate_report`'s when-to-call rules).
|
||||
|
||||
## Decision flow
|
||||
1. **Source strategy.** Decide which `source_strategy` fits:
|
||||
- `conversation` — substantive Q&A on the topic already in chat.
|
||||
- `kb_search` — fresh topic; supply 1–5 precise `search_queries`.
|
||||
- `auto` — partial conversation context; let the tool fall back.
|
||||
- `provided` — verbatim source text only.
|
||||
2. **Style.** Default to `report_style="detailed"` unless the user explicitly asks for "brief", "one page", "500 words".
|
||||
3. **Revisions.** When modifying an existing report from this conversation, set `parent_report_id` and put the change list in `user_instructions` ("add carbon-capture section", "tighten conclusion").
|
||||
4. **Never paste the report back into chat** after `generate_report` returns — confirm and let the artifact card render itself.
|
||||
|
||||
## Hooks for KB-only mode
|
||||
If `kb_search`/`auto` returns no results, do **not** silently switch to general knowledge. Surface the gap in your confirmation message.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
name: slack-summary
|
||||
description: Distill a Slack channel or thread into actionable summary
|
||||
allowed-tools: search_surfsense_docs
|
||||
---
|
||||
|
||||
# Slack summarization
|
||||
|
||||
## When to use this skill
|
||||
The user asks to summarize Slack ("what happened in #eng-platform this week", "what did Alice say about the launch", "catch me up on the design channel").
|
||||
|
||||
## Required inputs
|
||||
Confirm before searching:
|
||||
- **Which channel(s) or thread(s)?** Don't guess if ambiguous.
|
||||
- **What time window?** Default to the last 7 days when not specified, but say so.
|
||||
|
||||
## Output shape
|
||||
Produce three concise sections:
|
||||
1. **Key decisions** — explicit choices that were made, with the deciding message cited.
|
||||
2. **Open questions** — things asked but not answered, with the asking message cited.
|
||||
3. **Action items** — `@mention` who owes what by when, *only if explicitly stated*. Don't invent assignees.
|
||||
|
||||
## What not to do
|
||||
- Never produce a chronological play-by-play of every message — distill.
|
||||
- Never quote private messages without flagging them as such.
|
||||
- If the channel was empty in the time window, say so — don't fabricate filler.
|
||||
Loading…
Add table
Add a link
Reference in a new issue