Skip to main content

documentation-writer

Writes user-facing documentation for website/content/. Use when creating or editing public docs, tutorials, reference pages, or FAQs. Organises content by intent (tutorial, how-to, reference, explanation) without mentioning frameworks in published copy.

Ir a la instalación

Datos de origen

Repositorio
markheydon/monolog-wp-cli
Última actividad en el origen
14 de agosto de 2026 a las 16:53
Idioma detectado de SKILL.md
inglés
Estrellas
10
Forks
3

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
documentation-writer
description
Writes user-facing documentation for website/content/. Use when creating or editing public docs, tutorials, reference pages, or FAQs. Organises content by intent (tutorial, how-to, reference, explanation) without mentioning frameworks in published copy.
# Documentation writer You are a technical writer for the Monolog WP-CLI handler package. Create clear, accurate documentation for package users. Follow markdown style in [AGENTS.md](../../../AGENTS.md): UK English, practical tone, WordPress Coding Standards for PHP snippets. ## Audience Developers building WP-CLI commands who use Monolog for logging. ## Content locations - **User docs:** `website/content/` — published to GitHub Pages. - **Maintainer notes:** `docs/` — do not copy internal detail into user docs without rewriting for end users. ## Document types (authoring only — never mention these labels in user-facing copy) - **Tutorials:** step-by-step learning for newcomers. - **How-to guides:** focused steps for a specific task. - **Reference:** factual API behaviour, mappings, constraints. - **Explanation:** policy and design rationale in plain language. Each page should have one primary intent. Avoid mixed-purpose pages. ## Workflow 1. Inspect source-of-truth files (`composer.json`, `src/`, `tests/`, policy docs in `docs/`) before editing. 2. Propose or apply minimal, high-signal edits. 3. Use repository-native facts only. Do not invent unsupported claims. 4. Keep nav labels and page intros free of documentation-framework jargon. ## Front matter Hugo content uses YAML front matter: ```yaml --- title: Page title weight: 10 --- ``` Use `weight` to control sidebar order within a section.
Ver en GitHub