← Back to EasyMD

Markdown templates

6 ready-to-use Markdown templates — copy one, or open it straight in EasyMD

📚

TIL — Today I Learned

A daily learning log for developers. One entry a day, and it compounds.

DevTILLearning log
Markdown source
# TIL — 2024-01-15

## Today I Learned

### Topic: [what you looked into]

#### Context
- Why this came up
- What problem you were trying to solve

#### Key takeaways
- Point 1
- Point 2
- Point 3

#### Code example

```javascript
// Your example goes here
const example = "Hello, World!";
console.log(example);
```

#### References
- [Official docs](https://example.com)
- [Blog post that helped](https://example.com)

#### Next steps
- [ ] Something to read up on
- [ ] Try it in a real project

---
*Written 2024-01-15 | Tags: #JavaScript #TIL*
📂

GitHub README

A README for an open-source project — from installation through to contributing.

GitHubREADMEOpen Source
Markdown source
# Project Name

[![License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
[![Version](https://img.shields.io/badge/version-1.0.0-green.svg)]()

> One sentence describing what this project is and who it is for.

## ✨ Features

- ⚡ Feature one — a short description
- 🎨 Feature two — a short description
- 🔒 Feature three — a short description

## 🚀 Getting started

### Prerequisites

```bash
node >= 18.0.0
npm >= 9.0.0
```

### Installation

```bash
# Clone the repository
git clone https://github.com/username/project-name.git

# Move into the directory
cd project-name

# Install dependencies
npm install

# Start the dev server
npm run dev
```

## 📖 Usage

```javascript
import { example } from 'project-name';

const result = example({ option: 'value' });
console.log(result);
```

## 🗂️ Project structure

```
project-name/
├── src/
│   ├── components/
│   ├── utils/
│   └── index.js
├── tests/
├── docs/
└── README.md
```

## 🤝 Contributing

1. Fork the repository
2. Create a feature branch (`git checkout -b feature/amazing-feature`)
3. Commit your changes (`git commit -m 'Add amazing feature'`)
4. Push the branch (`git push origin feature/amazing-feature`)
5. Open a pull request

## 📄 License

Released under the MIT License. See [LICENSE](LICENSE) for details.

## 📬 Contact

Your Name — [@username](https://twitter.com/username) — email@example.com

Project link: [https://github.com/username/project-name](https://github.com/username/project-name)
🔧

API reference

A standard layout for REST endpoint specs and technical documentation.

APITechnical docsREST
Markdown source
# API Reference — Service API v1.0

**Base URL**: `https://api.example.com/v1`

**Authentication**: every request needs a bearer token.

```
Authorization: Bearer {your-api-token}
```

---

## Endpoints

### 1. List users

**GET** `/users`

Returns a paginated list of users.

#### Query parameters

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `page` | integer | No | Page number (default: 1) |
| `limit` | integer | No | Items per page (default: 20) |
| `search` | string | No | Search keyword |

#### Response

```json
{
  "status": "success",
  "data": [
    { "id": 1, "name": "Alex", "email": "alex@example.com" }
  ],
  "meta": { "page": 1, "limit": 20, "total": 137 }
}
```

---

### 2. Create a user

**POST** `/users`

#### Request body

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `name` | string | Yes | Display name |
| `email` | string | Yes | Must be unique |
| `role` | string | No | `admin` or `member` (default: `member`) |

```json
{
  "name": "Alex",
  "email": "alex@example.com",
  "role": "member"
}
```

---

## Error codes

| Code | Meaning | When it happens |
|------|---------|-----------------|
| `400` | Bad Request | A required field is missing or malformed |
| `401` | Unauthorized | The token is missing or invalid |
| `404` | Not Found | No resource with that identifier |
| `409` | Conflict | The email address is already in use |
| `429` | Too Many Requests | Rate limit exceeded |

## Rate limits

- 1,000 requests per hour per token
- Remaining quota is returned in the `X-RateLimit-Remaining` header
📝

Meeting notes

Structure that keeps decisions and action items from getting lost.

MeetingsTeamWork
Markdown source
# [Meeting name] — 2024-01-15

**Time**: 14:00 – 15:00
**Location**: Room A / video call
**Attendees**: Alex, Sam, Jordan
**Notes by**: Alex

---

## Agenda

1. Review of last week
2. This week's priorities
3. Blockers

---

## Discussion

### 1. Review of last week
- What was completed
- What slipped, and why

### 2. This week's priorities
- Priority one — owner, target date
- Priority two — owner, target date

### 3. Blockers
- What is blocked, and what would unblock it

---

## Decisions

- **Decision 1** — what was decided and the reasoning
- **Decision 2** — what was decided and the reasoning

---

## Action items

- [ ] **Alex** — draft the spec — by Jan 19
- [ ] **Sam** — review the API design — by Jan 17
- [ ] **Jordan** — set up the staging environment — by Jan 22

---

## Next meeting

**2024-01-22 (Mon) 14:00**
🎯

Project plan

For the start of a new project — goals, scope, schedule, and risks.

PlanningProjectPM
Markdown source
# [Project name] — Project plan

**Version**: 1.0
**Date**: 2024-01-15
**Status**: Draft / In review / Approved
**Owner**: [name]

---

## Background and purpose

Why this project exists. What problem it solves, and what happens if it is not done.

## Goals

| Goal | How it is measured | Target |
|------|--------------------|--------|
| Goal one | Metric | Number |
| Goal two | Metric | Number |

## Scope

### In scope
- Item one
- Item two

### Out of scope
- Item one — and why it is excluded
- Item two — and why it is excluded

## Schedule

| Phase | Period | Deliverable |
|-------|--------|-------------|
| Discovery | Jan 15 – Jan 26 | Requirements document |
| Design | Jan 29 – Feb 9 | Design and specs |
| Build | Feb 12 – Mar 15 | Working software |
| Testing | Mar 18 – Mar 29 | Test report |
| Launch | Apr 1 | Live |

## Risks

| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| Risk one | Medium | High | What we will do |
| Risk two | Low | Medium | What we will do |

## Open questions

- [ ] Question that still needs an answer
- [ ] Decision that has not been made yet
✍️

Blog post

A structure for technical and personal blog posts that keeps the thread.

BlogWritingContent
Markdown source
# [Title — say what the reader gets]

> One or two sentences on what this post covers and who it is for.

---

## The problem

What situation prompted this. Be concrete — a real case is worth more than an abstract description.

## What I tried first

The approach that seemed obvious, and why it did not work. This is often the most useful part for the reader.

## What worked

The approach that did work, with enough detail to reproduce.

```javascript
// Code that shows the actual solution
const solution = doTheThing();
```

## Why it works

The reasoning underneath. Without this the reader can copy the code but cannot adapt it.

## What to watch out for

- Edge case one
- Edge case two
- Where this approach stops being appropriate

## Summary

- Key point one
- Key point two
- Key point three

---

## References

- [Official documentation](https://example.com)
- [Related post](https://example.com)

---
*Written by [author]. Corrections and feedback welcome in the comments.*

📝 Build your own template in EasyMD

Open the EasyMD editor