david.delagneau
1ad707373a
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
55 lines
3.1 KiB
Markdown
55 lines
3.1 KiB
Markdown
---
|
|
type: agent-workflow
|
|
status: active
|
|
updated: 2026-04-21
|
|
tags:
|
|
- prompting
|
|
- quality
|
|
- standup
|
|
- workflow
|
|
---
|
|
|
|
# Prompt Engineering Lessons
|
|
|
|
## Goal
|
|
|
|
Capture reusable prompting lessons so the agent does not need to re-research the same quality patterns for future prompt and command improvements.
|
|
|
|
---
|
|
|
|
## Stable Lessons
|
|
|
|
- Start with the smallest prompt that solves the measured failure mode, then add constraints only where they fix a real recurring error.
|
|
- Prefer explicit output contracts over vague quality goals.
|
|
- Define completion criteria clearly so the model knows what "done" looks like.
|
|
- Separate sections by purpose: source selection, decision rules, output rules, and anti-patterns.
|
|
- Put high-priority behavioral instructions in the command or prompt that directly controls the output, not in project-facing notes.
|
|
- Use concrete anti-patterns when a recurring failure mode is known; models respond better to explicit "do not do X" guidance than to general advice alone.
|
|
- Prefer source-bound selection rules when stale or overly broad context can pollute the answer.
|
|
- If a task depends on chronology, state chronology explicitly as an output rule.
|
|
- If a task depends on dates, inject an explicit temporal context block near the top of the command: current timestamp, today, calendar yesterday, and the default previous workday. Do not rely on the model to infer this from session history.
|
|
- Delegate date arithmetic to code or shell commands and feed the result back to the model as data.
|
|
- If concision matters, define how to compress: what should be merged, what should remain split, and what should be omitted.
|
|
- If the output is meant to be sent directly, make "copy/paste ready" part of the contract.
|
|
- Avoid mixing task logic with human-facing project documentation; reusable prompting logic belongs in prompts, commands, skills, or agent memory.
|
|
|
|
---
|
|
|
|
## Standup-Specific Lessons
|
|
|
|
- The model should not infer "worked yesterday" from durable status alone.
|
|
- The standup command should anchor `today`, `yesterday`, and `previous workday` with absolute dates before reading logs or Mattermost evidence.
|
|
- `Yesterday` should be tied to previous-workday evidence first, then disambiguated with current memory.
|
|
- Only active work items should be expanded by default; avoid loading every ticket note when generating short status output.
|
|
- Future-sprint work should be excluded from `Today` unless it is a real blocker or the user explicitly wants forward-looking planning.
|
|
- Chronological ordering inside a Jira item reduces awkward or misleading summaries.
|
|
- Closely related events should usually be compressed into one concise sub-bullet when they belong to the same continuous investigation.
|
|
|
|
---
|
|
|
|
## Quality Loop
|
|
|
|
- Treat prompt improvement as eval-driven iteration: identify the exact bad output pattern, add the smallest correction, and check whether it fixes the failure without bloating the prompt.
|
|
- When a correction is about workspace behavior, update the controlling prompt or command immediately so the next run benefits.
|
|
- Keep project memory clean while improving prompt quality; do not store agent heuristics in `workspaces/fidelity/project-knowledge/`.
|