agentleFS
opendatahub-ioopendatahub-io/docs-skills/skills/docs-review-modular-docs/SKILL.md

docs-review-modular-docs

Skill4 starsChanged 4 months agoApache-2.0View on GitHub

Review AsciiDoc (.adoc) files for Red Hat modular documentation compliance — module types (concept, procedure, reference), assembly structure, anchor IDs, context variables, leveloffset, and include directives. Use this skill whenever someone asks about modular docs, checks .adoc file structure, asks if a module is the right type, needs to verify anchor IDs have _{context}, or reviews assemblies. Also triggers for questions about concept vs procedure vs reference modules, prerequisites formatting, or Red Hat doc structure.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Verify file is .adoc format

    line 125
  2. Distinctive:

    Check required parts are present using the checklists above

    line 127
  3. Very specific:

    Verify anchor ID includes _{context} (except assemblies)

    line 128
  4. Distinctive:

    Check for common violations

    line 129
  5. Distinctive:

    Check for undefined attributes (see "Attribute validation" section)

    line 130
  6. Very specific:

    lint-with-vale: Run vale <file> for automated style linting

    line 142

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

Modular documentation review skill

Review AsciiDoc source files for Red Hat modular documentation compliance: module types, required sections, anchor IDs, and assembly structure.

Applies to: .adoc files only

For detailed module type guidance, templates, and structural rules, read asciidoc-reference.md. It contains full descriptions of each module type, required/optional parts, templates, and examples.

Concept checklist

  • Title is noun phrase (NOT gerund) and uses sentence case (not Title Case)
  • Anchor ID includes _{context}
  • Introduction provides overview (what and why)
  • No step-by-step instructions (those belong in procedures)
  • Actions avoided unless highly context-dependent
  • If subheadings used, first tried splitting into separate modules
  • Standard subheadings (included in TOC) have anchor IDs with _{context}: [#anchor-id_{context}]
  • Only valid admonition types used: NOTE, IMPORTANT, WARNING, TIP (CAUTION is not supported by the Red Hat Customer Portal)
  • Additional resources focused on relevant items only
  • All attribute references (e.g., {product-name}) are defined in the project

Procedure checklist

  • Title uses imperative phrase (verb without -ing) and sentence case (not Title Case)
  • Anchor ID includes _{context}
  • Introduction explains why and where
  • .Procedure section present with numbered steps
  • Each step describes ONE action
  • Steps use imperative form ("Click...", "Run...")
  • Single-step procedures use bullet (*) not number
  • No custom subheadings - only allowed sections used
  • .Next steps contains links only, not instructions
  • Prerequisites written as conditions, not instructions
  • Only valid admonition types used: NOTE, IMPORTANT, WARNING, TIP (CAUTION is not supported by the Red Hat Customer Portal)
  • Optional sections in correct order: Limitations, Prerequisites, Verification, Troubleshooting, Next steps, Additional resources
  • All attribute references (e.g., {product-name}) are defined in the project

Reference checklist

  • Title is noun phrase and uses sentence case (not Title Case)
  • Anchor ID includes _{context}
  • Introduction explains what data is provided
  • Body uses tables or labeled lists
  • Data logically organized (alphabetical, categorical)
  • Consistent structure for similar data
  • Standard subheadings (included in TOC) have anchor IDs with _{context}: [#anchor-id_{context}]
  • Additional resources focused on relevant items only
  • All attribute references (e.g., {product-name}) are defined in the project

Assembly checklist

  • Title matches content (imperative if procedures included)
  • Anchor ID does NOT include _{context}
  • Context variable set: :context: my-assembly-name
  • Introduction explains what user accomplishes
  • Modules included with leveloffset= and appropriate level
  • Next steps and Additional resources in correct order
  • All attribute references (e.g., {product-name}) are defined in the project

Common violations

IssueWrongCorrect
Missing context[id="my-assembly"][id="my-module_{context}"]
Standard subheading without anchor ID== Subheading[#anchor-id_{context}] then == Subheading
Procedure title= Database Configuration= Configure the database
Custom subheading in procedure== Additional setupUse allowed sections only
Instructions in Next stepsNumbered stepsLinks only
Module contains moduleinclude:: of moduleOnly snippets in modules
Missing leveloffsetinclude::mod.adoc[]include::mod.adoc[leveloffset=+1]
Prerequisite as step* Install JDK 11* JDK 11 is installed.
Deep assembly nestingMany levels of nested assembliesLink to assemblies instead
Writers defining user storiesWriter creates user storyProduct management defines user stories
Undefined attribute{my-product} without :my-product: definedDefine in attributes file or document header

Attribute validation

Finding attribute references

Attribute references use the format {attribute-name}. Common patterns:

  • {product-name} — product name
  • {product-version} — version number
  • {kebab-case-attr} — multi-word attributes
  • {context} — built-in context variable (always valid)

Finding attribute definitions

Attributes are defined with the format :attribute-name: value. Check these locations in order:

  1. Shared attributes files — typically:
    • common-attributes.adoc
    • attributes.adoc
    • _attributes.adoc
    • attributes/common-attributes.adoc
    • Files included with :includedir: or include:: at the top
  2. Master/assembly files — parent files that include this module
  3. Build configuration — attributes passed via command line (check build scripts)

Built-in attributes (always valid)

These AsciiDoc built-ins don't need definition checking:

  • {doctype}, {backend}, {docname}, {docfile}, {docdir} — document metadata
  • {author}, {email}, {revdate}, {revnumber} — revision info

Example check

File contains: Install {product-name} version {product-version}

✅ Valid if attributes file has:

:product-name: OpenShift sandboxed containers
:product-version: 1.12

❌ Invalid if no definition found — report: "Undefined attributes: {product-name}, {product-version}"

How to use

  1. Verify file is .adoc format
  2. Identify module type from content (concept, procedure, reference, assembly)
  3. Check required parts are present using the checklists above
  4. Verify anchor ID includes _{context} (except assemblies)
  5. Check for common violations
  6. Check for undefined attributes (see "Attribute validation" section)
  7. Mark issues as required (modular violations) or [SUGGESTION]

Example invocations

  • "Review this procedure module for modular docs compliance"
  • "Check if this assembly follows Red Hat modular guidelines"
  • "Verify the anchor IDs include context variable"
  • "Do a modular docs review on modules/*.adoc"

Integrates with

  • lint-with-vale: Run vale <file> for automated style linting

References

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.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.