- 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.
44 lines
1.8 KiB
Markdown
44 lines
1.8 KiB
Markdown
---
|
|
name: copilot-prompt-engineering
|
|
description: Create high-quality prompts for GitHub Copilot or another AI running on the Fidelity development machine, using this workspace's context without assuming the target AI has access to it.
|
|
compatibility: opencode
|
|
---
|
|
|
|
## When To Use
|
|
|
|
Use this skill when the user wants a prompt for another AI assistant, GitHub Copilot, or the Fidelity development machine.
|
|
|
|
## Workflow
|
|
|
|
1. Identify the target task type:
|
|
- investigation
|
|
- implementation plan
|
|
- code change
|
|
- review
|
|
- test strategy
|
|
- story/PR drafting
|
|
2. Pull only the relevant context:
|
|
- `project-knowledge/02-work-items/` for ticket-specific context
|
|
- `project-knowledge/03-context/systems/` for component context
|
|
- `project-knowledge/03-context/workstreams/` for recurring constraints
|
|
- `project-knowledge/03-context/ios/` for Swift/iOS guidance
|
|
3. Make the prompt self-contained.
|
|
4. Tell the target AI what to inspect before acting.
|
|
5. State constraints, non-goals, and validation expectations.
|
|
|
|
## Fidelity Prompting Rules
|
|
|
|
- Include Jira ID and approved title when available.
|
|
- For REST work, say REST is behind a feature flag and GraphQL is fallback unless confirmed otherwise.
|
|
- For XFlow work, say behavior may depend on entry point, auth state, backend config, and consumer integration.
|
|
- For AO/Discourse issues, say external report vs regression must be separated.
|
|
- For SwiftUI/XFlow work, mention lifecycle, modal presentation, UIKit bridge, feature flag, and Fid4 validation if relevant.
|
|
|
|
## Output Rules
|
|
|
|
- Return only the prompt unless the user asks for explanation.
|
|
- Keep the prompt concise but complete.
|
|
- Prefer sections over paragraphs.
|
|
- Do not invent file paths unless the workspace context explicitly names them.
|
|
- If exact files are unknown, ask Copilot to locate them first.
|