85 lines
4.2 KiB
Markdown
85 lines
4.2 KiB
Markdown
---
|
|
type: agent-workflow
|
|
status: active
|
|
updated: 2026-05-06
|
|
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
|
|
|
|
- Write prompts in English by default for GitHub Copilot and other development-machine AI tools unless the user explicitly asks for another language.
|
|
- Prefer first-person phrasing when drafting a prompt the user will paste directly into another AI tool, unless the user asks for a different voice.
|
|
- Keep prompts concise by default; include only the context needed for correct execution.
|
|
- In follow-up prompts to the same AI session, do not restate completed work or who performed it unless that detail is needed for the next step.
|
|
- 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.
|
|
- For VS Code multi-root Copilot workflows, preserve repo-provided customizations such as `.github/prompts`, `.github/instructions`, `.github/agents`, `.github/skills`, and `AGENTS.md`. Shared `fidelity-ai-copilot` customizations should supplement these repo files, while repo-specific instructions should be treated as the practical authority when they conflict.
|
|
- For Fidelity Jira/Confluence access from GitHub Copilot CLI or VS Code, do not assume the approved access method. First have the target AI read the current Fidelity-provided human instructions from Confluence or local exported docs, then configure the smallest matching workflow. If those instructions require terminal `curl` with environment variables such as `COPILOT_JIRA_URL` and `COPILOT_JIRA_TOKEN`, enforce that path; otherwise follow the documented Fidelity-approved method. Never print, persist, or hardcode tokens.
|
|
- Treat `fidelity-ai-copilot` as a self-improving AI harness rather than a static prompt dump: the target AI should notice recurring useful workflows, newly discovered internal instructions, and tool changes, then propose small auditable updates to instructions, skills, prompts, agents, specs, or validation checklists. It should ask before making broad changes and keep product repos clean.
|
|
|
|
---
|
|
|
|
## 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."
|