agentleFS
skyf0xxskyf0xx/gambit/skills/capacity/SKILL.md

capacity

Skill29 starsChanged 33 days agoMITView on GitHub

Use when the plan assumes more time, money, or personal energy than actually exists — or periodically on any sustained effort. Assesses the operator's real capacity and runway, checks whether posture is sustainable, and finds the culminating point in concrete personal terms rather than abstract ones. The failure mode it catches is the operator running out before the goal does. Writes to the goal's capacity key.

We split this skill into the rules it gives an agent

12 rules. 0 are common, 8 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 9 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Purpose: Check whether the person running this can actually run it, for as long as it needs running.

    line 18
  2. Distinctive:

    Do not moralise about rest, do not catastrophise about burnout, and do not collude with a plan that obviously doesn't fit the hours …

    line 36
  3. Very specific:

    Read the goal — the goal statement, deadline, the plan key, the posture key, the people key, and the log.

    line 48
  4. Distinctive:

    Ask directly. Estimates are fine.

    line 54
  5. Distinctive:

    Ask once, plainly, and accept whatever's given.

    line 74
  6. Distinctive:

    If the plan requires more than is available, say it plainly and immediately.

    line 92
  7. Distinctive:

    When the plan is short, find the constraint before cutting anything (Eliyahu Goldratt, *The Goal*, 1984).

    line 97
  8. Very specific:

    If the posture key is set:

    line 113
  9. Very specific:

    Call write_section on capacity with the honest hours per week, the runway, and any specific warning sign to watch:

    line 184
  10. Very specific:

    Call append_log with one note on what changed this pass, not a summary of the section the page already shows.

    line 204
  11. Distinctive:

    If the write returns { ok: false, errors }, fix the reported fields and retry before ending the turn.

    line 207
  12. Distinctive:

    If capacity genuinely fits the plan, say so and stop.

    line 221

“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “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

Skill: capacity

Trigger: The plan is getting bigger, the timeline is getting longer, or the user is tired. Also run periodically on any effort lasting more than a few weeks, and whenever strategy escalates posture — an escalation nobody has checked against real capacity is how sustained efforts end.

Purpose: Check whether the person running this can actually run it, for as long as it needs running.

systems analyses the culminating point abstractly — the moment past which effort yields less. This one asks the concrete version: when do you run out? Of hours, of money, of goodwill at home or at work, of the energy to keep asking people for things.

Most sustained coordination efforts don't fail because the strategy was wrong. They fail because the person driving it stopped, and everything downstream of them stopped too.


Voice & Tone

Direct and practical, not therapeutic. This is a resource assessment. The user is an adult making their own choices about what to spend themselves on, and the job is accurate information, not persuasion toward balance.

Do not moralise about rest, do not catastrophise about burnout, and do not collude with a plan that obviously doesn't fit the hours available — that's the specific failure this skill exists to catch, and softening it is the way to be useless.

Where the numbers don't work, say so plainly and give options. The user decides.


Execution Sequence

1. Load Context

Read the goal — the goal statement, deadline, the plan key, the posture key, the people key, and the log. Look at the log's rhythm as much as its content: gaps, and stretches of high activity, both carry information.

2. Establish the Real Numbers

Ask directly. Estimates are fine; precision isn't the point, and orders of magnitude are.

TIME
  Hours per week actually available for this: [N]
  Competing commitments: [work, family, study, other obligations]
  Is that sustainable, or is it borrowed from something? [what's being displaced]

MONEY (if the goal costs anything)
  Spent so far: [N]
  Committed but unspent: [N]
  Available before it hurts: [N]
  Is any of it other people's? [obligations that creates]

ENERGY
  Current level: [running well | tired but fine | running on reserves | depleted]
  How long at this rate: [honest estimate]
  Last real break: [when]

Ask once, plainly, and accept whatever's given. If the user won't put numbers on it, work with ranges and note the assessment is rough.

3. Compare Against the Plan

The core arithmetic:

PLAN REQUIRES: [estimated hours/week to execute the current plan]
ACTUALLY AVAILABLE: [N hours/week]
GAP: [surplus | matched | short by N]

RUNWAY: [how long the current rate can hold — weeks, months]
DEADLINE: [time remaining]
VERDICT: [runway exceeds deadline | runway falls short by N | no deadline, but rate is
          unsustainable from [date]]

If the plan requires more than is available, say it plainly and immediately. Do not soften it and do not present it as a motivation problem. A plan that needs twenty hours a week from someone who has six is not a discipline failure; it's an arithmetic error, and it resolves by changing the plan.

When the plan is short, find the constraint before cutting anything (Eliyahu Goldratt, The Goal, 1984). One thing limits how fast the whole effort moves: usually one person's hours, one approval, or one skill only the user has. Work it in Goldratt's five steps:

  1. Identify it: the step everything else waits on.
  2. Exploit it: spend none of its hours on work something else could do.
  3. Subordinate the rest to it: other work runs at its pace, not faster.
  4. Elevate it: only then add hours, money or people to it.
  5. Repeat: once it stops being the limit, find the next one.

An hour saved anywhere but the constraint saves nothing. What this finds feeds options 1 and 3 in step 7.

4. Check Posture Against Capacity

If the posture key is set:

POSTURE vs CAPACITY
  Current posture: [level] — implies [pace, concurrent asks, margin]
  Capacity supports: [level]
  Mismatch: [none | posture exceeds capacity — sustainable for ~N weeks]

Elevated posture is meant to be temporary. A posture that's been elevated for months isn't a posture — it's the new baseline, and it's consuming reserves that were meant for the moment they're actually needed. Say so where it's happening, and say when it started.

5. Single-Point-of-Failure: The Operator

IF YOU STOPPED FOR TWO WEEKS
  What continues: [...]
  What stops: [...]
  What breaks permanently: [...]

Almost always, too much stops. That's diagnostic rather than damning, but it's worth seeing concretely. If the answer is "everything stops", the effort has no resilience — and building some is a strategic question, not a personal one.

Where the people key is non-empty, ask what could be handed over. The usual blocker isn't willingness; it's that nothing has been written down in a form anyone else could pick up.

6. The Honest Culminating Point

CULMINATING POINT — personal
  At current rate, you run short of [time | money | energy] around [date/condition]
  Warning signs to watch: [specific and observable — the log going quiet, missed
                           commitments, dreading the work, avoiding the file]
  What extends it: [reduce scope | hand off | slow the pace | add money | recruit]

Frame warning signs as observable events, not feelings. "Two weeks with no log entry" is checkable; "feeling overwhelmed" gets rationalised away in the moment.

7. Give Real Options

Where capacity falls short, don't leave it as a problem. Lay out the actual choices — they're limited, and seeing all four together makes the decision cleaner:

OPTIONS
  1. Cut scope — [what specifically comes out] — [what that costs against the criteria]
  2. Extend time — [is the deadline actually fixed?] — [what that costs]
  3. Add capacity — [who, doing what, and what recruiting them costs]
  4. Sustain and accept — [what breaks, and when]

Option 4 is legitimate. Sometimes an effort is worth spending yourself on for a fixed period, and a fixed sprint at a known cost with an end date is very different from an open-ended one nobody has measured. Make it a choice rather than a drift.

8. Elicit

  - Does that match how it actually feels, or am I over- or under-reading it?
  - What would you drop first if you had to drop something?

The second question surfaces the real priority ordering, which is often different from the plan's stated one — and that difference is worth carrying back to strategy.

9. Update the Goal

Call write_section on capacity with the honest hours per week, the runway, and any specific warning sign to watch:

  • availableHrsPerWeek: concrete number per week, or null if unknown
  • runway: when you run short (e.g., "until 2026-10-15", or "6 months at this rate")
  • watch: the specific observable warning sign (e.g., "two weeks with no log entry", "missing family dinners three nights running")
  • detail (optional, max 280 chars): hover tooltip in the visual layer, elaborating on runway — what the number rests on. Fill in only when the short field alone would be unclear later.
  • lastReviewed (required, YYYY-MM-DD): today's date, every time this skill writes capacity. Lets strategy tell a stale capacity read from a current one without scanning log.
{
  "capacity": {
    "availableHrsPerWeek": 15,
    "runway": "until 2026-11-30",
    "watch": "log goes quiet or work creeps into evenings regularly",
    "detail": "...",
    "lastReviewed": "YYYY-MM-DD"
  }
}

Call append_log with one note on what changed this pass, not a summary of the section the page already shows. If capacity forces a scope change, load plan or strategy rather than trimming the plan here.

If the write returns { ok: false, errors }, fix the reported fields and retry before ending the turn.

10. Name the Next Step

Next: [the single change that closes the gap, or "nothing — capacity fits the plan"]

Or:
  - Cut or resequence the plan → plan
  - The goal itself needs resizing → strategy
  - Choosing between the options above → decide
  - Hand something over → comms, then plan

If capacity genuinely fits the plan, say so and stop. This skill should return "you're fine" when that's true — a check that always finds a problem stops being believed.

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.