agentleFS
pr-pmpr-pm/prpm/.claude/skills/creating-agents-md/SKILL.md

creating-agents-md

Skill124 starsChanged 8 months agoMITView on GitHub

Use when creating agents.md files - provides plain markdown format with NO frontmatter, free-form structure, and project context guidelines for AI coding assistants

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Free-form content: - No required structure

    line 14
  2. Distinctive:

    Plain markdown: No YAML frontmatter or special syntax

    line 301
  3. Distinctive:

    Human-readable: Write for both AI and human developers

    line 302
  4. Distinctive:

    Project-specific: Avoid generic advice that AI already knows

    line 303
  5. Distinctive:

    When converting to agents.md:

    line 308
  6. Distinctive:

    Strip all frontmatter: - Remove YAML headers completely

    line 310
  7. Distinctive:

    Focus on content: - Keep only markdown content

    line 311
  8. Distinctive:

    Simplify: - Remove format-specific features (globs, regex, etc.)

    line 313
  9. Distinctive:

    Plain markdown only: - Use standard markdown syntax

    line 314

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Creating agents.md Files

Overview

The agents.md format provides project-specific context for AI coding assistants. It's the simplest format: plain markdown only with NO YAML frontmatter, NO special syntax.

CRITICAL:

  • No frontmatter - Pure markdown only (no YAML)
  • Free-form content - No required structure
  • Single file - Typically agents.md in project root

Quick Reference

AspectRequirement
FormatPlain markdown
FrontmatterNone (forbidden)
StructureFree-form
File locationagents.md in project root

Creating agents.md Files

Plain markdown with no frontmatter:

# TaskMaster Development Guide

## Project Overview

TaskMaster is a task management application for remote teams, built with real-time collaboration features and offline-first architecture.

## Architecture

### Frontend

- React 18 with TypeScript
- Vite for build tooling
- Zustand for state management
- React Query for server state
- Tailwind CSS for styling

### Backend

- Node.js with Express
- PostgreSQL with Prisma ORM
- WebSocket for real-time features
- Redis for caching and pub/sub
- JWT for authentication

## Coding Conventions

- Use TypeScript strict mode
- Functional components with hooks (no class components)
- Server components by default in Next.js
- Colocate tests with source files (*.test.tsx)
- Use Zod for runtime validation

## File Structure

\`\`\`
src/
  components/     # Reusable UI components
  features/       # Feature-based modules
  hooks/          # Custom React hooks
  lib/            # Utility functions
  pages/          # Route pages
  types/          # TypeScript types
\`\`\`

## Development Workflow

1. Create feature branch from `main`
2. Write tests first (TDD)
3. Implement feature
4. Run `pnpm test` and `pnpm lint`
5. Create PR with description
6. Merge after approval

## Testing

- Use Vitest for unit tests
- Use Playwright for E2E tests
- Aim for 80% coverage on new code
- Mock external dependencies

What to Include

Focus on project-specific information AI doesn't already know:

High Priority:

  • Project overview and purpose
  • Architecture decisions and patterns
  • Tech stack and dependencies
  • File structure and organization
  • Coding conventions
  • Development workflow
  • Testing approach
  • Domain knowledge and business logic

Skip:

  • General programming best practices
  • Language syntax explanations
  • Framework basics
  • Obvious code quality rules

Example: Backend API Project

# Payment Gateway API

## Overview

RESTful API for payment processing with support for multiple payment providers.

## Tech Stack

- Node.js 20.x
- Express
- PostgreSQL 15
- Redis for rate limiting
- Stripe and PayPal integrations

## API Design

### Endpoints

All endpoints follow REST conventions:

- `GET /api/payments` - List payments
- `GET /api/payments/:id` - Get payment details
- `POST /api/payments` - Create payment
- `PUT /api/payments/:id` - Update payment
- `DELETE /api/payments/:id` - Cancel payment

### Error Handling

Return consistent error format:

\`\`\`json
{
  "error": {
    "code": "PAYMENT_FAILED",
    "message": "Payment could not be processed",
    "details": {...}
  }
}
\`\`\`

## Security

- All endpoints require JWT authentication
- Rate limiting: 100 requests/minute per IP
- Input validation with Zod schemas
- SQL injection prevention via Prisma
- PCI DSS compliance for payment data

## Database

### Conventions

- Use snake_case for table/column names
- Add timestamps (created_at, updated_at) to all tables
- Use UUIDs for primary keys
- Foreign keys follow `{table}_id` pattern

Example: Frontend Component Library

# Design System Components

A React component library following Atomic Design principles.

## Component Structure

All components follow this structure:

\`\`\`
ComponentName/
  ComponentName.tsx       # Main component
  ComponentName.test.tsx  # Tests
  ComponentName.stories.tsx # Storybook stories
  index.ts                 # Exports
\`\`\`

## Styling

- Use Tailwind CSS utility classes
- Create custom classes in `styles/components/` for complex components
- Follow BEM naming for custom classes
- Responsive by default (mobile-first)

## TypeScript

\`\`\`typescript
// Good: Explicit prop types
interface ButtonProps {
  variant: 'primary' | 'secondary' | 'ghost';
  size?: 'sm' | 'md' | 'lg';
  disabled?: boolean;
  onClick?: () => void;
  children: React.ReactNode;
}

export function Button({ variant, size = 'md', ...props }: ButtonProps) {
  return <button className={cn(variants[variant], sizes[size])} {...props} />;
}
\`\`\`

## Accessibility

- All interactive elements must be keyboard accessible
- Use semantic HTML (button, nav, main, etc.)
- Include ARIA labels for icon-only buttons
- Test with screen readers
- Maintain minimum 4.5:1 contrast ratio

Content Format

Free-form markdown including:

  • Project overview: Purpose and goals
  • Architecture notes: Technical decisions and patterns
  • Conventions: Coding standards and practices
  • Context: Domain knowledge and business logic
  • Workflows: Development processes
  • File structure: Directory organization
  • Dependencies: Key libraries and tools

Common Mistakes

MistakeFix
Adding YAML frontmatterNo frontmatter allowed - plain markdown only
Generic best practicesFocus on project-specific patterns
Verbose explanationsBe concise, AI already knows general concepts
Language tutorialsSkip basics, focus on project conventions
Missing contextInclude domain knowledge and business logic

Writing Style

Concise (Good):

## Testing

- Vitest for unit tests
- Playwright for E2E
- 80% coverage target
- Mock external dependencies

Verbose (Bad):

## Testing

When you are writing tests, it's important to understand that we use Vitest
for our unit tests because it's fast and modern. For end-to-end testing,
we have chosen to use Playwright because it provides excellent cross-browser
support and has a great developer experience...

File Placement

Typically in project root:

project-root/
  agents.md           # Main file
  src/
  tests/
  package.json

Can also be in subdirectories for monorepos:

monorepo/
  packages/
    frontend/
      agents.md       # Frontend-specific context
    backend/
      agents.md       # Backend-specific context

Validation

Documentation: /Users/khaliqgant/Projects/prpm/app/packages/converters/docs/agents-md.md

Schema location: /Users/khaliqgant/Projects/prpm/app/packages/converters/schemas/agents-md.schema.json

Best Practices

  1. Be concise: Focus on project-specific info (AI knows general practices)
  2. Keep updated: Review and update as project evolves
  3. Real examples: Show actual code patterns from your project
  4. Plain markdown: No YAML frontmatter or special syntax
  5. Human-readable: Write for both AI and human developers
  6. Project-specific: Avoid generic advice that AI already knows
  7. Natural structure: Organize however makes sense for your project

Migration from Other Formats

When converting to agents.md:

  1. Strip all frontmatter - Remove YAML headers completely
  2. Focus on content - Keep only markdown content
  3. Combine files - Merge multiple rule files into one cohesive document
  4. Simplify - Remove format-specific features (globs, regex, etc.)
  5. Plain markdown only - Use standard markdown syntax

Official Specification

For the authoritative specification, see: https://github.com/openai/agents.md


Remember: agents.md uses plain markdown with NO frontmatter. Free-form structure. Focus on project-specific context AI doesn't already know.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.