How do I install the Code Coverage skill?

Run npx skillmds@latest add srinandan/code-coverage 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 Code Coverage 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 Code Coverage?

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 Code Coverage free to use?

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

Who published Code Coverage?

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

Code Coverage by srinandan — Agent Skill

Name: Code Coverage
Author: srinandan

Code Coverage

Coverage targets and exclusions for this repo (Python for the orchestrator, Go for pkg and frontend server), and why coverage should be treated as a signal rather than a target. Use when assessing whether a change has adequate test coverage, or when coverage drops in CI.

srinandan 306c897 2.0 KB Updated Sep 17, 2026

File contents

Code coverage

Coverage is a signal for finding untested code, not a target to write tests against. Don't add a test whose only purpose is moving the number.

Targets

orchestrator/ (Python): 80% line coverage, measured with pytest --cov=orchestrator --cov-report=term-missing
Go packages (pkg/, frontend/server/): 80% line coverage, measured with go test ./... -coverprofile=coverage.out && go tool cover -func=coverage.out
frontend/ (Vue/TS): 60% line coverage, advisory rather than enforced — UI code has a lower ratio of logic to markup, so the number is less meaningful here
The Reviewer/Critic and HITL approval path specifically: treat as needing coverage closer to 100%, regardless of the module-wide target — this is the governance surface the whole demo depends on being trustworthy

Exclusions

Don't count against the target, and don't chase coverage on:

Generated code
main.go / __main__.py / wiring and dependency-injection setup with no branching logic
Thin wrappers around external SDKs with no logic of their own

Where enforced

CI gate, once CI config exists (not yet built — see repo status in the root README.md). Until then, run coverage locally before opening a PR:

pytest --cov            # orchestrator/
go test ./... -cover    # pkg/ and frontend/server/
npm run test -- --coverage    # frontend/

When coverage drops

Treat a coverage regression as a prompt to ask "what code just got added without a test," not as a number to patch. If the honest answer is "this line genuinely doesn't need a test" (e.g. a trivial getter), that's a valid outcome — say so in the PR rather than padding with a low-value test.

---name: code-coveragedescription: Coverage targets and exclusions for this repo (Python for the orchestrator, Go for pkg and frontend server), and why coverage should be treated as a signal rather than a target. Use when assessing whether a change has adequate test coverage, or when coverage drops in CI.---# Code coverageCoverage is a signal for finding untested code, not a target to writetests against. Don't add a test whose only purpose is moving the number.## Targets- `orchestrator/` (Python): **80% line coverage**, measured with `pytest --cov=orchestrator --cov-report=term-missing`- Go packages (`pkg/`, `frontend/server/`): **80% line coverage**, measured with `go test ./... -coverprofile=coverage.out && go tool cover -func=coverage.out`- `frontend/` (Vue/TS): **60% line coverage**, advisory rather than enforced — UI code has a lower ratio of logic to markup, so the number is less meaningful here- The Reviewer/Critic and HITL approval path specifically: treat as needing coverage closer to 100%, regardless of the module-wide target — this is the governance surface the whole demo depends on being trustworthy## ExclusionsDon't count against the target, and don't chase coverage on:- Generated code- `main.go` / `__main__.py` / wiring and dependency-injection setup with no branching logic- Thin wrappers around external SDKs with no logic of their own## Where enforcedCI gate, once CI config exists (not yet built — see repo statusin the root `README.md`). Until then, run coverage locally before openinga PR:```bashpytest --cov # orchestrator/go test ./... -cover # pkg/ and frontend/server/npm run test -- --coverage # frontend/```## When coverage dropsTreat a coverage regression as a prompt to ask "what code just got addedwithout a test," not as a number to patch. If the honest answer is "thisline genuinely doesn't need a test" (e.g. a trivial getter), that's avalid outcome — say so in the PR rather than padding with a low-value test.

Frequently asked questions