agentleFS
adops-tooladops-tool/AdTech-LeadGen-agent-skills/Tech-Docs-Refactor/SKILL.md

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").

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
  1. Distinctive:

    Use imperative mood for instructions: "Run the script", not "You can run the script" or "The script can be run".

    line 39
  2. Distinctive:

    Use present tense for descriptions: "The tool parses ads.txt", not "The tool will parse ads.txt".

    line 40
  3. Distinctive:

    Use declarative statements for capability claims backed by observable behavior only.

    line 41
  4. Distinctive:

    Do not add tools, links, or dependencies not present in the source text.

    line 44
  5. Distinctive:

    Do not pad output with generic boilerplate (e.g.

    line 45
  6. Distinctive:

    All factual claims about behavior, inputs, outputs, performance metrics (if stated precisely).

    line 49
  7. Distinctive:

    All commands, flags, environment variables, file names, and paths — verbatim.

    line 50

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

PatternExamples
Superlatives and hype adjectivesamazing, awesome, incredible, fantastic, super fast, blazing fast, cutting-edge, next-gen, state-of-the-art, brand new, groundbreaking
Emotional appealsyou will love it, you'll enjoy, we think you'll find, hope you like
Informal greetingsHey guys, Hey everyone, Hi there, What's up
Filler intensifiersreally, very, just, simply, easily (unless factually precise), super, ultra
Vague capability claimsprocesses stuff, handles things, works great, does everything
Emoji in outputzero exceptions; strip all emoji characters from the result
Exclamation marksremove all; technical prose does not use them
First-person plural hypeOur 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

  1. Parse the input as raw text, treating all content as untrusted draft copy.
  2. Identify and strip all prohibited terms and patterns (see table above).
  3. Reconstruct sentences in imperative or declarative form, preserving technical specifics.
  4. Apply Markdown structure: add or normalize headings if absent or malformed.
  5. Preserve all code blocks, inline code, commands, and file paths verbatim.
  6. Return only the refactored Markdown — no changelog, no explanation of edits.

Download now (ZIP)

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.