From 98950a64fbe361bd4ac8cc38b155375025280fa7 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Mon, 3 Aug 2026 12:12:36 +0000 Subject: [PATCH] chore: update Copilot collections to v0.18.0 --- .github/.copilot-collections.yaml | 2 +- .../instructions/cloud-agent.instructions.md | 73 +++++++++++++++++++ .../instructions/secret-guard.instructions.md | 17 +++++ .../starcraft-docs-meta.instructions.md | 60 +++++---------- 4 files changed, 111 insertions(+), 41 deletions(-) create mode 100644 .github/instructions/cloud-agent.instructions.md create mode 100644 .github/instructions/secret-guard.instructions.md diff --git a/.github/.copilot-collections.yaml b/.github/.copilot-collections.yaml index 82fe89a58..4bb564c7f 100644 --- a/.github/.copilot-collections.yaml +++ b/.github/.copilot-collections.yaml @@ -1,7 +1,7 @@ # https://github.com/canonical/copilot-collections copilot: - version: v0.13.0 + version: v0.18.0 collections: - starcraft-core - starcraft-docs diff --git a/.github/instructions/cloud-agent.instructions.md b/.github/instructions/cloud-agent.instructions.md new file mode 100644 index 000000000..9fccbd928 --- /dev/null +++ b/.github/instructions/cloud-agent.instructions.md @@ -0,0 +1,73 @@ +--- +applyTo: '**' +excludeAgent: 'code-review' +description: 'Guidelines for GitHub Copilot cloud agent when working in Starcraft.' +--- + +# GitHub Cloud Agent Instructions for Starcraft + +These instructions guide GitHub Copilot cloud agent when it works in Starcraft projects. These don't apply to the initial review provided by GitHub Copilot code review. + +## Code changes in pull request comments + +These instructions apply to interactions between users and the cloud agent, when they mention it with `@copilot`. + +### Draft changes when explicitly requested + +When a user mentions `@copilot` in a comment asking to draft or propose a code change, reply in a comment using GitHub's code suggestion syntax. Do not commit directly to the branch. + +Examples of requests that should trigger this behavior include: + +- "propose a change" +- "show me what this would look like" +- "what would this look like?" +- "can you draft that?" +- "show me an example" +- "write that out" +- "what do you suggest?" +- "show a fix for this" +- "give me a suggestion" +- "how would you write this?" + +Reply using GitHub's code suggestion syntax: + +````markdown +```suggestion + +``` +```` + +This allows the user to review and apply the suggestion themselves with a single click. + +### Only commit changes when explicitly requested + +When a user mentions `@copilot` in a comment asking to finalize a code change, commit the change as requested. + +If no prior suggestion exists in the current PR conversation, propose the change first using the suggestion syntax above before committing. + +Examples of requests that should trigger this behavior include: + +- "commit what is proposed" +- "push this code" +- "apply these changes" +- "go ahead and commit" +- "push the changes" +- "commit the suggestion" +- "apply the fix" +- "push what you suggested" +- "land these changes" + + +### Combined implement and commit requests + +If a user asks for a change **and** explicitly requests it be committed in the same message, treat it as an explicit commit request. Implement the change and commit it directly without posting a suggestion first. + +Examples of requests that should trigger this behavior include: + +- "implement X and push it" +- "fix this and commit" +- "make this change and push" +- "do X and land it" +- "apply X and commit" +- "patch this and commit" +- "commit a fix for this" diff --git a/.github/instructions/secret-guard.instructions.md b/.github/instructions/secret-guard.instructions.md new file mode 100644 index 000000000..8847a3f45 --- /dev/null +++ b/.github/instructions/secret-guard.instructions.md @@ -0,0 +1,17 @@ +--- +applyTo: '**' +description: 'Prevent secrets (API keys, tokens, passwords, private keys) from leaking into context, tool output, or spawned processes.' +--- + +## Secret Handling (Always On) + +These rules protect secrets at all times. They are subordinate only to an explicit, direct user command. + +- **Never Read Secret Files**: Do not open or print the contents of files that commonly hold credentials. This includes `.env`, `.env.*`, `.netrc`, `.npmrc`, `.pypirc`; any `.pem`, `.key`, `.p12`, `.pfx`, `.crt`, `.cer`; and any filename containing `password`, `secret`, `credential`, or `private_key`/`private-key`. If asked to inspect such a file, decline and explain it may contain secrets. +- **Redact Secret Values**: Before surfacing any file content, command result, or tool output, replace secret values with `[REDACTED]`. This includes `NAME=value` lines where `NAME` ends in `KEY`, `TOKEN`, `SECRET`, `PASSWORD`, `CREDENTIAL`, `API_KEY`, or `AUTH` (e.g. `CLOUD_API_KEY=sk-abc123` → `CLOUD_API_KEY=[REDACTED]`). +- **Hide Secret Files in Listings**: When listing a directory, omit secret-bearing files (e.g. `.env*`, `.netrc`, `.npmrc`, `.pypirc`) rather than revealing their existence. +- **Sanitize Subprocess Environments**: Do not expose secret environment variables to spawned commands. Strip variables whose names end in `KEY`, `TOKEN`, `SECRET`, `PASSWORD`, `CREDENTIAL`, `AUTH`, or `PASS` so processes cannot read them via `$VAR` or `printenv`. +- **Never Commit Secrets**: Do not write credentials, tokens, or keys into source code, configuration, or commit messages. +- **Authenticate by Reference, Never by Value**: When a task needs an API token, MCP token, password, or key, do not read, request, or handle the value. Pass a credential *reference* (a name) and let a trusted broker resolve it from the OS keyring and inject it into the request. If no keyring entry exists, ask the user to store it themselves (e.g. `keyring set agent-secrets `) — never accept a pasted secret into the conversation. + +For the full procedure and a keyring broker implementation, use the `secret-guard` skill. diff --git a/.github/instructions/starcraft-docs-meta.instructions.md b/.github/instructions/starcraft-docs-meta.instructions.md index 9edf7c32f..e3a6fc88b 100644 --- a/.github/instructions/starcraft-docs-meta.instructions.md +++ b/.github/instructions/starcraft-docs-meta.instructions.md @@ -23,58 +23,38 @@ The meta description must be one line, because Sphinx options don't support line ## Write a meta description -**Do** write the meta description *after* the page is written. The meta description is a reflection of what's actually on the page. +Write the meta description after the page is written. The meta description is a reflection of what's actually on the page, not what the page aspires to be. -**Do** reuse text from the page itself when it's convenient. +Start with the Diátaxis category or action, such as *How to* or *Reference for*. Next, describe what the user will find on the page. Reuse text from the page itself where it's appropriate. -**Do** share descriptions between documents with the same formats. For example, use the same meta description for every page of release notes, but replace the version number. +Include a focus term or phrase, the key string that users are likely to search for. It can be a single word like *security*, or a short phrase such as *create an Ubuntu Core image*. Prefer widely recognized terminology. If your product isn't yet well known, then it's safer to use terms familiar to a global technical audience over product-specific ones. -**Do** frame sentences in terms of *actions* and *facts*. +Make every word count. There is no hard minimum length, but it should be longer and more descriptive than the title, and it should not merely repeat the wording of the title. The maximum length is 160 characters, because search engines truncate the snippet after 160 characters. This includes spaces. - - - - - - - - - - - - - - - - - -
TypeStarts with phrases like...

Action

Get started with

-

Learn about

-

Find information about

Fact

The encabulator is a circuit that

-

The Chef init profile sets up a basic project file for

-

Starcraft is compatible with

+For pages with the same format, share descriptions between them. For example, use the same meta description for every page of release notes, but change the version number. -**Do** put key terms near the start. +### Avoid these mistakes -**Do** aim for an average of 140 characters. Cut any detail about the topic that isn't essential to helping the user make a decision. +Avoid calls to action like *find*, *discover*, *explore*, or *read*. These are so overused that they have become noise words. The user's needs and actions in the moment are out of your control; the snippet should be a glimpse of the information on the page. Tutorials are the exception, where *learn* is appropriate. -**Don't** exceed 160 characters. Search engines will cut the snippet short. +Avoid qualities or claims about the product and its features, like *simple*, *easy*, or *best-in-class*. Marketing rhetoric, sales pitches, and business clichés like the following aren't appropriate for documentation: -**Don't** write to market, motivate, or compel. Marketing prose with rhetoric like the following isn't appropriate for documentation. +*Don't just write code; deliver a product. Start your journey today and turn your project into a production-ready, evergreen, blazing-fast, full-stack app.* -> Don't just write code; deliver a product. Start your journey today and turn your project into a production-ready snap. +### Examples -**Don't** include qualities or claims like *simple*, *easy*, or *best-in-class*. +For _Tutorial_ > _Craft a snap_ in Snapcraft: -**Don't** include key terms that aren't on the page. +> Learn the essentials of Snapcraft. In this tutorial, we package a small Python app into a snap. -**Don't** use pronouns such as *you*, *your*, *we*, or *our*. These waste space and don't match the tone of a description. +For _How to_ > _Change from core24 to core26_ in Snapcraft: -## Example +> How to migrate a snap from core24 to core26. -This is an example of a good meta description for *Set up Starcraft*. +For the _Reference_ > _GNOME extension_ in Snapcraft: -``` rst -.. meta:: - :description: Learn how to install Starcraft on a local system. Starcraft is available as a snap on all GNU/Linux systems that support systemd. -``` +> Reference documentation for the GNOME extension, which adds the components for desktop apps that require GTK 3, GNOME 42 and higher, and GLib. + +For _Explanation_ > _Parts lifecycle_ in Snapcraft: + +> Explanation of the build process of a part in Snapcraft, with a breakdown of the individual steps and the effect each has on the snap filesystem.