agentleFS
ARCASSystemsARCASSystems/FounderOS/skills/founder-review/SKILL.md

founder-review

Skill7 starsChanged 19 days agoMITView on GitHub

Your own monthly performance review, run by your OS. Say "review my month", "score my month", "founder review", "coach me through the month", or run /founder-os:founder-review. Two steps - a scorecard counted from your own files first (counts only, never opinions), then at most five coaching questions that end in at most three commitments with dates. Next month opens by scoring those. Private by default. This reviews YOU, not a client and not a digital employee.

The file

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
  1. Very specific:

    Read context/priorities.md silently for the goal the month was serving.

    line 36
  2. Distinctive:

    Ask at most five questions, in one batch of up to four plus at most one follow-up.

    line 40
  3. Distinctive:

    No judgments delivered as verdicts.

    line 53
  4. Distinctive:

    If the scorecard exposes something the OS itself owns - a measure with no instrument, a file nobody has updated in six weeks - name it as …

    line 54
  5. Distinctive:

    Do not write any part of this into a file another person reads.

    line 70
  6. Distinctive:

    Never invent a number the files do not carry.

    line 74
  7. Distinctive:

    No em dashes. Writing rules apply.

    line 77

≈ “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

Founder review - the monthly mirror

Runs on: local-writes - it reads your files and writes commitments into cadence/queue.md and one entry into brain/log.md.

Cadence: monthly, first Sunday, about thirty minutes. It rides the weekly-review Sunday rhythm so it is not a new habit to remember.

This is not a self-esteem instrument, not something you share, and not daily. The daily step belongs to the coach line in /founder-os:morning-loop. This is the monthly altitude pass.

Step 1 - the scorecard (counted, never judged)

Count these from your own files for the month just ended. Counts only. No interpretation yet, and no number you cannot point at a file for.

MeasureWhere it comes from
Weekly must-dos set, and how many landedcadence/weekly-commitments.md retros for the month
Days with a log entry, versus days in the monthbrain/log.md
Outreach entries, and days since the most recent onebrain/log.md outreach entries, context/clients.md
Content or deliverables shippedbrain/log.md, cadence/queue.md DONE
Queue items closed, versus openedcadence/queue.md
Open flags older than 14 daysbrain/flags.md
Decisions made, versus decisions still parkedcontext/decisions.md
Last month's commitments: done, slipped, or killedthe Review commitment: items in cadence/queue.md

The rules that make the scorecard trustworthy:

  • A measure with no instrument says "no instrument". It never gets a guessed number. If you want that measure next month, the fix is to start recording it, and that is worth naming as an OS gap rather than a personal failing.
  • Scoring last month's commitments opens the conversation, not the counts. Each one done, slipped, or killed, in your words first.
  • Read context/priorities.md silently for the goal the month was serving. The scorecard is measured against that, not against a generic idea of a good month.

Step 2 - the coaching pass (at most five questions)

Ask at most five questions, in one batch of up to four plus at most one follow-up. Narrow options with a recommendation first. Plain language, no OS jargon. Skipping is always free and costs nothing.

Shape them across the four coaching moves, always forward-looking:

  1. Goal - one question tying the month to the number or outcome you are actually working toward. If that target is still vague, the question is whether to fix it now, not what it should be.
  2. Reality - one question on the sharpest gap the scorecard shows. Name the number plainly, without softening it, then ask what is actually in the way.
  3. Options - two or three concrete moves for that biggest gap, with a recommendation, and with "do nothing this month" as a real option.
  4. Will - the commitment question. At most three things, each with a date.
  5. The standing question, never dropped: "What should the OS stop doing for you?" The system gets reviewed by its user every cycle. If only four slots fit, this one survives and Options folds into Will.

Rules for the pass:

  • At most one bias lens per session (rules/biases.md). Pick the one the sharpest gap suggests, or none.
  • No judgments delivered as verdicts. The scorecard shows, the questions ask, you conclude.
  • If the scorecard exposes something the OS itself owns - a measure with no instrument, a file nobody has updated in six weeks - name it as an OS gap, not a personal failing. The distinction matters and it is easy to get wrong.

Step 3 - commitments become queue items

At most three. Before writing, show the commitments as they will read and name the file: "I will add these to your task queue (cadence/queue.md). Add them?" Write only on a yes, and only the ones it covers. Each one goes into cadence/queue.md with a due date inside the month, titled with the exact prefix:

Review commitment: <your words>

That prefix is the contract. Next month's scorecard finds these by the prefix and opens by scoring them. Respect the 3-item ACTIVE cap: if ACTIVE is full, commitments land in BACKLOG with their date, which is itself a signal worth saying out loud.

Close

One entry in brain/log.md: ### <date> - Founder review <month>: <one-line outcome> with the commitments named. The counts stay in this session, the commitments live in the queue, and the log entry is the written record.

Do not write any part of this into a file another person reads. Private by default.

Rules

  • Never invent a number the files do not carry. "No instrument" is an honest row and a guess is not.
  • The scorecard proposes, it never grades silently. The coaching pass asks, it never sentences.
  • Refuse to run twice in one month unless you explicitly ask for a re-run.
  • No em dashes. Writing rules apply.

Cross-refs

  • Daily half: the coach line in skills/morning-loop.
  • Weekly half: skills/weekly-review.
  • The same loop pointed at a digital employee instead of you: skills/employee-review.

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.