ワンクリックでManusで任意のスキルを実行

atomic-wiki

スター40

フォーク5

更新日2026年6月12日 20:14

Conversational wiki and capture-bucket routing. Fires when the user wants a place, space, or folder for notes, research, tickets, raw dumps, or knowledge capture — checks the <wikis> block in ~/.claude/CLAUDE.md; if the cwd is under a registered realm, creates the folder as a bucket via `atomic wiki bucket add` rather than a bare mkdir. Also fires on "add a bucket", "set up a karpathy wiki", "karpathy realm", "set up a wiki for my projects", "add this to my wiki", "wiki this", "what does my wiki know about X", "is my wiki stale". Not invoked by other commands — this skill is the conversational entry point for wiki and bucket operations; /refresh-wiki is the synthesis engine.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

damusix

damusix/atomic-claude

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Realm resolution

Read the <wikis> block in ~/.claude/CLAUDE.md (outside <atomic>, CLI-managed). Each entry is a path to a registered wiki's index.md. The realm root is the directory containing wiki/index.md.

cwd under a realm root → that realm is active. Bucket operations target it.
No registered realm + setup intent → atomic wiki scan --root <path> bootstraps. Ask which folder is the realm root if ambiguous.
atomic binary absent → say so; point at /refresh-wiki and docs/reference/wiki-workflow.md. Do not hand-build the structure.

Bucket creation route

When the user wants a folder for notes, tickets, research, or any loose material and the cwd is under a registered realm:

Run atomic wiki bucket add <name> --root <realm-root> — never bare mkdir.
- Creates <realm-root>/<name>/index.md (stub: purpose line + ## Conventions placeholder).
- Creates wiki/.buckets/<name>/ (empty manifest dir).
- Splices a <bucket name="<name>" path="<abs-path>"/> entry into the <wiki-buckets> block in wiki/index.md.
- On the first bucket in the realm, writes a ## Capture surfaces section to the realm CLAUDE.md.
Drive the meaning-fill: ask the user what the bucket is for, then replace the  placeholder in the realm CLAUDE.md ## Capture surfaces section and write the bucket's index.md purpose line + ## Conventions block to match. Code writes structure; the model writes meaning.

Reserved name wiki is refused by the binary. If <wiki-buckets> carries declined="true", bucket add removes the attribute when registering a new bucket.

Karpathy-wiki setup route

When the user asks to set up a wiki for a folder of projects:

Run atomic wiki scan --root <realm-root> to scaffold wiki/ and classify member repos.
Offer bucket names — research, raw, tickets are examples; user defines the actual names.
Create each named bucket via atomic wiki bucket add <name>.
Fill in meaning for each bucket's index.md and ## Capture surfaces entry.
Point at /refresh-wiki for the synthesis pass that writes wiki/repos/, wiki/concerns/, and wiki/knowledge/.

Wiki repo commits happen inside wiki/ — never the realm root.

Query and staleness route

"what does my wiki know about X" → read wiki/index.md, wiki/knowledge/, wiki/repos/, wiki/concerns/ for the active realm. Summarize what is present; say explicitly if nothing matches.
"is my wiki stale" → run atomic wiki stale --root <realm-root>. Exit 0 = fresh. Exit 1 = stale: stdout lists DRIFT/STALE lines (including STALE bucket <name> for buckets with a non-empty diff). Exit 2 = hard error.

Conventions that prevent foot-guns

<wiki-scan> and <wiki-buckets> blocks in wiki/index.md are code-owned — never hand-edit them.
wiki/concerns/ files need a reflects: stamp or they perpetually STALE-nag. Route through /refresh-wiki; or stamp after a light single-file edit with atomic wiki stamp.
Knowledge pages (wiki/knowledge/<topic>.md) are stamped via atomic wiki stamp --knowledge — never write sources: frontmatter by hand; the model declares which bucket files contributed, code writes every SHA-256 value.
Light single-file edit + stamp vs full /refresh-wiki for anything multi-artifact — full refresh is for batch staleness.

Boundaries

Complements /refresh-wiki: /refresh-wiki is the synthesis engine (repo summaries, bucket synthesis, concern re-auth, linkify). This skill is the conversational entry point — it registers and describes; /refresh-wiki synthesizes.
Not invoked by other commands. No cross-reference needed in the other direction.
Never bare mkdir for capture intent in a registered realm. atomic wiki bucket add is the only correct path — it wires the manifests and registry.

このリポジトリの他の Skills

同じリポジトリ

atomic-cli-contrib

damusix/atomic-claude

Conventions for editing the atomic CLI and command artifacts in this repo. Auto-fires on phrases like "add a CLI subcommand", "wire a new flag", "prompt the user", "add a doctor check", "add a doctor repair", "edit cmd/atomic/main.go", "extend claudeinstall", "add an internal package", "use huh", "add a command", "create a new verb", "add a partial", "render templates", "edit a command", "edit commands/", "create a new command", "edit an agent", "edit agents/", or "add an agent". Contributor-only — never bundled, never installed.

2026-06-2440

atomic-debug

damusix/atomic-claude

Hypothesis-driven debugging skill. Use when a bug, test failure, crash, or unexpected behavior is reported. Auto-trigger on error pastes or "broken/doesn't work/failing" language. Explicit invocation: /atomic-debug. Output: symptom statement → hypothesis table → cheapest test first → root cause. No symptom-patching. Boundary with atomic-tdd: this skill owns diagnosing an unknown root cause. Once the cause is known and you are writing the fix, that is atomic-tdd's job (failing test first, then the fix).

2026-06-2440

atomic-tdd

damusix/atomic-claude

Test-first discipline. Auto-triggers on "let's implement X", "add feature Y", "fix bug Z", "write a test for", "implement", "build out", and similar pre-code-change phrases. Iron rule: failing test exists before production code. Skip only for pure docs/config changes with an explicit "skipped because:" note. Explicit invocation: /atomic-tdd. Boundary with atomic-debug: this skill owns writing or changing code — new behavior, or a fix whose root cause is already understood. Diagnosing why something is broken (unknown cause) is atomic-debug's job; debug to the root cause first, then return here to write the fix test-first.

2026-06-2440

atomic-visual-options

damusix/atomic-claude

Planning-phase visual comparison aid. Renders 2-4 side-by-side variants per decision dimension as a single throwaway, self-contained HTML file and captures the user's pick as typed terminal codes (e.g. "A2 B3"). Auto-fires on phrases like "show me a few options", "mock up some variants", "let me see this side by side", "visual options for", "compare these layouts", "show layout options", "wireframe some choices". Also invoked by /atomic-plan just-in-time when a design question is genuinely visual. Scope is strictly visual choices — mockup, layout, color, spacing, hierarchy, diagram — not conceptual or text decisions, which stay in the terminal.

2026-06-1840

atomic-review

damusix/atomic-claude

Compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix. Use when user says "review this PR", "code review", "review the diff", or invokes /atomic-review. Auto-triggers when reviewing pull requests.

2026-06-1740

atomic-commit

damusix/atomic-claude

Compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. Use when user says "write a commit", "commit message", "generate commit", or invokes /atomic-commit. Auto-triggers when staging changes.

2026-06-1140

name

atomic-wiki

description

Auto-fires on:

"I want a place for my notes / research / tickets / raw dumps"
"create a space for [notes|tickets|research]" — any capture-intent phrase
"add a bucket", "add this to my wiki", "wiki this"
"set up a karpathy wiki", "karpathy realm", "set up a wiki for my projects"
"what does my wiki know about X"
"is my wiki stale"

Conversational entry point for wiki and capture-bucket operations. Code writes structure; the model writes meaning. Degrades gracefully when atomic binary is absent.

Realm resolution

cwd under a realm root → that realm is active. Bucket operations target it.
No registered realm + setup intent → atomic wiki scan --root <path> bootstraps. Ask which folder is the realm root if ambiguous.
atomic binary absent → say so; point at /refresh-wiki and docs/reference/wiki-workflow.md. Do not hand-build the structure.

Bucket creation route

When the user wants a folder for notes, tickets, research, or any loose material and the cwd is under a registered realm:

Run atomic wiki bucket add <name> --root <realm-root> — never bare mkdir.
- Creates <realm-root>/<name>/index.md (stub: purpose line + ## Conventions placeholder).
- Creates wiki/.buckets/<name>/ (empty manifest dir).
- Splices a <bucket name="<name>" path="<abs-path>"/> entry into the <wiki-buckets> block in wiki/index.md.
- On the first bucket in the realm, writes a ## Capture surfaces section to the realm CLAUDE.md.
Drive the meaning-fill: ask the user what the bucket is for, then replace the  placeholder in the realm CLAUDE.md ## Capture surfaces section and write the bucket's index.md purpose line + ## Conventions block to match. Code writes structure; the model writes meaning.

Reserved name wiki is refused by the binary. If <wiki-buckets> carries declined="true", bucket add removes the attribute when registering a new bucket.

Karpathy-wiki setup route

When the user asks to set up a wiki for a folder of projects:

Run atomic wiki scan --root <realm-root> to scaffold wiki/ and classify member repos.
Offer bucket names — research, raw, tickets are examples; user defines the actual names.
Create each named bucket via atomic wiki bucket add <name>.
Fill in meaning for each bucket's index.md and ## Capture surfaces entry.
Point at /refresh-wiki for the synthesis pass that writes wiki/repos/, wiki/concerns/, and wiki/knowledge/.

Wiki repo commits happen inside wiki/ — never the realm root.

Query and staleness route

"what does my wiki know about X" → read wiki/index.md, wiki/knowledge/, wiki/repos/, wiki/concerns/ for the active realm. Summarize what is present; say explicitly if nothing matches.
"is my wiki stale" → run atomic wiki stale --root <realm-root>. Exit 0 = fresh. Exit 1 = stale: stdout lists DRIFT/STALE lines (including STALE bucket <name> for buckets with a non-empty diff). Exit 2 = hard error.

Conventions that prevent foot-guns

<wiki-scan> and <wiki-buckets> blocks in wiki/index.md are code-owned — never hand-edit them.
wiki/concerns/ files need a reflects: stamp or they perpetually STALE-nag. Route through /refresh-wiki; or stamp after a light single-file edit with atomic wiki stamp.
Knowledge pages (wiki/knowledge/<topic>.md) are stamped via atomic wiki stamp --knowledge — never write sources: frontmatter by hand; the model declares which bucket files contributed, code writes every SHA-256 value.
Light single-file edit + stamp vs full /refresh-wiki for anything multi-artifact — full refresh is for batch staleness.

Boundaries

Complements /refresh-wiki: /refresh-wiki is the synthesis engine (repo summaries, bucket synthesis, concern re-auth, linkify). This skill is the conversational entry point — it registers and describes; /refresh-wiki synthesizes.
Not invoked by other commands. No cross-reference needed in the other direction.
Never bare mkdir for capture intent in a registered realm. atomic wiki bucket add is the only correct path — it wires the manifests and registry.