Brain · Team brain metrics

Team brain metrics

Your team's brain, summed. Errors-per-week across every tracked repo. Recurring prevention-rule fingerprints (a rule that failed twice is a rule that needs work). Decisions-per-month pace. Aged open questions. The institutional-memory health view, rolled up from every bound desktop.

Start here if you want to judge whether the brain is working, one repo or the whole team: Brain health.

See it in motion

Where to find it

  • Hosted: https://www.repoops.ai/team/brain-metrics
  • Source: Each bound desktop streams a per-repo brainPulse() snapshot hourly via the brain-pulse streamer.
  • API: POST /api/brain-pulse/ingest (desktop hosted, device-token auth).
  • Localhost equivalent: The Today view's Brain pulse panel and the Brain reflection tab.

What it does for you

You'll see the brain compound.Errors-per-week trending down. Decisions logged climbing. The team memory is a number that moves, not a slogan.
You'll catch the rules that failed.Recurring prevention-rule fingerprints surface here. Two entries in errors.md with the same prevention rule, at any distance in time, mean the rule is not doing its job: re-word it, fix it, or replace it.
You'll see aged open questions.Questions filed more than 30 days ago with no Resolved: note show up as aged. Either resolve them, escalate, or accept they're permanently parked.

Configure

Nothing on the hosted side. The desktop streamer needs only the bound-device token, set during the connect-code flow. The reflector is a separate job, checked hourly, that needs the BYOK Anthropic key you set in Settings.

  • REPOOPS_BRAIN_DREAM=0 (desktop): kill switch on the reflector itself. The streamer ships regardless (it streams metric summaries, not LLM output).
  • What is sent: aggregate counts, prevention-rule fingerprints, up to three sample entry titles per recurring rule, and aged question titles with dates. No proposal bodies, prompts, or reflector LLM output.
  • Streamer cadence: hourly while online, driven by a single in-process timer in the desktop server (server.mjs).
  • Freshness: a device whose last pulse is older than 7 days is listed as stale and left out of the team totals.

Use it well

  1. Look at errors-per-week trend first.

    If it's climbing, the team's prevention rules aren't firing. Open the recurring-rule fingerprint list; that is where a fix pays off most.

  2. Pick one recurring-rule fingerprint to fix per week.

    The rule already exists in errors.md; the issue is that it failed. Either re-word it, add an example, or replace it with a checkable rule.

  3. Close aged open questions weekly.

    30+ days means either resolve or move to backlog. Aged questions are a quality signal, not a TODO list.

  4. Decisions-per-month is a leading indicator.

    Climbing means the team is making architecture calls and documenting them. Flat means the team is moving by default. Either is fine; be honest about which.

Read more

Last updated