creating-copilot-packages
Skill124 starsChanged 8 months agoMITView on GitHub
Use when creating GitHub Copilot instructions - provides repository-wide and path-specific formats, applyTo patterns, excludeAgent options, and natural language markdown style
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 256
Plain language: Write for human readability
- Distinctive: line 363
Natural language: Write as you would explain to a developer
- Distinctive: line 364
Update regularly: Keep instructions in sync with codebase
- Distinctive: line 365
Granular targeting: Use path-specific for different contexts
- Very specific: line 366
Descriptive filenames: Use clear names like api-endpoints.instructions.md
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Creating GitHub Copilot Packages
Overview
GitHub Copilot uses natural language markdown instructions. Repository-wide instructions use plain markdown with NO frontmatter. Path-specific instructions use YAML frontmatter with applyTo field.
Package Types
| Type | File Location | Frontmatter |
| Repository-wide | .github/copilot-instructions.md | None (plain markdown) |
| Path-specific | .github/instructions/*.instructions.md | Required (applyTo field) |
Quick Reference
Repository-Wide (No Frontmatter)
# API Development Guidelines
Follow REST best practices when developing API endpoints.
## Principles
- Use semantic HTTP methods (GET, POST, PUT, DELETE)
- Return appropriate status codes
- Include error messages in response bodyPath-Specific (With Frontmatter)
---
applyTo: "src/api/**/*.ts" # REQUIRED
excludeAgent: "code-review" # Optional
---Creating Repository-Wide Instructions
File: .github/copilot-instructions.md
Plain markdown with NO frontmatter:
# TaskManager Development Guidelines
## Architecture
### Frontend
- React 18 with TypeScript
- Vite for build tooling
- Zustand for state management
- Tailwind CSS for styling
### Backend
- Node.js with Express
- PostgreSQL with Prisma ORM
- JWT for authentication
## Coding Conventions
- Use TypeScript strict mode
- Functional components with hooks
- Colocate tests with source files
- Use Zod for runtime validation
## Testing
- Use Vitest for unit tests
- Aim for 80% coverage on new code
- Mock external dependencies
## Examples
\`\`\`typescript
// Good: RESTful endpoint
app.get('/api/users', async (req, res) => {
try {
const users = await db.users.findAll();
res.json({ users });
} catch (error) {
res.status(500).json({ error: 'Failed to fetch users' });
}
});
\`\`\`Creating Path-Specific Instructions
File: .github/instructions/api-endpoints.instructions.md
REQUIRED: File name must end with .instructions.md
Single Pattern
---
applyTo: "app/models/**/*.rb"
---
# Model Guidelines
These rules apply only to Ruby model files.
## Conventions
- Use ActiveRecord validations
- Define associations explicitly
- Add database indexes for foreign keysMultiple Patterns (Comma-Separated)
---
applyTo: "**/*.ts,**/*.tsx"
---
# TypeScript Guidelines
These rules apply to all TypeScript files.
## Type Safety
- Always define explicit types for function parameters
- Avoid using `any` type
- Use `unknown` instead of `any` for truly unknown typesMultiple Patterns (Array)
---
applyTo:
- "src/api/**/*.ts"
- "src/services/**/*.ts"
---
# API Endpoint Guidelines
These rules apply only to API files.
## Requirements
- All endpoints must have error handling
- Use async/await for database calls
- Log all errors with structured logging
- Validate input with Zod schemas
## Example
\`\`\`typescript
import { z } from 'zod';
const createUserSchema = z.object({
name: z.string().min(1),
email: z.string().email(),
});
app.post('/api/users', async (req, res) => {
try {
const data = createUserSchema.parse(req.body);
const user = await db.users.create(data);
res.status(201).json({ user });
} catch (error) {
if (error instanceof z.ZodError) {
return res.status(400).json({ error: error.errors });
}
logger.error('Failed to create user', { error });
res.status(500).json({ error: 'Internal server error' });
}
});
\`\`\`ApplyTo Patterns
Common Glob Patterns
# All TypeScript files
applyTo: "**/*.ts"
# React components
applyTo: "src/**/*.{tsx,jsx}"
# API routes
applyTo: "src/api/**/*.ts"
# Test files
applyTo: "**/*.test.ts"
# All files (any of these work)
applyTo: "**"
applyTo: "*"
applyTo: "**/*"
# Multiple patterns (array)
applyTo:
- "src/api/**/*.ts"
- "src/services/**/*.ts"
- "src/routes/**/*.ts"ExcludeAgent Field
Control which Copilot agent uses the instructions:
Coding Agent Only
---
applyTo: "**"
excludeAgent: "code-review"
---
# Coding Agent Only Instructions
These instructions are only used by the Copilot coding agent.
- Focus on implementation patterns
- Suggest modern syntax alternatives
- Optimize for readability in generated codeCode Review Only
---
applyTo: "**/*.test.ts"
excludeAgent: "coding-agent"
---
# Code Review Only Instructions
These instructions are only used by Copilot code review.
- Verify test coverage is adequate
- Check for proper assertions
- Ensure tests are not flakyContent Format
Natural language markdown with:
- Clear headings: Organize with H1/H2
- Bullet points: For lists of rules
- Code examples: Show concrete patterns
- Plain language: Write for human readability
- Actionable guidance: Specific, not generic
Example: Testing Standards
---
applyTo: "**/*.test.ts"
---
# Testing Standards
All tests use Jest and React Testing Library.
## Component Tests
- Test user interactions, not implementation
- Use `screen.getByRole` over `getByTestId`
- Mock external dependencies
- Test accessibility (ARIA roles)
## Example
\`\`\`typescript
test('submits form when valid', async () => {
render(<LoginForm />);
await userEvent.type(screen.getByLabelText('Email'), 'test@example.com');
await userEvent.type(screen.getByLabelText('Password'), 'password123');
await userEvent.click(screen.getByRole('button', { name: 'Login' }));
expect(mockLogin).toHaveBeenCalledWith({
email: 'test@example.com',
password: 'password123',
});
});
\`\`\`Example: Database Patterns
---
applyTo:
- "src/db/**/*.ts"
- "src/repositories/**/*.ts"
---
# Database Access Patterns
We use Prisma ORM with PostgreSQL.
## Query Guidelines
- Always use transactions for multi-step operations
- Use `select` to limit returned fields
- Include proper indexes
- Handle unique constraint violations
## Example
\`\`\`typescript
// Good: Transaction with error handling
async function transferFunds(fromId: string, toId: string, amount: number) {
try {
await prisma.$transaction(async (tx) => {
await tx.account.update({
where: { id: fromId },
data: { balance: { decrement: amount } },
});
await tx.account.update({
where: { id: toId },
data: { balance: { increment: amount } },
});
});
} catch (error) {
if (error.code === 'P2025') {
throw new Error('Account not found');
}
throw error;
}
}
\`\`\`Common Mistakes
| Mistake | Fix |
| Frontmatter in repo-wide | Repository-wide uses NO frontmatter |
| Missing .instructions.md suffix | Path-specific files must end with .instructions.md |
| Missing applyTo field | Path-specific requires applyTo in frontmatter |
| Generic advice | Focus on project-specific patterns |
| No code examples | Show concrete patterns from your project |
Validation
Schema location: /Users/khaliqgant/Projects/prpm/app/packages/converters/schemas/copilot.schema.json
Documentation: /Users/khaliqgant/Projects/prpm/app/packages/converters/docs/copilot.md
Best Practices
- Be specific: Generic advice is less useful than project-specific patterns
- Show examples: Code samples are more effective than descriptions
- Keep it short: Copilot processes limited context
- Natural language: Write as you would explain to a developer
- Update regularly: Keep instructions in sync with codebase
- Granular targeting: Use path-specific for different contexts
- Descriptive filenames: Use clear names like
api-endpoints.instructions.md
Storage Locations
Instructions can be stored in multiple locations:
- Repository:
.github/copilot-instructions.md(repository-wide) - Repository:
.github/instructions/*.instructions.md(path-specific) - Team Dashboard: Created via Copilot Dashboard for team sharing
Remember: Repository-wide uses NO frontmatter. Path-specific requires applyTo field and .instructions.md suffix.
In this repository64 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- beanstalk-deployCursor rule
- .cursor/rules/core-principles.mdcCursor rule
- .cursor/rules/creating-agents-md.mdcCursor rule
- .cursor/rules/creating-claude-agents.mdCursor rule
- .cursor/rules/creating-claude-commands.mdCursor rule
- .cursor/rules/creating-claude-hooks.mdCursor rule
- .cursor/rules/creating-continue-packages.mdCursor rule
- .cursor/rules/creating-copilot-packages.mdCursor rule
- .cursor/rules/creating-cursor-commands.mdCursor rule
- .cursor/rules/creating-cursor-rules.mdcCursor rule
- .cursor/rules/creating-kiro-agents.mdcCursor rule
- .cursor/rules/creating-kiro-packages.mdCursor rule
- .cursor/rules/creating-skills.mdcCursor rule
- .cursor/rules/creating-windsurf-packages.mdCursor rule
- .cursor/rules/elastic-beanstalk-deployment.mdCursor rule
- .cursor/rules/format-conversion.mdcCursor rule
- .cursor/rules/github-actions-testing.mdcCursor rule
- .cursor/rules/karen-repo-reviewer.mdcCursor rule
- .cursor/rules/prpm-json-best-practices.mdcCursor rule
- .cursor/rules/self-improve-cursor.mdcCursor rule
- .cursor/rules/testing-patterns.mdcCursor rule
- .cursor/rules/typescript-type-safety.mdcCursor rule
- .cursor/rules/typescript-type-specialist.mdcCursor rule
- creating-agent-skillsSkill
- adding-new-ai-formatSkill
- agent-builderSkill
- aws-beanstalk-expertSkill
- beanstalk-deploySkill
- claude-hook-writerSkill
- creating-agents-mdSkill
- creating-claude-agentsSkill
- creating-claude-commandsSkill
- creating-claude-hooksSkill
- creating-claude-rulesSkill
- creating-continue-packagesSkill
- creating-cursor-commandsSkill
- creating-cursor-rules-skillSkill
- creating-kiro-agentsSkill
- creating-kiro-packagesSkill
- creating-opencode-agentsSkill
- creating-opencode-pluginsSkill
- creating-skillsSkill
- creating-windsurf-packagesSkill
- creating-zed-extensionsSkill
- documentation-standardsSkill
- elastic-beanstalk-deploymentSkill
- github-actions-testingSkill
- human-writingSkill
- integrating-stripe-webhooksSkill
- karen-repo-reviewerSkill
- npm-trusted-publishingSkill
- osgrepSkill
- postgres-migrationsSkill
- prpm-developmentSkill
- prpm-json-best-practicesSkill
- pulumi-troubleshootingSkill
- self-improvingSkill
- slash-command-builderSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

