agentleFS
EndavaEndava/BEEQ/.agents/skills/doc-component/SKILL.md

doc-component

Skill162 starsChanged 11 days agoApache-2.0View on GitHub

Write or complete the Mintlify MDX page for a BEEQ component, extracting props, events, slots, parts and CSS variables from the component source. Use when documenting a new component or filling missing sections. To audit an existing page use review-doc.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is 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.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read in full before writing a line:

    line 26
  2. Distinctive:

    Treat old docs as reference for tone and concepts, never for API facts.

    line 44
  3. Very specific:

    Write apps/beeq-docs/components/<name>.mdx following the component docs and code examples instructions.

    line 50
  4. Distinctive:

    Run review-doc on the new page and fix every finding.

    line 56

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

Write documentation for BEEQ components

When to use

  • Creating a new MDX page in apps/beeq-docs/components/ for an existing bq-* component.
  • Filling missing sections on a partially written page.

When NOT to use this skill

  • The page exists and only needs an audit: use review-doc.
  • The component itself is missing or incomplete: finish it with create-component and review-component.
  • Non-component pages (foundations, theming, getting started, guides, framework integrations, migration docs): follow the documentation instructions and review with review-doc.

Procedure

1. Load the rules

Read in full before writing a line:

  • Documentation instructions: tone, rule strength keywords, anti-patterns, frontmatter, imports, Mintlify components.
  • Component docs instructions: page structure and section order, related components, allowed values, keyboard and rules tables, invalid combinations, image paths, Do/Don't cards, anatomy, API tables, CSS variable naming, resources.
  • Code examples instructions: CodeLivePreview isolation, CodeGroup tab order, icons, CSS tab.

Done when you can name the section order and the tab order without looking.

2. Read the component source

The source is the ground truth for the API reference. Document only what exists in it:

  • packages/beeq/src/components/<name>/bq-<name>.tsx: @Prop, @Event, @Method, class-level JSDoc (@slot, @part, @cssprop, @attr)
  • packages/beeq/src/components/<name>/bq-<name>.types.ts: prop type unions and constants
  • packages/beeq/src/components/<name>/__tests__/*.e2e.tsx: what is asserted, for keyboard rows and "Verified by" values
  • packages/beeq/src/components/<name>/scss/bq-<name>.variables.scss: every --bq-<name>--* custom property and its default
  • packages/beeq/cem/: the Custom Elements Manifest; the API tables must match it

Treat old docs as reference for tone and concepts, never for API facts. Read icon.mdx or badge.mdx as a structural reference.

Done when every prop, event, slot, part and CSS variable you plan to document is traced to the source.

3. Write the page

Write apps/beeq-docs/components/<name>.mdx following the component docs and code examples instructions. Verify every value against the source.

Done when every section of the component docs instructions is present, in order, or explicitly marked optional and skipped.

4. Review

Run review-doc on the new page and fix every finding.

Done when the review report has no failures.

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.