feat: Enhance learning session guidelines to prioritize durable understanding and high-leverage questioning
This commit is contained in:
@@ -38,12 +38,16 @@ The agent should support incremental self-learning sessions.
|
||||
|
||||
When the user asks a question, the agent may answer from existing context, but must not invent missing facts.
|
||||
|
||||
Learning sessions should improve durable project understanding. They are not the same as standup preparation, daily status refresh, or ticket triage unless the user explicitly asks for that.
|
||||
|
||||
The agent should:
|
||||
|
||||
- say what is known from the workspace
|
||||
- say what is unclear or not available
|
||||
- label assumptions and inferences explicitly
|
||||
- ask a concise clarification question when the missing context materially changes the answer
|
||||
- focus clarification questions on architecture, process, ownership, debugging patterns, domain concepts, release mechanics, and decision rules
|
||||
- avoid asking mostly about transient ticket state unless the answer would clarify a durable project rule
|
||||
- learn from user corrections or confirmations by updating the smallest correct canonical file
|
||||
- avoid promoting unconfirmed exploration as durable truth
|
||||
|
||||
@@ -53,9 +57,25 @@ Good learning behavior:
|
||||
- If the answer is partly clear, answer the known part, state the gap, and ask for the missing detail.
|
||||
- If the user corrects the answer, update the stale memory or behavior rule directly.
|
||||
- If the user teaches a reusable workflow preference, update the relevant command, prompt, skill, agent rule, or process note.
|
||||
- If the user asks what the agent wants to clarify, propose 3 to 5 high-leverage questions that would help a senior engineer ramp into the project.
|
||||
|
||||
Do not ask for clarification just to avoid work. Ask only when the missing context is material or when guessing would create misleading memory.
|
||||
|
||||
Avoid low-value learning-session questions such as:
|
||||
|
||||
- whether a specific PR was approved today
|
||||
- whether a ticket moved columns today
|
||||
- what the next standup line should be
|
||||
- temporary sequencing questions that belong in `vault/01-current/` or `vault/06-daily/`
|
||||
|
||||
Prefer high-value questions such as:
|
||||
|
||||
- what determines ownership between SDK, adapter, feature module, app, and backend configuration
|
||||
- how release propagation works across SDK, adapter, consuming app, and validation environment
|
||||
- what invariants define REST vs GraphQL parity
|
||||
- how authenticated and non-authenticated flows differ operationally
|
||||
- what evidence is required before classifying an external issue as a regression
|
||||
|
||||
---
|
||||
|
||||
## What Counts As Memory-Worthy
|
||||
|
||||
@@ -38,6 +38,9 @@ Keep this workspace useful as living memory instead of a pile of disconnected no
|
||||
## Ingestion Rules
|
||||
|
||||
- Treat Mattermost, Slack history, and direct prompts as potential memory sources.
|
||||
- Treat learning sessions as durable-understanding sessions, not status refreshes.
|
||||
- In learning sessions, prioritize architecture, ownership, release mechanics, debugging strategy, domain concepts, and process rules.
|
||||
- Avoid promoting transient ticket status from learning sessions unless it exposes a reusable rule.
|
||||
- Do not promote failed syncs or tooling errors as project facts.
|
||||
- Promote repeated durable patterns from historical archives into stable context when confidence is high.
|
||||
- Keep old status-only details archive-only unless they still change current understanding.
|
||||
|
||||
Reference in New Issue
Block a user