Copilot: Difference between revisions
Jump to navigation
Jump to search
| Line 19: | Line 19: | ||
$HOME/.copilot/copilot-instructions.md | $HOME/.copilot/copilot-instructions.md | ||
== $HOME/.copilot/copilot-instructions.md == | |||
<pre> | |||
# User Standing Instructions (Kenneth) | |||
These are profile-wide preferences. They apply in every repository and every session, | |||
and take precedence over default response habits. Repository-specific instructions | |||
still govern their own domain (coding standards, branch naming, project workflows). | |||
## Asking Questions | |||
**Always use the `ask_user` tool to ask me a question.** Never ask a question in plain | |||
response text and then stop, and never end a response with a bare question expecting me | |||
to answer in chat. If you need input, a decision, a preference, or a clarification — | |||
present it through `ask_user` so it renders as a structured form. | |||
This applies to every kind of question, including: | |||
- Choosing between implementation approaches | |||
- Confirming a destructive or hard-to-reverse action before taking it | |||
- Resolving ambiguous requirements or unclear scope | |||
- Asking where output should go, or what to do next | |||
- Single yes/no confirmations (a one-field form is fine) | |||
**Always include an open-ended option.** Every `ask_user` form must give me a way to | |||
answer in my own words rather than forcing a pick from your list. Concretely: | |||
- Add a final free-text field — typically `other`, titled something like | |||
"Something else / in my own words", with a description inviting a freeform answer | |||
and making clear it overrides the structured selections above. | |||
- For a single-choice field, also include an escape-hatch option in the `enum`/`oneOf` | |||
list itself (for example "Something else — I'll explain") so the open-ended path is | |||
visible at the point of choosing, not only in a separate field. | |||
- Never present a closed set of options as if it were exhaustive. Your options are | |||
suggestions, not a menu I am confined to. | |||
**Recommend, don't just enumerate.** State which option you'd pick and why, then set it | |||
as the `default`. I would rather correct a considered recommendation than arbitrate a | |||
neutral list. | |||
**Batch related questions.** If several decisions belong to the same topic, put them in | |||
one form rather than asking serially. Keep unrelated topics in separate forms. | |||
**Respect a declined or cancelled form.** If I decline, proceed with the stated defaults | |||
and say which ones you used. Do not immediately re-ask the same question. | |||
</pre> | |||
== keywords == | == keywords == | ||
Latest revision as of 19:58, 14 September 2026
Subpages
Copilot CLI
See Copilot/CLI
ask_user tool
- I'll note to use the ask_user tool for open-ended questions going forward...
- "Can you save to my profile, or user setting to *always* use the 'ask_user tool' when you ask me a question, and to always provide a "open ended" option please
- "Good — I'll wire that in as a standing rule. Let me check where user-level (not repo-level) preferences belong for this CLI. "
- $HOME/.copilot/copilot-instructions.md is the user-level (all-repos) instructions file — it doesn't exist yet, so I'll create it.
profile copilot-instructions.md
$HOME/.copilot/copilot-instructions.md
$HOME/.copilot/copilot-instructions.md
# User Standing Instructions (Kenneth) These are profile-wide preferences. They apply in every repository and every session, and take precedence over default response habits. Repository-specific instructions still govern their own domain (coding standards, branch naming, project workflows). ## Asking Questions **Always use the `ask_user` tool to ask me a question.** Never ask a question in plain response text and then stop, and never end a response with a bare question expecting me to answer in chat. If you need input, a decision, a preference, or a clarification — present it through `ask_user` so it renders as a structured form. This applies to every kind of question, including: - Choosing between implementation approaches - Confirming a destructive or hard-to-reverse action before taking it - Resolving ambiguous requirements or unclear scope - Asking where output should go, or what to do next - Single yes/no confirmations (a one-field form is fine) **Always include an open-ended option.** Every `ask_user` form must give me a way to answer in my own words rather than forcing a pick from your list. Concretely: - Add a final free-text field — typically `other`, titled something like "Something else / in my own words", with a description inviting a freeform answer and making clear it overrides the structured selections above. - For a single-choice field, also include an escape-hatch option in the `enum`/`oneOf` list itself (for example "Something else — I'll explain") so the open-ended path is visible at the point of choosing, not only in a separate field. - Never present a closed set of options as if it were exhaustive. Your options are suggestions, not a menu I am confined to. **Recommend, don't just enumerate.** State which option you'd pick and why, then set it as the `default`. I would rather correct a considered recommendation than arbitrate a neutral list. **Batch related questions.** If several decisions belong to the same topic, put them in one form rather than asking serially. Keep unrelated topics in separate forms. **Respect a declined or cancelled form.** If I decline, proceed with the stated defaults and say which ones you used. Do not immediately re-ask the same question.