Productivity

Briefings, inbox triage, meeting notes, and feed prompts that run your day on a schedule.

23 of 23 skills

type

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.
Research Brief Builder
Gathers multi-source research into a structured brief with sources, key findings, and open questions.
skillinstructionsworkflowbrief-template
by Muse Skills editors · Written for this directory
ViewInstall 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.
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.
Deep Work Scheduler
Turns your weekly priorities into protected calendar focus blocks that survive meeting creep.
Tested in Museskillcalendar scanfocus blocksmeeting-creep defenseweekly reset
by Muse Skills editors · Written for this directory
ViewInstall the "Deep Work Scheduler" skill. Its full source is below. Create it at ~/workspace/skills/deep-work-scheduler/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Confirm it is installed and tell me the trigger phrases. Then, as a separate step, offer to run the first scheduling pass and wait for the user's priorities before creating anything. --- SOURCE --- --- name: deep-work-scheduler description: Turns a weekly priority list into protected deep-work calendar blocks, then defends them from meeting creep. You bring the priorities; it places the time-boxed sessions where meetings cannot swallow them. Trigger phrases: schedule my deep work, plan my focus time, protect my calendar, book deep work blocks. ## Purpose Plans focused work sessions for the week ahead and places them on your calendar where meetings cannot swallow them. You bring the priorities; the skill turns them into time-boxed blocks with start times, durations, and a clear outcome per block. ## Workflow 1. Collect the week's priorities: ask the user to list 1 to 3 outcomes that need focused work this week, each with a plain-language description and a rough size (small: 30 to 60 minutes, medium: 1 to 2 hours, large: 2+ hours, split into pieces). 2. Read the user's calendar for the week to find free windows and existing commitments. 3. Draft a schedule of focus blocks: - Schedule deep work in the user's peak-energy windows when possible; ask when those are if unknown. - Keep blocks between 45 and 120 minutes, with short breaks between back-to-back blocks. - Leave at least one 30-minute unscheduled buffer per day for the unexpected. - Label each block with the priority it serves and the outcome expected by its end. 4. Present the proposed schedule for approval before creating any calendar events. 5. After approval, create the calendar events, marked private and set to decline new overlapping invites automatically when the calendar supports it. 6. On request, run a weekly reset: review which blocks survived, note what stole the others, and adjust next week's draft accordingly. ## Output Contract - A proposed schedule table with day, start time, duration, priority served, and expected outcome per block. - After approval, the created calendar events, confirmed with their titles and times. - A short summary: total focused hours planned, and which priorities still lack coverage. ## Operating Rules - Never create, move, or delete a calendar event without the user's explicit approval of the plan. - Never read or share calendar details beyond what this skill needs; report only titles and times of the relevant blocks. - If the calendar is fully booked, say so and propose the smallest meeting to reschedule, rather than stacking blocks on top of commitments. - When a block must be cut short, keep the expected outcome attached so the work can resume where it stopped. - Do not invent priorities; only schedule what the user named.
1:1 Agenda Builder
Turns scattered notes into a tight agenda for your next 1:1.
Tested in Museprompt packprompt-text
by Muse Skills editors · Written for this directory
ViewInstall the "1:1 Agenda Builder" prompt pack. Its full source is below. Save it to ~/workspace/prompts/one-on-one-agenda-builder.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack turns scattered notes into a 1:1 meeting agenda. Paste it into Muse along with your notes. > Turn these notes into a 1:1 agenda for [person, role]. Sort > into: (1) updates I owe them, 2 minutes max, (2) things I > need from them, each as a clear ask, (3) topics to discuss: > with my position stated briefly, and (4) anything sensitive, > flagged so I handle it with care. Cut anything that doesn't > need a conversation, if it could be an email, say so and > drop it from the agenda. Keep the whole thing fittable in > 30 minutes, hardest items first.
Daily Brief
Weekday mornings: your calendar, weather that matters, and top 3 tasks.
Tested in Museworkflowinstructionsworkflowschedule
by Muse Skills editors · Written for this directory
ViewSet up the "Daily Brief" workflow. Its full source is below. Default schedule: weekdays at 07:00 local time. Ask me to confirm or change this time before you create the recurring job. Once I confirm, create the job. Tell me the job name and the confirmed schedule when it is set up. --- SOURCE --- name: daily-brief description: Weekday morning brief, today's calendar, weather that affects your plans, and your top 3 tasks in one short message. Trigger phrases: "morning brief", "what's today look like", "daily briefing". schedule: weekdays at 07:00 local time. Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "morning brief" request. steps: 1. Pull today's calendar events with times and locations. 2. Check the weather for the user's location. Mention it only if it affects plans: rain during commute hours, extreme temps, anything that changes what to wear or whether to drive. 3. Pull the user's task list. Pick the top 3 by deadline and stated priority. If the list is empty, say so instead of inventing tasks. 4. Flag conflicts: overlapping events, or a task deadline colliding with a packed day. 5. Write the brief in the Output shape and send it. Keep it short enough to read in 30 seconds. output: - Today: events in order with times, one line each - Weather: only if it affects plans, one line - Top 3: the day's priorities, one line each - Heads up: conflicts or tight spots, one line each rules: - 30-second read. If it needs scrolling, it's too long. - Weather gets mentioned only when it changes a decision. - Tasks come from the user's list, not from inference. - Run only on the confirmed schedule or when asked.
Travel Day Brief
Flight day: times, terminal, delays, and what to have ready.
Tested in Museprompt packprompt-text
by Muse Skills editors · Written for this directory
ViewInstall the "Travel Day Brief" prompt pack. Its full source is below. Save it to ~/workspace/prompts/travel-day-brief.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack builds a flight-day brief from your booking details. Paste it into Muse along with your flight info. > Build my travel-day brief for [flight number, date]. Include: > (1) the timeline working backward, when to leave home, when > to be at the airport, boarding time, (2) terminal and gate if > known, plus how I'm getting there and the backup plan, > (3) the current status, on time, delayed, or cancelled, with > what that means for connections, (4) what to have ready: > ID, boarding pass, and anything this specific trip needs > (international docs, checked-bag rules), and (5) the one > thing most likely to go wrong today and the fix. Times in > my local timezone.
Birthday Radar
Monthly: who's coming up, with enough lead time to get the gift.
Tested in Museworkflowinstructionsworkflowschedule
by Muse Skills editors · Written for this directory
ViewSet up the "Birthday Radar" workflow. Its full source is below. Default schedule: first of each month at 09:00 local time. Ask me to confirm or change this time before you create the recurring job. Once I confirm, create the job. Tell me the job name and the confirmed schedule when it is set up. --- SOURCE --- name: birthday-radar description: Monthly birthday and anniversary scan: who's coming up in the next 30 days, with gift lead time and past gift notes. Trigger phrases: "whose birthday is coming up", "upcoming birthdays", "birthday reminders". schedule: first of each month at 09:00 local time. Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "whose birthday is coming up" request. steps: 1. Pull birthdays and anniversaries from the user's contacts for the next 30 days. 2. First run: ask the user which contacts matter (close circle vs. everyone) and save the preference. 3. For each upcoming date: name, date, days away, relationship note if the user has mentioned one. 4. Gift lead time: flag anything within 7 days as "order now", 8-14 days as "this week", the rest as "plenty of time". 5. If the user has mentioned past gifts, include the note so nothing gets repeated. 6. Write the report in the Output shape and send it. output: - Coming up: name, date, days away, lead-time flag - Gift lead time: flag anything within 7 days as "order now", 8-14 days as "this week", the rest as "plenty of time" - Quiet months: "Nobody on your list this month." rules: - Read only. Never message or post anything to anyone. - Dates come from the user's contacts, not from the web. Never look up someone's birthday online. - "Close circle" is the user's definition. Ask once, reuse. - Run only on the confirmed schedule or when asked.
Appointment Prep
Who you're seeing and why: the context worth re-reading first.
Tested in Museprompt packinstructionsprep-template
by Muse Skills editors · Written for this directory
ViewInstall the "Appointment Prep" prompt pack. Its full source is below. Save it at ~/workspace/prompts/appointment-prep.md exactly as given, with the frontmatter (name and description) and the prompt body. Do not run it now. Then confirm it is saved and tell me the trigger phrases: "prepare for an appointment", "brief me for my appointment", "what should I ask at my appointment". --- SOURCE --- # Appointment Prep How to use: name the appointment (person, doctor, contractor, interview: anything). It pulls the relevant history and hands you a one-page brief: what this is about, what happened last time, and what to ask or bring. Trigger phrases: "prepare for an appointment", "brief me for my appointment", "what should I ask at my appointment". Save it as a reusable prompt pack named "Appointment Prep". ## The prompt Prep me for this appointment. I will tell you who it is with and what it is about. 1. Find the calendar event and any related emails, notes, or threads about this person or topic. 2. Summarize: what this appointment is for, in 2-3 sentences. 3. Recap what happened last time (if there was a last time): what was decided, what was left open. 4. List what to bring or prepare: documents, questions, numbers to have on hand. 5. Suggest 3 questions worth asking, specific to this appointment, not generic small talk. Rules: use only what the sources contain; do not invent history. If there is no prior history, say so and build the brief from the appointment details alone. Keep it to one page.
Chief of Staff Briefing
A morning brief with today's priorities, meeting prep, and inbox items to answer.
Tested in Museprompt packinstructionsgoal-state-template
by Muse Skills editors · Written for this directory
ViewInstall the "Chief of Staff Briefing" prompt pack. Its full source is below. Save it at ~/workspace/prompts/chief-of-staff-briefing.md exactly as given, with the frontmatter (name and description) and the prompt body. Do not run it now. Then confirm it is saved and tell me the trigger phrases: "prepare my morning briefing", "brief me on today", "run chief of staff briefing". --- SOURCE --- # Chief of Staff Briefing How to use: run this each morning, or on a schedule you set. Keep a goal file up to date; the prompt reads it each run and does not change it. ## Goal state file Maintain a short file, for example `goals.md`, with one active goal per line: ``` - [Goal name]: [current status in one line] - [Goal name]: [current status in one line] ``` Update it yourself as goals change. The briefing reads this file; it never edits it. Trigger phrases: "prepare my morning briefing", "brief me on today", "run chief of staff briefing". ## The prompt You are my chief of staff for this morning's brief. Read my calendar for today, my inbox for unread and flagged messages from the last 24 hours, and my goal file at ~/workspace/goals.md. Use only what these three sources contain. Do not invent a meeting, an email, or a goal that is not in them. Build the brief in this exact order: 1. **Today's three priorities.** Pick the three items that matter most today, drawn from calendar commitments, time-sensitive inbox items, and open goals. State each as one line: what it is and why it made the cut. 2. **Meetings with prep notes.** List today's meetings in time order. For each: time, title, attendees, and one prep note (the open question, the decision needed, or the document to bring). If a meeting needs no prep, say so in one line rather than inventing a note. 3. **Inbox items needing a reply.** List unread or flagged messages from the last 24 hours that need a response from me, oldest first. For each: sender, subject, and what the reply needs to resolve. Skip anything already answered or informational-only. 4. **One goal nudge.** Pick exactly one goal from the goal file and name one concrete next action for it today. Pick the goal that has gone longest without a status change, or the one closest to a deadline if any goal states one. Keep the whole brief scannable: short lines, no restating the question, no summary at the end. If a section has nothing to report (no meetings today, no inbox items needing reply), say so in one line instead of skipping the heading silently. Never draft or send a reply, never create or edit a calendar event, and never edit the goal file. This is a read-and-report task only. If ~/workspace/goals.md does not exist, ask the user where their goals file lives before the first run.
Decision Log
Log decisions with context; query them instead of re-litigating.
Tested in Museskillinstructionsworkflowdecision-file
by Muse Skills editors · Written for this directory
ViewInstall the "Decision Log" skill. Its full source is below. Create it at ~/workspace/skills/decision-log/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: decision-log description: Keep a running log of decisions: what was decided, why, by whom, and when to revisit. Query it instead of re-litigating. Trigger phrases: "log this decision", "record a decision", "what did we decide about". --- # Purpose End the "wait, why did we do it this way?" loop. Every decision gets one entry: the call, the reasoning, who made it, and when it should be revisited. Six months later, the answer is in the file. # Workflow 1. When the user reports a decision, capture: date, the decision in one sentence, the context and reasoning (2-3 sentences), who decided, and any alternatives considered and rejected. 2. Ask for a revisit date when one makes sense ("revisit after the holiday traffic spike"); otherwise mark "no revisit set". 3. Append the entry to decisions.md in the workspace, newest at the bottom, with a simple header per entry. 4. On query ("what did we decide about X"), search the log and quote the entry, decision, reasoning, date, decider, then stop. Do not re-argue the decision. 5. On request ("what needs revisiting"), list entries whose revisit date has passed. # Output Contract - decisions.md: one entry per decision with date, decision, reasoning, decider, alternatives, revisit date - Query answers: the quoted entry plus its date, nothing more - Revisit lists: entries past their revisit date, oldest first # Operating Rules - Record what was decided, not what should have been decided. No editorializing. - Never invent reasoning the user didn't give. Ask for the "why" if it's missing, one question, then log it. - The log is append-only. Corrections go in as new entries referencing the old one; never rewrite history. - The file stays in the user's workspace. Nothing is sent anywhere.
Follow-up Radar
Finds your unanswered promises and flags the ones that went quiet.
Tested in Museworkflowinstructionsworkflowschedule
by Muse Skills editors · Written for this directory
ViewInstall the "Follow-up Radar" workflow. Its full source is below. Create it at ~/workspace/skills/follow-up-radar/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Confirm it is installed and tell me the trigger phrases. Then, as a separate step, propose the default schedule (Monday at 08:00 local time) and wait for me to confirm or change it before you create any recurring job. --- SOURCE --- name: follow-up-radar description: Weekly scan of sent mail for "I'll get back to you" promises; flags the ones with no reply after 7 days. Trigger phrases: "any follow-ups due", "check my promises", "run follow-up radar". schedule: weekly, Monday at 08:00 local time (cron: 0 8 * * 1). Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "any follow-ups due" request. steps: 1. Search sent mail from the last 30 days for follow-up promises: phrases like "I'll get back to you", "I'll send that over", "let me check and revert", "I'll circle back", "I'll follow up". 2. For each promise, check the thread for a fulfilling reply from the user, or any reply activity in the last 7 days. 3. Keep only promises with no fulfilling reply and no thread activity in 7 days. 4. Sort oldest first. Write the report in the Output shape and send it. If nothing is overdue, send nothing at all. output: - One line per overdue promise: thread subject and person, the promise quoted, days quiet, and a suggested next step - Quiet weeks: no message rules: - Read only. Never send a follow-up email on the user's behalf. - Quote the promise; do not paraphrase it into something stronger than what was written. - A thread with any reply in the last 7 days is not overdue, even without a fulfilling reply. - Run only on the confirmed schedule or when asked.
Inbox Triage
Sorts new email into reply, delegate, archive, or later, then drafts your replies.
Tested in Museworkflowscheduleworkflowdraft repliesapproval step
by Muse Skills editors · Written for this directory
ViewInstall the "Inbox Triage" workflow. Its full source is below. Create it at ~/workspace/skills/inbox-triage/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Confirm it is installed and tell me the trigger phrases. Then, as a separate step, propose the default schedule (weekdays at 07:30 local time) and wait for me to confirm or change it before you create any recurring job. --- SOURCE --- name: inbox-triage description: Scheduled email triage. Classifies new mail into reply, delegate, archive, or later, drafts replies for the reply set, and holds every draft for approval before send. Trigger phrases: triage my inbox, sort my email, draft my replies. schedule: weekdays at 07:30 local time (cron: 30 7 * * 1-5). Confirm the time with the user before the first scheduled run. A user change to the time takes effect on the next run. trigger: the scheduled time, or a manual "run inbox triage now" request. steps: 1. Read all mail that arrived since the last successful run, using the user's own connected email account. Never sign in with credentials the user has not already connected. 2. Classify each message into exactly one bucket: - reply: needs a response from the user. - delegate: needs action from someone else the user has already named as a delegate. - archive: no action needed (receipts, notifications, newsletters with no ask). - later: needs the user's attention but not a reply today (long threads, decisions that need more context). 3. For every message in the reply bucket, draft a reply in the user's own voice, using the thread history for context. Keep each draft under 150 words unless the source message needs a longer answer. 4. For every message in the delegate bucket, draft a one-line forward note to the named delegate. Never send it without approval. 5. Present the full batch: bucket counts, then each reply and delegate draft in full, with the original message it answers. 6. Wait for the user's decision on each draft: approve, edit, or discard. Send only the drafts marked approved, exactly as approved or as edited by the user. 7. Apply the archive and later labels only after the user has seen the batch summary. Never archive a message the user has not at least seen listed. output: a batch report per run: counts by bucket, then the full text of every reply and delegate draft awaiting approval. If no new mail arrived, or every new message fell into archive or later, the report says so in one line and includes no drafts. stop_conditions: - Stop and ask the user if a message looks like it needs a password, payment, or legal commitment. Never draft a reply that commits money or signs an agreement. - Stop the whole run and report the error if the mail account disconnects mid-run. - Never retry a send. A failed send is reported, not resent automatically. operating_rules: - Never send a message without per-message approval, every run, no exceptions. - Never delegate mail to anyone not already named by the user as a delegate. - Never ask the user for their email password or any credential. Use only the account they already connected. - Never forward or quote a message to a third party outside delegation the user set up. - A quiet run (no reply or delegate drafts) sends nothing beyond the one-line summary.
Interview Prep Coach
Role and company in, likely questions and talking points out.
Tested in Museprompt packinstructionsprep-template
by Muse Skills editors · Written for this directory
ViewInstall the "Interview Prep Coach" prompt pack. Its full source is below. Save it at ~/workspace/prompts/interview-prep-coach.md exactly as given, with the frontmatter (name and description) and the prompt body. Do not run it now. Then confirm it is saved and tell me the trigger phrases: "prep me for this interview", "practice interview questions", "build my interview prep". --- SOURCE --- # Interview Prep Coach How to use: give the role, the company, and the interview round (screen, hiring manager, panel, final). It researches the company and returns likely questions, your talking points, and questions to ask them. Trigger phrases: "prep me for this interview", "practice interview questions", "build my interview prep". Save it as a reusable prompt pack named "Interview Prep Coach". ## The prompt Prep me for this interview. I will give you: the role title, the company, the interview round, and a short version of my background. 1. Research the company: what it does, recent news, and anything relevant to this role. Keep it to 5 bullets. 2. List 8-10 likely questions for this round: mix role-specific, behavioral ("tell me about a time"), and company-specific. 3. For each question, give a 2-line talking point drawn from my background, a direction, not a script. 4. Give me 4 questions to ask them: 2 about the role and team, 1 about the company's direction, 1 that shows I did the reading. 5. End with one honest weak spot to prepare for: the likeliest hard question about my background, and how to answer it directly. Rules: talking points, not scripts: no one should memorize paragraphs. If my background doesn't obviously fit a question, say so instead of inventing experience.
Meal Macro Estimator
Photo a meal; get rough calories and macros logged to a daily file.
Tested in Museskillinstructionsworkflowdaily-log
by Muse Skills editors · Written for this directory
ViewInstall the "Meal Macro Estimator" skill. Its full source is below. Create it at ~/workspace/skills/meal-macro-estimator/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: meal-macro-estimator description: Estimate calories and macros from a meal photo and log them to a daily file, with a running daily total. Trigger phrases: "log this meal", "what are the macros", "track this food". --- # Purpose Frictionless food logging. The user photos a meal; the skill estimates calories, protein, carbs, and fat, appends the entry to today's log, and reports the running daily total. # Workflow 1. Look at the meal photo. Identify the foods and estimate portions in familiar units (a palm of chicken, a cup of rice). 2. Estimate calories, protein (g), carbs (g), and fat (g) per item. Mark every number as an estimate; never present it as measured. 3. Append one entry to food-log/YYYY-MM-DD.md in the workspace: time, foods, and the four numbers. 4. Report the meal's totals plus the running daily total in one short block. 5. On request ("how did I eat today"), summarize the day: total calories and macros, no judgment, no advice unless asked. # Output Contract - food-log/YYYY-MM-DD.md: one entry per meal with time, foods, calories, protein, carbs, fat - Each report: meal totals, then "Day so far: X cal | P xg | C xg | F xg" # Operating Rules - Every number is an estimate. Say so every time. - Never give medical or diet advice. If the user asks for advice, suggest talking to a professional. - Never shame or praise food choices. Report the numbers, nothing else. - The log stays in the user's workspace. Nothing is sent anywhere.
Meeting Agenda Builder
Goal plus attendees becomes a tight agenda with timeboxes.
Tested in Museprompt packinstructionsagenda-template
by Muse Skills editors · Written for this directory
ViewInstall the "Meeting Agenda Builder" prompt pack. Its full source is below. Save it at ~/workspace/prompts/meeting-agenda-builder.md exactly as given, with the frontmatter (name and description) and the prompt body. Do not run it now. Then confirm it is saved and tell me the trigger phrases: "build a meeting agenda", "timebox this meeting", "plan this meeting". --- SOURCE --- # Meeting Agenda Builder How to use: give the meeting goal, the attendees, and the time available. It returns a timeboxed agenda where every item earns its slot. Trigger phrases: "build a meeting agenda", "timebox this meeting", "plan this meeting". Save it as a reusable prompt pack named "Meeting Agenda Builder". ## The prompt Build the agenda for this meeting. I will give you: the goal of the meeting (the decision to make or problem to solve), the attendees, and the time available. 1. State the goal at the top in one sentence, phrased as an outcome ("Decide the Q4 hiring plan", not "Discuss hiring"). 2. Build the agenda backwards from the goal: only items that serve the decision earn a slot. 3. Timebox every item; the boxes must sum to the available time minus 5 minutes of buffer. 4. Mark each item: (info) 2-minute updates, (discuss) the real debate, (decide) the call to make. At least one (decide) item is required: if nothing needs deciding, say the meeting should be an email. 5. End with: owner and deadline for anything decided. Rules: if the goal is vague, ask one clarifying question before building. Never pad a 20-minute decision into a 60-minute agenda.
Meeting Notes Polisher
Turns raw meeting notes into decisions, owned action items, and a three-line summary.
Tested in Museprompt packprompt
by Muse Skills editors · Written for this directory
ViewInstall the "Meeting Notes Polisher" prompt pack. Its full source is below. Save it at ~/workspace/prompts/meeting-notes-polisher.md exactly as given, with the frontmatter (name and description) and the prompt body. Do not run it now. Then confirm it is saved and tell me the trigger phrases: "polish my meeting notes", "clean up these notes", "structure my meeting notes". --- SOURCE --- # Meeting Notes Polisher Trigger phrases: "polish my meeting notes", "clean up these notes", "structure my meeting notes". Paste raw meeting notes below the line. Turn them into a structured record. Rules: 1. Read the notes once. List every decision made in the meeting. 2. List every action item. For each one, give the task, the owner, and the deadline. 3. If an action item has no named owner, write "No owner assigned" next to it instead of guessing a name. 4. If an action item has no deadline, write "No deadline set" next to it. 5. List every open question the notes raise but do not answer. 6. Write a three-line summary of the meeting. Each line covers one idea. 7. Do not add a decision, action item, or question that the notes do not state. 8. Do not invent an owner, a deadline, or a next step. Output format: ## Decisions - [Decision 1] - [Decision 2] ## Action items - [Task] | Owner: [Name or "No owner assigned"] | Deadline: [Date or "No deadline set"] ## Open questions - [Question 1] ## Summary [Line 1] [Line 2] [Line 3] --- NOTES --- [Paste raw meeting notes here]
Packing List Generator
Trip details in, complete packing checklist out.
Tested in Museprompt packinstructionslist-template
by Muse Skills editors · Written for this directory
ViewInstall the "Packing List Generator" prompt pack. Its full source is below. Save it at ~/workspace/prompts/packing-list-generator.md exactly as given, with the frontmatter (name and description) and the prompt body. Do not run it now. Then confirm it is saved and tell me the trigger phrases: "make a packing list", "what should I pack", "pack for this trip". --- SOURCE --- # Packing List Generator How to use: give the destination, dates, trip type, and anything special (a wedding, hiking, a work presentation). It returns a complete checklist grouped by category, adjusted for weather and trip length. Trigger phrases: "make a packing list", "what should I pack", "pack for this trip". Save it as a reusable prompt pack named "Packing List Generator". ## The prompt Build my packing list. I will give you: destination, dates, trip type (beach / city / hiking / business / family visit), and any special events. 1. Check the weather forecast for the destination and dates. 2. Scale clothing quantities to the trip length (a 3-day trip and a 10-day trip pack differently; say which assumption you used). 3. Group the list: Documents & money, Clothing, Toiletries & health, Tech, Extras for the trip type. 4. Add a "day before" section: charge devices, water plants, take out trash, hold mail, the leaving-the-house checklist. 5. Flag anything easy to forget that is hard to replace at the destination (medications, chargers, ID). Rules: no generic filler. Every item should earn its place for this specific trip. Keep it to one page.
Reservation Tracker
Weekly inbox scan; one list of every upcoming reservation.
Tested in Museworkflowinstructionsworkflowschedule
by Muse Skills editors · Written for this directory
ViewSet up the "Reservation Tracker" workflow. Its full source is below. Default schedule: Sunday at 09:00 local time. Ask me to confirm or change this time before you create the recurring job. Once I confirm, create the job. Tell me the job name and the confirmed schedule when it is set up. --- SOURCE --- name: reservation-tracker description: Weekly inbox scan for upcoming reservations: restaurants, hotels, flights, rentals, in one chronological list. Trigger phrases: "what reservations do I have", "upcoming bookings", "track my reservations". schedule: weekly, Sunday at 09:00 local time (cron: 0 9 * * 0). Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "what reservations do I have" request. steps: 1. Search the inbox for confirmation emails: restaurant bookings, hotel and flight confirmations, car rentals, event tickets. 2. Extract for each: what, where, date and time, party size or confirmation code where shown. 3. Keep only reservations in the future. Drop anything already past. 4. Sort chronologically, soonest first. 5. Write the list in the Output shape and send it. If nothing is upcoming, say so in one line. output: - One line per reservation: date/time, what and where, confirmation code if shown - Grouped loosely: this week / later - Quiet weeks: "No upcoming reservations found." rules: - Read only. Never book, change, or cancel a reservation. - Use the most recent confirmation per booking; ignore superseded emails. - If a confirmation is ambiguous, mark it "check manually" rather than guess. - Run only on the confirmed schedule or when asked.
Weekly Feed Brief
A feed-prompt template that turns your weekly briefing into topics you chose.
Tested in Museconfigconfigfeed-prompt
by Muse Skills editors · Written for this directory
ViewInstall the "Weekly Feed Brief" config template. Its full source is below. Save the template at ~/workspace/prompts/weekly-feed-brief.md exactly as given, with the bracketed fields left as literal placeholders. Confirm it is saved. Then, as a separate second step, ask me for my topics, sources, desired length, and delivery day. Only after I answer, offer to write the feed prompt setting, and wait for my confirmation before writing it. --- SOURCE --- # Weekly Feed Brief config ## Where this lives Assistant settings → Feed → Feed prompt. This snippet replaces or extends the text in that field. ## Config snippet ``` topics_follow: - "[Topic 1, e.g. commercial real estate financing]" - "[Topic 2, e.g. changes to a named regulation]" - "[Topic 3, e.g. a competitor or company name]" sources_prefer: - "[Source 1, e.g. a named trade publication]" - "[Source 2, e.g. a named analyst or outlet]" sources_skip: - "[Source to exclude, e.g. a low-quality aggregator]" - "[Topic to exclude, e.g. general market commentary with no new fact]" output_length: "[short: 3-5 bullets | medium: one paragraph per topic | long: full briefing with links]" delivery_day: "[day of week, e.g. Monday morning]" quiet_rule: "If no topic has a genuine update this week, send nothing rather than a briefing with no news." ``` ## What to change - `topics_follow`: name specific topics, not broad categories. - `sources_prefer`: name outlets or people, not "reputable sources." - `sources_skip`: name what to exclude, whether a source or a category of story. - `output_length`: pick one of the three named lengths. - `delivery_day`: one day and a rough time of day. ## Install steps 1. Fill in each bracketed field from what the user states. 2. Show the completed snippet back to the user. 3. Wait for explicit confirmation. 4. Write the confirmed snippet to the assistant's feed prompt setting. 5. Confirm the write succeeded and name the day the first briefing arrives.
Weekly Review
End-of-week review: open loops surfaced, next week's priorities drafted.
Tested in Museprompt packinstructionsreview-template
by Muse Skills editors · Written for this directory
ViewInstall the "Weekly Review" prompt pack. Its full source is below. Save it at ~/workspace/prompts/weekly-review.md exactly as given, with the frontmatter (name and description) and the prompt body. Do not run it now. Then confirm it is saved and tell me the trigger phrases: "run my weekly review", "draft my weekly review", "review my week". --- SOURCE --- # Weekly Review How to use: run this Friday afternoon, or on a schedule you set. It reads your calendar, inbox, and goal file, then drafts the review. You approve the priorities; it never sets them for you. Trigger phrases: "run my weekly review", "draft my weekly review", "review my week". ## The prompt You are running my weekly review. Read my calendar for the past 7 days, my inbox for flagged and unread messages, and my goal file. Use only what these three sources contain. Do not invent a meeting, an email, a goal, or completed work that is not in them. Build the review in this exact order: 1. **Done this week.** The 3-5 most significant completed items, from calendar events and sent mail. One line each. 2. **Open loops.** Anything started but unfinished: unanswered threads, meetings with no follow-up, goals with no movement. One line each, with the next physical action. 3. **Proposed priorities for next week.** Three items, drawn from the open loops and the goal file. Mark them as proposed; the user confirms or edits them. 4. **Calendar check.** Anything next week that needs prep, flagged one line each. Rules: do not mark anything done that is not evidenced in the sources. Keep the whole review under one page. End by asking which of the three proposed priorities to keep.