due

Files (2)

• SKILL.md
• due-room.md · reference/

SKILL.md (first lines)

# Obligations and reminders

## Installed entry points

In normal chat or the notebook personal-command form, use `/due` followed by the command below. In the isolated native assistant terminal, use `mc-due`. The wrapper binds the current workspace; never override it with `--godspeed` or use a personal engine installation. `mc-due help` shows the actual installed command contract.

This recipe retains the complete obligation workflow. Calendar creation, updates and deletion require the person's exact approval. Calendar bookkeeping is local and works with no account. Read `reference/due-room.md` for bands, targets, windows and the canonical file format.

## What this is

Your mission control keeps track of the things in the person's life that have a last day, or a day
they would like them done by. It gets louder as a last day comes, and goes quiet the moment a thing
is done. The design target is **hundreds** of them (credentials, domains, taxes, contracts,
insurance, timesheets, returns, health checks, promises to people), so nothing here may cost
anything per obligation.

**The rule that shapes every decision: one skill, one runner, N data files, one output gate.**
Adding obligation 301 means adding a file under `due/`. If a change to this recipe would have to be
repeated per obligation, it is the wrong change.

**Read `reference/due-room.md` before your first run.** The three dates (start, target, deadline) and how
each combination behaves, the strip, the bands, the three states, the file format and the gate are
all defined there and are not restated here.

**Read `../watch/SKILL.md` too.** This recipe is its sibling and follows the same law: four
questions asked once, one skill for all of them, a hard cap on what can reach the person. One thing is
deliberately inverted. For a watch topic, a finding that expires unread is a correct outcome. For
an obligation it is exactly the failure, so an obligation inside its window outranks any watch
finding, and a window that ended without being closed stays open and stays red.

## The modes

### `add`: creating one

The person says "my timesheet is due every month". Ask them **four questions, once, ever:**

1. **What is true when this is finished?**
2. **"Is there a day after which this costs you something, or is it a day you'd like to have it done
   by?"** Ask it in those plain words. A day after which it costs them is the **deadline**
   (`--to`); a day they would like it done by is the **target** (`--target`); it can be both (a tax
   return: aim for the end of January, must by the end of February). Many things only have a
   target, and that is a full answer. If the first day they can start is not today, ask for that
   one too (`--from`); otherwise leave it out and it is today.
3. **What does it cost you if it slips?** Only when there is a deadline: it is what ranks two reds.
   A target alone costs nothing when missed, by definition, so do not make them invent a cost.
4. **How could your mission control tell you did it, without asking you?** (the self check)

Plus: does it repeat, and how often.

```
mc-due add <slug> --title "<in their words>" [--from YYYY-MM-DD] \
  --target YYYY-MM-DD and/or --to YYYY-MM-DD \
  --done-when "<answer 1>" [--cost "<answer 3>, needed with --to"] \
  --self-check none|secret-changed|file-newer [--self-check-arg X] \
  [--repeats monthly|yearly|"every N days"] [--link <https url>]
```

**Ask question four every single time, even when you already know the answer is "it cannot".**
Knowing which kind of obligation this is changes what gets built around it, and an obligation that
cannot check itself is legitimate, not second class. It says so and waits for the person's word.

**Never interview them again after that.** Same discipline as the watch skill and for the same
reason.

**NO DATE, NOT ELIGIBLE.** If they can say neither a last day nor a day they would like it done by,
this is not an obligation and it does not go in here. "Someday" is not a target; "by the end of May" is. For an undated request to discuss something with a person, use `../talk-about/SKILL.md`.
For other undated requests, offer a note or a watch topic. The tool refuses it
anyway, in those words, but you should not need the tool to refuse you.

**Never invent a date.** If you do not know when the window opens, ends or is aimed at, ask them for
that one date and nothing else. Never turn a target they gave into a deadline, or a deadline into a
target: which one it is changes everything about how loud it gets. Before you ask, search: the notebook tools `search_knowledge` and `search_notes`, the chat
history, the page itself. The search is the check.

### `run`: the daily runner

```
mc-due check      # roll the windows forward, run the self checks, close what is provably done
```

That is the whole job on a normal day, and it is arithmetic and file reads, not judgment. It needs
no model at all, which is why the installed deadline-reminder routine runs this check without asking the model. You are here
for the three things arithmetic cannot do: creating one, closing one on the person's word, and the calendar.

### `close`: they say they did it

```
mc-due done <slug> --evidence "<what shows it: a receipt, a link, or their own words>"
```

That writes the closing as an event in `world/events/` (`closes: [due/<slug>#<first day>]` plus an
`evidence:` line); the `due/` file keeps only the plan and is never edited to say done. A
hand-written or life-capture event with `closes:` and `evidence:` closes it just the same, and
`mc-due state` shows what closed each one.

**Never close an obligation on an inference.** "They mentioned the tax adviser" is not "they filed the
return". If a self check cannot prove it, the person's word is the only thing that closes it, and the event
must carry what shows it: an event without `evidence:` closes nothing. **Their word includes doing it
with you:** when they approve, send or publish the thing in this session, that is their word; close it
before the session ends and never ask them to say "close it" afterwards. The installed notebook and chat use the same obligation files and event evidence. At the end of work that actually completes one, run `mc-due done` with that evidence. Do not infer completion from discussion or a saved draft. The deadline reminders routine runs the self checks every morning; Settings > Routines shows whether it is switched on and when it last ran.

### `target`: their answer after a target passed

A target with no deadline asks once, the morning after it passed: "<title>: on <day they set it> you
told me you would like this done by <day>. That day was yesterday, so I am asking once: a new date,
or as soon as you can? Reply with a new date and I stay quiet until that day; reply "as soon as you
can" and it stays on your list with a short line in the morning brief about once a week; reply "drop
it" and nothing mentions it again. No reply counts as "as soon as you can"." Days are said the way a
person says them ("10 March"). Whatever channel their answer arrives on, it goes here ("drop it" goes
to `drop`, below):

```
mc-due target <slug> YYYY-MM-DD    # a new day: quiet until then, one mention, the question again if it passes
mc-due target <slug> asap          # as soon as they can: written into its log, nothing else changes
```

"As soon as you can" and no answer behave the same, on purpose: it stays open and is mentioned
about once a week, in the brief only, until it is done or dropped. So never chase them for an
answer, and never ask the question a second time yourself. The same command gives a target to an

From MichaelZelbel/godspeed-mission-control, MIT.

More from MichaelZelbel/godspeed-mission-control