Do things with Mel

A gallery of practical, copy-ready things Mel can do today. Every prompt below is literal — paste it into the agent input (ctrl+enter to start a conversation) — and every workflow names the shipped surface it uses. Nothing here is aspirational.

Ship and review code

Review my open changes — a first-pass review before any human looks:

Review both the uncommitted and committed changes on this branch. Read the
surrounding code before judging any diff. Check for logic bugs, unhandled
edge cases, security issues, and places that break this project's existing
conventions. Summarize findings grouped by severity, each with the file,
the line, and a concrete suggested fix.

Create a PR from open changes — commits, push, PR, URL, end to end:

Stage and commit the open changes with clear, conventional commit messages
(split into multiple commits if the changes are unrelated). Then push the
branch, open a pull request with the GitHub CLI with a description that
summarizes what changed and why, and print the PR URL.

Fetch PR comments into the terminal — address feedback without leaving Mel:

Using the GitHub CLI, fetch all review comments and threads for the pull
request belonging to the current branch. Group them by file, show the
commented line for context, and list which threads are unresolved. Then
propose an order to address them.

Summarize what changed since main — a reviewer-oriented narrative:

Diff this branch against main. Read the changed files (not just the diff)
and write a reviewer-oriented summary: the intent of the change, how the
pieces fit together, anything risky or surprising, and the best order to
read the files in.

Investigate and plan

Set up an unfamiliar project — from fresh clone to running dev server:

Set this project up from scratch. Read the README and any contributing docs
first, detect the language, package manager, and required tool versions from
the lockfiles and manifests, install dependencies, run the project's own
checks to confirm the setup works, and then start the dev entry point. Tell
me each command before you run it.

Investigate a failing test — reproduce first, fix with approval (full walkthrough in the bug investigation guide):

One of the tests is failing. Run the test suite to reproduce the exact
failure, read the failing test and the code under test, and trace the root
cause — do not guess. Explain the cause with file/line references, then
propose the minimal fix and wait for my approval before editing.

Plan before building — the write_plan tool opens the plan in a side panel next to the conversation, before any code is written:

Before writing any code: explore the codebase, then produce a plan document
for the change I described — goals, files to touch, step order, risks, and
how we'll verify each step. Put it in a plan I can read side-by-side, and
wait for my sign-off before implementing.

Ship a PDF report of the work — the create_pdf tool turns an investigation into a typeset document. It renders with the best PDF engine on your machine (Chrome, Edge, or Chromium give the highest fidelity) and falls back to Mel's built-in renderer when none is installed, so it works on a fresh machine too:

Summarize everything you found and changed in this conversation as a
professional PDF report: an executive summary, a findings table with
severity, the key diffs as syntax-highlighted code blocks, and a next-steps
section. Save it in the project root and tell me the path.

Workbench workflows

For deeper end-to-end walkthroughs, see the code review, refactors, and incident response guides.