define-area

Creates durable cross-repo area documentation with summaries, dependency graphs, and drift signals.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams working across multiple repositories lose track of which repos participate in a capability, how they depend on each other, and where the canonical documentation lives. This Skill indexes that architecture once so future agents and engineers can orient from docs/resources/<area>/ instead of rediscovering repo relationships, package names, install modes, and runtime dependencies. ## Core Features & Use Cases - Area Summary Generation: Writes a structured summary.md covering responsibility, participant repos, boundaries, runtime modes, known docs, and open questions. - Dependency Graph Mapping: Produces dependency-graph.md with repo edges, runtime versus development relationships, install modes, and drift signals that trigger context refreshes. - Registry and System-Map Alignment: Uses repo slugs from .config/repos.project.md, optionally registers task-area prefixes in docs/tasks_manager/_areas.md, and updates docs/resources/system-map.md when the capability picture changes. - Use Case: A platform team spanning a runtime repo, an SDK repo, and a docs repo asks to "define the billing-platform area"; the Skill inspects manifests, Dockerfiles, and lockfiles across checkouts and writes evidence-backed area docs with explicit unknowns instead of guesses. ## Quick Start Ask the agent to define the area for your capability, for example: "Define the search-indexing area across these repos and write its summary and dependency graph."

Frequently Asked Questions about define-area

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

FAQPage Schema
How do I document a capability that spans multiple repositories?

Run the define-area workflow to inspect each repo's manifests, lockfiles, Dockerfiles, and CI files, then write a summary.md and dependency-graph.md under docs/resources/<area>/. Every repo and dependency edge is backed by file evidence rather than guesses.

What is the difference between an area and a feature in cross-repo docs?

An area is a long-lived capability such as billing-platform or search-indexing with durable architecture docs. A feature is one concrete contract inside an area, captured afterward with the cross-repo-feature skill.

Where should cross-repo area documentation live?

Choose one canonical docs home before writing. Prefer a central docs repo via CONTEXT_DOCS_DIR when it exists and is shared; otherwise use the initiating repo's docs/resources/<area>/ directory. Never split one area's docs across repos.

How are unknown ownership or dependencies handled in the dependency graph?

Unproven ownership or dependency edges are recorded as "unknown" or "not found" rather than filled with plausible guesses. This keeps the graph trustworthy and flags open questions for later resolution.

When should the area documentation be refreshed?

Refresh when drift signals change, such as API schema files, env/config definitions, package manifests, Dockerfiles, generated SDK outputs, or contract docs. These signals are listed in dependency-graph.md to trigger the refresh-context workflow.