david.delagneau
dbc1894e27
- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People." - Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views. - Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation. - Updated scripts and prompts to reflect the new project-knowledge directory structure. - Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps. - Ensured all references in workflows and scripts point to the new project-knowledge paths.
49 lines
2.9 KiB
Markdown
49 lines
2.9 KiB
Markdown
# Standup Prompt
|
|
|
|
Use `project-knowledge/01-current/current-work.md`, `project-knowledge/01-current/work-items.md`, the relevant files under `project-knowledge/02-work-items/`, `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.
|
|
|
|
Generate a standup update for an iOS engineer working on Fidelity.
|
|
|
|
Requirements:
|
|
|
|
- Use the most recent context only
|
|
- Be specific about what was worked on during the previous workday, not necessarily the previous calendar day
|
|
- 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
|
|
- Mention debugging findings only if they materially changed understanding
|
|
- Clarify auth-dependent behavior when relevant
|
|
- Mention Jira 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
|
|
- Prefer updates directly tied to active work items over side questions, context refreshes, or manager-only reminders
|
|
- If documentation or root cause updates directly support a story, group that work under the related story instead of reporting it as a separate unrelated item
|
|
- Avoid vague phrases and generic progress language
|
|
- Separate the main issue from unrelated follow-up work unless both are explicitly relevant today
|
|
- Omit standup items that are not directly related to a story unless they are a real blocker
|
|
- Prefer evidence-backed statements over assumptions
|
|
- Write in natural US English that can be forwarded externally without rewriting
|
|
- Write the standup as David's external progress report
|
|
- For standups that will also be sent to Teams, prefer plain outcome language over internal implementation jargon; avoid terms like `fallback` unless they are explained well enough for a broader audience
|
|
- 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
|
|
- Use bullet points for each item
|
|
- When one Jira item has multiple concrete updates, use one top-level Jira bullet and indented markdown sub-bullets instead of repeating the same Jira ID/title multiple times
|
|
- When pairing a Jira ID with a title, prefer `ID - Title` or `ID Title`; do not use commas between them
|
|
- Keep it concise and ready to send
|
|
|
|
Format:
|
|
|
|
Yesterday:
|
|
- PDIAP-#### - Title
|
|
- Update 1
|
|
- Update 2
|
|
|
|
Today:
|
|
- PDIAP-#### - Title
|
|
- Next action 1
|
|
- Next action 2
|
|
|
|
Blockers:
|
|
- ...
|