Standard structure for TMHSDigital developer tool READMEs. Adapt section content to the specific tool; keep the section order consistent.
# <Tool Name>
**<One-line description>**
License: CC BY-NC-ND 4.0
Version
GitHub stars
DocumentationThe version badge is auto-updated by the release workflow. Use the format version-X.Y.Z-blue.
**Getting Started** - Documentation - Features - Quick Start - MCP Server - Skills - Rules - RoadmapLink to sections within the README and to the external docs site.
> X skills - Y rules - Z MCP toolsThese counts must match the actual files on disk. The validate.yml workflow checks this.
One paragraph explaining what the plugin does, who it's for, and what it covers.
A Mermaid flowchart showing the relationship between skills, rules, and MCP tools.
Minimal steps to get the plugin working. Assume the reader already has Cursor installed.
Bullet list or table of key capabilities.
| Skill | What it does |
|---|---|
| Skill Name | One-line description |
| Rule | What it does |
|---|---|
| Rule Name | One-line description |
| Tool | Description |
|---|---|
tool_name |
One-line description |
<tool-name>/
.cursor-plugin/ Plugin manifest
skills/ AI skill files
rules/ Coding convention rules
...
Link to ROADMAP.md or inline version table.
Link to CONTRIBUTING.md.
State the license and link to LICENSE.
**Built by TMHSDigital**- Keep the README scannable. Use tables over long prose.
- Do not duplicate content that belongs in
docs/or skill files. - Stats in the README must match reality. CI enforces this.
- The release workflow manages the version badge. Don't manually update it.