Developer Productivity

Handoff

Matt PocockMITSkill language: English
License verifiedNo scripts
DemoReal run · claude-opus-5-5 · October 2026
Read billing/due_dates.py. Here is what we decided in today's planning meeting: (1) the Friday "+1 day" adjustment in invoice_due_date is a bug and will be removed, (2) we will add public-holiday support by loading a holidays.json file per country, starting with US and DE, (3) terms_days stays at a default of 10, and (4) finance wants the change released before the November invoicing run. Summarise in three bullets how the module behaves today and where holiday support would plug in. Don't change any code yet.

Here's how billing/due_dates.py behaves today:

  • Business-day counting (add_business_days, lines 4–12): It starts the day after start and counts only Mon–Fri. Holidays aren't considered, so a public holiday counts as a working day. The function has no country parameter.
  • Due-date calculation (invoice_due_date, lines 15–21): It adds terms_days business days (default 10) to the issue date. Then it adds one calendar day when issued.weekday() >= 4 (lines 19–20). That condition covers Friday, Saturday and Sunday, not just Friday. A 10-day term always lands on a Friday for those issue days, so the extra day makes the due date a Saturday. For example, an invoice issued Fri 2026-10-02 is due Sat 2026-10-17. Removing the adjustment makes it Fri 2026-10-16. Anyone who has seen the current Saturday dates should know they will move one day earlier.
  • Where holiday support plugs in: The weekend check at line 10 (if current.weekday() < 5) is the place to also skip holidays. To do that, add_business_days and invoice_due_date would take a country argument (or a set of holiday dates) and pass it down. A small loader would read the per-country holidays.json once and cache it, starting with US and DE. Lines 18–20 come out at the same time, as planned. terms_days=10 stays as it is.

I haven't changed any code. Two things to settle before November: what happens for a country that has no holidays.json (fail, or fall back to weekdays only), and whether the JSON files will include future years so dates stay correct around year-end.

/handoff The next session will implement the holiday support and remove the Friday adjustment.
Slash command: /handoff
Bash: echo "$TMPDIR"; cd <workdir> && git ls-files
Read: tests/test_due_dates.py
Write: handoff-billing-holidays-2026-10-04.md (system temp folder)

Handoff document written by the skill:

Handoff: holiday support + removing the Friday adjustment in billing due dates

Date: 2026-10-04
Repo: <workdir> (branch main, clean, single commit fc8800b seed)
Next session's job: add public-holiday support and remove the Friday "+1 day" adjustment.

No code has been changed yet. The user said not to touch code in the previous session.

Decisions from today's planning meeting (not recorded anywhere else)

  1. The Friday "+1 day" adjustment in invoice_due_date is a bug. It will be removed.
  2. Add public-holiday support by loading a holidays.json file per country. Start with US and DE.
  3. terms_days keeps its default of 10.
  4. Finance wants this released before the November 2026 invoicing run.

Relevant files

  • billing/due_dates.py: the whole module, about 20 lines. Read it first.
    • add_business_days (lines 4–12): skips weekends only. The check at line 10 (current.weekday() < 5) is where holiday skipping goes.
    • invoice_due_date (lines 15–21): lines 18–20 hold the adjustment that is being removed.
  • tests/test_due_dates.py: only two tests. Neither covers the Friday adjustment or holidays.
  • No holidays.json files and no loader exist yet. The location and format still need to be chosen.

Facts established in the previous session

  • The adjustment condition is issued.weekday() >= 4. It fires for invoices issued on Fri, Sat and Sun, not just Friday.
  • For those issue days, a 10-business-day term lands on a Friday. The +1 then makes the due date a Saturday. For example, an invoice issued Fri 2026-10-02 is currently due Sat 2026-10-17 and should be due Fri 2026-10-16. Removing the bug moves these dates one day earlier. This is worth mentioning in the PR or release notes for finance.

Suggested approach (not yet agreed with the user)

  • Add a country parameter (or an injected set of holiday dates) to add_business_days and invoice_due_date, and pass it down.
  • Add a small cached loader that reads per-country holidays.json files, with US and DE first.
  • Delete lines 18–20 of due_dates.py and update the docstring or comment.
  • Tests to add: Fri/Sat/Sun issue dates without the +1, a due date pushed past a US holiday, a due date pushed past a DE holiday, and a check that the terms_days default stays 10.

Open questions for the user

  • What should happen for a country with no holidays.json: raise an error, or fall back to weekdays only?
  • Which years should the JSON files cover? Due dates near year-end need next year's holidays.
  • Where should the JSON files live, and what schema should they use (for example, a list of ISO date strings)?
  • Is country required, or optional with a default? Existing callers and tests currently pass no country.

Suggested skills

  • code-review: review the diff before committing or opening a PR.
  • simplify: optional cleanup pass after the change is in.

Run the tests with pytest from the repo root. Commit and open a PR only if the user asks, and create a branch off main first.

I've written the handoff document for the next session at <system temp folder>/handoff-billing-holidays-2026-10-04.md. It's in the OS temp folder, not in the repo.

It covers:

  • Meeting decisions: the four decisions from today's planning meeting, which aren't recorded anywhere else.
  • Where the changes go: the line numbers in billing/due_dates.py for removing the Friday adjustment and adding holiday skipping.
  • Current behaviour: the adjustment fires for invoices issued on Friday, Saturday and Sunday, and it produces Saturday due dates. Finance should be told those dates will move one day earlier.
  • Test gaps: tests/test_due_dates.py has only two tests, and neither covers the adjustment or holidays.
  • Open questions: what happens for a country with no holiday file, which years the files cover, where the files live and their format, and whether a country must always be given.
  • Suggested skills: code-review and simplify.

I haven't changed any code, and the document contains no personal information or credentials.

Real run recorded with claude-code / claude-opus-5-5. This is a two-turn conversation: first the agent read the code and summarised it, then /handoff was entered. It is a command you type yourself, so the record shows a slash command rather than a Skill tool call. The handoff document is the agent's own text, written to the system temp folder, unmodified. The only change: the trial machine's temp-folder path was replaced with a generic placeholder.

What it does

Writes a handoff document that summarises what happened in this conversation, so a new agent (or a new session) can continue without starting from scratch.

How it works

  1. You type /handoff, optionally followed by what the next session will be used for, and the document is tailored to that.
  2. It saves the document in your operating system's temporary folder, not in your project.
  3. It does not repeat anything already captured in specs, plans, issues, commits or diffs; it points to them by path or link instead.
  4. It adds a "suggested skills" section naming skills the next agent should load, and redacts keys, passwords and personal data.

Good for

Long sessions you want to continue elsewhere, or passing work to a different agent.

Worth knowing

In our trial it recorded the decisions from a meeting, the exact lines to change, test gaps and open questions.

Notes & risks

Pure instruction files: no scripts and no network access. It is a command you type (/handoff); the agent does not start it on its own. It writes one Markdown file to your operating system's temporary folder (not your project) and runs no scripts. The file is built from your conversation, so check it for anything sensitive before sharing it, even though the skill tells the agent to redact keys, passwords and personal data. The package also contains the original MIT LICENSE and agents/openai.yaml (display name for Codex).