feat: Add prompt engineering lessons for reusable prompting strategies and standup-specific guidance

agent-memory/README.md

@@ -22,6 +22,7 @@ It is not Fidelity project documentation. Do not transfer this folder as project
 - Define how the agent uses the memory interface and Obsidian adapter.
 - Define how the agent verifies technical claims.
 - Define how the agent updates commands, prompts, skills, and rules when recurring behavior changes.
+- Preserve reusable prompting and output-quality lessons so the agent does not need to rediscover them in later sessions.
 
 ---
 
@@ -32,4 +33,3 @@ It is not Fidelity project documentation. Do not transfer this folder as project
 - `ai/inbox/` and connector `generated/` folders are evidence, not canonical memory.
 - `scripts/memory/` is the project-agnostic interface for reading, searching, creating, querying, and validating project knowledge.
 - `scripts/obsidian/` is the current Obsidian adapter and must not become the core abstraction.
-

agent-memory/workflows/prompt-engineering-lessons.md

@@ -0,0 +1,51 @@
+---
+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 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.
+- `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 `project-knowledge/`.