Stack Diagram skill: diagrams you can share

FuturPulse analysis · 2 November 2026

Stack Diagram version 0.2.0 was released on 1 November 2026 with AWS architecture icon support. The skill turns a written stack description into an architecture diagram and delivers a self-contained HTML file by default.

The result is aimed at teams that need a file they can review, store in a repository or publish in a wiki. The project also supports PNG, a dependency-free React component and a Claude Artifact.

Can Stack Diagram turn a sentence into a useful architecture diagram?

Stack Diagram is designed to turn a sentence about a software stack into a diagram with official logos. The repository’s main example names a Next.js front end, a Hono API, Vercel hosting, Neon Postgres, Clerk authentication, Stripe payments and GitHub Actions deployment.

That prompt contains enough information to identify several components and their broad relationships. It does not establish network boundaries, failure handling, identity rules or every direction of data flow.

A generated picture is therefore a communication aid, not proof of how a system operates. Reviewers still need to compare the diagram with source code, deployment settings and the people responsible for identity, networking and data.

Anthropic describes Agent Skills as folders containing instructions, scripts and resources that an agent can load for a specialised task. Stack Diagram fits that model: it packages a repeatable diagramming workflow rather than presenting itself as a conventional visual editor.

The distinction matters when a team needs a durable deliverable. Claude’s visual-generation feature is intended to help users understand a topic during a conversation, while Stack Diagram’s repository says its default result is one HTML file with fonts and logos inlined.

Anthropic says its in-line charts, diagrams and visualisations are temporary and change or disappear as the conversation evolves. That statement applies to Claude’s conversational visuals, not to Stack Diagram’s exported file.

What shipped in version 0.2.0?

The version 0.2.0 release notes list AWS architecture icon support. The same release metadata identifies the project as an Agent Skill that describes a stack and produces an architecture diagram with official logos.

The release does not establish automatic infrastructure discovery, cloud-account inspection or deployment management. Those are separate capabilities and should not be inferred from the presence of AWS icons.

The repository also shows that the project is small and focused. Its release metadata lists Python as the primary language, an MIT licence and no open issues or pull requests at the time recorded.

That narrow scope is useful. A diagram generator has a simpler job when the input is a known list of services and relationships. It is not being asked to reconcile documentation, source code, deployed resources and account permissions.

How does the skill work?

The agent receives a natural-language description and uses the skill’s instructions to assemble a diagram. The repository says the agent fetches official logos, routes lines around labels and renders the diagram for checking before handing it over.

The output options are practical rather than exotic. The default is a self-contained HTML file, while PNG, a dependency-free React component and a Claude Artifact are also available.

The repository says the HTML includes its fonts and logos. That means the delivered file can render without a further network request, although the build itself needs network access to obtain logos.

Logo handling is part of the project’s design. The repository says it looks first to svgl, then devicon, then gilbarbara/logos, a brand repository or the brand’s own site.

AWS icons come from AWS’s own package. The project says logos are not bundled with the skill, and that its scripts do not recolour or redraw them.

The same documentation says bundled fonts use the SIL Open Font License 1.1. It identifies third-party logo sources and notes that brand names and logos remain the trademarks of their owners.

This approach separates the generator from the artwork. The skill can download a current logo when it builds a diagram, but the resulting file is intended to carry the assets needed for later viewing.

That separation also creates a review point. Teams should decide whether their publication process allows downloaded third-party marks, particularly when diagrams leave an internal repository or appear in customer material.

How do you install Stack Diagram?

The documented installation command is npx skills add caru-ini/stack-diagram. This installs the skill through the Agent Skills command-line tool.

The repository names Claude Code, Codex and Cursor as supported hosts. It also says the skill works with other agents that support the Agent Skills format.

Users of the Claude apps have a separate route. The project says they can upload stack-diagram.zip from the Releases page as a skill.

The project’s published compatibility statement is deliberately narrower than a universal support claim. It identifies hosts that the maintainer has named, but does not provide a compatibility matrix for every Agent Skills implementation.

That matters for teams choosing an editor. A host may support the general format while differing in how it discovers skills, exposes files or handles generated artifacts.

Cloudflare’s public skills repository illustrates the same split. It documents native plugin installation where supported, separate Agent Skills installation for other hosts and an npx skills route.

Cloudflare also documents host-specific locations for copied skills. Its examples name ~/.claude/skills/, ~/.cursor/skills/ and ~/.codex/skills/ for Claude Code, Cursor and OpenAI Codex. That is evidence of different installation paths, not evidence that every host handles every skill identically.

For an unfamiliar host, the sensible test is small: install the skill, use the repository’s example prompt and inspect the returned file before adopting it for a review process.

What is a reproducible before-and-after test?

The repository provides an exact prompt that can serve as a baseline test: Diagram our stack: Next.js and a Hono API on Vercel. Postgres on Neon, auth with Clerk, payments with Stripe. GitHub Actions deploys.

Run that prompt after installing the skill. The documented delivery format is a self-contained HTML file with inlined fonts and logos.

The repository is the public inspection point for the sample. Its landing page publishes the prompt, the installation command and example output material in the project’s documentation. A reader can open the repository, run the prompt and compare the returned file with the stated requirements.

The important test is not whether the markup resembles a prescribed template. The public documentation does not establish one exact HTML structure for every generated file, and the public record does not capture a single generated file from a controlled run.

A reviewer should compare the file with the prompt. The required corrections are limited to facts the prompt does not establish: confirm the direction of each connection, check the placement of the database and authentication service, and remove any component the system does not use.

The prompt does not specify private networking, failure paths, callback direction or deployment environments. A reviewer should therefore mark those details as unknown rather than treating an inferred arrow or group boundary as verified architecture.

This makes the sample useful as a before-and-after test. The input is fixed, the expected named components are visible and the reviewer can preserve the output for later comparison.

A stronger test would run the same prompt in each supported host. It would preserve the generated HTML, record whether installation completed, and ask a second reviewer to score the diagram without knowing which host produced it.

No such controlled cross-host result is published in the project material. The comparison below therefore separates documented capability from measured performance.

How does Stack Diagram compare with other approaches?

Stack Diagram differs from conversational visuals and cloud-specific toolchains mainly through its output. It is built around a portable file created from a stack description.

The table does not claim that one host renders better than another. Stack Diagram’s documentation describes one renderer and three named hosts, but it does not publish separate screenshots, edit histories or installation measurements for Claude Code, Codex and Cursor.

That distinction matters because host support and output quality are different questions. If all three hosts invoke the same skill instructions and scripts, the diagram may look similar. Differences can still arise from file permissions, tool access, prompt handling or how an agent presents the generated artifact.

Stack Diagram is the narrowest option in this comparison. It does not claim to inspect a live account or manage infrastructure. Its value is the conversion of a known stack description into a file that can be shared.

The AWS workflow addresses a different problem. AWS documents a Kiro CLI setup using a Diagrams MCP server and an AWS Documentation MCP server. The Diagrams MCP server uses the Python diagrams library and includes access to the AWS icon set.

AWS lists Kiro CLI, Python 3.10 or newer, GraphViz and MCP configuration among the prerequisites. AWS also says the Diagrams MCP server can create diagrams with more than 15 provider families.

AWS now also publishes an agent-plugin route. AWS says its plugins equip coding agents with skills for architecting, deploying and operating on AWS, and that the plugins are currently supported by Claude Code, Codex and Cursor.

The AWS material describes a broader package than a diagram skill. An agent plugin can include skills, MCP servers, hooks and references. That can support live documentation or operational workflows, but it also creates more configuration and review surface.

For AWS users, the MCP repository describes servers that provide AWS documentation, contextual guidance and best practices. Its documentation lists setup paths for Kiro, Cursor, VS Code, Claude Code and other MCP clients.

When should a team choose the skill?

Choose Stack Diagram when the team already knows the components it wants to explain and needs a shareable artifact. The repository’s examples cover product stacks, development tooling and an AI application.

For developer tooling, the project gives an example involving a pnpm workspace, Turborepo, Biome, Vitest, Lefthook, GitHub Actions and npm publishing. For an AI application, it names Next.js, Vercel, Supabase pgvector, Claude, Inngest and Notion.

These examples show the intended range without proving automatic discovery. The agent can draw what the user describes; it cannot confirm an undocumented connection merely because that connection would be common.

Cloud-specific workflows are more appropriate when the user needs provider documentation or live system context. AWS’s MCP documentation describes servers that provide AWS documentation, contextual guidance and best practices.

Cloudflare gives a similar example from the operations side. Its Cloudflare One stack combines skills with a code mode MCP server that can query a live account, inspect configurations and make changes through curated workflows.

Cloudflare’s skills collection covers Cloudflare products, Workers, the Agents SDK and the wider Cloudflare Developer Platform. Its public documentation says matching skills are loaded when their triggers fit the conversation.

That boundary is important. A diagram skill explains a stated architecture, while an operations workflow can use account context. A polished diagram should not be presented as a verified inventory without that context.

What does the skill need to run?

Stack Diagram requires Python 3.9 or later and network access for logos. PNG export uses Playwright with Chromium.

The repository says the HTML, fonts and logos are inlined into the delivered file. That supports offline rendering after the build, but it does not remove the build-time need for network access.

The project’s code and documentation are licensed under MIT. Its bundled fonts use SIL Open Font License 1.1.

The logo terms need separate attention. The project says logos come from external repositories or brand sites and are not bundled with the skill. It also says their use does not imply endorsement.

Teams publishing diagrams should keep that distinction clear. The software licence covers the project’s code and documentation, not every trademark or logo shown in an output.

What should reviewers check before sharing a diagram?

Start with the prompt, not the picture. Every box should correspond to a named component, and every arrow should represent a relationship the team can explain.

Check the entry point, data stores, authentication provider, external services and deployment path. Then compare those elements with the repository, deployment configuration and system owners.

• Check the scope: Confirm that the diagram describes a proposed design, a current system or a mixture of both.
• Check the arrows: Ask who initiates each request and where data returns.
• Check the boundaries: Remove network or security boundaries that the prompt does not establish.
• Check the file: Open the HTML without network access and confirm that the logos and fonts still render.
• Check the licence: Review the project licence and the status of third-party logos before publication.

Review is not a sign that the skill failed. The tool converts language into a visual explanation; the team remains responsible for deciding whether that explanation is accurate.

Anthropic’s randomized study of 52 software engineers found that the AI-assisted group scored 17% lower on a later mastery quiz than the hand-coding group. The study also found that users who asked follow-up and conceptual questions retained more understanding.

For diagram work, the practical lesson is direct: ask the agent to explain its assumptions, then verify the result against the system rather than accepting a plausible picture.

A useful review record should preserve the original prompt, the generated file, the host used, the installation steps and every correction made by a system owner. That record turns a one-off demonstration into an auditable test.

Teams should also separate visual defects from architecture defects. A misplaced logo is a presentation problem. An unsupported data flow is a system-understanding problem. They need different owners and different fixes.

What we could not verify?

Public project material does not establish that Stack Diagram can inspect a codebase, compare a diagram with deployed infrastructure or detect architectural drift.

The public record also does not provide a formal support matrix for every Agent Skills host. The repository names Claude Code, Codex, Cursor and other compatible agents, but does not define support for every implementation.

The public record does not include a controlled, captured generated HTML file from the baseline prompt or measured rendering-quality, editability or installation-success results for Claude Code, Codex and Cursor.

The repository does provide the sample prompt and public example material. A reader can inspect the project, run the documented command and preserve the returned file, but that local run would be a new measurement rather than an already published result.

The most useful next step is therefore a controlled architecture review. Install the skill with the documented command, run the fixed prompt in each named host, preserve the returned HTML and record every correction made by a system owner.

Sources

• caru-ini/stack-diagram repository
• Stack Diagram v0.2.0 release notes
• Anthropic: Equipping agents with Agent Skills
• AWS: Build AWS architecture diagrams using Kiro CLI and MCP
• Claude: interactive charts, diagrams and visualizations
• Anthropic: AI assistance and coding skills study