prepare-prompt
Skill85 starsChanged 21 days agoMITView on GitHub
Prepare a prompt that hands this session's work to a fresh agent session — to continue it, check it, or pick up what was left open. Use when asked for a prompt or brief for the next session.
In this repository31 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agentify-projectSkill
- attach-to-ticketSkill
- check-ticket-implementationSkill
- compact-docs-writerSkill
- compact-skill-creatorSkill
- context-checkupSkill
- create-implementation-planSkill
- create-manual-test-instructionsSkill
- execute-plan-tasksSkill
- explain-in-simple-languageSkill
- extract-pr-review-rulesSkill
- fetch-pr-reviewSkill
- fetch-ticketSkill
- fresh-eyes-reviewSkill
- grill-meSkill
- handoverSkill
- harden-artifactSkill
- maintainer-reviewSkill
- memory-doctorSkill
- refine-pr-reviewSkill
- refine-ticketSkill
- review-code-assistantSkill
- review-ticketSkill
- run-nx-checksSkill
- self-improveSkill
- self-reviewSkill
- split-plan-tasksSkill
- use-conversational-languageSkill
- verify-understandingSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 11
Write for a session holding only this text — no chat history, no memory of what was meant — and make it as short as that reader allows: …
- Distinctive: line 48
When its job is to check, verify or review something, this session's own conclusions about that thing go entirely — they would steer the …
- Very specific: line 56
When an installed skill covers what the next session must do, the prompt opens with its slash command and the rest follows as its arguments …
- Distinctive: line 72
Every path, id and command in the prompt exists or works — verified by a read-only lookup, not remembered.
- Distinctive: line 74
Every fact stated as settled was verified in this session or stated by the user.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Prepare prompt
Write for a session holding only this text — no chat history, no memory of what was meant — and make it as short as that reader allows: nothing it needs is cut for brevity, nothing else stays. The reader is a fresh interactive session the user pastes it into; a subagent brief only when the invocation asks for one, under the same rules.
Input
The user's goal, in a line, plus this session. Draft at once; ask only what neither settles, one question at a time, with a recommended answer.
Content
A suggested order, every part optional: a part is never filled to exist, and two lines are a complete prompt when two lines cover the case.
- Situation — what exists that the next session builds on, and what is open or was missed, each with its identifier (ticket URL, branch, commit, PR, task ids).
- Task and deliverable — what to do, in what form to report or produce it (a chat report with a given structure, a file, a code change) and, when the work continues, the check that says it is done (a command, a criterion, a file to exist).
- Latitude and boundaries — what it may decide alone, when deviating is fine, what it must not touch (read-only, no git or tracker writes, files to ignore).
- Facts it cannot derive — paths, the planning directory, docs to read, tool quirks with the workaround (even one a failed try revealed), a command that saves time. When it continues the work, picking up what was left open included, also each approach this or an earlier session tried and ruled out, one line with the reason; none when its job is to check, verify or review, even if it continues the work afterwards, since they would steer the check.
The deliverable form and the write boundaries are the usual gaps: check whether the case needs them.
What stays and what goes:
- A fact the next session builds on takes one line, never how it was reached. Anything it will redo anyway, and any narration of this session, goes. A ruled-out approach (part 4) is a fact in its own right, not narration, and may share the line of the decision that replaced it ("X, not Y: reason").
- When its job is to check, verify or review something, this session's own conclusions about that thing go entirely — they would steer the check. When its job is to continue the work, the decisions it must build on stay, one line each.
- Point, never paste: what exists in a file or commit is referenced precisely (path and section, hash), never copied. Only what lives nowhere — a decision made in the chat, a tool quirk, a useful command — is written out. Never a credential: one the next session needs is named by where it lives (env var, config path); one that lives nowhere, such as a key pasted in chat, is left out and the prompt says to get it from the user.
- When an installed skill covers what the next session must do, the prompt opens with its slash
command and the rest follows as its arguments (
/refine-ticket 1234 …) — not a description of the procedure, nor prose like "run/refine-ticket", which cannot load a skill that blocks model invocation. Verify it exists first. A subagent cannot run a slash command: its brief names the skill to invoke instead, and a task whose skill blocks model invocation stays with an interactive session.
Form
Plain imperative prose in paragraphs, no headings, bullets for lists. Agent-facing, so no
conversational voice. Print it as one fenced block, commands and paths inline in backticks (never
the opening slash command), never a nested fence; then a --- line before any note to the user;
every revision reprints the whole block.
Check before printing
- Every path, id and command in the prompt exists or works — verified by a read-only lookup, not remembered.
- Every fact stated as settled was verified in this session or stated by the user; an inference is marked as one ("probably", "unverified") or cut.
- Nothing narrates this session (a ruled-out approach is not narration); for a checking job, nothing states this session's conclusion about the thing checked, nor a ruled-out approach.
- A session holding only this text can act without asking what was meant.
Done when all four hold.
Boundaries
- The printed prompt is the product: write no file unless asked.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

