🛠️ Show & Tell: What Custom Copilot Skills Have You Built? Share Your SKILL.md Files!

[shinybrightstar]

👋 Hey Community!

Custom Skills (SKILL.md) are one of the most powerful, and most under-documented, features in GitHub Copilot. We've seen incredible things being built in this community, from deterministic React UI generators to multi-agent orchestration workflows for full-stack development.

But right now, there's no central place to discover what others have built, learn from their SKILL.md file structures, or get inspired for your next custom skill.

Let's change that. 🚀

---

Share your custom Copilot Skill!

Reply to this thread with:

1. 🏷️ Skill name -- What does your skill do?
2. 🎯 Problem it solves -- What was flaky, slow, or impossible before this skill?
3. 📄 Your SKILL.md (or a snippet) -- Show us the actual file! Frontmatter, instructions, example references — the more detail, the better.
4. 🖥️ Where it works -- VS Code? CLI? github.com? PR review? All of the above?
5. 💡 One thing you learned -- What surprised you, tripped you up, or took the longest to figure out?

---

Not sure where to start?

Here are some skill ideas based on what the community has been asking about:

Idea	Who's asking	Source
Code style enforcer — Make Copilot follow your team's exact coding conventions	Teams frustrated with inconsistent AI output	Multiple CLI & Skills threads
Database schema generator — Generate migration files from natural language	Full-stack developers building multi-skill workflows	#192232
PR review checklist — A domain-specific validation skill for code review	Teams using Copilot Code Review	#191616
Test scaffolder — Generate test boilerplate matching your team's patterns	Developers who want consistent test structure	Community pattern
API contract validator — Ensure generated code matches an OpenAPI spec	Backend teams with strict API contracts	Community pattern
Deterministic UI layout — Force consistent React/Vue component structure	Frontend developers (already built! See #189283)	#189283

---

Quick reference: SKILL.md file structure

For anyone new to custom skills, here's the basic anatomy:

.github/skills/my-skill/
├── SKILL.md          ← The main skill definition
└── examples/         ← Optional: example code for the skill to reference
    ├── good.py
    └── bad.py

Your SKILL.md file typically contains:

• YAML frontmatter — metadata like name, description, and scoping
• Instructions — what the skill should do, in natural language
• Context sections — example patterns, constraints, and references

📖 Official docs: Custom skills for Copilot

---

🏆 Community highlights

We'll periodically update this section with standout skills shared in the replies:

Skill	Author	Description
Markdown-UI DSL	@MegaByteMark	Deterministic React UI from rigid wireframe syntax — the OG community skill
Your skill here	You!	Reply below to be featured

---

Whether you've built a production-grade skill or just a weekend experiment, we want to see it. The best way to learn SKILL.md is from real examples — and right now, there aren't enough of them.

Let's build that library together. Drop your skill below! 👇

[tracysstroud-stack]

I need to see photos

[naqibullahsaber24-ctrl]

https://github.com/orgs/community/discussions/194436#discussioncomment-16811085

[m-hasnainhaider]

thanks this really helps alot.

[KonstantinSpasski]

where computer buy &

? 121

[miller-28]

🧩 Skill name

AI DB Investigator
A read-only local database investigation skill for AI-assisted development.

Repository:
https://github.com/miller-28/skill-ai-db-investigator

---

🎯 Problem it solves

Most AI database help still behaves like direct question-answering.

But real database work usually requires investigation first.

A slow endpoint, suspicious schema, missing index, unclear relation, or bad data model is rarely solved by one immediate answer. The useful flow is usually:

1. identify the target environment
2. identify the database engine
3. inspect existing runtime context
4. understand entities and relationships
5. run bounded read-only queries
6. document findings
7. separate symptoms from root causes
8. suggest safe next actions

This skill is designed to make Copilot / AI agents approach database analysis as a structured investigation rather than a guessing process.

---

📄SKILL.md

The skill defines a local DB investigation protocol with explicit safety and documentation rules.

Core characteristics:

• read-only by design
• mandatory environment resolution
• mandatory engine resolution
• mandatory diagnostic step before DB commands
• support for multiple engines
• runtime database context files
• query audit trail per investigation session
• generated investigation reports
• Mermaid schema context
• no credential collection in chat
• no secrets echoed in responses or logs

Supported engines include:

• PostgreSQL
• MongoDB
• MySQL
• MariaDB
• SQL Server
• SQLite
• Redis
• Elasticsearch / OpenSearch
• Cassandra
• Neo4j

The skill starts by requiring:

node scripts/diagnose.mjs

or:

npm run diagnose

Then it resolves the explicit target environment and engine before running any database command.

One of the main design rules is:

Never assume or auto-pick an environment or database engine when the user did not explicitly provide one.

Another important rule:

The bridge is read-only. Do not attempt INSERT, UPDATE, DELETE, DDL, or destructive commands through the skill.

The skill also requires investigation artifacts to be updated before ending the work:

• db-context/<env>/<engine>/schema.mermaid
• db-context/<env>/<engine>/entity-map.md
• investigations/<env>/<engine>/<session>/investigation-report.md

So the AI does not only answer the user - it leaves behind reusable investigation context.

---

🖥️ Where it works

The skill is intended for local AI-assisted development workflows where the model can inspect a project and use local scripts/tools.

Use cases:

• database schema investigation
• PostgreSQL query analysis
• entity relationship mapping
• index review
• production-style DB debugging
• bounded read-only data inspection
• AI-assisted technical diagnosis
• documenting database findings for future sessions

It is not a monitoring dashboard and not a database admin replacement.

It is a focused investigation protocol for AI agents.

---

💡 One thing I learned

The biggest lesson was that AI database work needs guardrails before intelligence.

Without structure, the model may jump too fast into conclusions.

For database work, that is risky.

The important parts are not only “which query to run”, but also:

• which environment is being inspected
• which engine is being used
• whether the command is safe
• whether the result is documented
• whether the next AI session can continue from the previous context

So the skill became less about generating SQL and more about enforcing a disciplined investigation process.

The direction I’m exploring is:

AI-assisted development should not only generate code.
It should also investigate systems carefully.

Feedback is very welcome, especially around database investigation flows, PostgreSQL-specific checks, and how this could be improved for Copilot / agent workflows.

[aiprofithub]

🏷️ Skill name
Production SaaS Agent OS

🎯 Problem it solves
I built this because AI agents are powerful, but in a real SaaS monorepo they need strict boundaries.

The main issue was not code generation.
The issue was controlling how the agent investigates, changes, validates, and reports work.

Before using a skill-style workflow, AI-assisted changes could easily become:

• too large for one PR
• mixed across unrelated apps
• inconsistent with existing repo patterns
• missing validation
• risky around auth, environment variables, i18n, deployment, or production code
• hard for a maintainer to review safely

So this skill acts as an operating protocol for AI-assisted SaaS development.

It pushes the agent to investigate first, make bounded changes, run relevant checks, and leave clear evidence for review.

📄 SKILL.md / snippet

# Production SaaS Agent OS Skill

## Mission

Operate as a disciplined AI engineering agent for a production SaaS monorepo.

Do not only generate code.
Investigate the existing system, make bounded changes, validate them, and prepare work that a human maintainer can safely review.

## Core Rules

1. Prefer small scoped changes over large mixed changes.
2. One task should map to one clear app, package, feature path, or infrastructure concern.
3. Do not stage unrelated files.
4. Do not use broad `git add .`.
5. Inspect existing patterns before adding new code.
6. Preserve i18n, auth, analytics, environment, and deployment boundaries.
7. Treat production deployment logic as high-risk.
8. Never expose secrets or echo credential values.
9. Run the most relevant validation before claiming success.
10. Report files changed, checks run, risks, and next recommended action.

## Pull Request Discipline

A valid PR should usually affect one of:

- one app
- one package
- one feature path
- one infrastructure concern
- one documentation concern

Avoid mixed PRs that combine UI, auth, database, deployment, copy, and infrastructure changes together.

## Validation

Before completing work, run the most relevant checks available, for example:

- pnpm lint
- pnpm test
- pnpm build
- package-specific tests
- route smoke checks
- i18n validation
- deployment-readiness checks

If validation cannot be run, say exactly why.
Do not claim success without evidence.

## Final Report

Every completed task should include:

- what changed
- files touched
- validation run
- known risks
- what should happen next

🖥️ Where it works
This is mainly for local AI-assisted development workflows:

• VS Code
• CLI
• Copilot-style coding agents
• PR preparation
• monorepo cleanup
• production-readiness checks
• SaaS feature extraction and refactoring

It works best in a TypeScript / Next.js / pnpm / Turborepo-style monorepo where app boundaries matter.

💡 One thing I learned
The biggest lesson: AI coding gets better when the workflow is constrained.

For production work, the hard part is not only generating code.
The hard part is reducing blast radius.

The skill became less about “write this feature” and more about:

• investigate first
• change less
• validate more
• preserve boundaries
• document clearly
• make review easier

A good SKILL.md is not just a reusable prompt.
It is a workflow contract for how the agent should behave inside a real codebase.

[aiprofithub]

One thing I am still thinking about is how strict a SKILL.md should be about validation.

For example, in a production monorepo, should the skill require the agent to always run the nearest package-level checks before completion, or is it enough for the agent to clearly list the checks that should be run?

My current bias is that the skill should require validation whenever possible, because it reduces false confidence.

But there is a tradeoff:

• strict validation improves trust
• lighter validation improves speed
• too much validation can slow down small changes
• too little validation makes the agent sound more confident than it should

Curious how others are handling this in Copilot skills, especially for PR review, monorepos, and production workflows.

[ritabratamaiti]

🏷️ Skill name

browy-add-tool — adds a new browser tool to Browy, an open-source AI agent that lives in the Chrome side panel and DevTools and drives real browser tabs through chat.

Skill file: https://github.com/BrowyHQ/browy/blob/main/.github/skills/browy-add-tool/SKILL.md

🎯 Problem it solves

Browy is built around a tool registry. Every browser action the agent can take (click_index, inspect_page, read_console, tabs.open, etc.) is a register({ def, run }) block in src/agent/tools/browser.ts. Adding a new one has a half-dozen non-obvious rules that get re-learned every PR:

• always return a JSON string, never an object, never throw
• prefer indexed-element interaction ([N] from the page snapshot) over CSS selectors
• describe both what the tool does and when to call it, plus the return shape
• batch CDP work into a single Runtime.evaluate when possible
• return state-deltas (urlChanged, domChanged, modalAppeared) so the LLM can verify the side effect

Before the skill, contributors (including Copilot in agent mode) would land PRs that violated 2-3 of these and need a review round to fix. Now Copilot reads the skill at activation and the first draft is usually correct.

📄 SKILL.md (frontmatter + structure)

---
name: browy-add-tool
description: Use this skill when adding a new browser tool to the Browy agent (BrowyHQ/browy). Tools are functions the LLM can call from chat. Examples include click, type, scrape, network inspection, tab control. The skill walks through the register({ def, run }) pattern used in src/agent/tools/, the schema the Copilot SDK expects, the indexed-element interaction pattern (clicking by [N] from the page snapshot rather than guessed CSS), and the conventions every tool must follow. Activate when the user says "add a tool to Browy", "let the agent do X in the browser", or "extend Browy with a new capability".
license: Apache-2.0
compatibility: Targets the BrowyHQ/browy codebase. Tools live in src/agent/tools/browser.ts. Runtime is Node 20+, TypeScript strict, ESM. Tool implementations use a CDPSession (playwright-core) injected via BrowserToolContext.
---

Body sections:

• Quick anatomy with a complete register({...}) example
• The seven rules (return JSON string, validate args, prefer indexed-element, etc., each with the rationale)
• Workflow (read existing tools, factor helpers, mirror docs into zh-CN, CHANGELOG entry)
• Common mistakes mapped to the four annotated patterns in examples/bad.ts
• Beyond browser tools pointing at the host-tool registry and its permission-gated context

Layout:

.github/skills/browy-add-tool/
├── SKILL.md
└── examples/
    ├── good.ts   - a complete passing tool that follows every rule
    └── bad.ts    - same shape, four annotated mistakes

The good.ts / bad.ts pair is the highest-signal part. The agent reads the skill, then opens bad.ts and immediately pattern-matches the failure modes against the PR diff.

🖥️ Where it works

Project skill, lives in the repo. Picked up by:

• GitHub Copilot cloud agent when it is working on a Browy PR
• GitHub Copilot CLI when run inside the Browy checkout (copilot from the repo root)
• VS Code agent mode

I have not tested it with Claude Code or other Agent-Skills clients, but per the open spec it should load fine anywhere that supports project skills.

💡 One thing I learned

The description field is where the magic is, not the body. The body is loaded only after the agent decides the skill is relevant. The description is read at startup and is the only signal the agent has when deciding whether to activate.

My first draft had a description like "Skill for adding tools to Browy." It never fired. Rewriting it to include the trigger phrases ("add a tool to Browy", "let the agent do X in the browser", "extend Browy with a new capability") made it activate on every PR that touched the tool registry. Bias the description toward verbs and user-intent phrases, not toward what the skill is.

The second-biggest lever was the examples/good.ts + examples/bad.ts pair. Once those existed, the skill body could shrink by half: instead of describing the rules in prose, I could say "see examples/bad.ts for the four most common mistakes" and trust the agent to read it.

---

Hope this is useful as an example of a project-scoped skill (vs the personal/global ones). Happy to answer questions about the structure.

[Chlience]

Skill name

Clipboard Output Skill

Repository: https://github.com/Chlience/clipboard-output-skill

This is a small SKILL.md workflow for AI coding agents that generate scripts, config, prompts, JSON, Markdown, commands, or other exact multi-line artifacts. Instead of asking the user to copy from a terminal UI, the skill writes/copies the final artifact directly to the system clipboard.

Problem it solves

Terminal UI copy/paste is fragile for generated artifacts:

• selecting text can include left padding, prompts, or UI gutters
• long code blocks are easy to copy partially
• multiple generated files need a clear "what should be copied?" rule
• secrets should not be silently placed on a shared clipboard

The skill makes the agent decide what the user actually needs to paste, copy only that payload, and report exactly what was copied.

SKILL.md

The core rule is:

When the user is likely to copy exact generated content, put the final copyable text on the clipboard instead of relying on a chat code block.

Some of the guardrails:

• copy only the artifact, not explanatory text around it
• preserve exact indentation and line endings
• for multiple files, create real files first and copy only one useful payload: entrypoint file, path, command, manifest, or archive path
• refuse likely secrets by default unless explicitly allowed
• do not claim the clipboard was updated unless the helper reports success

The repo includes the full SKILL.md plus a Python helper:

• skills/clipboard-output/SKILL.md
• skills/clipboard-output/scripts/copy_text.py
• skills/clipboard-output/tests/test_copy_text.py

Where it works

I built and tested it as a local Codex personal skill, but the pattern is a general SKILL.md workflow that should be adaptable for custom skill-style agent setups.

The helper supports clipboard backends for:

• WSL / Windows clipboard
• native Windows Python
• macOS pbcopy
• Linux wl-copy, xclip, or xsel
• Termux

One thing I learned

The interesting part was not the clipboard command itself. It was defining the decision boundary around what should be copied.

For single artifacts, copying the artifact is obvious. For multi-file outputs, blindly concatenating files into the clipboard is usually wrong. The better default is to write real files and copy only the most useful entrypoint, path, or run command. The other important lesson was treating the clipboard as shared state, so the skill needs secret-detection and explicit failure handling.

Feedback welcome, especially on whether this kind of "output handoff" skill belongs in more agent workflows.

[gmashrsa01-art]

🏷️ Skill name
Production SaaS Agent OS

🎯 Problem it solves
I built this because AI agents are powerful, but in a real SaaS monorepo they need strict boundaries.

The main issue was not code generation.
The issue was controlling how the agent investigates, changes, validates, and reports work.

Before using a skill-style workflow, AI-assisted changes could easily become:

• too large for one PR
• mixed across unrelated apps
• inconsistent with existing repo patterns
• missing validation
• risky around auth, environment variables, i18n, deployment, or production code
• hard for a maintainer to review safely

So this skill acts as an operating protocol for AI-assisted SaaS development.

It pushes the agent to investigate first, make bounded changes, run relevant checks, and leave clear evidence for review.

📄 SKILL.md / snippet

# Production SaaS Agent OS Skill

## Mission

Operate as a disciplined AI engineering agent for a production SaaS monorepo.

Do not only generate code.
Investigate the existing system, make bounded changes, validate them, and prepare work that a human maintainer can safely review.

## Core Rules

1. Prefer small scoped changes over large mixed changes.
2. One task should map to one clear app, package, feature path, or infrastructure concern.
3. Do not stage unrelated files.
4. Do not use broad `git add .`.
5. Inspect existing patterns before adding new code.
6. Preserve i18n, auth, analytics, environment, and deployment boundaries.
7. Treat production deployment logic as high-risk.
8. Never expose secrets or echo credential values.
9. Run the most relevant validation before claiming success.
10. Report files changed, checks run, risks, and next recommended action.

## Pull Request Discipline

A valid PR should usually affect one of:

- one app
- one package
- one feature path
- one infrastructure concern
- one documentation concern

Avoid mixed PRs that combine UI, auth, database, deployment, copy, and infrastructure changes together.

## Validation

Before completing work, run the most relevant checks available, for example:

- pnpm lint
- pnpm test
- pnpm build
- package-specific tests
- route smoke checks
- i18n validation
- deployment-readiness checks

If validation cannot be run, say exactly why.
Do not claim success without evidence.

## Final Report

Every completed task should include:

- what changed
- files touched
- validation run
- known risks
- what should happen next

🖥️ Where it works
This is mainly for local AI-assisted development workflows:

• VS Code
• CLI
• Copilot-style coding agents
• PR preparation
• monorepo cleanup
• production-readiness checks
• SaaS feature extraction and refactoring

It works best in a TypeScript / Next.js / pnpm / Turborepo-style monorepo where app boundaries matter.

💡 One thing I learned
The biggest lesson: AI coding gets better when the workflow is constrained.

For production work, the hard part is not only generating code.
The hard part is reducing blast radius.

The skill became less about “write this feature” and more about:

• investigate first
• change less
• validate more
• preserve boundaries
• document clearly
• make review easier

A good SKILL.md is not just a reusable prompt.
It is a workflow contract for how the agent should behave inside a real codebase.

Auto Sync my website to SABC Channels