From domain-chassis
This skill should be used when the user asks to "write up this component", "document this system", "produce a technical writeup", "create a component writeup", "architecture documentation", "system documentation", "document the architecture of X", "technical writeup of X", "how does this system work — write it up", "map out this system's components", or mentions producing structured technical documentation of a system, subsystem, or component set. Produces progressive-disclosure documentation following the Patnaik template with system-decomposition analytical rigor — component inventory, architecture overview, data flow, per-component detail, and grouped references.
npx claudepluginhub basher83/domain-chassis --plugin domain-chassisThis skill uses the workspace's default tool permissions.
Produce a structured technical writeup of a target system by systematically discovering its components, tracing their relationships through artifacts, and rendering the findings into progressive-disclosure documentation.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
Produce a structured technical writeup of a target system by systematically discovering its components, tracing their relationships through artifacts, and rendering the findings into progressive-disclosure documentation.
The writeup follows the Patnaik template format. The analytical methodology is adapted from the system-decomposition pattern — phased discovery with gate checks ensures the documentation is grounded in artifact evidence rather than assumptions.
The operator provides a target system: a project directory, a subsystem within a project, or a set of artifacts to document. The operator may also specify the audience and the question the documentation should answer.
If the operator provides only a name or vague reference, ask for the artifact paths before proceeding. The skill cannot produce artifact-grounded documentation without access to the artifacts.
Phase 1 produces the raw inventory that all subsequent phases build on. Do not begin analysis or writing until discovery is complete.
Before beginning discovery, verify that the target system's artifacts exist and are accessible. Read the top-level directory structure. Identify the artifact types present (code, config, skills, hooks, specs, docs). If critical artifacts are missing or inaccessible, report the gaps to the operator before proceeding — a writeup produced from incomplete artifacts will contain gaps that look like analysis failures rather than input failures.
Read the system artifacts and identify every discrete component. A component is any unit with its own identity, inputs, outputs, and reason for existing. For each component, capture:
Apply the scoping test: each component should be describable in one sentence without "and." A component requiring "and" to describe its function likely represents two components that should be separated.
For every pair of components that interact, classify the relationship:
Trace relationships through artifacts — imports, config references, API calls, file reads/writes. If a relationship is implied but not explicitly visible, flag it as inferred with the evidence that suggests it.
Determine how execution flows through the system:
Before proceeding to Phase 2, verify completeness: every component in the artifact set appears in the inventory, and every inter-component interaction visible in the artifacts appears in the relationship list. Components that reference things outside the artifact set are listed as external dependencies. Output the inventory as a structured table.
Phase 2 transforms the raw inventory into the analytical structures that feed the documentation. Do not begin writing the final artifact until analysis is complete.
From the component inventory and relationships, construct the system's architecture:
From the execution pipeline, trace the primary data flow as a numbered sequence:
If the system has multiple primary workflows, trace each separately. Name the workflow being traced.
As you discover architectural decisions during analysis, collect the rationale:
Rationale feeds the "Why this approach" and "Why this shape?" sections in the output. If rationale is not visible in the artifacts, note what is unknown rather than inventing justifications.
Before proceeding to Phase 3, verify: the architecture synthesis accounts for all components in the inventory, the data flow trace names the component responsible at each step, and no component from the inventory is orphaned (present in inventory but absent from both the architecture and data flow).
Render the analysis into the Patnaik template format. The template is in references/component-writeup-template.md — read it before writing.
The writeup follows progressive disclosure through zoom levels. Each level is self-contained — a reader can stop at any layer and have a coherent understanding:
Every structural claim in the writeup must be anchored to an artifact. If the writeup states "Component A sends data to Component B," the artifact evidence (import statement, API call, config reference) should be traceable. Claims that could apply to any system — generic descriptions without target-specific names, paths, or structural details — indicate the analysis phase was incomplete.
Examples in per-component sections must be drawn from the target's actual code, config, or artifacts. Invented examples undermine the writeup's value as documentation of a real system.
The writeup documents what the system IS, incorporating design rationale where visible in artifacts. It does not prescribe improvements or redesigns unless the operator explicitly requests recommendations.