juandelossantosjuandelossantos/another-agent-skills/skills/project-metrics/SKILL.md

project-metrics

Skill1 starsChanged 11 days agoMITView on GitHub

Log empirical quality metrics across projects: build pass rate, rework, coverage, discovery time, gate pass rate. Runs automatically in the background. Do NOT use for manual data collection.

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
After these actions, skill MUST log:
line 48
Distinctive:
Never secrets, API keys, or code snippets.
line 96
Distinctive:
Only metadata: timestamps, counts, durations, pass/fail.
line 97
Distinctive:
Update global aggregates after every logged metric.
line 98
Distinctive:
Keep last 90 days per-project.
line 99
Distinctive:
After any action, log with:
line 105
Very specific:
When user requests report, read quality-metrics.json, calculate aggregates, present trends.
line 142

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Project Metrics

Runs automatically in background. Do NOT invoke directly.

When to Use

Automatically in background after every significant action. No direct invocation needed.

When NOT to Use

Manual data collection or ad-hoc queries (runs automatically)
Direct invocation (background skill only)

Output Contract

Artifact	Format	Location	Quality Criteria
quality-metrics.json data file	JSON file with per-project metrics (build, commit, gate, coverage, discovery, override) + global aggregates	`~/.config/opencode/quality-metrics.json`	Metrics logged automatically after every significant action, 6 metric types covered, global aggregates recalculated after each entry, no secrets or code in file, last 90 days per-project retained

Logs empirical quality metrics after every significant action, enabling retrospectives, trend analysis, and continuous improvement.

Purpose

Without metrics, "quality" is unmeasurable. Answers:

Builds passing more often over time?
Time in discovery vs rework?
Gates catching issues before code?
User frequently overriding suggestions?

Automatic Logging Triggers

After these actions, skill MUST log:

Action	Metric Type	Key Fields
`npm run build`	`build`	result, duration, errors, warnings
`git commit`	`commit`	files_changed, pre_commit_passed
Pre-commit checklist	`gate`	gate_name, result, checks_passed/failed
Test run	`coverage`	before, after, delta, tests_added
Discovery phase complete	`discovery`	duration, questions_asked, user_confirms
User override	`override`	type, reason, phase, was_agent_correct

→ See guides/METRICS-REFERENCE-GUIDE.md for complete JSON schemas of all 6 metrics.

Manual review: User says "show metrics" or "quality report" anytime.

Storage

Location: ~/.config/opencode/quality-metrics.json

Format:

{
  "version": "1.0",
  "created_at": "2026-05-24",
  "projects": {
    "project-name": {
      "first_session": "2026-05-20",
      "last_session": "2026-05-24",
      "total_sessions": 5,
      "metrics": [
        { "metric": "build", "timestamp": "...", "result": "pass" }
      ]
    }
  },
  "global": {
    "total_builds": 42,
    "build_pass_rate": 0.88,
    "rework_rate": 0.13,
    "avg_discovery_minutes": 9.5,
    "gate_pass_rate": 0.91,
    "user_override_rate": 0.08
  }
}

Rules:

Never secrets, API keys, or code snippets.
Only metadata: timestamps, counts, durations, pass/fail.
Update global aggregates after every logged metric.
Keep last 90 days per-project.

Logging Commands

After any action, log with:

LOG METRIC: [metric-type]
- project: [project-name]
- [field]: [value]

Examples:

LOG METRIC: build
- project: cafe-del-alba
- result: pass
- duration: 45
- errors: 0
- warnings: 2

LOG METRIC: gate
- project: cafe-del-alba
- gate_name: pre-commit-checklist
- result: pass
- checks_passed: 12
- checks_total: 12

LOG METRIC: override
- project: cafe-del-alba
- type: stack_change
- reason: user_preferred_vue
- phase: architecture_decision

Quality Report

→ See guides/REPORT-TEMPLATE-GUIDE.md for presentation format.

When user requests report, read quality-metrics.json, calculate aggregates, present trends.

Anti-Rationalizations

Excuse	Response
"Metrics slow me down."	3 lines of JSON. Insight prevents hours of rework.
"I already know I'm good."	Without data, "good" is a feeling. With data, improvable fact.
"User doesn't care about metrics."	User cares about results. Metrics deliver better results.
"I'll add metrics later."	Must log in the moment. Retroactive = guesswork.

Verification

~/.config/opencode/quality-metrics.json exists and updated after every session.
Global aggregates recalculated after each metric.
No secrets or code in metrics file.
Quality report shows meaningful trends, not just raw numbers.

Download now (ZIP)

In this repository59 other files it gives its agents.
- AGENTS.mdAGENTS.md
- templates/CLAUDE.mdCLAUDE.md
- adapt-skillSkill
- api-and-interface-designSkill
- architecture-analysisSkill
- audit-skillSkill
- backend-api-masterySkill
- browser-testing-with-devtoolsSkill
- ci-cd-and-automationSkill
- clarify-skillSkill
- cli-toolsSkill
- code-review-and-qualitySkill
- code-simplificationSkill
- context-engineeringSkill
- critique-skillSkill
- customize-opencodeSkill
- debugging-and-error-recoverySkill
- debugging-three-strikesSkill
- delight-skillSkill
- deprecation-and-migrationSkill
- dev-environment-auditSkill
- documentation-and-adrsSkill
- doubt-driven-developmentSkill
- engineering-fundamentalsSkill
- frontend-desktopSkill
- frontend-mobileSkill
- frontend-pwaSkill
- frontend-ui-engineeringSkill
- frontend-webSkill
- fullstack-shippingSkill
- gateSkill
- git-init-and-versioningSkill
- git-workflow-and-versioningSkill
- hard-skillSkill
- idea-refineSkill
- incremental-implementationSkill
- industrial-brutalist-uiSkill
- interview-meSkill
- minimalist-uiSkill
- multi-agent-orchestrationSkill
- observability-and-instrumentationSkill
- optimize-skillSkill
- output-skillSkill
- performance-optimizationSkill
- planning-and-task-breakdownSkill
- polish-skillSkill
- project-health-checkSkill
- redesign-skillSkill
- security-and-hardeningSkill
- self-improvementSkill
- shipping-and-launchSkill
- skill-creatorSkill
- skill-improverSkill
- soft-premium-uiSkill
- source-driven-developmentSkill
- spec-driven-developmentSkill
- test-driven-developmentSkill
- typeset-skillSkill
- user-onboardingSkill

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

What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free