Should I write docs before or after building?

Write the README before building — it's the best specification tool available. Explaining what your project does in plain English before writing code forces you to clarify assumptions and makes the final product better.

Which model writes the best technical documentation?

Claude is strongest for technical docs — it follows complex structural templates precisely, writes accurate code examples in multiple languages, and maintains consistent terminology throughout a long document.

How do I keep documentation up to date?

Make documentation part of your definition of done. For each code change, update the relevant doc section. Automated doc testing (checking that code examples in docs actually run) is the gold standard.

Should documentation live in the repo or on a separate docs site?

Start with the repo (README + /docs folder). Move to a dedicated docs site (Docusaurus, Mintlify, GitBook) when the project is complex enough that a README isn't navigable. Most small-to-medium projects are better served by excellent README documentation.

DeepSeek Technical Documentation Writer Prompt

Write clear, comprehensive technical documentation that developers actually use.

Category

💻 Coding

Difficulty

Intermediate

Models

Last Updated

2026-06-28

Works with

ChatGPT Claude DeepSeek

⚙️ Fill in your variables

project name and description

doc type

audience

existing docs

📋 Prompt

You are a technical writer with 10+ years of experience creating documentation that reduces support tickets by 50%.

Project: [project name and description]
Doc type: [doc type — README/setup guide/architecture overview/user guide/API reference/changelog]
Audience: [audience — beginner developer/senior engineer/non-technical user/open source contributor]
Existing docs: [existing docs — none/partial/full but outdated]

Task: Write complete [doc type]:

FOR A README:
1. Badge row: build status, version, license
2. One-liner: what the project does in under 15 words
3. Key features: 5 bullet points
4. Quick start: working from zero to 'it works' in under 5 minutes
5. Installation: prerequisites + step-by-step
6. Usage: basic example + advanced example
7. Configuration: all environment variables and config options
8. Contributing: how to file issues and submit PRs
9. License

FOR A SETUP GUIDE:
1. Prerequisites checklist
2. Step-by-step installation (numbered, one action per step)
3. Environment configuration
4. Verification: how to confirm it worked
5. Common errors + fixes
6. Next steps

Format: Markdown. Code blocks for all commands. Platform-specific notes in callout boxes.

📄 Example output

# ToolsNova AI Prompt Library

[![Build](https://img.shields.io/badge/build-passing-brightgreen)](https://toolsnova.net) [![License](https://img.shields.io/badge/license-MIT-blue)](LICENSE) [![Prompts](https://img.shields.io/badge/prompts-200+-orange)](data/prompts.json)

A static-site generator that builds 300+ SEO-optimised AI prompt pages from JSON data files.

## Features
- 🤖 200+ professional prompts across 12 categories
- ⚡ Generates 300+ HTML pages in under 10 seconds
- 🔍 Full on-page SEO: schema, canonical, OG, sitemap
- 📱 Dark/light mode, mobile-first, accessible
- 🔧 Add new prompts by editing JSON — no HTML required

## Quick Start

```bash
git clone https://github.com/farhan707/toolsnova
cd toolsnova
python3 generator.py
# Open prompts/chatgpt/seo-blog-post-writer.html in browser
```

## Adding a Prompt

1. Open `data/prompts.json`
2. Add your prompt object (see schema below)
3. Run `python3 generator.py --prompt your-slug`
4. Check `prompts/chatgpt/your-slug.html`

## Prompt Schema

```json
{
"id": 201,
"slug": "your-prompt-slug",
"title": "Your Prompt Title",
"category": "writing",
"supported_models": ["chatgpt","claude"],
"prompt_text": "Your full prompt text with [variables]",
"variables": ["variable one","variable two"],
"example_output": "What the output looks like"
}
```

🏆

Best model for this prompt

Claude

Claude (Opus 4 / Sonnet 4)

💡 Pro Tips

The Quick Start section should get someone from zero to 'it works' in under 5 minutes — if it takes longer, cut steps or add prerequisites

Code blocks for every command — never write shell commands in prose

Include the expected output after every command so users know they're on track

Common errors section reduces support load more than any other section — add it even for simple projects

⚠️ Common Mistakes

Assuming the reader has the same context as the author — explain prerequisites explicitly

Mixing installation instructions with configuration — separate these into distinct sections

No verification step — users should know how to confirm everything worked before moving on

Outdated docs that contradict the current code — schedule a docs review whenever the codebase changes significantly

❓ FAQ

Should I write docs before or after building?
Write the README before building — it's the best specification tool available. Explaining what your project does in plain English before writing code forces you to clarify assumptions and makes the final product better.
Which model writes the best technical documentation?
Claude is strongest for technical docs — it follows complex structural templates precisely, writes accurate code examples in multiple languages, and maintains consistent terminology throughout a long document.
How do I keep documentation up to date?
Make documentation part of your definition of done. For each code change, update the relevant doc section. Automated doc testing (checking that code examples in docs actually run) is the gold standard.
Should documentation live in the repo or on a separate docs site?
Start with the repo (README + /docs folder). Move to a dedicated docs site (Docusaurus, Mintlify, GitBook) when the project is complex enough that a README isn't navigable. Most small-to-medium projects are better served by excellent README documentation.

🔗 Related Prompts