52 lines
2.6 KiB
Markdown
52 lines
2.6 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 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/`.
|