david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Update standup prompt and daily log to enhance clarity and communication guidelines for Apollo removal progress

Browse Source
This commit is contained in:
David Delagneau
2026-04-27 07:43:47 -06:00
parent e5d41c876e
commit e19a10f588
4 changed files with 34 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
prompts/standup.md
View File

@@ -1,17 +1,20 @@
# Standup Prompt
Use `project-knowledge/01-current/current-work.md`, `project-knowledge/01-current/work-items.md`, the detailed files referenced from that active-work summary, `project-knowledge/03-context/project.md`, `project-knowledge/03-context/workstreams/index.md`, `project-knowledge/03-context/process/communication.md`, `project-knowledge/04-people/manager.md`, the previous workday Mattermost context, today's daily note if present, and the latest available Mattermost context.
Use `project-knowledge/01-current/current-work.md`, `project-knowledge/01-current/work-items.md`, the detailed files referenced from that active-work summary, `project-knowledge/03-context/project.md`, `project-knowledge/03-context/workstreams/index.md`, `project-knowledge/03-context/process/communication.md`, `project-knowledge/04-people/manager.md`, the previous workday communication context, today's daily note if present, and the latest available communication context.
Generate a standup update for an iOS engineer working on Fidelity.
Generate a standup update for the active project profile.
## Output contract
- Return exactly three sections in this order: `Yesterday:`, `Today:`, `Blockers:`
- Return Markdown that is ready to copy/paste directly into Mattermost
- Use one top-level bullet per Jira item
- Use the greeting required by the active profile or command. If no greeting is specified, omit the greeting and start with the previous-work section.
- Return the greeting, a previous-work section, and `Today:`
- Include `Blockers:` only when there is a real blocker to report; omit the entire section when there are no blockers
- Use `Yesterday:` only when the previous-work section truly refers to yesterday; otherwise use a truthful label such as `Last workday:` or the weekday/date when clearer
- Return Markdown that is ready to copy/paste directly into the configured team communication tool
- Use one top-level bullet per work item
- Use indented sub-bullets only when they improve clarity
- Prefer one concise sub-bullet when nearby events are part of the same continuous context
- Keep sub-bullets in chronological order within each Jira item
- Keep sub-bullets in chronological order within each work item
- Keep the whole standup concise and ready to send
## Selection rules
@@ -20,8 +23,9 @@ Generate a standup update for an iOS engineer working on Fidelity.
- `Yesterday` must describe work that actually happened on the previous workday, not older status changes that still appear in current memory
- On Mondays, use Friday's work context unless a later prior day has Mattermost activity
- If the previous calendar day has no work activity or is OOO/weekend, use the latest prior day with Mattermost activity
- Treat the previous workday communication context as the primary source for `Yesterday`
- Use current memory to disambiguate, not to backfill unrelated older events
- Treat the previous workday communication context as the primary source for the previous-work section
- If a latest daily log exists, use its `Work Done` and same-day findings as the primary source for `Yesterday`; use current memory only to disambiguate, not to backfill unrelated older events
- Do not reuse older investigation context from `current-work.md` as `Yesterday` unless the latest daily log or previous-workday communication confirms it happened on that workday
- Prefer updates directly tied to active work items over side questions, context refreshes, or manager-only reminders
- Exclude items that are not directly tied to a story unless they are true blockers
- Do not mention stories assigned to a future sprint unless they are a real blocker for today's work
@@ -29,26 +33,26 @@ Generate a standup update for an iOS engineer working on Fidelity.
## Story handling rules
- Mention Jira IDs and approved titles when they are available and clearly tied to the reported work
- Mention work item IDs and approved titles when they are available and clearly tied to the reported work
- Prefer including story titles whenever a reported update maps clearly to a Jira item
- Prefer story-based reporting when the work maps clearly to a Jira item
- If documentation, root-cause analysis, or implementation analysis directly supports a story, group that work under the related story instead of listing it separately
- When one Jira item has multiple concrete updates, keep them under one top-level `JIRA-ID - Title` bullet
- When pairing a Jira ID with a title, prefer `ID - Title` or `ID Title`; do not use commas between them
- When one work item has multiple concrete updates, keep them under one top-level `ID - Title` bullet
- When pairing a work item ID with a title, prefer `ID - Title` or `ID Title`; do not use commas between them
## Writing rules
- Write in natural US English that can be forwarded externally without rewriting
- Write the standup as David's external progress report
- Write the standup as the workspace user's progress report
- Be specific, concise, and evidence-backed
- Avoid vague phrases and generic progress language
- Mention debugging findings only if they materially changed understanding
- Clarify auth-dependent behavior when relevant
- Separate external issues from regressions when that distinction matters
- For standups that may also be sent to Teams, prefer plain outcome language over internal implementation jargon; avoid unexplained terms like `fallback`
- For standups that may also be sent outside the immediate team, prefer plain outcome language over internal implementation jargon; avoid unexplained terms like `fallback`
- If a release or propagation step is waiting on approvals or pipeline work, make the parallel work explicit instead of sounding like the day is blocked on waiting alone
- Do not mention Jeff by name
- Do not mention Mattermost because it is internal-only communication
- Do not mention manager or stakeholder names except in the configured greeting or when the user explicitly asks
- Do not mention internal evidence sources or communication tools unless the user explicitly asks
## Compression rules
@@ -58,22 +62,26 @@ Generate a standup update for an iOS engineer working on Fidelity.
## Anti-patterns to avoid
- Do not report a story as worked yesterday just because it is now `Done`
- Do not report a work item as worked yesterday just because it is now `Done`
- Do not pull old closure events from durable memory into a new standup unless they happened on the previous workday
- Do not mention next-sprint work in `Today` when today's plan is already known and different
- Do not turn context notes into fake progress lines
Format:
<optional configured greeting>
Yesterday:
- PDIAP-#### - Title
- ITEM-#### - Title
- Update 1
- Update 2
Today:
- PDIAP-#### - Title
- ITEM-#### - Title
- Next action 1
- Next action 2
Blockers:
- ...
If there are no blockers, omit `Blockers:` entirely.