[Extension]: Atlas — display-name correction for existing atlas entry

[ashbrener]

This updates the existing atlas catalog entry — display-name correction only.
id, version and download_url are unchanged; the only change is the human-readable
Extension Name: spec-kit-atlas → Atlas.
Rationale: every other catalog entry uses a display name rather than the repo name, and the
repo-name form only sorts correctly if a reviewer special-cases the spec-kit- prefix by hand.
Atlas sorts naturally between Archive Extension and Azure DevOps Integration.

Extension ID

atlas

Extension Name

Atlas

Version

0.1.0

Description

Synthesize spec-kit specs into faithful, interactive architecture storybooks & doc portals.

Author

Ash Brener

Repository URL

https://github.com/ashbrener/spec-kit-atlas

Download URL

https://github.com/ashbrener/spec-kit-atlas/archive/refs/tags/v0.1.0.zip

License

MIT

Homepage (optional)

https://github.com/ashbrener/spec-kit-atlas

Documentation URL (optional)

https://github.com/ashbrener/spec-kit-atlas/blob/main/README.md

Changelog URL (optional)

https://github.com/ashbrener/spec-kit-atlas/blob/main/CHANGELOG.md

Required Spec Kit Version

=0.1.0

Required Tools (optional)

• python (>=3.11) — required
• uv — required; the commands invoke the bundled scripts via uv run
• pydantic, pyyaml — required, but resolved on demand by uv run --with, so there is nothing to pre-install

No network access is used at any point, and nothing outside the extension's own working directory is written.

Number of Commands

2

Number of Hooks (optional)

0

Tags

documentation, architecture, storybook, traceability, atlas

Key Features

Spec Kit gets you from specify to plan to tasks to implement, and the result is an accurate but scattered record: specs in one place, ADRs in another, code in a third, and no single artifact a newcomer can read. Atlas turns that record into one document you can actually hand to someone — without letting it drift from the truth.

Faithfulness is architectural, not a review step. Every asserted claim carries at least one source reference that resolves to a real source fragment, and the verify gate is fail-closed: a claim with no source cannot ship. Where the specs leave something open it emits an unspecified callout instead of inventing an answer; where they contradict, it surfaces the tension rather than silently picking. The point is that a confident, wrong architecture document is worse than none.

• /speckit.atlas.storybook — one repo into one interactive, plain-English architecture storybook (a single self-contained HTML file, no build step). Organized by how the system is built, never by spec history — no spec numbers or requirement codes in the prose; those ride in citation chips. Every chip drills to the actual rendered source.
• /speckit.atlas.map — a workspace of repos into ONE melded, capability-organized story woven across tiers (docs, backend, frontend), aware of what is built versus planned, plus a hierarchical source index. On a workspace governed by an architecture contract it auto-scaffolds — one command, no hand-authored manifest.

Other properties worth knowing before you install it:

• Read-only on your sources. It never mutates the specs, code, or docs it reads.
• Deterministic and pure. Identical inputs produce byte-identical output — no clock, no randomness. The intermediate artifacts are a per-run build cache, regenerated every time, never hand-edited.
• Capability clustering is a projection of what you declared, not a guess. It groups work using the governance citations your specs actually declare, and where that grain is coarse the output is honestly coarse and flags it, rather than inventing a finer structure that the sources do not support.
• Source-agnostic core. Specs, code, design docs and ADRs all reach the core through adapters, so a new input kind is a new adapter rather than a rewrite.
• Reasoning and determinism are separated. The in-session agent does the reading and composing; deterministic scripts carry parsing, the fail-closed verify gate, and rendering. No phase hides a model behind a button.
• Accessible output. Light editorial design system, WCAG-minded contrast, and status/type always carried by a text label as well as colour, so nothing is lost in greyscale or print.

It conforms to the spec-kit-arch-governance contract (typed citations, declared topology) by vendoring a pinned copy of that contract with a drift guard — so it interoperates with a governed workspace while having no runtime dependency on that extension, and works standalone on an ungoverned project.

Testing Checklist

• Extension installs successfully via download URL
• All commands execute without errors
• Documentation is complete and accurate
• No security vulnerabilities identified
• Tested on at least one real project

Submission Requirements

• Valid extension.yml manifest included
• README.md with installation and usage instructions
• LICENSE file included
• GitHub release created with version tag
• All command files exist and are properly formatted
• Extension ID follows naming conventions (lowercase-with-hyphens)

[github-actions]

cc @github/spec-kit-maintainers — new catalog submission for review.

[github-actions]

Pull request created: #4202

Generated by Add Community Extension from Issue Submission · 222.2 AIC · ⌖ 16.5 AIC · ⊞ 35.2K