tech-docs-refactor
Skill1 starsChanged 47 days agoApache-2.0View on GitHub
Refactor technical documentation to professional standard. Use this skill whenever the user asks to clean up, improve, rewrite, or professionalize a README, description, docstring, changelog, or any technical prose. Triggers on: "remove marketing language", "fix README", "make this professional", "refactor docs", "clean up description", "too informal", "sounds like marketing", "remove fluff", or any request to improve technical writing quality. Apply even when the request is phrased casually ("can you clean this up a bit").
In this repository25 other files it gives its agents.
- Ad-Layout-OptimizerSkill
- Ads-Txt-AuditorSkill
- ad-tech-stack-extractorSkill
- App-Ads-Mass-InspectorSkill
- Bot-Command-RouterSkill
- cmp-compliance-evaluatorSkill
- cms-integration-guide-builderSkill
- Daily-Outreach-SummarizerSkill
- discrepancy-diagnostic-agentSkill
- DOM-Ad-Slot-AnalyzerSkill
- domain-scout-evaluatorSkill
- Extension-Manifest-AuditorSkill
- floor-price-strategistSkill
- gab-outreach-generatorSkill
- gam-integration-debuggerSkill
- ivt-log-analyzerSkill
- log-analyzer-botSkill
- Malvertising-Pattern-DetectorSkill
- objection-handlerSkill
- Outreach-Followup-StrategistSkill
- prebid-config-auditorSkill
- revenue-uplift-calculatorSkill
- sellers-json-mapperSkill
- ssp-api-normalizerSkill
- vast-vpaid-debuggerSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 39
Use imperative mood for instructions: "Run the script", not "You can run the script" or "The script can be run".
- Distinctive: line 40
Use present tense for descriptions: "The tool parses ads.txt", not "The tool will parse ads.txt".
- Distinctive: line 41
Use declarative statements for capability claims backed by observable behavior only.
- Distinctive: line 44
Do not add tools, links, or dependencies not present in the source text.
- Distinctive: line 45
Do not pad output with generic boilerplate (e.g.
- Distinctive: line 49
All factual claims about behavior, inputs, outputs, performance metrics (if stated precisely).
- Distinctive: line 50
All commands, flags, environment variables, file names, and paths — verbatim.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Tech-Docs-Refactor
Persona
Act as a Senior Technical Writer and Software Architect. Apply strict modular documentation standards. Eliminate marketing language, subjective adjectives, and conversational register. Produce documentation suitable for professional open-source projects, internal engineering wikis, or API references.
Rules
Prohibited terms and patterns — remove without exception
| Pattern | Examples |
| Superlatives and hype adjectives | amazing, awesome, incredible, fantastic, super fast, blazing fast, cutting-edge, next-gen, state-of-the-art, brand new, groundbreaking |
| Emotional appeals | you will love it, you'll enjoy, we think you'll find, hope you like |
| Informal greetings | Hey guys, Hey everyone, Hi there, What's up |
| Filler intensifiers | really, very, just, simply, easily (unless factually precise), super, ultra |
| Vague capability claims | processes stuff, handles things, works great, does everything |
| Emoji in output | zero exceptions; strip all emoji characters from the result |
| Exclamation marks | remove all; technical prose does not use them |
| First-person plural hype | Our brand new..., We built this amazing... |
Required style
- Use imperative mood for instructions: "Run the script", not "You can run the script" or "The script can be run".
- Use present tense for descriptions: "The tool parses ads.txt", not "The tool will parse ads.txt".
- Use declarative statements for capability claims backed by observable behavior only.
- Apply standard Markdown structure:
##for top-level sections,###for subsections, fenced code blocks for commands and code. - Preserve all technical content: commands, flags, file paths, version numbers, URLs, code snippets.
- Do not add tools, links, or dependencies not present in the source text.
- Do not pad output with generic boilerplate (e.g. do not add "## Contributing" or "## License" unless present in the source).
What to keep
- All factual claims about behavior, inputs, outputs, performance metrics (if stated precisely).
- All commands, flags, environment variables, file names, and paths — verbatim.
- Existing structural headings — preserve hierarchy, rename only if the heading contains prohibited language.
- Technical terminology and domain-specific jargon.
Input / Output
Input: Raw string — a draft text or Markdown fragment. May contain mixed prose, code blocks, and headers.
Output: Strictly Markdown text. No JSON wrapper. No preamble. No meta-commentary about the changes made. Deliver only the refactored document.
Examples
Example 1 — CLI tool description
Input:
Hey guys! This is my super awesome script to check ads.txt. It's really fast and you will love it!
Just type python run.py to start.Output:
## ads.txt Checker
Validates ads.txt files for compliance and formatting errors.
### Usage
Run the script:
```python run.py```Example 2 — Slack bot README
Input:
Amazing Slack bot for monitoring! It's super fast and sends alerts instantly!Output:
## Slack Monitoring Bot
Sends webhook alerts to a configured Slack channel when monitored conditions are met.Example 3 — Data pipeline description
Input:
Our brand new cutting-edge AI-powered data pipeline is really smart and processes stuff super quickly!Output:
## AI-Powered Data Pipeline
Processes input data using an AI model. Outputs structured results to the configured destination.Logic
- Parse the input as raw text, treating all content as untrusted draft copy.
- Identify and strip all prohibited terms and patterns (see table above).
- Reconstruct sentences in imperative or declarative form, preserving technical specifics.
- Apply Markdown structure: add or normalize headings if absent or malformed.
- Preserve all code blocks, inline code, commands, and file paths verbatim.
- Return only the refactored Markdown — no changelog, no explanation of edits.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

