Research Brief Builder

Gathers multi-source research into a structured brief with sources, key findings, and open questions.

skillProductivityinstructionsworkflowbrief-template

by Muse Skills editors · Written for this directory

Install the "Research Brief Builder" skill. Its full source is below. Create it
at ~/workspace/skills/research-brief-builder/SKILL.md following skill-creator
conventions (name and description frontmatter; Purpose, Workflow,
Output Contract, Operating Rules sections). Then confirm it is
installed and tell me the trigger phrases.

--- SOURCE ---
---
name: research-brief-builder
description: Turn scattered research into a structured brief with sources, findings, and open questions. Trigger phrases: "build a research brief", "research this for me", "brief me on".
---
# Purpose

Replace the tab sprawl with one document you can trust. Research
Brief Builder gathers research from the sources you name or that
are publicly reachable, distills it into key findings, and lays
it out as a structured brief: question asked, what each source
says, where they agree, where they conflict, and which questions
are still open. Every claim carries its source, so you can check
the original in seconds.

# Workflow

1. The user states the research question and any constraints:
   sources to prefer, sources to exclude, deadline for currency
   (e.g. "only 2025 or newer").
2. Gather the research from the named or publicly available
   sources. Note the publication date of each source.
3. Extract findings per source in the source's own terms before
   any synthesis. Do not mix sources into one voice.
4. Synthesize: agreement points, conflicts, and the gaps no
   source covers well.
5. Write the brief in the template below and deliver it with the
   source list, each claim linked to the source that made it.

# Output Contract

Each brief contains:

- The question, restated in one line
- Key findings: 3 to 7 bullet points, each with its source
- Where sources agree, and where they conflict
- Open questions the research did not answer
- A source list with publication dates and links where public

If fewer than three solid sources turn up, say so plainly and
deliver the thin brief rather than padding it.

# Operating Rules

- Never invent a citation. If a claim cannot be traced to a
  source you actually read, drop the claim.
- Never reach paywalled, logged-in, or private accounts. Only
  public pages and sources the user provides.
- Distinguish what a source says from what you infer. Inferences
  get flagged as your reading, not the source's claim.
- When sources conflict, report the conflict. Never pick a
  winner silently.
- Keep findings proportional to evidence: one source is a hint,
  not a consensus.
- Never act on the research: no purchases, no outreach, no
  decisions. The brief informs; the user decides.

View source

Ready to copy.

Details

Type: skill
Category: Productivity
Version: 1.0.0
Added: 10 Oct 2026
Author: Muse Skills editorsWritten for this directory
Includes: instructionsworkflowbrief-template
Source: github.com/…/research-brief-builder.md

Install the "Research Brief Builder" skill. Its full source is below. Create it
at ~/workspace/skills/research-brief-builder/SKILL.md following skill-creator
conventions (name and description frontmatter; Purpose, Workflow,
Output Contract, Operating Rules sections). Then confirm it is
installed and tell me the trigger phrases.

--- SOURCE ---
---
name: research-brief-builder
description: Turn scattered research into a structured brief with sources, findings, and open questions. Trigger phrases: "build a research brief", "research this for me", "brief me on".
---
# Purpose

Replace the tab sprawl with one document you can trust. Research
Brief Builder gathers research from the sources you name or that
are publicly reachable, distills it into key findings, and lays
it out as a structured brief: question asked, what each source
says, where they agree, where they conflict, and which questions
are still open. Every claim carries its source, so you can check
the original in seconds.

# Workflow

1. The user states the research question and any constraints:
   sources to prefer, sources to exclude, deadline for currency
   (e.g. "only 2025 or newer").
2. Gather the research from the named or publicly available
   sources. Note the publication date of each source.
3. Extract findings per source in the source's own terms before
   any synthesis. Do not mix sources into one voice.
4. Synthesize: agreement points, conflicts, and the gaps no
   source covers well.
5. Write the brief in the template below and deliver it with the
   source list, each claim linked to the source that made it.

# Output Contract

Each brief contains:

- The question, restated in one line
- Key findings: 3 to 7 bullet points, each with its source
- Where sources agree, and where they conflict
- Open questions the research did not answer
- A source list with publication dates and links where public

If fewer than three solid sources turn up, say so plainly and
deliver the thin brief rather than padding it.

# Operating Rules

- Never invent a citation. If a claim cannot be traced to a
  source you actually read, drop the claim.
- Never reach paywalled, logged-in, or private accounts. Only
  public pages and sources the user provides.
- Distinguish what a source says from what you infer. Inferences
  get flagged as your reading, not the source's claim.
- When sources conflict, report the conflict. Never pick a
  winner silently.
- Keep findings proportional to evidence: one source is a hint,
  not a consensus.
- Never act on the research: no purchases, no outreach, no
  decisions. The brief informs; the user decides.

Before you install

A shared skill carries somebody else's instructions. Read the source before you install it.
Never paste an API key, password, or token into anything a skill asks for. Legitimate skills use Muse's own secure flows.
Installing copies the setup into your own environment. It gives the author nothing.

What it does

Research Brief Builder turns the “forty open tabs” problem into one document you can actually use. Give it a question and any ground rules, like sources to prefer or a freshness cutoff, and it reads through what it can reach, extracts what each source says in its own terms, then synthesizes the result: the key findings, the points where sources agree, the places where they disagree, and the questions nobody has answered yet.

The discipline is in the citations. Every claim carries its source with a publication date, inferences are flagged as such, and if fewer than three solid sources turn up it tells you the brief is thin instead of padding it. Conflicts are reported, not resolved silently, so you see the real shape of the evidence.

It is read-only research support. It never touches paywalled or private accounts, and it never acts on what it finds. You get the brief, you make the call.

What it includes

A research question intake with source and freshness constraints
Per-source findings kept in the source’s own terms
Synthesis: agreements, conflicts, and open questions
Every claim linked to its source with publication date
Honest thin-brief reporting when sources are scarce

Example

Input: “Brief me on garage EV charger installation costs, only 2025 or newer sources, homeowner forums preferred.”

Output:

Question: What does a home EV charger install cost in 2025?

Key findings:
- Median installed cost $1,200 to $1,800 [Electrician forums, 2025]
- Panel upgrades add $800 to $2,000 when needed [NEC code guide, 2025]
- Utility rebates offset $300 to $500 in most states [DOE database, 2025]

Agreement: labor is half the bill. Conflict: whether 60A circuits
are needed for most drivers.

Open: long-run panel health after sustained 48A loads.
Sources: [3 links with dates]

What this one touches

Summarizes only the sources you name or that are publicly available. It never fabricates citations, never reaches paywalled or private accounts, and every claim carries the source it came from. It drafts research only; no decisions, purchases, or messages on your behalf.

Install

Copy this block and paste it into your Muse chat. Muse does the install and confirms when it's done.

Install prompt

Install the "Research Brief Builder" skill. Its full source is below. Create it
at ~/workspace/skills/research-brief-builder/SKILL.md following skill-creator
conventions (name and description frontmatter; Purpose, Workflow,
Output Contract, Operating Rules sections). Then confirm it is
installed and tell me the trigger phrases.

--- SOURCE ---
---
name: research-brief-builder
description: Turn scattered research into a structured brief with sources, findings, and open questions. Trigger phrases: "build a research brief", "research this for me", "brief me on".
---
# Purpose

Replace the tab sprawl with one document you can trust. Research
Brief Builder gathers research from the sources you name or that
are publicly reachable, distills it into key findings, and lays
it out as a structured brief: question asked, what each source
says, where they agree, where they conflict, and which questions
are still open. Every claim carries its source, so you can check
the original in seconds.

# Workflow

1. The user states the research question and any constraints:
   sources to prefer, sources to exclude, deadline for currency
   (e.g. "only 2025 or newer").
2. Gather the research from the named or publicly available
   sources. Note the publication date of each source.
3. Extract findings per source in the source's own terms before
   any synthesis. Do not mix sources into one voice.
4. Synthesize: agreement points, conflicts, and the gaps no
   source covers well.
5. Write the brief in the template below and deliver it with the
   source list, each claim linked to the source that made it.

# Output Contract

Each brief contains:

- The question, restated in one line
- Key findings: 3 to 7 bullet points, each with its source
- Where sources agree, and where they conflict
- Open questions the research did not answer
- A source list with publication dates and links where public

If fewer than three solid sources turn up, say so plainly and
deliver the thin brief rather than padding it.

# Operating Rules

- Never invent a citation. If a claim cannot be traced to a
  source you actually read, drop the claim.
- Never reach paywalled, logged-in, or private accounts. Only
  public pages and sources the user provides.
- Distinguish what a source says from what you infer. Inferences
  get flagged as your reading, not the source's claim.
- When sources conflict, report the conflict. Never pick a
  winner silently.
- Keep findings proportional to evidence: one source is a hint,
  not a consensus.
- Never act on the research: no purchases, no outreach, no
  decisions. The brief informs; the user decides.

Install the "Research Brief Builder" skill. Its full source is below. Create it
at ~/workspace/skills/research-brief-builder/SKILL.md following skill-creator
conventions (name and description frontmatter; Purpose, Workflow,
Output Contract, Operating Rules sections). Then confirm it is
installed and tell me the trigger phrases.

--- SOURCE ---
---
name: research-brief-builder
description: Turn scattered research into a structured brief with sources, findings, and open questions. Trigger phrases: "build a research brief", "research this for me", "brief me on".
---
# Purpose

Replace the tab sprawl with one document you can trust. Research
Brief Builder gathers research from the sources you name or that
are publicly reachable, distills it into key findings, and lays
it out as a structured brief: question asked, what each source
says, where they agree, where they conflict, and which questions
are still open. Every claim carries its source, so you can check
the original in seconds.

# Workflow

1. The user states the research question and any constraints:
   sources to prefer, sources to exclude, deadline for currency
   (e.g. "only 2025 or newer").
2. Gather the research from the named or publicly available
   sources. Note the publication date of each source.
3. Extract findings per source in the source's own terms before
   any synthesis. Do not mix sources into one voice.
4. Synthesize: agreement points, conflicts, and the gaps no
   source covers well.
5. Write the brief in the template below and deliver it with the
   source list, each claim linked to the source that made it.

# Output Contract

Each brief contains:

- The question, restated in one line
- Key findings: 3 to 7 bullet points, each with its source
- Where sources agree, and where they conflict
- Open questions the research did not answer
- A source list with publication dates and links where public

If fewer than three solid sources turn up, say so plainly and
deliver the thin brief rather than padding it.

# Operating Rules

- Never invent a citation. If a claim cannot be traced to a
  source you actually read, drop the claim.
- Never reach paywalled, logged-in, or private accounts. Only
  public pages and sources the user provides.
- Distinguish what a source says from what you infer. Inferences
  get flagged as your reading, not the source's claim.
- When sources conflict, report the conflict. Never pick a
  winner silently.
- Keep findings proportional to evidence: one source is a hint,
  not a consensus.
- Never act on the research: no purchases, no outreach, no
  decisions. The brief informs; the user decides.

Full source

This is the exact text Muse installs. Read it. That's the whole trust model.

SKILL.md

---
name: research-brief-builder
description: Turn scattered research into a structured brief with sources, findings, and open questions. Trigger phrases: "build a research brief", "research this for me", "brief me on".
---
# Purpose

Replace the tab sprawl with one document you can trust. Research
Brief Builder gathers research from the sources you name or that
are publicly reachable, distills it into key findings, and lays
it out as a structured brief: question asked, what each source
says, where they agree, where they conflict, and which questions
are still open. Every claim carries its source, so you can check
the original in seconds.

# Workflow

1. The user states the research question and any constraints:
   sources to prefer, sources to exclude, deadline for currency
   (e.g. "only 2025 or newer").
2. Gather the research from the named or publicly available
   sources. Note the publication date of each source.
3. Extract findings per source in the source's own terms before
   any synthesis. Do not mix sources into one voice.
4. Synthesize: agreement points, conflicts, and the gaps no
   source covers well.
5. Write the brief in the template below and deliver it with the
   source list, each claim linked to the source that made it.

# Output Contract

Each brief contains:

- The question, restated in one line
- Key findings: 3 to 7 bullet points, each with its source
- Where sources agree, and where they conflict
- Open questions the research did not answer
- A source list with publication dates and links where public

If fewer than three solid sources turn up, say so plainly and
deliver the thin brief rather than padding it.

# Operating Rules

- Never invent a citation. If a claim cannot be traced to a
  source you actually read, drop the claim.
- Never reach paywalled, logged-in, or private accounts. Only
  public pages and sources the user provides.
- Distinguish what a source says from what you infer. Inferences
  get flagged as your reading, not the source's claim.
- When sources conflict, report the conflict. Never pick a
  winner silently.
- Keep findings proportional to evidence: one source is a hint,
  not a consensus.
- Never act on the research: no purchases, no outreach, no
  decisions. The brief informs; the user decides.

---
name: research-brief-builder
description: Turn scattered research into a structured brief with sources, findings, and open questions. Trigger phrases: "build a research brief", "research this for me", "brief me on".
---
# Purpose

Replace the tab sprawl with one document you can trust. Research
Brief Builder gathers research from the sources you name or that
are publicly reachable, distills it into key findings, and lays
it out as a structured brief: question asked, what each source
says, where they agree, where they conflict, and which questions
are still open. Every claim carries its source, so you can check
the original in seconds.

# Workflow

1. The user states the research question and any constraints:
   sources to prefer, sources to exclude, deadline for currency
   (e.g. "only 2025 or newer").
2. Gather the research from the named or publicly available
   sources. Note the publication date of each source.
3. Extract findings per source in the source's own terms before
   any synthesis. Do not mix sources into one voice.
4. Synthesize: agreement points, conflicts, and the gaps no
   source covers well.
5. Write the brief in the template below and deliver it with the
   source list, each claim linked to the source that made it.

# Output Contract

Each brief contains:

- The question, restated in one line
- Key findings: 3 to 7 bullet points, each with its source
- Where sources agree, and where they conflict
- Open questions the research did not answer
- A source list with publication dates and links where public

If fewer than three solid sources turn up, say so plainly and
deliver the thin brief rather than padding it.

# Operating Rules

- Never invent a citation. If a claim cannot be traced to a
  source you actually read, drop the claim.
- Never reach paywalled, logged-in, or private accounts. Only
  public pages and sources the user provides.
- Distinguish what a source says from what you infer. Inferences
  get flagged as your reading, not the source's claim.
- When sources conflict, report the conflict. Never pick a
  winner silently.
- Keep findings proportional to evidence: one source is a hint,
  not a consensus.
- Never act on the research: no purchases, no outreach, no
  decisions. The brief informs; the user decides.

Packing List Builder
Turns trip details, weather, and activities into a checked packing list grouped by bag, so nothing important stays home.
skillinstructionsworkflowpacking-templatelast-check-list
by Muse Skills editors · Written for this directory
ViewInstall the "Packing List Builder" skill. Its full source is below. Create it at ~/workspace/skills/packing-list-builder/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: packing-list-builder description: Turns trip details, weather, and planned activities into a checked packing list grouped by bag, with a last-check list for the items people most often forget. Trigger phrases: "build my packing list", "what should I pack", "packing list for my trip", "pack for my trip", "trip packing checklist". --- # Purpose Do one narrow job: turn the facts of a trip into a packing list you can actually check off. You give the destination, dates, length, bags you plan to take, weather, and what you will do there: meetings, hiking, a wedding, a beach day, a cold morning run. The skill sorts everything into groups by bag, keeps daily clothes separate from gear, toiletries, and tech, and ends with a short last-check list for the items people most often leave behind: keys, wallet, phone charger, medication, travel documents, and house keys for the return. # Workflow 1. Gather the trip facts before drafting: destination, dates, nights away, bags and their limits, weather forecast or typical weather, activities by day, dress codes, and any items you already know you need, such as a laptop, camera, or sports gear. Ask for what is missing; never guess a dress code or a bag limit. 2. Build the core list first: clothes counted by nights away, with one spare set for delays, plus sleepwear and layers for the coldest and warmest hours, not just the daytime high. 3. Add activity gear next: one group per activity, so a hiking day does not mix with a meeting day. Add toiletries, tech, chargers, adapters, and documents as their own groups. 4. Sort the whole list by bag: carry-on, checked bag, personal item, and day bag. Mark items that must stay in the personal item, such as medication, documents, and chargers you need on the plane. 5. Finish with a last-check list of ten or fewer items to run through at the door, plus a short "buy before you leave" list for anything you do not own yet. # Output Contract - A packing list grouped by bag, with checkboxes - Clothes counted by nights away, with a spare set noted - One group per activity, plus toiletries, tech, and documents - A last-check list of ten or fewer door items - A "buy before you leave" list, kept separate from the packed list - A note on anything you still need to confirm, such as a bag limit or a dress code # Operating Rules - Never guess weather, bag limits, dress codes, or what an activity requires. Ask, or mark the item as unconfirmed. - Count clothes by nights away, not by vague trip length. - Keep medication, documents, and valuables in the personal item group, never in a checked bag group. - Keep the last-check list short. If it grows past ten items, cut it to the items that would ruin the trip if forgotten. - Ask for missing facts instead of filling them in.
Daily Journaler
Turns end-of-day notes into a structured journal entry in your notes system.
skillinstructionsworkflowtemplate
by Muse Skills editors · Written for this directory
ViewInstall the "Daily Journaler" skill. Its full source is below. Create it at ~/workspace/skills/daily-journaler/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: daily-journaler description: Turn rough end-of-day notes into a structured daily journal entry for your notes system. Trigger phrases: "journal today", "write my journal entry", "turn my notes into a journal entry". --- # Purpose Turn the user's raw end-of-day notes into a clean, structured journal entry that fits their notes system (Obsidian, Apple Notes, or plain markdown files). The entry captures what happened, what got done, what is still open, and what the user wants to remember, in the user's own words, tightened up and organized. # Workflow 1. Read the user's raw notes for the day: pasted text, dictated thoughts, or a pointer to an inbox note. 2. Ask for the notes-system format only on first use (Obsidian daily-note template, Apple Notes, or plain markdown), then reuse it without asking again. 3. Extract events, decisions, completed items, open loops, and anything the user explicitly marked as worth remembering. 4. Organize the entry into sections: Highlights, Completed, Open loops, Notes to self. Drop a section if it would be empty. 5. Preserve the user's phrasing where possible; tighten wording rather than rewriting in a different voice. 6. Never invent facts the notes did not contain. If something is unclear, flag it with a question instead of filling it in. 7. Present the entry as a markdown draft the user can paste into their notes system. If the user has a daily-note naming convention, use it for the file name suggestion. # Output Contract A markdown journal entry dated for the day being journaled, with sections in this order (skipping empty ones): - Highlights: the 1 to 3 moments that mattered most - Completed: what got finished, one short line each - Open loops: what is still pending, with the next action where known - Notes to self: reminders, ideas, or observations for later After the entry, a single line suggests the file name for the user's notes system. # Operating Rules - Never publish, send, or share a journal entry. It stays private to the user. - Never combine notes from more than one day into a single entry unless the user explicitly asks. - Never invent events, feelings, or facts the notes did not state. Mark gaps as questions. - Never rewrite the user's voice into formal or marketing copy; tighten, do not transform. - Keep the entry skimmable: short lines, no paragraph longer than two sentences. - Run only when asked; do not journal unprompted.
Report Watchdog
Watches incoming reports against rules you set and flags anomalies while the day is still live.
skillinstructionsworkflowrules
by Muse Skills editors · Written for this directory
ViewInstall the "Report Watchdog" skill. Its full source is below. Create it at ~/workspace/skills/report-watchdog/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: report-watchdog description: Watch incoming reports against rules you set and flag anomalies while the day is still live. Trigger phrases: "watch these reports", "flag bad reports", "set up report watchdog". --- # Purpose Catch bad reports before the day is over. Report Watchdog holds a set of rules you define once, checks each incoming report against them as reports arrive, and raises a flag the moment something looks wrong: a skipped checklist item, a number far outside the normal range, a missing photo, or a report that never arrived at all. # Workflow 1. The user defines the rules once: what a good report contains, what a good report looks like numerically, and when each report is due. Rules live in the watch config until the user changes them. 2. Each time a new report arrives, check it against the rules. Checklists must be complete, numbers must fall inside the expected ranges, required attachments must be present. 3. Compare the report against recent history for the same source. Flag anything that shifts sharply: a total that doubles, a reading that collapses, a value that is flat for the fifth run in a row. 4. Track what is due. If a report has not arrived by its due time, flag the absence. 5. For every flag, write one entry: which report, which rule broke, and the evidence. Group related flags from the same source into one alert so one bad day does not become ten messages. 6. If nothing broke, stay quiet. A clean check produces no message. # Output Contract One alert per source with a problem, containing: - Source and report time - The rule that broke, in plain words - The evidence: the value or gap that tripped it - What was normal: the recent baseline for comparison No problems: no message at all. This job is quiet by design. # Operating Rules - Never edit, correct, or re-file a report. Flag only. - Never contact the person who filed the report, or anyone else about it. The user handles every follow-up. - Never invent a rule. Every check runs against a rule the user wrote, and the alert always names it. - Never lower a threshold to quiet the noise without the user's say-so. If rules produce too many flags, report the pattern and propose new thresholds for approval. - Keep the alert short. One screenful per source, most days one alert at most.
Support Ticket Miner
Scans support tickets, clusters repeat issues, and suggests help-doc updates and marketing angles.
skillinstructionsworkflowtemplates
by Muse Skills editors · Written for this directory
ViewInstall the "Support Ticket Miner" skill. Its full source is below. Create it at ~/workspace/skills/support-ticket-miner/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: support-ticket-miner description: Scan support tickets, cluster repeat issues, and suggest help-doc updates and marketing angles. Trigger phrases: "mine my support tickets", "what are customers complaining about", "find repeat support issues". --- # Purpose Turn a batch of support tickets into an evidence-backed map of what customers keep running into: the repeat issues, the wording they use, and the gaps in your docs. It reads the tickets you give it, groups the problems into clusters, and hands you two things: which help articles need rewriting, and which customer pains are worth talking about in marketing. # Workflow 1. Read the ticket batch: exported CSV, pasted threads, or a connection you provide. Ask for the product name and date range if they are missing. 2. Normalize each ticket to one core problem in one sentence. 3. Cluster tickets by underlying problem, not by surface wording; count each cluster and pull 2-3 representative quotes. 4. For each top cluster, diagnose the root cause as product, docs, or messaging, and propose a fix in one line. 5. Map clusters to help docs: which articles cover them, which are missing, which need a rewrite based on real customer language. 6. Draft marketing angles from the sharpest pains, using the customers' own words, labeled as drafts only. # Output Contract - Cluster table: problem, ticket count, share of batch, sample quotes, root cause category. - Help-doc plan: rewrite list, new-article list, exact customer phrases to borrow. - Marketing angles: 5-10 one-line angles, each tied to a cluster, marked as drafts for human review. # Operating Rules - Never close, delete, or reply to a ticket. - Never publish a help-doc change or marketing copy without human approval. - Never invent tickets or quotes; every claim traces to a ticket in the batch. - Quote real customer language; do not smooth it into corporate phrasing.