--- name: task-daily-report type: task description: Morning brief on delivery work, posted as Linear initiative status updates — one per team-mirror initiative (Apps, careerOS, A1, Mr Pritchard) — so the briefs surface in Pulse. Linear connector only; writes only initiative status updates; excludes Pipeline. Self-contained task (no separate skill). --- # task-daily-report Scheduled deployment of the morning brief. This task is **self-contained**: there is no separate `skill-daily-report`, because the behaviour is inherently the scheduled job and has no independent use. (If it ever needs to be invoked outside the schedule, extract a `skill-daily-report` and reduce this file to a loader.) Each morning you post Aled's morning brief on his delivery work as a Linear **initiative status update** — one per team-mirror initiative — so the briefs surface in Pulse. Linear connector only. Follow `convention-linear`: calm, precise, sentence case, British spelling, no exclamation marks, no marketing language. This run **writes** to Linear, but **only** initiative status updates via `save_status_update` (type: initiative). Change nothing else: no issue status, labels, comments, assignments, or project membership. ## Where to post Post **one** status update per initiative, to each of these four **team-mirror** initiatives: - "Apps" - "careerOS" - "A1" - "Mr Pritchard" Do **not** post to the Pipeline initiative, nor to the outcome-initiatives (os.Claude, Luna, app.fitness, a1.MeirionPritchard, a1.assoc-one, a1.Heroes, bot.Trader). Only the four above. Each initiative mirrors its same-named team — read that team's issues and write a brief covering only that team's work. **Resolve each initiative name to its ID first** — one `list_initiatives` call — then call `save_status_update` with the ID, not the name. Posting by name fuzzy-matches the outcome-initiatives (os.Claude, app.fitness, the a1.* set) and returns a 400 invalid_request for the short team-mirror names; the ID is unambiguous. (Observed 2026-06-24: name posts failed for Apps, careerOS and A1; only Mr Pritchard, which has no name clash, succeeded — the ID retry posted all three.) ## Project gate — report only In Progress projects Within each team, report a project **only if its `statusType` is `started` (In Progress)**. Projects in Backlog, Planned, Hold, Completed, or Cancelled are skipped entirely. Apply the gate **before** pulling any issues: one `list_projects` call per team returns each project's status, so a non-started project is dropped without ever calling `list_issues` against it — that is the whole saving, since the per-project `list_issues` calls are the main cost. An In Progress project is by definition active, so it earns a section even in a quiet window; its update simply reads "nothing moved this window". There is no started-but-quiet special-casing and no idle roll-up line — a project either surfaces (started) or it does not. The gate assumes project status is kept honest — it pairs with the project-status lifecycle convention (statuses, transitions, and Relay's ownership of health via the weekly plan pass). A project parked mid-flight belongs in the **Hold** status (planned type), not Backlog and not a label, so it drops out of this gate cleanly while still reading as "started then parked". ## Canon that needs Aled — the os.Claude exception to the project gate The project gate is right for *delivery* work but it hides *canon* work that needs Aled. Canon-improvement intake lives in **Apps / os.Claude**, which is usually not a `started` project, so the gate would drop it — and a deferred `FRICTION:` note has no other way to reach this brief. Yet a canon item the Pulse drain has flagged as needing Aled is exactly a "what needs you" item. So os.Claude gets a **standing exception**: **Regardless of the project gate, always sweep Apps / os.Claude once for the notes the Pulse drain has surfaced to Aled** (`skill-ops-retro`, drain step 5): issues carrying `agent:PUL-5E` that are either - **Blocked + priority Urgent** — the drain's "this needs your decision" signal (a canon elicitation or design call), or - **Blocked** and **blocked-by a ticket assigned to Aled** — a canon change waiting on a prerequisite that is his to clear. Read this with a scoped `list_issues` (team Apps, project os.Claude, `state: Blocked`, `label: PUL-5E` — the agent filter takes the bare value `PUL-5E`; re-check each returned ticket's state name, since a Backlog filter also returns Refinement). Surface the results in the **Apps** initiative update under a dedicated `## os.Claude — canon needs you` heading, one tight line per item: `- ID · title · what it waits on (your decision, or prerequisite APP-xxx).` This is a **read-only** sweep like the rest of the brief — it never changes the notes' state, priority, or assignment (the drain owns those). If the sweep finds nothing, omit the heading. This keeps canon-needing-Aled as visible in the morning brief as delivery-needing-Aled, closing the gap where deferred canon sat invisibly in the queue (decision: Aled, 2026-07-07; pairs with the `skill-ops-retro` surfacing rule). ## Window "Moved" / "closed" = the last 24 hours. Awaiting / your move / blocked / in flight = current state as of now. A Done issue belongs in the Done bucket only if its `completedAt` falls in the window — a recent `updatedAt` from a label change is not a move. ## Body format (Markdown — replicate the established format) Start with `# Morning brief — D Month YYYY` (e.g. `# Morning brief — 24 June 2026`), then one summary sentence of the team's state. Group by project with `## ` headings; under each, use only the `### Your move` / `### Awaiting you` / `### Done` / `### Blocked` / `### In flight` subheadings that have items. One tight line per item: `- ID · title · priority, status/timing note — short why where useful.` For the **Apps** initiative only, append the `## os.Claude — canon needs you` heading (above) after the started-project sections, when the canon sweep found anything. Close with a one-line `Housekeeping:` note only if something structural needs flagging; otherwise omit. No preamble, no sign-off. Buckets: 1. **Your move** — issues assigned to Aled needing a decision or action; flag overdue and due-soon dates; most consequential first. 2. **Awaiting you** — In Review, especially `agent:PR-1SM` or issues carrying a QA write-up; say what awaits his call. 3. **Done** — moved to Done in the last 24h. 4. **Blocked** — Blocked state, or `agent:F0-RGE` stalled over 24h; give the why where a comment says. 5. **In flight** — In Progress under `agent:R3-LAY` / `agent:F0-RGE` / `agent:PR-1SM`; name the role. If nothing moved and nothing needs Aled for a **started** project, still give that project its heading and a one-line "nothing moved this window" note, matching the established daily cadence. If a whole team has no started projects, still post a short initiative update saying so in one line. ## Health Set the `health` field per initiative each run: `onTrack` by default; `atRisk` if there are overdue high-priority items or a blocked item gating an outcome; `offTrack` if a target date is at serious risk. ## Token safety `list_issues` returns full descriptions and can overflow on large teams. The project gate above is the first defence — idle projects are never queried. Then query by state (and team) with modest limits; request only what each bucket needs; if a list is too large, narrow by state rather than raising the limit. Never call `list_issues` with an `assignee` filter and **no** `state` — on a large team it returns every assigned issue with full descriptions and overflows the tool result (observed 2026-06-24: ~99k characters for one team, exceeding the result limit). For the "Your move" bucket, scope to assignee plus `state: Todo`; issues assigned to Aled that are Blocked or In Review already surface through their own state-scoped buckets, so a single Todo-scoped assignee query is enough. The os.Claude canon sweep is likewise state-scoped (`state: Blocked` + `label: PUL-5E`), so it stays small. ## On error If posting to one initiative fails, continue with the others and note the failure in your run output. Do not retry destructively. ## Setup - Deployed as a **Cowork scheduled task** (cloud) via a loader config: the scheduled task contains `Read .claude/skills/task-daily-report/SKILL.md and follow it verbatim.` Daily, ~7–8am. - **Connector:** Linear only. No GitHub, no repo — this task touches no code. - Output: four initiative status updates (not a file).