enhance(daily): richer report content + progressive delivery (streaming-edit or batched)

[eanzhao]

Summary

Day-one enhancement plan for /daily. The current report is functional after #421 closed the GitHub-403 root cause, but the content is thin and the delivery is one-shot — the user gets a single Lark message after the agent finishes, with no progress indication and no per-source breakdown. Two related areas to fix:

1. Content depth — the skill prompt at agents/Aevatar.GAgents.ChannelRuntime/AgentBuilderTemplates.cs:48-64 only suggests three GitHub queries (commits authored, issues authored, issues commented) and asks for "3-6 concise bullet points + one blocker line". This produces something like a TL;DR, not a daily.
2. Delivery UX — SkillRunnerGAgent.SendOutputAsync (agents/Aevatar.GAgents.ChannelRuntime/SkillRunnerGAgent.cs:254-300) sends the entire LLM output in one POST /open-apis/im/v1/messages call. There is no streaming-edit equivalent of normal chat (ChannelLlmReplyInboxRuntime → TurnStreamingReplySink → /channel-relay/reply/update). The user sees nothing for ~30s, then a wall of text.

Why current streaming doesn't transfer to SkillRunner

TurnStreamingReplySink works against the reply token baked into the inbound webhook payload — that token has a ~14-minute TTL and is bound to one specific user-initiated turn. Scheduled SkillRunner runs (the daily 9am cron, the manual /run-agent, retries) don't have a reply token; they're ambient. Trying to reuse /channel-relay/reply/update would land as reply_token_missing_or_expired.

The closest equivalent for SkillRunner is edit-own-message via Lark's PATCH /open-apis/im/v1/messages/{message_id} (text and card update endpoints already exist — the channel-runtime adapter uses them today for chat streaming). That gives SkillRunner the same "watch the message grow" UX without depending on a reply-token grant.

Proposed scope

A. Content depth (skill prompt + suggested data sources)

Rewrite TryBuildDailyReportSpec so the daily covers more surface area, with explicit structured sections and a length budget per section. Treat the new prompt as a specification of what to fetch + how to summarize, not a freeform creative brief.

Suggested sections (each with a hard ≤N-line budget, omitted entirely if empty rather than padded):

• Shipped — PRs merged in last 24h (title + repo + #PR), commits to default branch
• In flight — open PRs authored, with stale-flag (>24h since last activity)
• Reviews — PRs reviewed (approve/request-changes/comment counts), review comments left
• Issues — issues opened, closed, commented on
• CI status — recent failing builds on default branch (if any)
• Trend vs yesterday — comparing today's counts against the prior 24h window
• Blockers — auto-detected: PRs >24h waiting for review, CI red >2h, GitHub blocked/needs-info labels

GitHub queries to suggest (replacing the current 3):

GET /search/issues?q=author:{u}+is:pr+is:merged+merged:>={iso}      # shipped PRs
GET /search/issues?q=author:{u}+is:pr+is:open                       # in flight
GET /search/issues?q=reviewed-by:{u}+updated:>={iso}                # reviews
GET /search/issues?q=author:{u}+is:issue+created:>={iso}            # issues opened
GET /search/issues?q=author:{u}+is:issue+is:closed+closed:>={iso}   # issues closed
GET /repos/{owner}/{repo}/actions/runs?branch=main&per_page=10      # CI on each tracked repo

When the user provides repositories=…, the prompt must instruct the LLM to make these calls once per repo rather than collapsing into a global search — the global /search/* endpoints don't filter to a repo allowlist cleanly.

Future scope (out for the first cut, but the prompt should leave room for):

• Calendar provider via NyxID (api-google-calendar?) — meetings attended/upcoming
• Notion / Linear / Jira if the user has them connected — pages edited, tickets moved
• Slack/Lark message highlights via NyxID-bridge

B. Progressive delivery

Two real options, both implementable in this codebase:

Option 1 — batched (cheap, ships fast)
SkillRunner sends one Lark message per section as it produces them. Implementation: change SendOutputAsync to consume multiple outputs from the LLM turn (LLM emits a structured envelope: {section_id, header, body} per tool_call boundary, or use stop-sequence sectioning). For each section, send a fresh POST /im/v1/messages.

Pros: simplest. Pros: each section is an atomic artifact in the chat history.
Cons: chat clutter; user sees N notifications.

Option 2 — streaming-edit (richer UX, more work)
SkillRunner sends an initial placeholder Lark message and progressively edits it via PATCH /open-apis/im/v1/messages/{message_id}. Reuses the same TurnStreamingReplySink pattern but bound to the freshly-sent message_id instead of a reply token.

Concrete steps:

1. New SkillRunnerStreamingReplySink in agents/Aevatar.GAgents.ChannelRuntime/ modeled after TurnStreamingReplySink but driven by NyxIdApiClient.UpdateChannelRelayTextReplyAsync-equivalent calls against s/api-lark-bot/open-apis/im/v1/messages/{id} (existing edit endpoint, already wrapped by ChannelConversationTurnRunner for normal chat — confirm it works without reply token).
2. SkillRunnerGAgent.HandleTriggerAsync plumbs the sink through to LLMService so the OnDelta callbacks land on edit-the-message instead of buffer-and-send-once.
3. Throttle edits the same way TurnStreamingReplySink does (Lark has its own rate limit on edits, default 5 edits/sec; the existing throttle is conservative enough).
4. FinalizeAsync does one final edit with the complete text — same shape as the existing sink.

Pros: matches normal chat UX (one message that grows). Pros: no chat clutter.
Cons: more code; need to verify Lark message-edit doesn't have a "max edits" limit per message (rate limit yes, total count probably unlimited for text but worth confirming for cards).

Recommendation: ship Option 2. The infrastructure for edit-message is already in NyxIdApiClient (used by normal chat streaming), and the UX is what users actually expect when they trigger a multi-source report. Option 1 is a fallback if something blocks Option 2 mid-implementation.

C. Cross-cutting / safety net

• Failure-notification path is currently broken under cross-tenant Lark setups (SkillRunnerGAgent:407 TrySendFailureAsync goes through the same s/api-lark-bot proxy that just rejected with 99992364, so the user never sees the failure either). Either reuse the inbound-webhook reply token for failure notification when it's still in TTL, or store a recent-channel-bot fallback.
• Content boundary — the LLM should not invent activity when sources are empty. Current prompt says "say so plainly", but with 7+ sections it's tempting for the model to pad. Add a per-section "if zero results, omit the section entirely; if everything is empty, send 'No measurable activity in the last 24h.'" instruction.
• Length cap — Lark text messages have a body size limit (around 30KB). With richer content + multi-repo + multi-source, we can blow past it. Implement chunked delivery for the text path (split on section boundaries, send N messages) before any of the above ships, or route through cards (which have their own block-count limit but no body limit).

Acceptance

• Daily prompt rewritten with structured sections, repo-aware query suggestions, and "omit empty sections" guidance
• At least one of Option 1 or Option 2 lands; Option 2 preferred
• Failure-notification path no longer dies silently when outbound proxy 4xx's
• A new test under AgentBuilderToolTests (or a new file) pins the structured prompt's "omit empty section" instruction so future copy edits don't regress it
• Smoke test on a real GitHub user where commits authored is empty but PRs reviewed is non-empty — the report skips the Shipped section and renders Reviews

Out of scope for this issue

• Calendar / Notion / Linear / Jira integrations (need NyxID provider work upstream)
• Multi-language daily reports
• Per-user customization (which sections to include, length preferences) — would belong on the agent config, not the template

Related

• SkillRunner daily_report GitHub proxy 403s at runtime #411 — original /daily runtime failure (closed by fix(nyxid-proxy): inject default User-Agent so GitHub doesn't 403 #421)
• fix(nyxid-proxy): inject default User-Agent so GitHub doesn't 403 #421 — User-Agent fix that makes daily actually return GitHub data
• proxy: inject default User-Agent so GitHub-style "UA-required" services don't 403 silently ChronoAIProject/NyxID#514 — proxy default User-Agent (upstream)

[eanzhao]

Reference: chrono-ai-ceo /daily skill

The user has a battle-tested 567-line /daily skill at ~/Code/chrono-ai-ceo/.claude/skills/daily/SKILL.md that covers what a real founder/team daily looks like. Capturing the deltas here so this issue's "content depth" section has concrete grounding rather than my rough sketch.

What that skill does

Step	Mechanism	Sources
0. Role detect	gh api user --jq .login → founder (loning) vs team mode	gh CLI
0.5. Leave scan (founder)	POST /open-apis/attendance/v1/user_approvals/query	Lark attendance API
1. Per-person activity	2 GitHub /search/* calls per member from team.yaml	GitHub search API
2. Board scan	gh project item-list 3 --owner ChronoAIProject + 23 --owner aevatarAI	GitHub Projects v2
2.5. Outreach (founder)	cross-org repo activity + Marketing commits + NyxID traffic	GitHub + repo traffic
3. Critical path	Filter board items by blocker label	Projects v2
3.5. Reconcile (founder)	Detect issue-state↔board-status drift, auto-sync via GraphQL mutation	GraphQL updateProjectV2ItemFieldValue
4. Output	Multi-section structured: roadmap / team activity / blockers / Aevatar pipeline / outreach / decisions / next steps	—

Plus: configuration-driven (team.yaml, strategy/goals.md, repos.yaml, products/*.md), bilingual (中文 output), and a self-curated "Lessons Learned" section that captures field discoveries (e.g. "GitHub Projects doesn't auto-sync issue-close to board-Done — never trust the board as sole truth").

Mapping to Aevatar's /daily ambition

Aevatar's /daily is for an individual end-user, not a CEO running a multi-person org, so it shouldn't 1:1 clone team-wide scans. But the structural patterns transfer cleanly:

chrono-ai-ceo pattern	Aevatar adaptation	Status / dependency
Multi-step skill workflow	SkillRunner needs to support N-stage execution beyond single LLM turn	Architecture work
Multiple structured sections w/ length budget + omit-if-empty	Just rewrite the prompt	Easy — first PR
Role-/scope-based output	Per-agent config: mode: personal|team|org	Schema work on agent config
GitHub Projects v2 integration	New nyxid_proxy tool calls against api-github-projects user-service	Need NyxID provider for Projects v2
Reconcile (issue↔board drift)	Same as above, plus GitHub GraphQL mutation support	Needs read-write GitHub OAuth scope
Lark attendance API	New NyxID provider api-lark-attendance (or surface via existing api-lark-bot?)	Lark API permissions
Lessons Learned self-evolution	Persist agent-level memory; LLM appends learnings on each run	Memory store work (UserMemoryStore-adjacent)

Proposed implementation gradient

Refining this issue's scope into three tranches so we can ship value early without blocking on every dependency:

Tier 1 — content rewrite only (matches the "A. Content depth" section of this issue; ship-first PR)

• Rewrite TryBuildDailyReportSpec prompt with 7 structured sections (Shipped, In flight, Reviews, Issues, CI, Trend, Blockers)
• Add per-section length budget, omit-if-empty rule, repo-scoped query suggestions
• All within current Aevatar SkillRunner capabilities (single LLM turn + GitHub tool calls)
• No new providers, no architecture changes. Already concrete; tests pinnable.

Tier 2 — delivery UX (matches "B. Progressive delivery"; second PR)

• Streaming-edit via PATCH /im/v1/messages/{id} (preferred), or batched multi-message fallback
• Failure-notification fallback to inbound-channel-bot reply token (covers cross-tenant case in §C)

Tier 3 — broader integrations (matches "future scope"; opens follow-up issues)

• GitHub Projects v2 read (NyxID provider)
• GitHub Projects v2 write (reconcile mutation; needs OAuth scope review)
• Lark attendance API (only if Aevatar /daily ever wants team-mode; probably not for individual users)
• Per-agent memory for "Lessons Learned" persistence

Tier 1+2 deliver "the daily that doesn't look like a TL;DR" without needing any new provider or NyxID work. Tier 3 is only justified if/when Aevatar /daily extends to team scope.

One concrete refinement to the §A prompt

The chrono-ai-ceo skill enforces specific behaviors that read like load-bearing rules; we should bake the same into the Aevatar prompt:

• "如果 X 状态，跳过 X step" (don't burn API calls on known-skip cases like leave/holiday)
• Rate-limit awareness: GitHub search is 30 req/min — this prompt only suggests 6 calls but if we add per-repo CI scans we need to cap or batch
• No invention rule: "If sources are empty, say so plainly instead of inventing progress" — the Aevatar prompt has this; keep it but strengthen per-section
• Length cap is implicit in chrono-ai-ceo via "一屏能看完"; for Aevatar it should be explicit (Lark text limit ~30KB; cards have block count limits)

I'll keep this issue as the umbrella tracking item and split tiers into separate PRs. Tier 1 is straightforward enough that I can pick it up next if no one else has cycles.