首页 / Skills / 开发提效 / 交接 Handoff
开发提效

交接 Handoff

Matt PocockMITSkill 语言: 英文
协议已核对不含脚本
演示真实运行记录 · claude-opus-5-5 · 2026年10月
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.

它做什么

写一份交接文档,总结这次对话里发生的事,让新的代理(或新的会话)不必从头开始就能继续工作。

工作方式

  1. 输入 /handoff,后面可以写上下一个会话要做什么,文档会据此调整重点。
  2. 文档保存在操作系统的临时目录,而不是你的项目里。
  3. 已经记录在规格、计划、工单、提交或 diff 里的内容不会重复写,只给出路径或链接。
  4. 末尾加一节"建议使用的 skill",列出下一个代理应该加载的 skill,并对密钥、密码和个人信息做脱敏。

适合场景

想换个地方继续的长会话,或把工作交给另一个代理。

需要了解

我们试用时,它记下了会议上的决定、需要改的具体行号、测试缺口和待定问题。

说明与风险

纯指令文件:没有脚本、不联网。 它是需要你手动输入的命令(/handoff),代理不会自己启动。它会在操作系统的临时目录(不是你的项目目录)写入一个 Markdown 文件,不运行脚本。文件内容来自你们的对话,尽管 Skill 要求代理脱敏密钥、密码和个人信息,分享之前仍请自己检查是否有敏感内容。 压缩包里另有原仓库的 MIT 协议文件 LICENSE 和 agents/openai.yaml(供 Codex 使用的显示名)。