---
name: agnes-improve-score
description: Use when the user wants to raise their Agnes health score, or fix the findings of an Agnes report (agnes.dev), for a frontend repository. Reads the latest report through the Agnes MCP server and writes a prioritised plan before changing any code.
---

# Raise an Agnes health score

Agnes (agnes.dev) analyses the frontend code of a repository every day and gives it a health score from 0 to 100, with the findings behind it. This skill reads a project's latest report through the Agnes MCP server and turns it into a plan that raises the score, ordered by how much each fix gains.

It needs the Agnes MCP server. Create a token under Settings → API tokens in the Agnes app, then add the server, for example in Claude Code:

```sh
claude mcp add --transport http agnes https://app.agnes.dev/api/mcp --header "Authorization: Bearer <your token>"
```

The tools are read-only: `list_projects`, `get_report`, `rank_fixes`, `get_findings` and `get_scoring`.

## Workflow

1. **Find the project.** Call `list_projects`. Pick the one whose repository and branch match the code you are working in (compare with `git remote -v` and the current branch). If none matches, ask which project to use.
2. **Read the report.** Call `get_report` for the project: the overall score, the score per category (smells, dependencies, security, duplication, and tests and accessibility when they are on), and which checks did not run.
3. **Find what moves the score.** Call `rank_fixes`. It rescores the report without each rule's findings, so `overallGain` is the number of points fixing all of that rule's findings would add. Duplication is scored from a percentage, not per finding, so it shows no gain there; look at it separately if its score is low.
4. **Look at the findings.** For the rules you plan to fix, call `get_findings` with `ruleId` (and `file` to narrow down), page by page. Open the files and confirm each finding in the code. Findings with `confidence` "medium" or "low" can be false positives: say so in the plan instead of changing code that is fine.
5. **Write the plan, then stop.** Order the work by score gain per effort: quick wins with a large gain first. For each step give the rule, why it matters (use the finding's `url` when there is one), the files involved, how you will fix it, and the expected gain. Point out anything risky, such as a major dependency upgrade. **Do not change code until the user has approved the plan.**
6. **After approval, fix and check.** Make the changes step by step. Run the project's own linter, type checker and tests after each step. Agnes analyses the branch again after the next commit (daily), or straight away with a manual re-run on a paid plan.

## Rules

- Fix the cause. Never switch off a rule, add an ignore comment, or delete a check to make a finding disappear.
- For dependencies, prefer the smallest upgrade that removes the advisory, and mention breaking changes.
- Security findings come first when they are real, whatever their score gain.
- Keep each step small enough to review on its own.