create-copilot-instructions

AI Community

Repo stars 0
Author repo skills-registry

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Create a new domain-specific instruction file when current coverage gaps require file-scoped guidance Use when this capability i…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “When to Use This Skill”, “Workflow”, “Naming Convention”, “Required Frontmatter”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name create-copilot-instructions directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “When to Use This Skill / Workflow / Naming Convention” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Create Copilot Instructions File

Use this skill only when adding a new instruction file for a file type or workflow that currently lacks coverage. For updates to existing files, edit directly.

When to Use This Skill

✅ Use when:

A new file type is introduced (e.g., first Python script in a C repo)
A new workflow requires file-scoped rules (e.g., InSpec tests added)
Existing instruction coverage has a measurable gap

❌ Do NOT use when:

The file type already has an instruction file — edit it directly
The rule applies project-wide — add to copilot-instructions.md instead
Only 1-2 files of this type exist — avoid premature abstraction

Workflow

Check for existing coverage.
```
ls -1 .github/instructions/*.instructions.md
```
Read .github/instructions/copilot-customization.instructions.md overlap precedence matrix.
Survey the target files. Identify patterns, conventions, and existing style in the files you're writing instructions for.

Draft minimal frontmatter.

---
description: 'Brief description of what these instructions cover'
applyTo: 'glob/pattern/**/*.ext'
---

Test the glob pattern matches intended files:

# Bash glob test
shopt -s globstar nullglob
files=( glob/pattern/**/*.ext )
printf '%s\n' "${files[@]}"

Write actionable rules.
- Be concrete: "Use sodium_memzero() before free() for secret buffers"
- Not vague: "Handle memory safely"
- Include code examples for DO and DON'T patterns
Validate against SSOT. Confirm the new file follows .github/instructions/copilot-customization.instructions.md schema and doesn't conflict with existing overlap precedence rules.
Run validation.
```
scripts/validate-copilot-config.sh
```

Naming Convention

<topic>.instructions.md where <topic> is lowercase, hyphen-separated, and describes the file type or workflow.

Examples from this repository:

c-memory-safety.instructions.md
cmocka-testing.instructions.md
gnu-autotools.instructions.md
sbom.instructions.md

Required Frontmatter

Refer to .github/instructions/copilot-customization.instructions.md for the authoritative schema. At minimum:

description: (quoted string, one line)
applyTo: (comma-separated glob patterns)

Anti-Patterns

Creating instruction files for domains not present in the repo
Duplicating rules from existing instruction files
Writing instructions for a single file (use inline comments instead)
Including implementation code (instructions define conventions, not solutions)

Source: CTFfactory/salt — distributed by TomeVault.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: AI
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @tomevault-io · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Python
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview create-copilot-instructions.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# Create Copilot Instructions File

Use this skill only when adding a **new** instruction file for a file type or workflow that currently lacks coverage. For updates to existing files, edit directly.

## When to Use This Skill

✅ Use when:
- A new file type is introduced (e.g., first Python script in a C repo)
- A new workflow requires file-scoped rules (e.g., InSpec tests added)
- Existing instruction coverage has a measurable gap

❌ Do NOT use when:
- The file type already has an instruction file — edit it directly
- The rule applies project-wide — add to `copilot-instructions.md` instead
- Only 1-2 files of this type exist — avoid premature abstraction

## Workflow

1. **Check for existing coverage.**
   ```sh
   ls -1 .github/instructions/*.instructions.md
   ```
   Read `.github/instructions/copilot-customization.instructions.md` overlap precedence matrix.

2. **Survey the target files.**
   Identify patterns, conventions, and existing style in the files you're writing instructions for.

3. **Draft minimal frontmatter.**
   ```yaml
   ---
   description: 'Brief description of what these instructions cover'
   applyTo: 'glob/pattern/**/*.ext'
   ---
   ```
   Test the glob pattern matches intended files:
   ```sh
   # Bash glob test
   shopt -s globstar nullglob
   files=( glob/pattern/**/*.ext )
   printf '%s\n' "${files[@]}"
   ```

4. **Write actionable rules.**
   - Be concrete: "Use `sodium_memzero()` before `free()` for secret buffers"
   - Not vague: "Handle memory safely"
   - Include code examples for DO and DON'T patterns

5. **Validate against SSOT.**
   Confirm the new file follows `.github/instructions/copilot-customization.instructions.md` schema and doesn't conflict with existing overlap precedence rules.

6. **Run validation.**
   ```sh

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> When to Use This Skill → Workflow → Naming Convention → Required Frontmatter → Anti-Patterns
terms    -> new · Check for existing coverage. · Survey the target files. · Draft minimal frontmatter. · Write actionable rules. · Validate against SSOT. · Run validation.
files/cmd -> copilot-instructions.md · .github/instructions/copilot-customization.instructions.md · sodiummemzero() · free() · <topic>.instructions.md · <topic> · c-memory-safety.instructions.md · cmocka-testing.instructions.md
body sha256 -> f841bac7a79d