Create, update, or finalize a note in the kolu Atlas (docs/atlas) — frontmatter, the MDX component kit, build + check-sync, and the preview/share links. Use whenever authoring or editing an Atlas note (e.g. a /be plan-of-record).
Scanned 9/5/2026
Install to Claude Code
npx -y skills add juspay/kolu --skill atlas --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Atlas?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/juspay-atlas-kolu)More formats (shields.io, HTML) on the badges page.
---
name: atlas
description: Create, update, or finalize a note in the kolu Atlas (docs/atlas) — frontmatter, the MDX component kit, build + check-sync, and the preview/share links. Use whenever authoring or editing an Atlas note (e.g. a /be plan-of-record).
argument-hint: "<slug | what the note is about>"
---
# Atlas note
A self-contained Astro project at `docs/atlas/`. Author MDX in
`docs/atlas/src/content/atlas/<slug>.mdx` (flat, ancestry-free slug); Astro
renders the committed `docs/atlas/dist/<slug>.html`. Sync rules:
`.apm/instructions/atlas.instructions.md`.
## 1. Author
```yaml
---
title: Title in Title Case
description: One line — what this note is about.
parents: [feature] # REQUIRED — the filing edge(s). Categories (bug · feature · analysis · reference) are notes marked `moc: true`; there is no `kind` field.
status: proposed # optional — proposed → accepted → implemented (features then archive, §4)
maturity: seedling # seedling → budding → evergreen
updated: <YYYY-MM-DD>
---
```
`parents` is the single filing mechanism — list the index note and/or topical
hubs. A proposal is just a note under its real index with `status: proposed`.
- Prose in markdown; the component kit (`docs/atlas/src/components/` —
`<Cite>`, `<Callout>`, `<PrLink>`, `<Footnote>`, `<Terminal>`,
`<AtlasMockup>`, `<Svg>`, `<D2>`, …) only where markdown can't.
- **Push asides into `<Footnote>`, not parentheticals** — caveats, citations,
"why we rejected X". It renders as a superscript with a popover (full MDX
body). Not for load-bearing claims (inline) or whole paragraphs (`###` or
`<Callout>`).
- **Every phased work item carries an Atlas-unique identifier** — a track
prefix + number (`W3`, `SR5`), never a bare ordinal ("phase 2"). Declare a
new prefix once (grep for collisions), lead the section heading with it
(`### SR5 — …`), and reference it verbatim everywhere — no invented monikers.
- **Headings are an outline**: 3–5 genuine peer concepts as `##`s, no
catch-all buckets ("Details", "Misc"), no re-leveling to fake the count.
- **A plan's shape is free-form** — let content pick the structure; prefer
tables/diagrams over prose runs. **Default to one PR**: split into phases
only for a real sequencing constraint, not to look thorough.
- **Architecture ⇄ implementation is a loop**: a structural verdict
(package-vs-module, electricity-vs-leaf) is contingent on an implementation
choice — surface that choice as an explicit decision and state the verdict
conditioned on it, in both directions. (Adopting an external engine *reuses*
its electricity, leaving a thin leaf wrapper — don't miscount a dependency
as a receptacle you own.)
- **A plan-of-record is build-ready or it is not done** — written for the
*implementing* agent: another agent can execute it straight through without
asking anything. Before presenting, fix (don't leave for the user to catch):
- **Open decisions**: every fork that changes the build is resolved — bake
low-stakes ones in as defaults; put the genuinely user-facing forks in
**one batched `AskUserQuestion` up front** (mockup-rich previews).
- **Template phrasing / vague hand-waving**: every risk is named concretely
with its mitigation; if a sentence would make an implementer ask "like
what, specifically?", it isn't done.
- **Unpinned proof-paths**: a phase that exists to graduate or de-risk a
specific code path names **that path** and carries a done-criterion only
that path can satisfy — otherwise the implementer ships a green PR by the
easiest route and the graduation silently doesn't happen.
- **Phases a human can't verify**: each phase states its user-visible delta
("none" when internal), a reproducible manual acceptance path (a test
command is supporting evidence, not the path), and the sequencing reason
it's separate.
- **Structural notes lead with an architecture diagram.** Prefer a
hand-authored inline **SVG** (`<Svg svg={…} caption="…" />`, file in
`src/diagrams/`, imported `?raw`; re-author wholesale, don't
coordinate-patch) — colour as meaning, deliberate emphasis. **A dense
diagram must pass `wide`** or its text renders unreadably tiny in the 46rem
column. Reach for **D2** (`<D2 code={…} />`) only when auto-layout of a
large nested graph genuinely beats hand placement — then `direction: down`
(right renders wide and shrinks text). Toss-up → SVG.
- A note-local component is defined inline in the `.mdx`; promote to
`src/components/` only on reuse. Never hand-edit `dist/`.
## 2. Build & verify
`just atlas::build`, stage `docs/atlas/dist/`, finish with
`just atlas::check-sync` (the `ci::atlas-sync` gate). **The build empties
`dist/` before regenerating** — a `git add -A`/commit racing a running build
silently stages ~50 deletions and wipes the rendered Atlas. Build in the
foreground and stage by pathspec (`git add docs/atlas/dist/ <sources>`).
## 3. Preview & share
Each `dist/<slug>.html` is self-contained: previews in kolu's Code tab, and
once merged publishes at `https://kolu.dev/atlas/<slug>.html` (index:
`https://kolu.dev/atlas/`) with the next Pages deploy.
## 4. Lifecycle
Notes are living — git is the history. Advance `status`; link the implementing
PR with `<PrLink pr={<n>} />`.
- **A finished *feature* plan archives, it does not linger.** At
`status: implemented`, delete the note and add a one-line row to
`archived-notes.mdx` (former slug · what shipped · where to look now ·
`<PrLink>`s). Then reparent children, retarget links to the deleted slug,
delete note-only diagrams, rebuild + stage + check-sync. Don't "compact" it
into a current-state page unless the substance is durable reference — then
rewrite it as that kind of note under a different parent. Implemented
**bug/analysis/reference** notes may stay when they still teach.
- **Re-planning rewrites, never layers.** Superseded phases, abandoned
attempts, and "what we tried" belong in git, not as live sections. One
numbering scheme at a time — renaming means the old labels are gone, not
cross-mapped.
ARGUMENTS: $ARGUMENTS
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!