| name | assign-component-metadata |
| description | Use when assigning or validating components metadata in Markdown frontmatter for documentation articles. Processes one component folder at a time, supports dry runs, detects conflicts, and validates the resulting diff. |
Assign Component Metadata
Use this skill to add the repository's components frontmatter field to articles belonging to one component folder. This is an agent-driven Markdown edit workflow; it does not require Ruby, a script, or another runtime.
Workflow
-
Identify exactly one component folder, such as controls/grid. The component value is the folder name, grid in this example.
-
Recursively list Markdown files below that folder. Include Markdown articles in directories named templates; do not exclude a file based only on its directory name. Exclude only clearly identified non-documentation assets, such as image directories, and do not process files outside the requested folder.
-
Read the frontmatter of every candidate file before editing anything.
-
Build a dry-run report with these groups: eligible files, files already containing the requested component, files with another components value, malformed or missing frontmatter, and excluded files.
-
Stop and ask for guidance if any file has another component, a non-array components value, malformed/missing frontmatter, or unclear ownership.
-
For eligible files only, add exactly this line immediately after slug:
components: ["grid"]
-
Do not change article body text, existing frontmatter values, formatting outside the inserted line, or files outside the requested component folder.
-
Re-read every changed file and verify that it has exactly one requested component entry.
-
Inspect the diff and report the changed-file list. Never commit or push unless explicitly requested.
Process components in separate batches. Do not process the repository root or shared folders without an explicit component mapping.
