mcpField
G
groove-work-doc

groove-work-doc

github.com/andreadellacorteDevelopment6518 installsUpdated 14w ago
Repository

About groove-work-doc

A skill for creating structured reference documents about codebase components, concepts, or patterns for future contributors and agents. It grounds explanations in actual files and execution paths, and covers key files and gotchas.

Key features

  1. 01Create documentation for a topic or component
  2. 02Include overview, key files, flow, and gotchas
  3. 03Research the codebase and cite real file paths
  4. 04Clarify the audience when the scope is ambiguous
  5. 05Write to the designated groove documentation directory

Use cases

  1. 01Document component structure for new contributors
  2. 02Explain how a feature runs through the codebase
  3. 03Record non-obvious constraints and edge cases

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/andreadellacorte/groove --skill groove-work-doc

After installing, type/groove-work-docin Claude Code to confirm it loaded.

Details

From the project README

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

Comments

Markdown supported