How do I install the Improve skill?

Run npx skillmds@latest add cyberuni/improve in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Improve safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Improve?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Improve free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Improve?

cyberuni (@cyberuni) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Improve by cyberuni — Agent Skill

Name: Improve
Author: cyberuni

Improve

Use this skill when the user wants to improve an existing agent configuration — a skill, subagent, command, or AGENTS.md section — whether by diagnosing failing ACED evals or by general review against fit and quality bars. Trigger on "improve this skill", "make this agent better", "why does this config keep failing", or "review this AGENTS.md section", even when no eval suite exists yet.

cyberuni c47dace 2 files · 4.8 KB Updated Sep 17, 2026

File contents

ACED Improve

Improve an existing agent configuration of any kind. This is the general entry point — it routes to the right diagnostic path depending on whether the target is ACED-tracked.

Route the request first

Defer when the intent is narrower than "improve this config":

The request is really about…	Defer to
scaffolding a new skill, agent, command, or governance from scratch	`define-skill` / `define-agent` / `define-command` / `define-governance`
scoring a config against its frozen `.feature` suite	`run`
adding a new scenario	`add-scenario`
diffing two versions before committing a change	`compare`
auditing a `SKILL.md`'s structure/compliance specifically	`improve-skill`

Locate the target and its artifact type

Identify the config being improved: skill, subagent, command, or AGENTS.md section. Read it in full. If the artifact type or path is not clear from context, ask.

Determine ACED-tracked status

Check for the target's node in the project spec — .agents/specs/<project>/…/<node>/ (discovered through the SDD spec tree) — carrying a colocated eval.md for this target.

ACED-tracked (eval suite exists): ensure a recent result exists — run run first if the latest results/ file is stale or missing. Then load aced-impl-producer to identify failing scenarios, classify them by pattern, and propose concrete before/after edits.
Not yet tracked (no eval suite): there is nothing to diagnose failures against. Do a general review instead:
1. Load the fit classifier (aced-fit) to check whether this subject benefits from scenario→rubric evals at all — some configs are the wrong squad for ACED.
2. Load the relevant bar for the artifact type (aced-builder-spec for a subject with no frozen .feature yet, aced-builder-impl for one that has an existing implementation) and check the config against it.
3. Propose edits for any gap found: weak trigger coverage, missing near-miss handling, ambiguous steps, scope creep, structural issues.

Confirm before applying

Show all proposed edits — exact before/after diffs, not prose descriptions. Ask for approval before writing any changes.

Verify after applying

ACED-tracked: run compare (before = previous git revision, after = current working tree) to confirm the edits improved scores without regressions.
Not yet tracked: offer to hand off to sdd:start-mission (the conductor resolves the ACED roles for this artifact-type) to author a .feature (with inline @rubric), or add-scenario to start one manually. Do not fabricate a pass/fail verdict without a suite to run.

If no clear fix exists

If failures are caused by inherent non-determinism (high score variance across similar cases), recommend:

Adding more specific examples to the config
Lowering the threshold in eval.md for that layer if the bar was set too high
Splitting the config into two narrower ones

Do not propose removing test cases to fix failing evals — that defeats the purpose.

---name: improvedescription: Use this skill when the user wants to improve an existing agent configuration — a skill, subagent, command, or AGENTS.md section — whether by diagnosing failing ACED evals or by general review against fit and quality bars. Trigger on "improve this skill", "make this agent better", "why does this config keep failing", or "review this AGENTS.md section", even when no eval suite exists yet.---# ACED ImproveImprove an existing agent configuration of any kind. This is the general entry point — it routesto the right diagnostic path depending on whether the target is ACED-tracked.## Route the request firstDefer when the intent is narrower than "improve this config":| The request is really about… | Defer to ||---|---|| scaffolding a **new** skill, agent, command, or governance from scratch | `define-skill` / `define-agent` / `define-command` / `define-governance` || **scoring** a config against its frozen `.feature` suite | `run` || **adding** a new scenario | `add-scenario` || **diffing** two versions before committing a change | `compare` || auditing a `SKILL.md`'s structure/compliance specifically | `improve-skill` |## Locate the target and its artifact typeIdentify the config being improved: skill, subagent, command, or AGENTS.md section. Read it infull. If the artifact type or path is not clear from context, ask.## Determine ACED-tracked statusCheck for the target's node in the project spec — `.agents/specs/<project>/…/<node>/` (discoveredthrough the SDD spec tree) — carrying a colocated `eval.md` for this target.- **ACED-tracked (eval suite exists):** ensure a recent result exists — run `run` first if the latest `results/` file is stale or missing. Then load `aced-impl-producer` to identify failing scenarios, classify them by pattern, and propose concrete before/after edits.- **Not yet tracked (no eval suite):** there is nothing to diagnose failures against. Do a general review instead: 1. Load the fit classifier (`aced-fit`) to check whether this subject benefits from scenario→rubric evals at all — some configs are the wrong squad for ACED. 2. Load the relevant bar for the artifact type (`aced-builder-spec` for a subject with no frozen `.feature` yet, `aced-builder-impl` for one that has an existing implementation) and check the config against it. 3. Propose edits for any gap found: weak trigger coverage, missing near-miss handling, ambiguous steps, scope creep, structural issues.## Confirm before applyingShow all proposed edits — exact before/after diffs, not prose descriptions. Ask for approval beforewriting any changes.## Verify after applying- **ACED-tracked:** run `compare` (before = previous git revision, after = current working tree) to confirm the edits improved scores without regressions.- **Not yet tracked:** offer to hand off to `sdd:start-mission` (the conductor resolves the ACED roles for this artifact-type) to author a `.feature` (with inline `@rubric`), or `add-scenario` to start one manually. Do not fabricate a pass/fail verdict without a suite to run.## If no clear fix existsIf failures are caused by inherent non-determinism (high score variance across similar cases),recommend:1. Adding more specific examples to the config2. Lowering the threshold in `eval.md` for that layer if the bar was set too high3. Splitting the config into two narrower onesDo not propose removing test cases to fix failing evals — that defeats the purpose.

Frequently asked questions