Skip to main content

groove-work-doc

Create a 'how does X work' documentation file for a codebase component or concept. Use $ARGUMENTS as the doc topic if provided.

Ir a la instalación

Datos de origen

Repositorio
andreadellacorte/groove
Última actividad en el origen
9 de marzo de 2026 a las 19:59
Idioma detectado de SKILL.md
inglés
Estrellas
5
Forks
0

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
groove-work-doc
description
Create a 'how does X work' documentation file for a codebase component or concept. Use $ARGUMENTS as the doc topic if provided.
license
MIT
allowed-tools
Read Write Edit Glob Grep Bash(git:*) AskUserQuestion
metadata
{"author":"andreadellacorte"}
<!-- groove:managed — do not edit; changes will be overwritten by groove update --> # groove-work-doc Use $ARGUMENTS as the doc topic if provided. ## Outcome A structured documentation file explaining how a component, concept, or pattern works — for future agents and humans picking up the codebase. ## Acceptance Criteria Doc file contains: - **Overview**: What this component/concept is and what problem it solves - **Key Files**: The most important files, with a one-line role for each - **How It Works**: Step-by-step explanation of the main flow or logic - **Gotchas**: Non-obvious constraints, edge cases, known sharp edges ## Constraints - Sanitize topic for use as filename — strip path separators, special characters, and traversal patterns (`../`) - Docs directory is always `.groove/memory/docs/` - Ensure the docs directory exists (create if missing) - Research the codebase thoroughly before writing (use Explore agent) — docs should reference actual file paths, not generic descriptions - Interview user if scope is ambiguous: "What's the audience — a new contributor, a future agent, or both?" - Write doc in isolated context (use general-purpose agent) - Verify all four required sections exist before completing - Keep each section concise — this is a reference doc, not a tutorial ## Quality Signals - Key Files lists actual paths found in the codebase - How It Works traces a real execution path (e.g. "user runs X → Y reads config → Z writes file") - Gotchas surface things that are not obvious from reading the code - Doc does not duplicate what a spec already says — link to the spec if one exists
Ver en GitHub