首頁 / 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 使用的顯示名稱)。