A crowded inbox can feel like one long, undifferentiated task. A useful first pass is smaller: sort a deliberately limited set of messages into three lists—Act, Waiting and Read later—then make your own decisions. Meta's Japan launch announcement describes Muse's Gmail and Google Calendar connections and approval requests for important actions such as sending email. This template asks for an inbox brief, not those actions.

Start with a small slice

Avoid 'triage my inbox.' Name the mailbox, timeframe and limits. For example: only the work Gmail you identify, messages received in the last 48 hours, and at most 25 messages in Inbox. Narrow further with a named label, sender or project if needed. Don't broaden the search just because there are few results.

Ask for source-message links so summaries can be checked. If a direct link is unavailable, require sender, subject and received date instead—never a guessed link. For confidential material, first review connection permissions and whether the information should be shared at all; a redacted excerpt can be enough to explore the format.

Copy, then customize

Prepare a one-time triage brief from [mailbox/account]. Review only [date range and timezone], at most [number] messages in [Inbox / named label]. Do not search beyond that scope.

Sort relevant messages into Act, Waiting, and Read later. For each item include sender, subject, received date/time, a one-sentence reason for placement, the smallest useful next step (if any), and a direct source-message link. If a link is unavailable, give the subject and received date/time; do not invent one. Do not duplicate a message across lists. Leave out spam and newsletters unless I name them.

Act means a request needs my attention. Waiting means the reviewed evidence shows I am awaiting someone else's reply or delivery. Read later means useful information with no immediate request. If ownership or classification is unclear, do not force a category: list it in a short 'Needs checking' note with the reason. Do not assume what happened outside the reviewed messages.

Quote deadlines as written. If a date, year, time or timezone is missing or ambiguous, mark it uncertain and explain why. Distinguish a stated deadline from an estimate of urgency. If no deadline is stated, say 'none stated.'

This is read-only triage. Do not send, draft or reply; delete, archive, label, mark read, unsubscribe, or change settings; or create/edit calendar events. If the available reading method would change mailbox state, stop before that action and explain the limitation. Return the brief for my review, stating what you reviewed and could not verify.

Use a named timezone such as Singapore Time (SGT, UTC+8) or Japan Standard Time (JST, UTC+9). Do not assume the sender's timezone matches yours. 'Friday' without enough context should remain 'Friday' with an uncertainty note, not become a confident calendar deadline. A narrow review is not a complete account of every conversation.

A hypothetical three-message example

• 'Please review the draft by Friday' is an Act candidate. A small next step is opening the draft. The exact date and cutoff stay uncertain if the source doesn't establish them.
• 'I'll send the revised version tomorrow' is a Waiting candidate if the reviewed text contains no additional request for you. Preserve any ambiguity about 'tomorrow.'
• An optional industry roundup is a Read later candidate if it asks for no immediate action.

These are invented sample messages, not results from an actual inbox or Muse run. Each real entry should be checked against its source.

Review before doing anything

Open the originals in the order that matters to you. Check the deadline first, then who owns the task, then surrounding context. An Act item may already have been handled elsewhere; a Waiting item may contain a question the brief missed. Correct the lists yourself.

The result is a map for your attention, not permission to change your mailbox. If you later want drafts or calendar changes, treat that as a separate, clearly scoped task. No prompt guarantees security or perfect interpretation.

The official Muse design essay describes a computer, file system and terminal, and the ability to produce documents and other artifacts. That makes a small question worth asking before a file task: what will count as a delivered result?

Make done observable

A polished final reply is not the same as a usable file. A small acceptance contract names the artifacts, their minimum structure, and what an unfinished result should say. It does not score research quality; it checks a few things that are easy to overlook.

Here is a reusable prompt. Replace the bracketed topic and sources. Start with non-sensitive material.

Create a short Markdown note about [topic], using [provided context or sources]. Deliver report.md and manifest.json in one output directory. Attach both actual files or usable download links in your final reply; do not substitute a description of them.

report.md must be nonempty and contain these level-two headings, each on its own line: ## Scope, ## Findings, and ## Open questions. Keep it concise. Do not invent findings. Identify uncertainty under Open questions.

manifest.json must be valid JSON. Set status to complete, partial, or blocked, and unresolved_blockers to an array of strings. Use complete only when both requested files are delivered and the report meets the requirements. Otherwise, use partial or blocked and list the remaining issue(s). Do not describe an incomplete task as complete.

In the final reply, name the files and manifest status. Distinguish checks you actually performed from checks you could not perform.

The minimal manifest looks like this:

{
  "status": "complete",
  "unresolved_blockers": []
}

Status describes delivery, not whether the research is true. A self-reported field is a claim to inspect, not proof.

A synthetic fixture

This is a reference shape, not actual Muse output:

## Scope
Synthetic example for checking a file-delivery contract.
## Findings
The fixture includes the three requested headings.
## Open questions
No research claims are evaluated by this example.

Download the two requested files into a local directory, such as artifacts. Save this standard-library-only Python script as check_contract.py. It reads the files; it does not run anything they contain.

import json
import sys
from pathlib import Path

REQUIRED = {"## Scope", "## Findings", "## Open questions"}
ALLOWED = {"complete", "partial", "blocked"}


def validate(root):
    errors = []
    report, manifest = root / "report.md", root / "manifest.json"
    if not report.is_file():
        errors.append("missing report.md")
    else:
        try:
            text = report.read_text(encoding="utf-8")
            if not text.strip():
                errors.append("report.md is empty")
            lines = {line.strip() for line in text.splitlines()}
            errors.extend(f"missing heading: {h}" for h in sorted(REQUIRED - lines))
        except (OSError, UnicodeError) as exc:
            errors.append(f"unreadable report: {exc}")
    if not manifest.is_file():
        errors.append("missing manifest.json")
    else:
        try:
            data = json.loads(manifest.read_text(encoding="utf-8"))
            if not isinstance(data, dict):
                errors.append("manifest must be an object")
            else:
                status = data.get("status")
                if not isinstance(status, str) or status not in ALLOWED:
                    errors.append("invalid status")
                blockers = data.get("unresolved_blockers")
                if not isinstance(blockers, list) or not all(isinstance(x, str) for x in blockers):
                    errors.append("unresolved_blockers must be an array of strings")
                elif status == "complete" and blockers:
                    errors.append("complete status has unresolved blockers")
        except (OSError, UnicodeError, json.JSONDecodeError) as exc:
            errors.append(f"invalid manifest: {exc}")
    return errors


if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit("usage: python check_contract.py DIRECTORY")
    errors = validate(Path(sys.argv[1]))
    if errors:
        print("FAILED:", *errors, sep="\n- ")
        raise SystemExit(1)
    print("Contract checks passed")

Run python check_contract.py ./artifacts. A valid fixture prints Contract checks passed and exits with code 0. A complete manifest with an unresolved blocker is rejected and exits with code 1.

For this article, the validator was checked locally against 12 synthetic cases and two CLI exit-code checks. They covered missing files, empty text, a missing heading, invalid status values (including a JSON array), malformed JSON, a non-object manifest, an invalid blocker type, unreadable UTF-8, and a false-complete marker. This tested the Python validator, not Muse.

Know what passing means

This checks file presence, nonempty report text, required heading text on trimmed lines, allowed status values, and blocker-array consistency. It is not a Markdown parser: matching text inside a code block could fool the heading check. It does not require substantive text under each heading, reject extra files or JSON keys, assess truth or source quality, or establish that files are safe. It is a small local convenience, not a security boundary.

A partial or blocked manifest can pass the structural checks if both files are present and correctly shaped. Always read the status separately. Finally, open the report, check its claims against the supplied material, and confirm the final reply did not overstate what was delivered. A tiny contract helps catch mechanical omissions; judgment still belongs outside it.