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:
2026-04-17 15:52:08 -06:00
parent 11fdb17fcb
commit dbc1894e27
175 changed files with 1163 additions and 914 deletions

View 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."