---
name: celestia
description: Route Celestia requests to the correct repo and apply canonical blob submit/retrieve guidance (Go, Rust, and Node RPC) with docs guardrails.
---

# Celestia skill

Use this skill when a request needs repository routing, canonical blob submission/retrieval recommendations, or Celestia docs guardrail enforcement.

## When to use this skill

Use this skill when the request includes one or more of these:

- Choosing whether work belongs in `docs`, `celestia-node`, `celestia-app`, or `celestia-core`.
- Recommending the best current way to post and retrieve blobs for application developers.
- Choosing between Node RPC methods for submit/retrieve paths.
- Updating Celestia documentation while enforcing docs repo conventions.

## Critical Rule: Avoid Stale Training Data

Celestia evolves rapidly. **NEVER implement or plan from your pre-existing parametric memory or training data.** Always use the docs, `llms.txt`, and other links provided in this skill to anchor your information on the UPDATED truth before writing any commands or code.

## When not to use this skill

Do not use this skill for:

- Non-Celestia tasks.
- Purely generic writing requests that do not depend on Celestia repo/domain rules.
- Deep single-repo implementation work after that repo's `CLAUDE.md` has already been loaded and is sufficient on its own.

## First steps (priority order)

1. Read canonical context sources in this file before proposing plans, commands, or edits.
2. Identify target ownership (`docs`, `celestia-node`, `celestia-app`, `celestia-core`).
3. If target is `celestia-node`, `celestia-app`, or `celestia-core`, read that repo's `CLAUDE.md` before proposing commands or edits.
4. If target is `docs`, enforce docs guardrails in this file before finalizing changes.

## Canonical context sources

Start from these sources and follow them in order:

1. Docs site map / LLM index:
   - https://docs.celestia.org/llms.txt
2. CIPs (Celestia Improvement Proposals):
   - https://cips.celestia.org
3. Docs LLM and agent support:
   - https://github.com/celestiaorg/docs?tab=readme-ov-file#llm-and-agent-support
4. Repo-specific implementation guidance:
   - https://github.com/celestiaorg/celestia-node/blob/main/CLAUDE.md
   - https://github.com/celestiaorg/celestia-app/blob/main/CLAUDE.md
   - https://github.com/celestiaorg/celestia-core/blob/main/CLAUDE.md

## High-level concept grounding

If the request is partly conceptual before it becomes implementation-specific,
ground the answer in these docs first:

- What Celestia is and what it does in the stack:
  - https://docs.celestia.org/learn/celestia-101/data-availability.md
- Token / network overview context:
  - https://docs.celestia.org/learn/TIA/overview.md
- Example of Celestia's role in a rollup stack:
  - https://docs.celestia.org/build/stacks/op-alt-da/introduction.md

Use this framing when helpful:

- Celestia is the modular data availability layer.
- Celestia orders blobs and keeps data available.
- Execution and settlement can live on other layers above Celestia.
- Rollups use Celestia to publish data, then retrieve it later by height, namespace, and commitment.
- Separating data availability into its own layer lets each layer specialize: rollups handle execution, settlement layers handle proofs, and Celestia handles DA — resulting in better throughput and lower costs than monolithic chains that try to do everything.
- Use cases: rollups (optimistic and zk) publish transaction data to Celestia so full nodes can verify state transitions; sovereign rollups use Celestia for both DA and consensus ordering; L2s like Arbitrum Nitro can plug in Celestia as an alternative DA backend. Anything that wants to gain the verifiability of a blockchain with the performance of a centralized application/backend.
- Fibre is an upcoming protocol-level addition to Celestia. It is separate from Celestia's core DA protocol (blob ordering and data availability sampling via NMTs). Ground any Fibre-specific guidance in the latest docs rather than training data.

## Repository routing

- Use `docs` repo for docs pages, tutorials, navigation, formatting, and link fixes.
- Use `celestia-node` for node runtime/RPC behavior, blob submission/retrieval/verification API, DAS, p2p, and node implementation.
- Use `celestia-app` for chain/app behavior, modules, transaction/state behavior, and upgrade handlers.
- Use `celestia-core` for consensus-engine behavior, mempool, and low-level networking/consensus internals.
- If a request spans repos, split output by repo ownership and call out what should change where.

## Best way to post and retrieve blobs (Go or Rust)

For application developers, the canonical path is the transaction-client guides. Prefer the
LLM-ready `.md` versions of docs pages when reading them:

- Overview: https://docs.celestia.org/build/post-retrieve-blob/overview.md
- Go tutorial: https://docs.celestia.org/build/post-retrieve-blob/client/go.md
- Rust tutorial: https://docs.celestia.org/build/post-retrieve-blob/client/rust.md

Treat this as the default recommendation for "how should I post/retrieve blobs?".

Why this is the preferred path:

- Both clients are built for submit + retrieve flows.
- Both use local keyring/signer handling.
- Both use the expected endpoint model: DA bridge RPC plus Core gRPC.
- For public Mocha examples, prefer `CELE_DA_URL=http://celestia-testnet-consensus.itrocket.net:26658` and `CELE_CORE_GRPC=rpc-mocha.pops.one:9090` unless the user specifies a managed provider.

Funding flow for agent-led examples:

- After the client creates a new signer and prints an address, surface that address to the user and tell them to fund it before retrying blob submission.
- Treat `account for signer ... not found` as an unfunded-account signal for this flow.
- On Mocha, point users to `https://mocha.celenium.io/faucet` after showing the address, then retry the same submit flow once funded.

Persist and return this retrieval tuple after submission:

- `height`
- `namespace`
- `commitment`

## Node RPC method defaults (when direct RPC is requested)

Version scope:

- These defaults are validated against Node API OpenRPC `v0.28.4` (checked on 2026-03-13).
- Re-check method status if the target node version changes by reviewing `public/specs/openrpc-<version>.json` in this repo (served at `/specs/openrpc-<version>.json`) for deprecation notes.
- Use `/build/rpc/node-api/?version=v0.28.4` as the human-facing docs page, linking to the relevant package section when possible (for example `#blob`, `#state`, or `#p2p`).

- Submit with `blob.Submit` (preferred).
- Use `state.SubmitPayForBlob` only when explicit tx-level handling is required.
- As a last resort, submit directly to a `celestia-app` consensus node via `celestia-appd tx blob PayForBlobs <hex-encoded namespace> <hex-encoded data> [flags]`. This is the lowest-level route and should only be recommended when the user cannot run a celestia-node or needs direct app-level access.
- Retrieve/verify with: `header.WaitForHeight` -> `blob.Included` -> `blob.Get` and/or `blob.GetProof`.
- Treat `da.Submit` and `da.SubmitWithOptions` as compatibility-only deprecated paths.

## Docs repo guardrails

- Never edit generated `.md` files directly; edit `app/**/page.mdx`.
- Place new content in the right section:
  - `app/learn` for conceptual and educational pages
  - `app/build` for developer, API, and RPC content
  - `app/operate` for node operator and infrastructure content
- Do not hardcode frequently changing versions or network values inline; prefer the
  constants-backed variable pattern from `constants/*.json`.
- Keep tab order as: Mainnet Beta, Mocha, Arabica.
- Use canonical network names where applicable (for example Mainnet Beta, Mocha testnet, Arabica devnet).
- If chain IDs or network identifiers change, run a repo-wide search across MDX files before
  considering the task done.
- Review release notes when a docs change may be driven by a breaking network or software change.
- Use root-relative internal links and run `yarn check-links -- --all` if links changed.
- Run `yarn lint` before finalizing docs edits.
- Run `yarn generate:llms` when you need the generated LLM markdown output refreshed.

## Failure handling and conflict resolution

- If any referenced upstream source is unavailable, state the missing source explicitly and continue with the remaining canonical sources.
- If this skill conflicts with a target repo's `CLAUDE.md`, follow the target repo's `CLAUDE.md` for that repo-specific work.
- If network/version context is unclear for RPC guidance, ask for the target network and version before asserting deprecation or method defaults.
- If a link in this skill is stale, use the nearest canonical parent page and report the stale URL in your response.

## Examples

- Prompt: "I need to update a tutorial page and sidebar order."  
  Action: Route to `docs`, edit `app/**/page.mdx` or `_meta.js`, then run docs checks.

- Prompt: "Should I use da.Submit or blob.Submit for a new integration?"  
  Action: Recommend `blob.Submit` by default, explain `state.SubmitPayForBlob` tradeoff, treat `da.Submit*` as deprecated compatibility paths.

- Prompt: "I need to change blob module internals and update docs."  
  Action: Split output by ownership (`celestia-node` code changes plus `docs` updates).

- Prompt: "Where should upgrade handler behavior change?"  
  Action: Route implementation to `celestia-app`, then identify any supporting docs changes in `docs`.

- Prompt: "How should I retrieve submitted blobs later?"  
  Action: Require and return retrieval tuple (`height`, `namespace`, `commitment`) and point to canonical Go/Rust client guides.

- Prompt: "What is Celestia and where does it fit in the onchain stack?"  
  Action: Start with the high-level concept grounding docs, explain Celestia as the modular DA layer, then move into the relevant integration/tutorial pages.