Add project-knowledge structure and templates
- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People." - Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views. - Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation. - Updated scripts and prompts to reflect the new project-knowledge directory structure. - Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps. - Ensured all references in workflows and scripts point to the new project-knowledge paths.
This commit is contained in:
77
agent-memory/workflows/ai-to-ai-prompting.md
Normal file
77
agent-memory/workflows/ai-to-ai-prompting.md
Normal file
@@ -0,0 +1,77 @@
|
||||
---
|
||||
type: agent-workflow
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- process
|
||||
- ai-prompting
|
||||
---
|
||||
# AI-To-AI Prompting
|
||||
|
||||
## Goal
|
||||
|
||||
Generate prompts that can be sent to another AI assistant on the Fidelity development machine, especially GitHub Copilot.
|
||||
|
||||
---
|
||||
|
||||
## Operating Assumption
|
||||
|
||||
This workspace does not contain the product codebase. The target AI has access to the Fidelity codebase on another machine.
|
||||
|
||||
Therefore prompts must:
|
||||
|
||||
- include only the relevant project context from this workspace
|
||||
- tell the target AI what files/modules to inspect
|
||||
- ask for a concrete output
|
||||
- specify constraints and non-goals
|
||||
- avoid pretending the target AI already has this workspace memory
|
||||
|
||||
---
|
||||
|
||||
## Prompt Structure
|
||||
|
||||
Use this structure by default:
|
||||
|
||||
1. Role
|
||||
2. Project context
|
||||
3. Current task
|
||||
4. Relevant ticket/context
|
||||
5. Files/modules to inspect
|
||||
6. Constraints
|
||||
7. Expected output
|
||||
8. Validation requirements
|
||||
|
||||
---
|
||||
|
||||
## Prompt Quality Rules
|
||||
|
||||
- Prefer precise task framing over long background dumps.
|
||||
- Include Jira ID and title when the work maps to a ticket.
|
||||
- Include current constraints such as REST feature flag, GraphQL fallback, auth state, backend-driven behavior, and consumer validation when relevant.
|
||||
- Ask the target AI to inspect code before proposing changes.
|
||||
- Ask for a plan first when the implementation scope is uncertain.
|
||||
- Ask for code changes only when the desired write scope is clear.
|
||||
- Include "Do not assume REST is active by default" for REST migration tasks.
|
||||
- Include "Separate external issue from regression" for AO/Discourse issues.
|
||||
- Include "Validate against Fid4/consumer path when needed" for XFlow integration tasks.
|
||||
|
||||
---
|
||||
|
||||
## Bad Prompt Pattern
|
||||
|
||||
"Fix this issue in XFlow."
|
||||
|
||||
Why bad:
|
||||
|
||||
- no entry point
|
||||
- no auth state
|
||||
- no expected behavior
|
||||
- no ticket context
|
||||
- no validation path
|
||||
- no scope boundary
|
||||
|
||||
---
|
||||
|
||||
## Good Prompt Pattern
|
||||
|
||||
"You are working in the Fidelity iOS codebase. Inspect the XFlowSDK and XFlowViewMaker integration path for `PDIAP-14859 - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`. First identify where XFlow currently exposes SwiftUI through `UIHostingController`, where XFlowViewMaker consumes it, and what feature flag protects the migration path. Do not change code yet. Return a concise plan with affected files, risks, consumer validation needs in Fid4/FTTransfer, and any questions that block implementation."
|
||||
71
agent-memory/workflows/workspace-architecture.md
Normal file
71
agent-memory/workflows/workspace-architecture.md
Normal file
@@ -0,0 +1,71 @@
|
||||
---
|
||||
type: agent-workflow
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags: [onboarding, obsidian, workspace]
|
||||
related:
|
||||
- ../maps/ai-workspace-core.md
|
||||
---
|
||||
|
||||
# Workspace Architecture
|
||||
|
||||
This repository separates project knowledge from agent operation:
|
||||
|
||||
- `project-knowledge/` is the clean Obsidian second brain and transferable project memory.
|
||||
- `agent-memory/` is the operating manual for the AI agent.
|
||||
- Everything else is technical runtime, reusable core, profile configuration, scripts, commands, prompts, or raw evidence.
|
||||
|
||||
---
|
||||
|
||||
## Canonical Memory
|
||||
|
||||
Use these folders as the source of truth for project knowledge:
|
||||
|
||||
- `00-start/` for project onboarding and terminology
|
||||
- `01-current/` for current work state
|
||||
- `02-work-items/` for ticket/task memory
|
||||
- `03-context/` for systems, workstreams, project-facing process, and iOS context
|
||||
- `04-people/` for people and role memory
|
||||
- `05-decisions/` for confirmed decisions
|
||||
- `06-daily/` for daily notes
|
||||
- `07-maps/` for graph hubs
|
||||
- `08-bases/` for table-style review
|
||||
- `09-templates/` for note templates
|
||||
|
||||
---
|
||||
|
||||
## Runtime Outside The Vault
|
||||
|
||||
These folders are intentionally outside Obsidian memory:
|
||||
|
||||
- `.opencode/` stores agents and slash commands.
|
||||
- `core/` stores reusable workspace logic.
|
||||
- `profiles/` stores project-specific profile declarations.
|
||||
- `scripts/` stores connectors, importers, and wrappers.
|
||||
- `ai/inbox/` stores live evidence from communication sync.
|
||||
- `scripts/*/generated/` stores extracted evidence.
|
||||
|
||||
Runtime and generated files can be used as evidence, but durable project facts should be promoted into `project-knowledge/`.
|
||||
|
||||
Agent behavior rules belong in `agent-memory/`, not in the project vault.
|
||||
|
||||
---
|
||||
|
||||
## Memory Access Layer
|
||||
|
||||
Use `scripts/memory/` as the platform-agnostic interface to canonical memory.
|
||||
|
||||
Obsidian is the current visual and CLI-backed adapter, but the source of truth remains Markdown under `project-knowledge/`.
|
||||
|
||||
- Agents use `scripts/memory/memory.sh create` when a new typed note is needed.
|
||||
- Agents use `scripts/memory/memory.sh search` or direct Markdown reads for context lookup.
|
||||
- Agents use `scripts/memory/memory.sh base-query` and `health` for structured review.
|
||||
- Precise memory edits should still be made directly to Markdown so changes stay auditable.
|
||||
|
||||
---
|
||||
|
||||
## Memory Rule
|
||||
|
||||
Promoted memory lives in `project-knowledge/`.
|
||||
|
||||
Raw inbox and generated connector evidence stays outside the vault until the agent promotes durable facts.
|
||||
61
agent-memory/workflows/workspace-model.md
Normal file
61
agent-memory/workflows/workspace-model.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
type: agent-workflow
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags: [process, workspace, memory]
|
||||
---
|
||||
|
||||
# Workspace Model
|
||||
|
||||
## Purpose
|
||||
|
||||
This repository is a support workspace, not the implementation repository.
|
||||
|
||||
It separates reusable tooling, project knowledge, and agent operating memory:
|
||||
|
||||
- `core/` contains reusable project-independent operating rules
|
||||
- `profiles/<project>/` contains project-specific configuration and assumptions
|
||||
- `project-knowledge/` contains transferable project documentation and current work memory
|
||||
- `agent-memory/` contains agent behavior, learning, promotion, integration, and verification rules
|
||||
|
||||
---
|
||||
|
||||
## What belongs here
|
||||
|
||||
- daily logs
|
||||
- communication context
|
||||
- manager update drafts
|
||||
- stable project knowledge
|
||||
- debugging summaries
|
||||
- reusable command, prompt, skill, and agent rules that make the workspace behave consistently
|
||||
- project profiles that configure the reusable core for a specific project
|
||||
- optional navigation notes and portable Obsidian configuration
|
||||
|
||||
---
|
||||
|
||||
## What does not belong here
|
||||
|
||||
- product source code
|
||||
- assumptions about code changes not yet verified
|
||||
- statements that imply work was executed from this machine unless explicitly true
|
||||
- Obsidian local layout, plugin cache, or runtime state
|
||||
|
||||
---
|
||||
|
||||
## Operational Surface
|
||||
|
||||
When the user corrects a recurring behavior, the workspace should update the file that controls that behavior:
|
||||
|
||||
- `core/` for reusable project-independent behavior
|
||||
- `profiles/<project>/` for project-specific assumptions
|
||||
- `project-knowledge/.obsidian/` only for portable Obsidian configuration, not project memory content
|
||||
- `scripts/memory/` for project-agnostic memory access, creation, search, Base queries, and health checks
|
||||
- `scripts/obsidian/` for the current Obsidian adapter, not for core memory semantics
|
||||
- `.opencode/commands/` for slash commands
|
||||
- `prompts/` for reusable drafting templates
|
||||
- `.opencode/agents/` and `AGENTS.md` for default agent behavior
|
||||
- `.opencode/skills/` for specialized workflows
|
||||
- `project-knowledge/00-start/` and `project-knowledge/03-context/process/` for project-facing onboarding and process rules
|
||||
- `agent-memory/` for agent-specific behavior, learning, promotion, verification, and self-maintenance rules
|
||||
|
||||
Daily logs can preserve evidence, but they should not be the only place where a reusable behavior rule lives.
|
||||
Reference in New Issue
Block a user