How do I install the Aether Docs skill?

Run npx skillmds@latest add omacom/aether-docs in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Aether Docs safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Aether Docs?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Aether Docs free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Aether Docs?

omacom (@omacom) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Aether Docs by omacom — Agent Skill

Name: Aether Docs
Author: omacom

Aether Docs

Use when working in the Aether codebase and you need detailed project documentation — architecture decisions, design rationale, flow diagrams, feature specs, ADRs, historical context, WIP drafts. Detailed docs live OUTSIDE the repo at ~/Documents/bjarne/projects/Aether. Read that folder before making non-trivial changes, and write new detailed docs there (never into the git repo's docs/ folder, which is for user-facing docs only — CLI, installation, custom apps, templates).

omacom 4f62268 2.4 KB Updated Sep 17, 2026

File contents

Aether detailed documentation

The in-repo docs (README.md, docs/*.md, CLAUDE.md) cover only the minimum needed to build, run, and understand the public feature surface. Detailed project documentation lives outside the repo at:

~/Documents/bjarne/projects/Aether

When to consult this folder

Before implementing a non-trivial feature — check for existing design docs, prior decisions, or half-finished drafts on the area you're touching.
Before architectural changes — look for ADRs or flow diagrams that explain why things are structured as they are.
When the user asks "how does X work" or "why did we build X that way" and the answer isn't obvious from code.
After a significant design discussion — write a new doc so future work has the context.

How to use

ls ~/Documents/bjarne/projects/Aether
rg "<topic>" ~/Documents/bjarne/projects/Aether

Read relevant files before drafting a plan. Cite the filename when you rely on one.

Writing new docs

When the user asks you to document a design decision, flow, or feature internal:

Write to ~/Documents/bjarne/projects/Aether/<topic>.md.
Use a short descriptive filename (e.g. palette-extraction-pipeline.md, eyedropper-loupe-design.md, adr-001-split-sidebars.md).
Include date headers so the reader can see when something was decided.

Do not put these detailed docs into the repo's docs/ folder — that directory is reserved for user-facing documentation (CLI usage, installation, custom apps, custom templates, wallhaven setup, etc.).

Do not

Don't guess at Aether's architecture or history without checking this folder first — the user keeps decisions here rather than in commit messages or PR descriptions.
Don't duplicate content from here into the repo.
Don't commit anything to git from this folder — it's deliberately outside version control.

---name: aether-docsdescription: Use when working in the Aether codebase and you need detailed project documentation — architecture decisions, design rationale, flow diagrams, feature specs, ADRs, historical context, WIP drafts. Detailed docs live OUTSIDE the repo at ~/Documents/bjarne/projects/Aether. Read that folder before making non-trivial changes, and write new detailed docs there (never into the git repo's docs/ folder, which is for user-facing docs only — CLI, installation, custom apps, templates).---# Aether detailed documentationThe in-repo docs (`README.md`, `docs/*.md`, `CLAUDE.md`) cover only the minimum needed to build, run, and understand the public feature surface. **Detailed project documentation lives outside the repo** at:```~/Documents/bjarne/projects/Aether```## When to consult this folder- Before implementing a non-trivial feature — check for existing design docs, prior decisions, or half-finished drafts on the area you're touching.- Before architectural changes — look for ADRs or flow diagrams that explain *why* things are structured as they are.- When the user asks "how does X work" or "why did we build X that way" and the answer isn't obvious from code.- After a significant design discussion — write a new doc so future work has the context.## How to use```bashls ~/Documents/bjarne/projects/Aetherrg "<topic>" ~/Documents/bjarne/projects/Aether```Read relevant files before drafting a plan. Cite the filename when you rely on one.## Writing new docsWhen the user asks you to document a design decision, flow, or feature internal:- Write to `~/Documents/bjarne/projects/Aether/<topic>.md`.- Use a short descriptive filename (e.g. `palette-extraction-pipeline.md`, `eyedropper-loupe-design.md`, `adr-001-split-sidebars.md`).- Include date headers so the reader can see when something was decided.**Do not** put these detailed docs into the repo's `docs/` folder — that directory is reserved for user-facing documentation (CLI usage, installation, custom apps, custom templates, wallhaven setup, etc.).## Do not- Don't guess at Aether's architecture or history without checking this folder first — the user keeps decisions here rather than in commit messages or PR descriptions.- Don't duplicate content from here into the repo.- Don't commit anything to git from this folder — it's deliberately outside version control.

Frequently asked questions