describe-component

Generate a CONTEXT.md documenting a component's interface, dependencies, data ownership, and invariants.

Updated Apr 6, 2026
One-click install
npx skills add https://github.com/toderian/project_template --skill describe-component-toderian
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: describe-component
Source: https://github.com/toderian/project_template/tree/main/plugins/agents-tasks/skills/describe-component
Command: npx skills add https://github.com/toderian/project_template --skill describe-component-toderian

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineers repeatedly re-derive what a module or service does when onboarding, handing off, or refactoring code with unclear boundaries. This Skill produces a durable architectural CONTEXT.md for a component so that knowledge is captured once instead of rediscovered. ## Core Features & Use Cases - Grounded code exploration: Reads entry points, public interfaces, inbound and outbound dependencies, owned data, and tests before writing anything. - Structured CONTEXT.md output: Generates a fixed-format doc covering responsibility, public interface, key files, dependencies, data owned, invariants, tests, and related domain terms. - Path taxonomy integration: Places the doc under docs/resources/<area>/components/<component-slug>/ following the knowledge-base skill's ownership rules, with an optional CONTEXT_DOCS_DIR external storage override. - Use Case: Before refactoring a billing service whose boundaries are fuzzy, run this Skill on services/billing/ to produce a component doc that maps its public API, callers, and hidden invariants. ## Quick Start Ask the agent to describe the component at src/auth/ and generate its CONTEXT.md.

Frequently Asked Questions about describe-component

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I document a code component or module for onboarding?

Run this Skill against the component's path, such as src/auth/ or services/billing/. It explores the code, then writes a CONTEXT.md covering responsibility, public interface, dependencies, data owned, invariants, and tests.

What goes into a component architecture document?

The generated CONTEXT.md includes responsibility, public interface, key files and entry points, inbound and outbound dependencies, data owned, invariants and gotchas, tests, and links to related domain terms. Empty sections are dropped rather than padded.

Where are component CONTEXT.md files stored?

They live under docs/resources/<area>/components/<component-slug>/CONTEXT.md, following the knowledge-base skill's area ownership taxonomy. Setting CONTEXT_DOCS_DIR in project.env redirects storage to an external docs root while keeping the same structure.

When should I not create a component context doc?

Skip it for trivial components like a single small file where the doc costs more than it saves. Domain vocabulary belongs in the docs-primary glossary via domain-modeling, and step-by-step runbooks are out of scope since this doc describes structure, not procedures.

How is a component doc different from a domain glossary?

The component CONTEXT.md captures what one part of the system does and how it fits, while docs/resources/CONTEXT.md defines what domain words mean across the project. Component docs link to glossary terms instead of redefining them to avoid drift.