agentleFS
esmefongesmefong/gtm-skills/validation-tracker/SKILL.md

validation-tracker

Skill0 starsChanged 3 months agoMITView on GitHub

Run a weekly GTM operating rhythm: metrics with explicit floor and target bands, a deterministic weekly check of actuals against them, and an append-only decision log where every pivot, pause, and strategy change is written down with its rationale and revisit date. The script validates the log's integrity (append-only, supersession links resolve) and enforces the coverage rule: a week below floor with no logged decision inside the window is flagged as an undocumented miss. Use whenever the user says "operating rhythm", "weekly review", "track our benchmarks", "are we on track", "decision log", "why did we change strategy", "validation tracker", "weekly metrics check", or wants progress and pivots recorded instead of remembered. Works for any motion the other skills in this repo set up, and for any team that ships weekly.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When the check demands a decision, or strategy changes for any reason, append to the log: what was decided, the rationale at the time, what …

    line 51

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

Validation Tracker

The operating rhythm that keeps a GTM system honest week over week. Two claims drive the design: a metric without a benchmark is a mood, and a pivot without a written decision is a drift. The tracker holds both: bands that say what good looks like before the week happens, and an append-only log where every change of course is recorded with its reasoning, so the system's history can be audited instead of reconstructed.

What this consumes

InputWhyIf missing
Metrics with bands3-6 metrics, each with a floor (below this, act) and target (aim here), set before the periodHelp set them; a benchmark set after the results is a rationalization
Weekly actualsThe numbers, honestly, zeros includedA missing week is recorded as missing, never smoothed
The decision logEvery prior pivot with rationaleStart one now; entry one is why these metrics and bands

The workflow

Four phases, run weekly. The whole ritual is thirty minutes; the value is in never skipping it.

Phase 1: Record the week

Append the week's actuals to metrics.json. Zeros are data: a zero week recorded honestly is the input the coverage rule exists for. No retroactive edits to prior weeks; corrections are new entries with notes.

Phase 2: Run the check

scripts/weekly_check.py compares every metric against its bands and validates the decision log: chronological order, unique ids, supersession links that resolve, and coverage: any week with a metric below floor must have a decision logged within the window (default 21 days), or the check fails with an undocumented miss. The rule's point is not punishment; it is that a miss someone wrote a decision about is a managed miss, and a miss nobody wrote about is a drift.

Phase 3: Decide, in writing

When the check demands a decision, or strategy changes for any reason, append to the log: what was decided, the rationale at the time, what it supersedes, and when to revisit. Entries are never edited or deleted; a reversed decision gets a new entry that supersedes the old one, so the log reads as the true history of the system's thinking.

Phase 4: Revisit on schedule

Entries with revisit dates come due; the weekly run lists them. A revisit produces either a reaffirmation (log it, one line) or a supersession (log the new decision). Either way the log stays the single place where "why are we doing it this way" has an answer with a date on it.

Scripts

ScriptWhat it doesNetworkKeys
scripts/weekly_check.pyBand check per metric, append-only log validation, undocumented-miss detection, due revisitsNoneNone

Failure modes to avoid (the quality bar)

  • Bands set after results. Floors and targets are commitments, not descriptions.
  • Smoothed zeros. The zero week is the most informative row in the file.
  • Edited history. The log is append-only; supersession is the only way a decision changes.
  • The undocumented miss. Below floor with nothing written down is the failure mode this whole skill exists to catch, and the script fails on it mechanically.
  • Decision theater. An entry without a rationale and a revisit condition is a announcement, not a decision.
  • Metrics sprawl. More than six metrics and the ritual dies; track what would change behavior.

Bundled references

  • references/operating-rhythm.md: the weekly ritual, the band-setting guidance, the metrics.json and decisions.json schemas, and the coverage rule's exact mechanics.
  • examples/gtm-skills-repo/: this repo tracking itself. Every metric and decision in the example is real and checkable against the public git history, including two zero weeks and the decisions that cover them, plus a deliberately broken log the check refuses.

Download now (ZIP)

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.