refactor: update agent sync behavior, improve freshness detection patterns, and add diagnostic troubleshooting script

This commit is contained in:
2026-05-05 07:43:45 -06:00
parent f685ac37dd
commit 63e784cc97
11 changed files with 168 additions and 61 deletions

View File

@@ -27,6 +27,8 @@ Capture reusable prompting lessons so the agent does not need to re-research the
- 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.
@@ -36,6 +38,7 @@ Capture reusable prompting lessons so the agent does not need to re-research the
## 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.