Skip to content
Skills Library
Documents & office · Writing

markdown-documentation

/markdown-documentation

Use when writing technical documentation, READMEs, or project documentation in markdown. Covers structure, conventions, and best practices.

Repository
han ↗
Licence
Apache-2.0
Last repository change
08.09.2026

Assessment and security

100/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
1
Scripts
0
HTML comments
6
URLs in SKILL.md
0
Deprecation

No signals detected. Repository changed on 08.09.2026, without references to retired models or APIs.

Licence

Apache-2.0, otwarta: można używać i zmieniać, z zachowaniem licencji i informacji o zmianach.

What to check before installing
  • SKILL.md zawiera komentarze HTML (6). Nie widać ich w podglądzie Markdown, a model je czyta.

What it does and when to use it

Use when writing technical documentation, READMEs, or project documentation in markdown. Covers structure, conventions, and best practices.

Original author description

Use when writing technical documentation, READMEs, or project documentation in markdown. Covers structure, conventions, and best practices.

How it works

  1. README Structure
  2. Document Organization
  3. Writing Style
  4. Code Documentation
  5. Admonitions and Callouts
  6. API Documentation
  7. Changelogs
  8. Diagrams
  9. Best Practices
  10. Common Documentation Files
Original SKILL.md headings · 368 lines, 841 words
SKILL.md preview
---
name: markdown-documentation
user-invocable: false
description: Use when writing technical documentation, READMEs, or project documentation in markdown. Covers structure, conventions, and best practices.
allowed-tools:
  - Read
  - Write
  - Edit
  - Grep
  - Glob
---

# Markdown Documentation

Best practices for writing effective technical documentation in markdown.

## README Structure

### Minimal README

```markdown
# Project Name

Brief description of what this project does.

## Installation

Instructions to install.

## Usage

Basic usage example.

## License

MIT
```

### Comprehensive README

```markdown
# Project Name

![Build Status](badge-url)
![Version](badge-url)

One-paragraph description of the project.

## Features

- Feature one
- Feature two
- Feature three

## Installation

### Prerequisites

- Requirement 1
- Requirement 2

### Steps

Instructions...

## Usage

### Basic Example

Code example...

### Advanced Usage

More examples...

## Configuration

Configuration options...

## API Reference

API documentation...

## Contributing

See [CONTRIBUTING.md](CONTRIBUTING.md)

## License

MIT License - see [LICENSE](LICENSE)
```

## Document Organization

### File Naming

```
docs/
├── README.md           # Entry point
├── CONTRIBUTING.md     # Contribution guidelines
├── CHANGELOG.md        # Version history
├── CODE_OF_CONDUCT.md  # Community guidelines
├── getting-started.md  # Onboarding guide
├── api/
│   ├── README.md       # API overview
│   └── endpoints.md    # Endpoint reference
└── guides/
    ├── installation.md
    └── configuration.md
```

### Linking Between Documents

```markdown
See the [installation guide](./guides/installation.md) for details.

For API reference, check [endpoints](./api/endpoints.md#authentication).
```

## Writing Style

### Be Concise

```markdown
<!-- Bad -->
In order to install the application, you will need to run the following command.

<!-- Good -->
Install the application:
```

### Use Active Voice

```markdown
<!-- Bad -->
The configuration file should be created in the home directory.

<!-- Good -->
Create the configuration file in your home directory.
```

### Address the Reader

```markdown
<!-- Bad -->
Users can configure the timeout setting.

<!-- Good -->
You can configure the timeout setting.
```

## Code Documentation

### Inline Code vs Code Blocks

```markdown
Use `npm install` to install dependencies.

For multiple commands, use a code block:

```bash
npm install
npm run build
npm start
```

```

### Command Examples

Show both command and output:

```bash
$ npm --version
10.2.0
```

### Configuration Examples

Always show complete, valid examples:

Create `config.json`:

```json
{
  "port": 3000,
  "debug": true,
  "database": {
    "host": "localhost",
    "name": "myapp"
  }
}
```

## Admonitions and Callouts

### GitHub-Style Alerts

```markdown
> [!NOTE]
> Useful information that users should know.

> [!TIP]
> Helpful advice for doing things better.

> [!IMPORTANT]
> Key information users need to know.

> [!WARNING]
> Urgent info that needs immediate attention.

> [!CAUTION]
> Advises about risks or negative outcomes.
```

### Custom Callouts (Emoji-Based)

```markdown
⚠️ **Warning**: This action cannot be undone.

💡 **Tip**: Use environment variables for sensitive data.

📝 **Note**: This feature requires version 2.0+.
```

## API Documentation

### Endpoint Documentation

#### Create User

Creates a new user account.

**Request:** `POST /api/users`

**Headers:**

| Header | Value | Required |
|--------|-------|:--------:|
| Content-Type | application/json | ✅ |
| Authorization | Bearer {token} | ✅ |

**Body:**

```json
{
  "name": "John Doe",
  "email": "john@example.com"
}
```

**Response (201):**

```json
{
  "id": "abc123",
  "name": "John Doe",
  "email": "john@example.com"
}
```

**Error (400):**

```json
{
  "error": "Invalid email format"
}
```

### Function Documentation

#### `parseConfig(path, options?)`

Parses a configuration file.

**Parameters:**

| Name | Type | Default | Description |
|------|------|---------|-------------|
| path | string | — | Path to config file |
| options.strict | boolean | false | Throw on unknown keys |
| options.env | boolean | true | Expand environment variables |

**Returns:** `Config` - Parsed configuration object

**Throws:**

- `FileNotFoundError` - Config file doesn't exist
- `ParseError` - Invalid JSON/YAML syntax

**Example:**

```javascript
const config = parseConfig('./config.json', { strict: true });
```

## Changelogs

### Keep a Changelog Format

```markdown
# Changelog

All notable changes to this project will be documented in this file.

## [Unreleased]

### Added
- New feature X

### Changed
- Updated dependency Y

## [1.2.0] - 2024-01-15

### Added
- Feature A
- Feature B

### Fixed
- Bug in feature C

### Deprecated
- Old API endpoint

## [1.1.0] - 2024-01-01

### Added
- Initial release
```

## Diagrams

### Mermaid (GitHub Supported)

````markdown
```mermaid
graph LR
    A[Start] --> B{Decision}
    B -->|Yes| C[Action 1]
    B -->|No| D[Action 2]
    C --> E[End]
    D --> E
```
````

### ASCII Diagrams

````markdown
```
┌─────────┐     ┌─────────┐     ┌─────────┐
│ Client  │────▶│ Server  │────▶│Database │
└─────────┘     └─────────┘     └─────────┘
```
````

## Best Practices

1. **Start with why**: Explain what the project does and why it exists
2. **Show, don't tell**: Provide working code examples
3. **Keep it current**: Update docs when code changes
4. **Test examples**: Ensure code samples actually work
5. **Use consistent terminology**: Define terms and use them consistently
6. **Provide context**: Link to prerequisites and related docs
7. **Consider your audience**: Write for your users' skill level
8. **Include troubleshooting**: Document common errors and solutions

## Common Documentation Files

| File | Purpose |
|------|---------|
| README.md | Project overview and quick start |
| CONTRIBUTING.md | How to contribute |
| CHANGELOG.md | Version history |
| LICENSE | Legal terms |
| CODE_OF_CONDUCT.md | Community guidelines |
| SECURITY.md | Security policy |
| SUPPORT.md | How to get help |

Versions

The database has no other skills named markdown-documentation.

Identical content appears in 1 other GitHub folders. We show one copy with the highest score.

Database snapshot: 13.11.2026 · package version 7392fd3c37ca (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

  • 100markdown-writer
    Generates well-structured technical documentation in Markdown. Use when a user asks to write docs, create a README, document an API, write a how-to guide, generate technical documentation, create a changelog, write a project wiki, or produce any structured Markdown content.…
  • 90technical-documentation
    Use this skill when creating, maintaining, or auditing technical documentation — READMEs, ADRs, API docs, runbooks, onboarding guides, changelogs, knowledge bases, and AI agent context files (AGENTS.md/CLAUDE.md). Covers documentation- driven development, OpenAPI generation,…
  • 95technical-writing
    Write clear, comprehensive technical documentation. Use when creating specs, architecture docs, runbooks, or API documentation. Handles technical specifications, system design docs, operational guides, and developer documentation with industry best practices.
  • 90docs-writer
    Write, review, and edit documentation files with consistent structure, tone, and technical accuracy. Use when creating docs, reviewing markdown files, writing READMEs, updating `/docs` directories, or when user says "write documentation", "review this doc", "improve this…
  • 100documentation
    Use this skill when the user asks you to write, update, or fix project documentation — READMEs, API docs, user guides, ADRs, or other Markdown docs. Also use when code changes need user-facing docs updates. Only write Markdown files; do not use for implementation, planning or test work.
  • 100common-documentation
    Write effective code comments, READMEs, and technical documentation following intent-first principles. Use when adding comments, writing docstrings, creating READMEs, or updating any documentation.

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.