Day 01 · Jira → Telegram

Deadline radar

Every morning at 09:00: what's overdue, what's due today, what lands within three days. Sorted by how much it burns.

Schedule→Jira→Code→Telegram

Post ↗Flip for the build

Deadline radarFront

The problem

A board never tells you something is about to slip. You have to go and look — and on a loud week, looking is the first thing that drops.

Worth knowing

statusCategory, not status. Statuses get renamed and translated; categories don't. One word between a filter that works and one that quietly breaks in six months.

Schedule triggerJQLTelegram Bot API

Day 02 · Notes → Jira

Meeting follow-up

Paste raw notes into a bot. Action items come back as tickets — the uncertain ones arrive flagged, not hidden.

Telegram→Gemini→Split→Jira

Post ↗Flip for the build

Meeting follow-upFront

The extra field

confidence. "Anna will send the wireframes by Wednesday" is a commitment. "Someone should chase legal, probably me" is not. A model that can say not sure beats one forced to pick.

Worth knowing

It doesn't guess dates. A parser for "by Wednesday" breaks on the ninth phrasing — and when it breaks it puts a confident wrong date on a ticket. The field stays empty; the original phrase goes in the description.

Event triggerLLM + JSON schemaSplit OutWrite to Jira

Day 03 · Jira → Sheets → Telegram

Workload snapshot

Every Monday: open and overdue work per person, a flag on anyone over the line, and a row for work nobody owns.

Schedule→Group→Sheets→Telegram

Post ↗Flip for the build

Workload snapshotFront

The sheet isn't the output

It's the thing that outlives it. A board shows now and forgets. One row per person per week becomes the trend the tracker never keeps.

Worth knowing

The code was right and the report was still wrong. One task had two owners; the logic took the first. Every number checked out — the second person simply vanished.

AggregationOAuthPersisted historyThresholds

Day 04 · state between runs

Carryover counter

Not "these four are still open" but "this one is on its third sprint in a row." A status is a fact. A count is an argument.

Read state→Merge→Count→Write back

Post ↗Flip for the build

Carryover counterFront

Three cases

Still open → increment. New → start at one. Now closed → leave the row alone. Overwrite the sheet with current state and every closed task's history evaporates.

Worth knowing

Ran it three times. Still four rows. The write matches on issue key, so a re-run updates instead of appending — the difference between a script and something you can safely re-run.

State between runsIdempotent writesMerge logic

Day 05 · history, not status

Work that keeps coming back

Counts how often each task returned to a status it had already left. Two or more, and it surfaces before the retro does.

Changelog→Count→Filter→Telegram

Post ↗Flip for the build

Work that keeps coming backFront

History, not status

A board tells you where a task is, not that this is the fourth time it's been there. 61 change records across 10 issues, counted by revisits — compared by numeric id, since the log held two languages at once.

Worth knowing

The first run flagged four. Two were me. I'd closed and reopened them while testing. A changelog records what people did to the tracker, not what work happened.

Changelog APIItem mappingDerived metrics

Day 06 · form → Jira

Intake that asks back

Two free-text fields. A thin brief isn't rejected — it comes back with the questions that are actually missing. The answers merge into the original, and only then does a ticket appear.

Brief→Gaps→Questions→Jira

Post ↗Flip for the build

Intake that asks backFront

Two fields, not fifteen

Fifteen required fields don't work — people fill them formally to clear the gate and you get a complete-looking brief that says nothing. So the form asks for free text and the check happens after, in conversation. That only works because the questions come from what's actually missing: a static form can't ask which date in september, it can only demand a date up front.

Worth knowing

The same request came back as design on one run and development on the next. Same input, different answer — not a bug, just what a model does. The type shouldn't be guessed at all, it should be a dropdown the requester picks. And the whole exchange lives inside one execution: close the tab and the draft is gone. That's v2.

Free-text intakeGenerated questionsMerge into brief

Day 07 · Jira → Gmail draft

The email writes itself

Friday 16:00: the week sorted into done, in progress and at risk, then written up as a client update. It lands in drafts. You still press send.

Jira→Buckets→Model→Gmail draft

Post ↗Flip for the build

The email writes itselfFront

Code decides, the model phrases

Done, in progress and at risk are sorted in javascript by status category and due date. The model never gets to choose what counts as at risk — it only turns three lists into a paragraph a client can read.

Worth knowing

A junk task named avavaavavfdr324 went into the letter as a fact. The prompt wasn't broken — a task name is data. So the filter moved into code: anything shorter than two words never reaches the model, and the count of what got dropped comes to me instead.

Bucketing in codeAlways Output DataDraft, not send