feat: Obsidian integration via cli scripts
This commit is contained in:
@@ -13,10 +13,14 @@ Behavior rules:
|
||||
- Treat `core/` as the reusable project-independent operating model.
|
||||
- Treat `profiles/fidelity/profile.md` as the active Fidelity project profile.
|
||||
- Treat `vault/` as the canonical clean knowledge base for humans and AI.
|
||||
- Treat `scripts/memory/` as the project-agnostic access layer for note creation, vault search, Base queries, and health checks.
|
||||
- Treat `scripts/obsidian/` as the current Obsidian adapter. Do not couple durable memory rules to Obsidian-specific behavior.
|
||||
- Treat `ai/inbox/` and generated connector files as raw evidence only, not promoted memory.
|
||||
- Keep Obsidian Bases clean: do not let templates in `vault/09-templates/` appear as real daily notes, work items, people, decisions, systems, or workstreams.
|
||||
- Role mapping notes such as `vault/04-people/manager.md` are `type: role-map`; actual people profiles are `type: person`.
|
||||
- When editing canonical vault notes, update useful metadata at the same time: `updated`, `systems`, `workstreams`, `people`, `related`, `focus`, `work-items`, and `blockers` when applicable.
|
||||
- When creating a new typed note, prefer `bash scripts/memory/memory.sh create <type> <slug> [title]`, then inspect and refine the generated Markdown.
|
||||
- When checking vault quality, use `bash scripts/memory/memory.sh health` and direct file inspection.
|
||||
- Work item notes should preserve Jira ID/title and explicit relationships so standups, Bases, and graph navigation stay useful.
|
||||
- Daily notes should include `focus`, `work-items`, and `blockers` when those values are clear.
|
||||
- Before answering a prompt that depends on current state, verify the latest relevant files instead of relying only on conversation history.
|
||||
@@ -44,6 +48,7 @@ Behavior rules:
|
||||
- Update preexisting memory when a new prompt clarifies or corrects something already stored.
|
||||
- Do not wait for a dedicated sync command if the correct memory update is already obvious.
|
||||
- Do not leave behavior-only corrections only in daily logs. If a correction should affect future output, update the tool or instruction that produces that output.
|
||||
- If the memory interface or Obsidian adapter fails, continue with direct Markdown operations when safe and do not promote the failure as project memory.
|
||||
- Do not over-promote uncertain information. Keep uncertain items in the daily log.
|
||||
- When drafting communication, preserve technical meaning and improve clarity in natural US English.
|
||||
- When answering Swift/iOS programming questions, use the project-local iOS skills and `vault/03-context/ios/`.
|
||||
|
||||
@@ -13,12 +13,15 @@ Behavior rules:
|
||||
- Load `core/` first for project-independent operating rules.
|
||||
- Load the active profile from `AIW_PROJECT_PROFILE` when available; otherwise use the configured project files in this workspace.
|
||||
- Treat `vault/` as the canonical clean knowledge base.
|
||||
- Treat `scripts/memory/` as the stable memory access layer.
|
||||
- Treat tool-specific integrations such as Obsidian as replaceable adapters.
|
||||
- Treat profile files as configuration and `ai/inbox/` plus generated connector files as raw evidence.
|
||||
- Keep Obsidian Bases clean by excluding templates and typing role maps separately from people.
|
||||
- When updating canonical vault notes, maintain relationship metadata and `updated` fields so the vault remains useful to both humans and agents.
|
||||
- Before answering current-state questions, inspect current state, active work items, recent logs, and inbox evidence when available.
|
||||
- For any meaningful prompt, decide whether it adds, corrects, or invalidates memory.
|
||||
- Update the smallest correct canonical file when memory should change.
|
||||
- Use the memory interface to create new typed notes and inspect vault health, then edit Markdown directly for precise curation.
|
||||
- If the user corrects recurring behavior, update the command, prompt, agent, skill, vault process note, or other control file that enforces that behavior.
|
||||
- Keep imported evidence separate from promoted memory.
|
||||
- If an integration or sync command fails, do not update project memory from that failure.
|
||||
|
||||
Reference in New Issue
Block a user