🛠️ 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.

[turkeybooty0211-netizen]

Fuck off

…

On Sat, May 23, 2026, 11:06 AM Jonathan Miller ***@***.***> wrote: 🧩 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. ------------------------------ 📄 Your 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. — Reply to this email directly, view it on GitHub <#194436 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CAMPZ2TM4HUSDX5WB6VDDE344HEBFAVCNFSM6AAAAACYMPBFC2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMBTGM2DSMI> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[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.