render-code-shape

Render module boundaries, signatures, and cited call graphs from existing source code.

723|93|Updated Nov 14, 2021
One-click install
npx skills add https://github.com/citypaul/.dotfiles --skill render-code-shape
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: render-code-shape
Source: https://github.com/citypaul/.dotfiles/tree/main/claude/.claude/skills/render-code-shape
Command: npx skills add https://github.com/citypaul/.dotfiles --skill render-code-shape

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Understanding how code composes — which modules a request touches, what types cross boundaries, and in what order calls happen — usually requires reading many files and holding the result in memory. This Skill produces a trustworthy, read-only render of that shape where every name, type, and path is cited by file and line or marked [NEW], so the output can be checked against the source instead of trusted from memory.

Core Features & Use Cases

  • Cited shape rendering: Produces types crossing boundaries, a module boundary table stating what each module hides, and signatures grouped by module, each verified against source.
  • Annotated call graphs: Draws one indented call graph per wiring (production, tests, feature flags) with annotations for conditions, loops, async, errors, and boundary crossings.
  • Pre-implementation pseudocode: Renders a [NEW] shape for a planned change, saved beside the slice plan so implementation and tests can be checked against it.
  • Use Case: When onboarding to an unfamiliar checkout flow, ask for a render of the entry point; you receive the boundary table, signatures, and a call graph showing exactly which network, database, and async edges the request touches.

Quick Start

Use render-code-shape to render how the checkout request composes, including entry points, boundary types, signatures, and the cited call graph, without changing any code.

Frequently Asked Questions about render-code-shape

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

FAQPage Schema
How do I trace what a request actually touches in a codebase?

Render the call graph from the request's entry point, following each call until it hits a boundary crossing, pure leaf, or the frame edge. Every edge is cited by file and line and annotated for async, error, and boundary-crossing behavior.

How to write pseudocode for a change before implementing it?

Render a [NEW] shape: read the existing modules the change attaches to, derive the new signatures from the requirement, and mark each new element [NEW]. Save the render beside the slice plan so implementation and tests can be checked against it.

Does rendering the code shape modify any files?

No, the render is strictly read-only and is itself the deliverable. Producing a render never authorizes changing production code, tests, or configuration; implementation proceeds separately under the governing workflow such as TDD or refactoring.

What is the difference between render-code-shape and a design review?

A render states only facts visible in the code, such as dependency cycles, argument counts, and uncovered paths. Judgments about whether boundaries are well-drawn belong to codebase-design, and file placement decisions belong to structure-codebase.

When should I not render the entire repository?

Prefer the narrowest frame that answers the question asked. A render that expands to the whole repository answers nothing; name specific entry points and a frame edge that excludes outside packages and libraries.