Back to Efficiency · Installation
Efficiency helps your coding agent choose simpler solutions, maintain useful instructions, and explain its work clearly. A skill is a set of instructions for a particular task. You can select one explicitly or describe what you want and let your app choose a matching skill.
Start with the task you want help with:
| I want to… | Read this example | Skill |
|---|---|---|
| Review or simplify code | Review a change | efficiency |
| Choose useful checks without unnecessary work | Plan verification | efficiency |
| Improve a bug investigation or repeated work | Keep work focused | efficiency |
| Remove duplicated agent instructions | Improve context | context-optimization |
| Explain a change clearly | Write a change summary | efficiency |
| Reduce noisy terminal output | Use RTK | rtk-setup, rtk-filter-design |
| Make concise responses and simple code changes a lasting preference | Set up persistent guidance | response-simplicity-setup in Codex |
In Cursor, type / followed by the skill name. In Codex, use $geldmacher-efficiency: followed by the skill name:
/efficiency Review my current changes for unnecessary complexity.
$geldmacher-efficiency:efficiency Review my current changes for unnecessary complexity.
The examples below use Cursor commands. In Codex, replace the command prefix in the same way; for example, /context-optimization becomes $geldmacher-efficiency:context-optimization.
Natural-language requests such as “Review this refactor for complexity” or “Find duplicated instructions in AGENTS.md” can also select the matching skill. Selection depends on your app and the task. Name the skill explicitly when you want to make your choice clear.
Use this when a change is difficult to follow, adds new abstractions, or seems larger than the requirement needs.
/efficiency Review my current changes. Can we meet the requirement with fewer concepts or reuse something already in this project?
You get a recommendation tied to the requirement and the code: what adds unnecessary complexity, what a simpler alternative would be, and which behavior must be checked before changing it. The review can also conclude that the current design is appropriate.
Example: A change adds a configurable formatter registry for one date format. The project already has a date helper. A useful recommendation is to reuse the helper after checking timezone and invalid-input behavior. An adapter that hides necessary transaction recovery may still be worth keeping, even if it has only one implementation.
Example: A large new TypeScript module adds several any casts, an empty catch, and two near-identical helpers. A useful recommendation is to narrow the types, surface the error, and keep one helper — without demanding a coverage or mutation score the project does not already enforce.
These are illustrative examples, not recorded agent results or benchmarks.
A review leaves files unchanged. To request an implementation, name the change and its scope:
/efficiency Replace the new formatter registry in this diff with the existing date helper. Preserve timezone and invalid-input behavior, and verify those cases.
You can also name a file or provide a design proposal. Without an explicit code scope, Efficiency uses the current Git changes, including staged, unstaged, and untracked files. If there are none, it asks what to review.
The approach is called Evidence-Guided Simplicity: start from what the task requires and what the repository shows, then consider these options in order:
- Omit work the requirement does not need.
- Reuse something the project already provides.
- Use a built-in language or platform feature.
- Use an installed dependency if it reduces the overall burden.
- Write the smallest local implementation that meets the requirement.
Three familiar principles guide the choice: build for current needs (YAGNI), keep the design easy to understand (KISS), and keep each shared rule in one authoritative place (DRY). Similar-looking code alone is not a reason to combine two rules that may change independently.
Ordinary code changes do not load this skill. The always-applied guidance keeps a short core for them: reuse what exists, build only what the requirement needs, stay in scope, and preserve behavior. It also points to the debugging, verification, repeated-work, and design references when one of those situations arises, so they apply silently without an efficiency assessment. When this skill reviews or changes code, the quick check stays quiet unless it changes the chosen solution, scope, or risk. An explicit review or a material complexity risk triggers a fuller comparison with one smaller alternative. Fewer lines are not the goal: behavior, public interfaces, saved data formats, security, accessibility, performance, and necessary error recovery must remain intact unless your assignment explicitly changes them.
Use this to decide which evidence would show that a proposed or completed change works.
/efficiency What should we check for this date-formatting change? Explain which behavior each check would verify.
Efficiency covers every independent material risk in scope with the smallest set of facts and recommends the least costly adequate way to check them, alongside any required project checks. It does not add a fact that does not change the check.
Example: For a date helper, a focused check of timezone boundaries and invalid input may answer the main correctness questions. If the claim is that the date is readable in a browser, a unit test cannot establish that; an inspection of the rendered result is still needed.
The recommendation explains what the evidence proves and what remains unknown. Asking for a verification plan does not by itself start tests, servers, or live checks.
Efficiency can help decide where to spend effort during an existing assignment.
/efficiency Review this investigation. Which observation would help distinguish
the remaining explanations for the failure?
You get a focused next check, including whether the failed fixes share an untested assumption.
/efficiency Should we make these edits directly or write a small script?
Consider reruns and how we will verify the result.
You get a comparison of manual effort with the cost of building, checking, and maintaining a tool.
These requests produce advice. Diagnosis, fixes, scripts, and additional checks need to be part of the work you have asked the agent to carry out.
Context is the material an agent reads to do its work: project instructions, rules, skills, and tool output. Repeated or irrelevant instructions can make that material harder to maintain and use.
/context-optimization Review AGENTS.md and this project's rules for duplicated or always-loaded instructions. Suggest a clearer structure without editing files yet.
You get specific suggestions about what to keep, combine, or load only when needed, with the constraints that must survive the change.
Example: If three files repeat the same test command, keep one authoritative instruction and clear references to it. If deployment instructions are long and only matter during a release, keep a short pointer that says exactly when to read them. Required security or approval rules must remain available wherever they apply.
To implement a recommendation, ask for it explicitly:
/context-optimization Consolidate the duplicated test instructions in AGENTS.md and the project rules. Preserve required checks and make the shared instructions easy to find.
Use Efficiency to prepare a commit message, pull request description, release notes, or a change summary.
/efficiency Draft a pull request description from this diff and the checks we ran. Explain the user-visible change and any remaining verification gaps.
The summary follows project conventions and leads with the result. It distinguishes what the diff changes, what checks actually passed, and what is still unverified. This request drafts text; it does not start a code review or an RTK inspection.
Example: “Invalid dates now show a validation message. The parser tests pass; the browser display has not been checked yet.” This tells a reviewer both what changed and the limit of the evidence.
For a one-off shorter answer, simply ask “Explain your last answer more simply.” No setup is needed; the rewrite should retain facts, risks, and open questions.
- Cursor: the plugin includes a short rule for clear responses and simple, in-scope code changes. It applies automatically. The same rule writes rules, skills, commands,
AGENTS.md, and new code in English, including comments and names, and keeps replies in the user's language. - Codex: the same global guidance is an optional, separate setup step. Ask
$geldmacher-efficiency:response-simplicity-setup Show the current status and preview setup.
The Codex skill shows the proposed change to your global instructions before asking for approval. Once configured, start a new task. See setup and removal for details.
RTK (Rust Token Killer) is a separate tool that condenses command output before the agent reads it. Efficiency can inspect, install or update RTK, verify its integration and create project-specific output filters. You can use all other Efficiency workflows without installing RTK.
/rtk-setup Check whether RTK is installed and integrated with my app. Report what works and what still needs setup.
This checks the current state. In Codex, invoke $geldmacher-efficiency:rtk-setup instead. After updating RTK, use the same skill with this request:
Check RTK integration after the update. Compare the installed version and current upstream guidance with this app's configuration. Inspect setup dry-runs, command rewriting, native approvals, tracking, and output quality. Report the smallest needed changes; do not change configuration.
The update check distinguishes configured hooks, processor results, actual execution in the app, and output quality. Codex can use native hooks or instruction-based integration depending on the installed RTK and active Codex runtime. A terminal test or history entry alone does not prove automatic rewriting in either app.
To request the update itself, use /rtk-setup Update RTK to the latest stable official release and verify integration in this app. The skill previews the identified package-manager command before applying the requested change. It preserves pins and newer/development installations and gives instructions for unknown/manual binaries. In this plugin's development checkout, the update also reconciles affected skills and documentation, even when RTK is already current. Installed plugin bundles are updated through plugin releases.
After a successful Efficiency plugin update, install-new-release-from-repo also checks RTK. It offers first installation or a needed update separately. Only your acceptance starts RTK changes; a decline or RTK failure leaves the successful plugin update intact. Checks run on these relevant invocations, without a background watcher.
If you request configuration, the skill previews the affected settings before applying the authorized change. Generated RTK.md content belongs to rtk init and can change between versions. Setup examples and verification instructions in older versions apply to setup or troubleshooting. Before replacing a file with custom additions, account for needed tracking, environment, and sandbox settings in user-owned configuration or instructions; do not silently lose them or hand-edit the generated file as a durable fix.
For a recurring noisy command:
/rtk-filter-design Review the output of our test command and suggest a filter that keeps failures, warnings, file paths, and the exit status intact.
An approved filter must preserve the meaning needed by its reader, including exact paths, important ordering, visible truncation, and output consumed by another program. If that cannot be established, the command should keep its native output. After editing a filter, complete RTK's trust step again before using it.
| Evidence | What it tells you |
|---|---|
| Command history | Whether a command actually ran through RTK. |
rtk gain |
Estimated reduction in shell output within the reported scope. |
| Largest contributors | Which commands account for most of that reduction in absolute terms. |
| Comparable complete task runs | Whether the whole task used fewer provider tokens, cost less, or finished with fewer turns while preserving quality. |
A large rtk gain percentage alone does not establish lower total cost. That claim needs comparable runs with the same task, app, model, reasoning effort, and environment, plus provider usage and result-quality evidence.
Skills can be selected explicitly or when relevant to a request. Only Cursor's short rule for responses and code changes is always applied; Codex needs the optional global setup for equivalent persistent guidance. That rule routes ordinary debugging, verification, repeated-work, and design decisions to the matching Efficiency reference; the efficiency skill itself is a short router for explicit reviews, assessments, and change texts. Specialized instructions load for the task that needs them.
Reviews give recommendations and do not edit files. Implementation stays within the change you requested. Existing project checks and app approvals still apply, and concise answers must retain material evidence, uncertainty, risks, blockers, and validation status. Efficiency adds no custom MCP server, telemetry, or background automation.
If you explicitly ask for an independent second pass, Cursor provides the read-only efficiency-auditor and rtk-filter-auditor. Codex can delegate the corresponding review to a subagent using the selected parent model. Auditors do not run automatically.
| App or component | Support |
|---|---|
| Cursor with plugin support | Five skills, matching slash commands, two optional auditors, and the response rule. |
| Codex with plugin support | The same five skills, plus response-simplicity-setup. |
| Other Agent Plugins v1 clients | Five portable skills; app-specific integration must be verified for that client. The release installer supports only Cursor and Codex. |
| Release installer and development tools | Node.js 22 or newer. See installation requirements. |
| Optional RTK integration | Native Cursor and version-dependent Codex hook or instruction paths. Verify the installed RTK version and active host runtime after updates; processor checks alone do not certify live compatibility. |
The five shared skills are efficiency, context-optimization, rtk-setup, rtk-filter-design, and install-new-release-from-repo. Broad version compatibility is not certified; release records state the versions actually tested.
| Problem | Next step |
|---|---|
| Skills are missing after installation | Follow activation and installation checks. |
| Codex responses do not follow the persistent guidance | Ask $geldmacher-efficiency:response-simplicity-setup Check status. Plugin installation alone does not configure it. |
rtk gain fails |
Check that the installed rtk is Rust Token Killer; another tool can use the same executable name. |
| Project filters are skipped | Run rtk verify --require-all, complete RTK's trust flow, and re-trust after each filter edit. |
| Another Agent Plugins client rejects the package | Check the client's stated v1 support and use the generated agent-plugins bundle. Repository checks do not certify every client. |