celestiaorg · jcstein · Apr 17, 2026 · Feb 20, 2026 · Feb 25, 2026 · Mar 6, 2026
diff --git a/README.md b/README.md
@@ -19,12 +19,14 @@ Welcome to the official documentation repository for [Celestia](https://celestia
 Celestia Documentation Access:
 - Clean markdown: Add .md to any URL (e.g., https://docs.celestia.org/learn/TIA/overview.md)
 - LLMs.txt: https://docs.celestia.org/llms.txt
+- Skill file: https://docs.celestia.org/SKILL.md
 - DeepWikis: https://deepwiki.com/celestiaorg/docs, https://deepwiki.com/celestiaorg/cips, https://deepwiki.com/celestiaorg/celestia-app, https://deepwiki.com/celestiaorg/celestia-node
 ```
 
 ### Resources
 
 - LLMs.txt: https://docs.celestia.org/llms.txt
+- Skill file: https://docs.celestia.org/SKILL.md (served from `public/SKILL.md`)
 - Built with: Next.js + Nextra (MDX), exported as a static site.
 - **LLM-ready**: Add `.md` to any URL to get clean markdown (e.g., `https://docs.celestia.org/learn/TIA/overview` → `https://docs.celestia.org/learn/TIA/overview.md`)
 - DeepWikis for @celestiaorg:
@@ -68,7 +70,7 @@ BASE=/docs-preview/new_docs/ NEXT_PUBLIC_BASE_PATH=/docs-preview/new_docs yarn b
 
 - `app/**/page.mdx`: documentation pages
 - `app/**/_meta.js`: sidebar order/titles
-- `public/`: static assets
+- `public/`: static assets, including the published agent skill at `public/SKILL.md`
 - `constants/*.json`: shared values referenced in MDX (e.g. `{{mainnetVersions['app-latest-tag']}}`), replaced by `plugins/remark-replace-variables.mjs`
 
 ## Useful scripts
@@ -106,10 +108,10 @@ This section outlines the standards and guidelines for maintaining consistent, h
 - **Node types**: use lowercase for node types (e.g., “bridge node”, not “Bridge Node”)
 - **Politeness**: avoid using “please” in instructional content
 - **Unique headings**: ensure no duplicate headings within a document
-- **Network references**: use “Coffee Beta” network (note the specific capitalization)
+- **Network references**: use "Mainnet Beta" network (note the specific capitalization)
 - **Latin abbreviations**: use italicized _i.e._ or _e.g._ instead of plain i.e. or e.g.
 - **Code references**: use “celestia-app” in regular text (not inline code) when referring to the application name
-- **Tab ordering**: when using tabs, order them as: Coffee Beta, Mocha, Arabica
+- **Tab ordering**: when using tabs, order them as: Mainnet Beta, Mocha, Arabica
 - **Placeholders**: use angle brackets with underscores for placeholders: `<flag_name>` not `<flag-name>` or `<flag name>`
 
 ### Documentation update procedures

diff --git a/app/build/blobstream/integrate-offchain/page.mdx b/app/build/blobstream/integrate-offchain/page.mdx
@@ -71,7 +71,7 @@ The rollup sequencer is responsible for creating blocks and, in this demo, writi
 
 Therefore, we can start by first defining the reading and writing interactions rollup nodes will have with both the Celestia and Ethereum networks. The actual implementations of these interfaces are left as exercises to the reader. Assume that those implementations of these interfaces are verifying the respective chain. For the connection to Celestia, this would likely mean connecting to a Celestia light node, which can detect faults in consensus such as hidden data. For the connection to Ethereum, this would likely mean running and connecting to a full node.
 
-More information on the RPC that is exposed by a Celestia light node can be found [in the RPC documentation](https://node-rpc-docs.celestia.org/?version=v0.28.4). Additionally, if you need more information on how to run a light node, you can [check out the documentation](/operate/data-availability/light-node/quickstart).
+More information on the RPC that is exposed by a Celestia light node can be found [in the Node API docs](/build/rpc/node-api/). Additionally, if you need more information on how to run a light node, you can [check out the documentation](/operate/data-availability/light-node/quickstart).
 
 ```go
 // CelestiaLightNodeClient summarizes the actions that a rollup that uses

diff --git a/app/build/post-retrieve-blob/client/go/page.mdx b/app/build/post-retrieve-blob/client/go/page.mdx
@@ -11,7 +11,7 @@ The Celestia Go client lets you submit and retrieve data from the Celestia netwo
 
 ## Prerequisites
 
-- Go 1.24 or later
+- Go 1.25.1 or later
 - A Celestia account (created automatically)
 - Testnet tokens from the [Mocha faucet](/operate/networks/mocha-testnet#mocha-testnet-faucet)
 
@@ -139,7 +139,7 @@ func main() {
 		if balanceStr == "0utia" || balanceStr == "0 utia" {
 			fmt.Println("Account has no funds. Fund this address at the Mocha faucet to submit blobs:")
 			fmt.Printf("Address: %s\n", address.String())
-			fmt.Println("Faucet: https://docs.celestia.org/operate/networks/mocha-testnet#mocha-testnet-faucet")
+			fmt.Println("Faucet: https://mocha.celenium.io/faucet")
 		} else {
 			if err := submitAndRetrieveBlob(ctx, c); err != nil {
 				panic(err)
@@ -246,10 +246,23 @@ go mod tidy
 Choose your connection type:
 
 <Callout type="info">
-For QuickNode: `CELE_DA_URL` uses `https://` and no port, while `CELE_CORE_GRPC` uses a port (e.g. `:9090`) and no `https://` prefix.
+To submit blobs, you need both a DA JSON-RPC endpoint on port `26658` and a consensus gRPC endpoint on port `9090`.
+The public Mocha combination verified for this guide is ITRocket for DA JSON-RPC
+and P-OPS for consensus gRPC:
+`http://celestia-testnet-consensus.itrocket.net:26658` and
+`rpc-mocha.pops.one:9090`.
 </Callout>
 
-**QuickNode (recommended for beginners):**
+**Public community endpoints (tested on Mocha):**
+
+```bash
+export CELE_DA_URL=http://celestia-testnet-consensus.itrocket.net:26658
+export CELE_DA_TLS=false
+export CELE_CORE_GRPC=rpc-mocha.pops.one:9090
+export CELE_CORE_TLS=false
+```
+
+**Managed provider (for example QuickNode):**
 
 ```bash
 export CELE_DA_URL=https://your-quicknode-url.celestia-mocha.quiknode.pro/<your-token>
@@ -259,19 +272,19 @@ export CELE_CORE_TLS=true
 export CELE_CORE_TOKEN=<your-token>
 ```
 
-**Local bridge node:**
+**Local bridge node + local consensus node:**
 
 ```bash
 export CELE_DA_URL=http://localhost:26658
 export CELE_DA_TLS=false
-export CELE_CORE_GRPC=localhost:26657
+export CELE_CORE_GRPC=localhost:9090
 export CELE_CORE_TLS=false
 ```
 
 **Read-only mode (no blob submission):**
 
 ```bash
-export CELE_DA_URL=http://localhost:26658
+export CELE_DA_URL=http://celestia-testnet-consensus.itrocket.net:26658
 export CELE_DA_TLS=false
 # Don't set CELE_CORE_GRPC for read-only mode
 ```
@@ -282,7 +295,7 @@ export CELE_DA_TLS=false
 go run main.go
 ```
 
-**First run:** You'll see your account address. Fund it at the [Mocha faucet](/operate/networks/mocha-testnet#mocha-testnet-faucet).
+**First run:** You'll see your account address. Fund it at [https://mocha.celenium.io/faucet](https://mocha.celenium.io/faucet).
 
 **Second run:** After funding, you'll see:
 
@@ -310,7 +323,7 @@ Connecting to Celestia...
 Balance: 0utia
 Account has no funds. Fund this address at the Mocha faucet to submit blobs:
 Address: celestia16k0wsej6rewd2pfh0taah35suzf3apj552q8c3
-Faucet: https://docs.celestia.org/operate/networks/mocha-testnet#mocha-testnet-faucet
+Faucet: https://mocha.celenium.io/faucet
 ✓ Tutorial complete!
 ```
 
@@ -340,10 +353,10 @@ Balance: 1000000utia
 
 ### Connection types
 
-| Purpose     | Node type      | Example URL              |
-| ----------- | -------------- | ------------------------ |
-| Read data   | Bridge node    | `http://localhost:26658` |
-| Submit data | Consensus node | `localhost:26657`        |
+| Purpose     | Node type               | Example URL                                   |
+| ----------- | ----------------------- | --------------------------------------------- |
+| Read data   | DA JSON-RPC             | `http://localhost:26658`                      |
+| Submit data | Consensus node gRPC     | `localhost:9090`                              |
 
 ### Read-only mode
 

diff --git a/app/learn/TIA/submit-data/page.mdx b/app/learn/TIA/submit-data/page.mdx
@@ -260,11 +260,11 @@ unordered transaction workflows where your system requires a single signer, a.k.
 
 ### Retrieving blobs submitted via parallel lanes
 
-When using parallel submission, retrieve your blobs using the following RPC methods:
+When using parallel submission, retrieve your blobs using the following RPC methods from the [Node API `blob` section](/build/rpc/node-api/):
 
-- [blob.Get](https://node-rpc-docs.celestia.org/#blob.Get) - Get blob by namespace and commitment
-- [blob.GetProof](https://node-rpc-docs.celestia.org/#blob.GetProof) - Get inclusion proof by height, namespace, and commitment
-- [blob.GetCommitmentProof](https://node-rpc-docs.celestia.org/#blob.GetCommitmentProof) - Get commitment proof by height, namespace, and share commitment
+- [`blob.Get`](/build/rpc/node-api/#blob) - Get blob by namespace and commitment
+- [`blob.GetProof`](/build/rpc/node-api/#blob) - Get inclusion proof by height, namespace, and commitment
+- [`blob.GetCommitmentProof`](/build/rpc/node-api/#blob) - Get commitment proof by height, namespace, and share commitment
 
 Example using blob.Get:
 
@@ -311,10 +311,10 @@ See the [Rust client tutorial](/build/post-retrieve-blob/client/rust).
 
 Using the JSON RPC API, submit data using the following methods:
 
-- [blob.Submit](https://node-rpc-docs.celestia.org/#blob.Submit)
-- [state.SubmitPayForBlob](https://node-rpc-docs.celestia.org/#state.SubmitPayForBlob)
+- [`blob.Submit`](/build/rpc/node-api/#blob.Submit)
+- [`state.SubmitPayForBlob`](/build/rpc/node-api/#state.SubmitPayForBlob)
 
-Learn more in the [celestia-node API docs](https://node-rpc-docs.celestia.org/).
+Learn more in the [Node API docs](/build/rpc/node-api/).
 
 ### Post a blob directly from Celenium
 

diff --git a/app/operate/data-availability/light-node/advanced/page.mdx b/app/operate/data-availability/light-node/advanced/page.mdx
@@ -289,7 +289,7 @@ While your node is running, run:
 celestia p2p info
 ```
 
-See also `p2p.Info` in the [celestia-node API docs](https://node-rpc-docs.celestia.org/#p2p.Info).
+See also `p2p.Info` in the [Node API `p2p` section](/build/rpc/node-api/#p2p).
 
 ---
 

diff --git a/app/operate/networks/mocha-testnet/page.mdx b/app/operate/networks/mocha-testnet/page.mdx
@@ -161,6 +161,18 @@ broadcast transactions.
 - `grpc-2.testnet.celestia.nodes.guru:10790`
 - `celestia-testnet-grpc.itrocket.net:443`
 - `celestia-t-grpc.noders.services:21090`
+- `celestiam.grpc.lava.build:443`
+- `grpc-celestia-testnet.mzonder.com:443`
+
+## Community JSON-RPC endpoints
+
+- `celestia-testnet-consensus.itrocket.net:26658`
+- `celestiam.jsonrpc.lava.build`
+- `celestia-testnet-da-archival.rpc.grove.city/v1/c33eeadb`
+
+## Community Tendermint RPC endpoints
+
+- `celestiam.tendermintrpc.lava.build`
 
 ## Community bridge node endpoints
 

diff --git a/public/SKILL.md b/public/SKILL.md
@@ -0,0 +1,168 @@
+---
+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. Docs LLM and agent support:
+   - https://github.com/celestiaorg/docs?tab=readme-ov-file#llm-and-agent-support
+3. 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.
-Original file line number
+Diff line change
@@ Expand Up / @@ -289,7 +289,7 @@ While your node is running, run: @@
     celestia p2p info
     ```
-    See also `p2p.Info` in the [celestia-node API docs](https://node-rpc-docs.celestia.org/#p2p.Info).
+    See also `p2p.Info` in the [Node API `p2p` section](/build/rpc/node-api/#p2p).
     ---
@@ Expand Down @@