89 lines
5.9 KiB
Markdown
89 lines
5.9 KiB
Markdown
---
|
|
type: agent-workflow
|
|
status: active
|
|
updated: 2026-05-12
|
|
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.
|
|
- For corporate-tool captures in `fidelity-ai-copilot`, prefer a single raw Charles Mirror source such as `archive/charles-mirror/` and treat it as read-only evidence organized by hostname. Generated Copilot outputs should be written to separate per-platform folders only when useful, with prompts requiring source inspection, narrow scope, local-only processing, and explicit evidence paths.
|
|
- When advising on `fidelity-ai-copilot` customization, use this routing: keep global safety and repo role in `AGENTS.md` / `.github/copilot-instructions.md`; use `.github/instructions/*.instructions.md` for path-scoped rules such as `archive/**`; use `.github/prompts/*.prompt.md` for repeatable slash-command tasks; use `.github/agents/*.agent.md` for persistent personas with tool restrictions and handoffs; use `.github/skills/*/SKILL.md` for reusable multi-step capabilities with scripts, examples, or resources. Prefer small, composable artifacts over one large instruction file.
|
|
- For read-only evidence prompts such as Discourse/Charles Mirror search, explicitly prevent the target AI from editing the prompt/configuration files while running the workflow. If Copilot changes `.github/prompts/*.prompt.md` during an evidence query, treat that as a workflow bug unless the user specifically asked to update the prompt.
|
|
- When the user says they will handle dependency alignment, registry configuration, or compile/test execution manually on the development machine, generated Copilot follow-ups should not ask Copilot to solve those dependency/tooling issues or run broad builds. Instead, ask Copilot for the smallest source-level fix for the specific compiler error the user provides, state that the user will rerun validation manually, and request a concise summary of changed files and expected validation impact.
|
|
|
|
---
|
|
|
|
## 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."
|