fs-daily-report

---
name: fs-daily-report
description: Drafts a non-technical daily work report from your latest Git commits (GitHub CLI, GitHub MCP, or GitLab MCP) and your active Jira tickets (Atlassian Rovo MCP). Use when the user asks for a daily report, standup update, EOD summary, client update, progress report, or 'what did I do today'. Runs a prerequisite check first, lets the user pick the reference Jira ticket from a picker widget, then emits a fixed-format stakeholder-ready summary with the technical detail translated into business language.
license: MIT
---

# fs-daily-report

Turn raw engineering activity into a report a non-technical stakeholder can read.

Pipeline is strictly ordered. Do not skip or reorder steps.

```
0. HELP        `--help` short-circuits everything — print usage, stop
1. PREFLIGHT   verify Jira MCP + a Git host (gh CLI, GitHub MCP, or GitLab MCP)
2. TICKETS     list user's active Jira tickets → user picks one or more reference tickets
3. COMMITS     pull latest commits via gh CLI, GitHub MCP, or GitLab MCP, matched per ticket
4. TRANSLATE   map technical changes → business outcomes
5. REPORT      emit the canonical report format (never freestyle it)
```

## Usage

```
/fs-daily-report                      # today, auto-detect repo, ask which ticket
/fs-daily-report --help               # print usage and stop (also: help, -h)
/fs-daily-report today                # midnight to now, local time
/fs-daily-report yesterday            # yesterday, full calendar day, local time
/fs-daily-report --since 2026-07-21   # explicit window (ISO date)
/fs-daily-report --since A --until B  # explicit range, both ISO dates
/fs-daily-report --ticket FS-1234     # skip the picker, use this ticket
/fs-daily-report --ticket FS-1234,FS-1198   # skip the picker, use these tickets
/fs-daily-report --repo owner/name    # explicit repo instead of auto-detect
/fs-daily-report --audience client    # tone: client (default) | manager | exec
/fs-daily-report --no-widget          # plain numbered list instead of HTML picker
```

Default window: commits from the last 24 hours. `--since` overrides. `today`/`yesterday`
resolve against the machine's local timezone; state the resolved window in the report header.

Full usage text lives in `references/help-text.md` — keep it, this block, and `README.md`
in sync whenever a flag changes.

---

## Step 0 — HELP (short-circuit)

Triggered by `--help`, `-h`, or a bare `help` as the first argument.

**Print `references/help-text.md` verbatim and stop.** Nothing else runs — no preflight, no
Jira call, no `gh` call. Help must work on a machine with no MCP servers and no `gh` installed,
so a user can discover what the skill needs before setting anything up.

Ignore every other argument when `--help` is present: `/fs-daily-report yesterday --help`
prints help and exits. Do not draft a report "as well".

An unrecognized flag is not a help request — say which flag was unrecognized, print the
`references/help-text.md` options table, and stop without running the pipeline.

---

## Step 1 — PREFLIGHT (mandatory, runs before any other tooling)

**Never call a Jira tool, `gh`, or a GitHub/GitLab tool before this check passes.**

Requirements:

| Requirement | Accepted |
| --- | --- |
| Jira (required) | Atlassian Rovo MCP |
| Git host (required, any one) | **GitHub CLI (`gh`), authenticated** — or GitHub MCP — or GitLab MCP |

GitHub is preferred through the `gh` CLI, which carries its own auth. An
installed-but-unauthenticated `gh` does not fill the slot by itself — fall through to GitHub MCP,
then GitLab MCP, and only fail preflight if none of the three is usable.

**Jira** — detect in this order, stopping at the first conclusive result:

1. **Own tool list** — scan the tools available this session for `atlassian`, `rovo`, or `jira`
   in the name. If tool schemas are deferred/lazy-loaded, search for them by name before
   concluding they are absent.
2. `claude mcp list` — non-zero exit or unknown command → fall through.
3. **Config files** — `./.mcp.json`, `~/.claude.json`, `~/.claude/settings.json`,
   `~/.codeium/windsurf/mcp_config.json`,
   `~/Library/Application Support/Claude/claude_desktop_config.json`,
   `~/.cursor/mcp.json`, `~/.config/Code/User/mcp.json` — inspect `mcpServers` keys.

**Git host** — try in order, stop at the first usable one:

1. `gh auth status` — exit 0 means installed **and** authenticated; slot filled.
   Exit 1 with "not logged into any GitHub hosts" → installed, unauthenticated.
   `command not found` → not installed.
2. No usable `gh` → look for a **GitHub MCP** server using the same three-tier detection as Jira
   (`github` in the tool name, e.g. `mcp__github__list_commits`). The slot needs commit listing
   at minimum.
3. Still nothing → look for a **GitLab MCP** server the same way (`gitlab` in the tool name).

`scripts/check-prereqs.sh` runs all of the above and prints a verdict. Prefer it when Bash is
available.

**Outcomes**

- Both requirements satisfied → state one line confirming what was found, then continue to Step 2.
- Anything missing → **stop**. Print the gap and the exact install commands from
  `references/preflight.md`. Do not attempt a partial report, do not fabricate commits or
  ticket data, do not fall back to plain `git log` against the local clone.
- Present but unauthenticated (`gh` exit 1 **with no MCP fallback available**, or a
  Jira/GitHub/GitLab MCP call returning 401/403/`authenticate`) → surface the auth step, then
  stop. Auth is the user's action, not yours.

---

## Step 2 — TICKETS (pick the reference ticket(s))

Skip entirely if `--ticket` was supplied; validate each key (split on comma) with
`getJiraIssue` instead.

1. Resolve the current user: `atlassianUserInfo`, then `getAccessibleAtlassianResources`
   for the cloud id.
2. List active tickets assigned to the user via JQL:

```jql
assignee = currentUser() AND statusCategory != Done ORDER BY updated DESC
```

Cap at 10. If empty, retry once widening to recent activity:

```jql
assignee = currentUser() AND updated >= -7d ORDER BY updated DESC
```

Still empty → tell the user, ask for a ticket key, stop.

3. Present the picker, multi-select on. See `references/ticket-picker.md` for the full contract.
   - Rich path: render `assets/ticket-picker.html` (populate the `TICKETS` array) as an
     artifact/widget, then confirm the choice(s) with the question tool.
   - Native path: the question tool with multi-select — top 3 tickets by `updated`, plus a
     **"Show more tickets"** option that pages through the rest in groups of 3.
   - Plain path (`--no-widget`, or no widget/question tool): numbered markdown list, ask
     the user to reply with one or more numbers.
   - Each option label: `KEY — short title`. Description line: `Status · Type · updated Nth`.
   - Require at least one selection; re-ask once on empty submit.

4. Fetch full detail for each chosen ticket: summary, description, status, issue type,
   priority, sprint, due date, and the last 5 comments.

**Every selected ticket anchors the report** — each gets at least one bullet under "What I did
today" (or a plain "no code landed" line if the window was empty for it), in pick order.
Commits that clearly belong to a ticket the user did *not* pick are not merged into a picked
ticket's bullet — call them out separately, tagged with their own key.

---

## Step 3 — COMMITS (latest activity from the Git host)

Full command reference: `references/github-cli.md` (GitHub CLI), or the GitHub / GitLab MCP tools.

Use whichever source preflight selected. On GitHub MCP, the steps below are identical — the
tool calls replace the `gh` commands (`list_commits`, `get_commit`, `list_pull_requests`,
`search_repositories`, `get_me`), and every rule in this step still applies.

1. Resolve the repo:
   - `--repo` if given.
   - Else, inside a clone: `gh repo view --json nameWithOwner -q .nameWithOwner`, or read the
     `origin` remote when only MCP is available.
   - Else, repos the user pushed to recently:
     `gh search commits --author=@me --sort=committer-date --limit=20 --json repository`, or the
     MCP equivalent search.
   - Ambiguous → ask, using the same picker pattern as Step 2.
2. Resolve the author identity — the Git host user, not the Jira account:
   `gh api user -q .login`, or the MCP `get_me`.
3. Pull commits in the window on the default branch **and** any branch whose name contains
   one of the chosen ticket keys. Include per-commit: short sha, message, timestamp, files
   changed, insertions/deletions. Tag each commit with the ticket key(s) it belongs to
   (message reference or branch name) so Step 5 can attribute it to the right ticket's bullet;
   untagged commits on the default branch are attributed to context, not a specific ticket.
4. Also collect open/merged PRs (or MRs) referencing any chosen ticket key, plus their
   review state.
5. Zero commits in the window for a ticket → do not stop. Report that ticket's Jira-side
   progress and say plainly that no code landed for it in the window; other selected tickets
   still report normally.

Git host rules:

- Always `--json` (or `gh api ... -q`) — never parse human-formatted `gh` output.
- Read-only only. No `gh pr create`, `gh pr merge`, `gh release`, `gh api -X POST`; on MCP, no
  create/update/merge/delete tools — read tools exclusively.
- Commit list responses omit line counts; fetch stats per commit only for the commits you
  actually need to translate into a bullet, capped at 10.
- A Git-host failure is reported, not worked around. Do not fall back from `gh` to MCP (or the
  reverse) mid-run to paper over an error, and never substitute local `git log` — the local
  clone may be stale or on an unrelated branch.

Only read diffs when a commit message is too thin to translate. Prefer file paths and message
bodies; they are cheaper and usually enough.

---

## Step 4 — TRANSLATE (technical → business)

Apply `references/translation-rules.md`. Non-negotiables:

- **No jargon anywhere in the report.** No shas, branch names, file paths, function names,
  library names, or tool names — there is no technical-detail footer to exile them to.
- **Outcome over mechanics.** Not "refactored `AuthGuard` to use middleware" but
  "tightened the login checks so expired sessions can no longer slip through".
- **Group by user-visible capability**, not by commit. Twelve commits on one feature are
  one bullet.
- **Ticket first, commits second.** Each Jira ticket sets what its slice of work *is for*;
  its matched commits supply evidence of progress. Never blend two tickets' work into one
  "What I did today" bullet, even if the underlying commits touched the same files.
- **Never invent progress.** No commit and no Jira movement means "no change to report" —
  say it.
- **Percentages only if Jira has them.** Otherwise use the status words in the reference file.
- Tone shifts by `--audience` but the section structure never changes.

---

## Step 5 — REPORT (fixed output)

Emit `references/report-template.md` exactly — the company's standard three-section format
(`What I did today` / `What I will be doing the next working day` / `Roadblocks & Support
Needed`), same headings, same order, every time. All three headings always print; "Roadblocks
& Support Needed" gets the literal body `None.` when there are none — never omit the heading.
Consistency is the product; a stakeholder reading two reports a week apart must see the same
shape.

After printing, offer follow-ups in one line: post as a Jira comment on each ticket, copy for
Slack/email, or re-run for different tickets. Do not write to Jira without explicit
confirmation.

---

## Reference files

| File | Read when |
| --- | --- |
| `references/help-text.md` | Step 0 — the verbatim `--help` output |
| `references/preflight.md` | Step 1 — detection details, install commands, error text |
| `references/ticket-picker.md` | Step 2 — picker contract for all three paths |
| `references/github-cli.md` | Step 3 on GitHub — exact `gh` commands, jq filters, MCP tool equivalents |
| `references/translation-rules.md` | Step 4 — jargon→plain mapping, status vocabulary |
| `references/report-template.md` | Step 5 — canonical report format, worked example |
| `assets/ticket-picker.html` | Step 2 rich path — widget markup |
| `scripts/check-prereqs.sh` | Step 1 — scripted preflight |

## Hard rules

0. `--help` short-circuits before preflight and must work with nothing installed.
1. Preflight before any external tool call. No other exceptions.
2. Missing prerequisite → stop with install instructions. Never degrade silently, and never
   fall back to local `git log`.
3. Never fabricate commits, tickets, statuses, or dates. Missing data is stated as missing.
4. Report stays non-technical throughout — no shas, branch names, file paths, or tool names
   anywhere in it; the only identifiers allowed are Jira ticket keys.
5. No writes to Jira or the Git host without explicit user confirmation.