القائمة
How to write a compelling GitHub README that makes developers instantly understand and want to use your library.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
CLI tool for patching files and resolving file includes - useful when working with LLMs
How to maintain project task docs and handle "whats next" requests. Read this when the user asks whats next or at conversation start.
Git workflow conventions — commit hygiene, squashing, force-push, and interactive rebase patterns.
Lightweight Bun process manager. Use bgrun to start, stop, restart, watch, and monitor background processes — with built-in web dashboard, TOML config, Docker support, and programmatic API.
Core behavioral rule: say 'I DON'T KNOW' when you don't actually know something. Never fabricate confident answers from incomplete information.
Install, uninstall, and list agent skills. Handles NTFS hardlinks for auto-sync with source repos.
| name | github-readme |
| description | How to write a compelling GitHub README that makes developers instantly understand and want to use your library. |
Developers skim READMEs. You have 5 seconds to show them why your library matters. Structure everything around that constraint.
Centered banner image + npm version, downloads, license badges. Makes the repo look established.
<p align="center">
<img src="banner.png" alt="project-name" width="100%" />
</p>
<p align="center">
<b>One-sentence value proposition.</b>
</p>
<p align="center">
<a href="https://www.npmjs.com/package/NAME"><img src="https://img.shields.io/npm/v/NAME.svg" alt="npm version"></a>
<a href="https://www.npmjs.com/package/NAME"><img src="https://img.shields.io/npm/dm/NAME.svg" alt="npm downloads"></a>
<a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-green.svg" alt="License"></a>
</p>
The single most effective way to sell a dev tool. Show the ugly boilerplate first, then your clean alternative. Both must produce the same result so the comparison is direct.
**Before:**
[manual boilerplate code]
**After:** [project-name] does the same in one line:
[your clean code]
Rules:
T | null")## Installation
\`\`\`sh
npm install your-package
# or bun add / pnpm add / yarn add
\`\`\`
Always include multiple package managers.
Short bullet list of what happens automatically. Use emoji for visual scanning:
## ✨ Defaults
Every call automatically:
- 🛡️ **Feature one** → brief explanation
- ⏱️ **Feature two** → brief explanation
- 🌳 **Feature three** → brief explanation
Whatever makes your library unique — don't bury it at the bottom. If nesting/tracing/reactivity/etc. is the differentiator, it goes right after defaults. Show code + output.
Show all variants in a table so readers can compare at a glance:
| Pattern | On error | Return Type |
|---------|----------|-------------|
| `fn(a)` | returns `null` | `T \| null` |
| `fn(a, fallback)` | returns fallback | `T` |
| `fn.assert(a)` | throws | `T` |
Use a table for option objects:
| Field | Type | Effect |
|-------|------|--------|
| `label` | `string` | Display name |
| `timeout` | `number` | Abort after N ms |
Each extension gets:
### method signature headerRuntime config + environment variables.
Quick symbol/format reference table at the bottom.
Just "MIT" — one line.
Don't just show the function call — show what gets logged/returned.
If you show fetchUsers() in one example, don't switch to getUsers() in the next. Same function names throughout.
Each feature appears once. If error handling is covered in a section, don't re-explain it in the API section.
✨ Defaults, 🛡️ Error Handling, 🚦 Timeouts, 🧰 Extensions, ⚙️ Configuration
For comparing variants, listing options, or showing output formats — always use a table.
After pushing, always check the README renders correctly on GitHub: