Copilot: Difference between revisions

From Omnia
Jump to navigation Jump to search
No edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
== Table of Contents ==
== Subpages ==


{{Special:PrefixIndex/{{PAGENAME}}/|hideredirects=1}}
{{Special:PrefixIndex/{{PAGENAME}}/|hideredirects=1}}
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.

keywords