prompt-leverage
Skill0 starsChanged 3 months agoMITView on GitHub
The Prompt Leverage framework — how to turn a rough request into a well-scoped prompt with the right amount of structure. Use when writing a prompt for another agent or session, or as the fallback classification reference when the augment CLI is unavailable.
In this repository3 other files it gives its agents.
- augment-autoSkill
- augment-runSkill
- augmentSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 76
Before finalizing, check the rewrite:
- Distinctive: line 83
If the draft is already strong, make only minimal edits.
≈ “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
Prompt Leverage
A framework for adding just enough structure to a prompt. The failure mode it guards against is not under-specification — it is ceremony: wrapping a two-line request in five headings nobody reads.
The plugin's CLI (bin/augment.mjs) applies all of this deterministically. These
tables are the same rules in readable form, for when you need to classify by hand.
1. Intent
Nine intents, checked in this order. First match wins.
| Intent | Signals |
explain (lead) | Draft opens with explain / walk me through / help me understand — and asks for no action. why/how openers skip this pass. |
review | review, audit, findings, look for issues |
test-fix | failing tests, regression tests, update tests, add tests, fix tests |
debug | debug, fix, bug, broken, fails, stuck, hangs, crash, error, root cause |
refactor | refactor, clean up, simplify, dedupe, restructure, reorganize |
docs | readme, docs, document, documentation, usage guide |
research | research, look up, investigate, compare, evaluate, spike, find the best approach |
implement | an implement verb (implement, add, build, create, support, integrate, update, change, modify) plus a code surface (file path, extension, backticked term, repo/module/API/test/tooling word) or a verification word |
explain (late) | explain-ish wording that reached this point |
general | nothing matched |
2. Rewrite mode
execution-contract— implement, debug, refactor, review, research, docs, test-fixplain— explain, general
A plain rewrite is stronger prose. An execution contract is compiled into
<task>, <context>, <constraints>, <verification>, <deliverable> — only
the sections that earn their place.
3. Effort
- Deep — the draft contains careful, deep, thorough, high-stakes, production, critical, architecture, or security
- Standard — implement, debug, refactor, review, research, test-fix
- Light — everything else
Deep and Standard both add: review the result once with fresh eyes before finalizing.
4. Blocks
Assemble only the blocks that improve the prompt.
| Block | What it fixes |
| Objective | The agent optimising for plausible instead of correct |
| Context | Missing files, constraints, unknowns |
| Work Style | Depth, breadth, first-principles expectations |
| Tool Rules | Editing before reading; guessing checkable facts |
| Output Contract | Shape and level of detail of the answer |
| Verification | Correctness, edge cases, regressions |
| Done Criteria | Stopping too early, or not stopping |
Per-intent defaults for the last four:
| Intent | Tool Rules | Verification | Done when |
| implement / refactor / test-fix | Read the files and their dependencies before editing; validate with the narrowest useful check first | Tests, lint, typecheck; no broken existing behavior | Change complete, tests pass, no known regressions |
| debug | Same, plus reproduce before editing | Root cause addressed; regression coverage added | Root cause confirmed fixed and covered |
| review | Read enough context to understand intent before critiquing | Correctness and completeness; no speculative redesign | Findings delivered with severity, reasoning, next step |
| research | Retrieve evidence before concluding; never guess checkable facts | Improve obvious weaknesses within scope | Synthesis grounded, uncertainties flagged, path recommended |
| docs | Read current docs and the behavior they describe | Examples and commands still work | Docs match behavior, examples verified |
| explain / general | Use tools only when they materially improve correctness | Correctness, completeness, edge cases | The question is clearly answered |
5. Quality bar
Before finalizing, check the rewrite:
- still matches the original intent
- adds no unnecessary ceremony
- carries the right verification level for the task
- gives a clear definition of done
If the draft is already strong, make only minimal edits.
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.