feat: Update behavior rules and documentation for workspace maintenance and flow references
This commit is contained in:
@@ -69,6 +69,7 @@ When drafting messages for a manager or stakeholder:
|
||||
- If the user asks for the latest/last/recent Mattermost message, the latest message from Jeff/current manager, or what someone just said, synchronize Mattermost first and then answer from the refreshed inbox
|
||||
- If automatic refresh is uncertain, use the explicit latest-message flow: run the Mattermost sync command, then answer from refreshed output only
|
||||
- Treat all meaningful user prompts as potential memory updates, not only explicit sync commands
|
||||
- Treat meaningful user corrections about workspace behavior as tool-maintenance inputs, not only as notes. If a correction affects a command, prompt, agent, skill, or knowledge rule, update that linked file directly.
|
||||
- If a Mattermost sync or other context-ingestion step fails, do not update `ai/logs/`, `ai/state/`, or stable context files based on that failure
|
||||
- Do not record missing dependencies, failed sync attempts, or missing inbox files as project facts unless the user explicitly asks to track the operational issue
|
||||
- Auto-promote Mattermost content when it is clearly project-relevant, explicit, and high-confidence
|
||||
@@ -81,6 +82,7 @@ When drafting messages for a manager or stakeholder:
|
||||
- Maintain `ai/context/people/` when repeated names, roles, or stakeholder relationships become useful for future sessions
|
||||
- Update existing memory when the new information is a correction, clarification, or refinement of something already stored
|
||||
- Prefer updating stable project context over appending generic operational summaries
|
||||
- Do not leave reusable behavior rules only in daily logs. Promote them to the prompt, command, agent, skill, or process file that controls future behavior.
|
||||
- Do not create daily log entries for tooling activity, sync status, or generic chat noise
|
||||
- For Swift/iOS best-practice answers, distinguish current Apple guidance from project-safe recommendations when Fidelity constraints may change the answer
|
||||
- For Copilot prompts, include only relevant context, tell Copilot what to inspect, and state constraints, non-goals, expected output, and validation
|
||||
@@ -93,6 +95,12 @@ When drafting messages for a manager or stakeholder:
|
||||
- `ai/context/people/index.md` for active roster mapping
|
||||
- `ai/context/people/<person>.md` for person-specific context
|
||||
- `ai/context/decisions/*.md` for confirmed decisions
|
||||
- If the new fact changes how this workspace should operate, update the linked tool surface as well:
|
||||
- `.opencode/commands/*.md` for slash-command behavior
|
||||
- `prompts/*.md` for reusable output templates
|
||||
- `.opencode/agents/*.md` and `ai/AGENTS.md` for default agent behavior
|
||||
- `.opencode/skills/*/SKILL.md` for specialized workflows
|
||||
- `knowledge/*.md` or `ai/context/process/*.md` for durable process rules
|
||||
- Prefer updating stale context over leaving conflicting statements in different files
|
||||
- If context is still uncertain, record it in the daily log rather than promoting it to a stable context file
|
||||
|
||||
|
||||
Reference in New Issue
Block a user