-
Run it. Call standup_run (blank session_id targets the most recent
planning session). Leave deliver false — you present the report; only set
deliver: true if the user explicitly asks to send it to their configured
channels (Slack/email/desktop).
-
Present the report. From data: lead with sprint day and the confidence
score + rationale, then the team summary, then per-member updates (yesterday
/ today / blockers style), including each person's General Overview,
ticketing_summary, code_summary, and documentation_summary with their
category-specific links. Surface any warnings (e.g. a tracker returned
401) — they explain missing sections.
Each member may also carry practices: deterministic engineering-practice
signals (work that landed with no ticket behind it, a board not updated after
a merge, too many tickets held in progress, an oversized PR, commits with no
PR, thin commit messages). Present them as observations, never as
judgements of the person — each carries the evidence it was derived from,
so quote the evidence and keep the framing coaching-shaped. They are computed
by rule, not written by a model, so do not embellish, re-rank, or infer new
ones; a repeat: true signal fired in the previous standup too. The
report-level practice_rollup counts members per rule, not signals.
Before a change is reported as untracked, it is matched against the
description, acceptance criteria and definition of done of every ticket the
team has open — a change that plausibly belongs to one is dropped silently,
and the matched ticket is deliberately never recorded. So an untracked-work
signal already means "we looked for a home for this and found none": do not
soften it with a guess about which ticket it might belong to.
When the user says a signal was wrong, record it with
standup_practice_feedback (member, rule, verdict='down', and a note
capturing their reason in one sentence). That removes it from the stored
report and stops every change behind it from ever being reported for that
rule again — an open pull request would otherwise re-fire the same wrong
nudge at the same person every morning. Use verdict='up' when they confirm
a signal was right. Both feed the matching pass as calibration, which is why
the note is worth writing. applied: false means the verdict was not
recorded — that signal is no longer in the run (already voted on, or
regenerated since), or it predates this feature and carries nothing to
remember. Read the reason back to the user; do not retry.
-
History. For trends or "how have standups been going", call
standup_history and summarize confidence over time.
-
Check a standup against its meeting. When the user has a transcript of
the standup itself — or says the report missed something someone mentioned —
call standup_review. It reads .txt/.md/.vtt/.srt/.json transcripts from
~/.yeaboi/transcripts (or specific files via transcript_paths), checks
what each person said they did against the evidence the report actually had,
and diagnoses each gap. Present the two halves separately, because they need
different actions:
If the user pastes the transcript into the conversation, or you already have
the text from a meeting-notes document, pass it as transcript_text — it is
saved into ~/.yeaboi/transcripts and reviewed like any other file. Do not
ask them to save it somewhere first. Pass standup_date alongside it when
the meeting was not today; for pasted text that date wins outright.
gaps are faults in yeaboi itself (a missing integration, a capability the
collectors lack, a summary that dropped collected evidence). These are
drafted as GitHub issues.config_suggestions are the user's to fix and carry an exact remedy.
They are never filed.
file_issues writes real, public GitHub issues on the yeaboi repository.
Never set it without asking the user first, and show them the gap titles
before you do. The default drafts everything locally so it can be reviewed.
Use standup_gaps to read back past reviews and see which gaps are already
filed, which recurred, and their issue numbers.
standup_gaps also returns nudge — the standups that ran but were never
checked against their meeting. When nudge.level is set, say which dates went
unchecked and offer to review a transcript for them. When it is "escalated",
the team has gone many standups without one: offer to turn the feature off
(transcript_review_enabled: false) rather than asking again.
-
Configuration. To view or change the standup setup (time, weekdays,
delivery channels, member aliases, user name, tracker sources, and selected
team), use standup_config_get / standup_config_set. Call
standup_members first to preview candidates from Jira, Azure DevOps, or
both, and standup_repositories to discover GitHub repository/Azure project choices.
Save an explicit code_sources, github_owners, github_repositories,
github_excluded_repositories, and azdo_projects scope; a GitHub owner
dynamically covers every active repository inside it (same as an Azure
project), github_excluded_repositories (owner/repo slugs) opts specific
repos back out of that expansion, and github_repositories pins exact
repos regardless of owner scope. Save documentation_sources as a subset
of confluence/notion; documentation files in selected repositories are
included automatically. The selected roster is authoritative:
unselected authors are excluded from member updates and team totals.
Activity providers and repository/project scans run concurrently with
bounded provider limits; a single final synthesis keeps the four summary
sections consistent.
transcript_dir adds an external folder to the transcript sweep (a Zoom or
Google Meet recordings folder), and transcript_review_enabled turns off the
automatic review that runs before each standup. Both are also settable in the
TUI now, under Standup › Review › "Change my transcript folders…", which
offers the detected recording folders by name — suggest that when the user
would rather point-and-pick than find the path themselves.
Practice detection is on by default: habit_detection is 'on'/'off', and
habit_rules narrows it to a comma-separated subset of untracked-work,
untracked-docs, board-not-updated, wip-sprawl, large-change,
no-pull-request, commit-messages (empty means all of them). An unknown
rule id is rejected rather than ignored. habit_ai_match ('on'/'off')
controls the LLM pass that excuses a change belonging to a ticket it never
names; it can only ever suppress a signal, never raise one.
Installing the OS schedule that fires it daily is done from the yeaboi TUI.
That wizard also offers a transcript reminder — a second scheduled job that
posts a desktop notification 30 minutes to 2 hours after the standup, only
when standups have actually gone unchecked. Point the user at it when they
say they keep forgetting to save the recording.
