| name | fasttrack-timesheet |
| description | Prepare a FastTrack timesheet draft and submit only after screenshot approval. |
| disable-model-invocation | true |
FastTrack Timesheet
Conversational front end for the FastTrack timesheet runbook. This skill turns a
plain request ("fill last week, 9 to 5 Mon to Thu") into the exact structured
input the runbook consumes, runs the fill, and — only on explicit approval after
showing a screenshot — runs the submit. It owns the ASKING and APPROVAL; it does
not reimplement browser mechanics.
Owner of the mechanics (delegate, never copy its contracts): the browser-use
skill and its fasttrack/fill-week + fasttrack/submit runbooks.
Safety gate (fail-closed)
- Never guess the week or the hours. If either is unstated or ambiguous, ask one
question with a sensible default before building the input.
- Before the first live fill, explain that it changes a portal draft but does
not submit, summarize the week, hours, and defaults, then obtain explicit
confirmation. A draft remains editable before submission; it is not
read-only.
- Never submit without BOTH: a screenshot of the filled timesheet shown to the
user, AND the user's explicit approval after seeing it. Treat submit as an
externally consequential action.
- Never fill or submit a week the user did not name. The runbook's own week-guard
refuses a wrong-week grid — do not try to bypass it.
- Submit only when the user says to. If they say "not yet" / "only draft", stop
after fill and report the draft state.
- The submit reviewed action must be promoted (Touch ID) before a live submit; if
it is unpromoted, stop and tell the user to promote it — never work around the
gate.
Gather (ask only what is missing)
Collect, in order, using defaults; ask one question per genuinely missing/ambiguous item:
- Week — the Mon–Sun the timesheet covers. "this week" / "last week" resolve
from today's date. Default: the current week.
- Work days + hours — per day start/end. Default: Mon–Fri 09:00–17:00.
- Breaks — default: one 12:00–13:00 lunch (confirm if it matters to the total).
- Attendance type — default: "Standard".
- Account / final action — default account "self"; final action "human-submit"
(fill draft, human submits) unless the user asks to submit now.
State the assumed defaults you used; do not silently invent non-default values.
Build the input
Write the timesheet_run input file the fill action reads. Its exact shape is
owned by the runbook input schema — read it live (browser-use runbook schema /
the fill-week runbook's declared inputs), do not restate fields here (they drift).
Write the file under the runtime private-input root as an owner-only file. Compute
dates from the named week; map "9 to 5" → 09:00/17:00. If unsure of the shape,
copy the structure of the last committed timesheet_run.json example.
Run card
Delegate the mechanics to the browser-use skill — it owns the exact runbook run command, the prerequisites (an ACTIVATED generation, the approval-broker env
for the Touch ID identity gate), and the connection. Read its run card; do not
restate the command here (it drifts). The service/flow is fasttrack /
fill-week, input timesheet_run=<abs path>.
The run reaches a Touch ID identity gate — tell the user to tap. On success the
timesheet grid fills (draft). Report what was filled (days + hours + total).
If the run fails on a prerequisite (broker env unset, catalog not activated, no
admissible tab), STOP and route the fix to the browser-use skill — do not work
around activation or the presence gate.
Submit (only on explicit approval)
Owned by the browser-use fasttrack/submit runbook + its run approve surface.
- The submit run halts at an
awaiting-approval gate and surfaces an
adapter-agnostic screenshot artifact of the filled timesheet.
- Present that screenshot to the user and ask for explicit approval to submit.
- Only if approved: complete the approval continuation (per the
browser-use
run card) and let the submit run.
- Never approve on the user's behalf. "Looks good" without a clear go is not a go
for an irreversible submit — confirm.
Owner of the submit action, approval gate, run approve, and screenshot artifact:
the browser-use fasttrack/submit runbook. Read its run card for the exact
approve/continuation commands; do not duplicate them here.
Verify
- After fill: confirm the reported days/hours match what the user asked; if the
run ended
unknown, say so — do not claim a fill that was not confirmed.
- After submit: confirm the run reports a submitted state before telling the user
it is submitted.
First safe action
Resolve the target week from the user's words + today's date, list the defaults
you will assume, ask one question only if the week or hours are missing/ambiguous,
then build the input and run the fill card. Do not submit in the same step as fill.
