Validate and perfect a Nethereum documentation section end-to-end. Use when working on docs sections (getting-started, core-foundation, signing, smart-contracts, defi, evm-simulator, devchain, account-abstraction, data-indexing, mud-framework, wallet-ui, consensus, client-extensions). Covers use case definition, NuGet README verification against source code with compilation, guide page creation, Claude Code plugin skill creation per use case, sidebar updates, and build verification. Trigger when user mentions validating docs, fixing a docs section, creating guides, or perfecting documentation for any Nethereum section.
You are perfecting the documentation for a section of the Nethereum Docusaurus site. This is a staged workflow with user approval gates — never skip a gate.
Golden rule: ZERO HALLUCINATION. Every class name, method name, namespace, parameter, and code example must be verified against actual source code. Code examples must compile.
| What | Path |
|---|---|
| Nethereum source | C:/Users/SuperDev/Documents/Repos/Nethereum/src/ |
| Package READMEs | C:/Users/SuperDev/Documents/Repos/Nethereum/src/{Package}/README.md |
| Docusaurus docs | C:/Users/SuperDev/Documents/Repos/Nethereum.Documentation/docs/ |
| Sync script | C:/Users/SuperDev/Documents/Repos/Nethereum.Documentation/scripts/sync-readmes.js |
| Sidebar config | C:/Users/SuperDev/Documents/Repos/Nethereum.Documentation/sidebars.ts |
| User skills plugin |
C:/Users/SuperDev/Documents/Repos/Nethereum/plugins/nethereum-skills/skills/ |
| Internal dev skills | C:/Users/SuperDev/Documents/Repos/Nethereum/.claude/skills/ |
| Tests & examples | C:/Users/SuperDev/Documents/Repos/Nethereum/tests/ |
| Doc example attribute | src/Nethereum.Documentation/NethereumDocExampleAttribute.cs |
| Playground | http://playground.nethereum.com |
| Progress tracking | C:/Users/SuperDev/Documents/Repos/Nethereum.Documentation/docs/{section}/PROGRESS.md |
Every section in sidebars.ts MUST follow this consistent structure:
{
type: 'category',
label: 'Section Name',
items: [
'section/overview', // 1. Overview page (always first)
{
type: 'category',
label: 'Guide Sub-Group Name', // 2. Guide categories (grouped by learning progression)
collapsed: false, // First group expanded, rest collapsed
items: [
'section/guide-topic-a', // Ordered for learner journey, NOT alphabetically
'section/guide-topic-b',
],
},
// ... more guide sub-groups as needed
{
type: 'category',
label: 'Package Reference', // 3. Package Reference (ALWAYS last, ALWAYS this label)
items: [
'section/nethereum-package-a', // Auto-generated from READMEs via sync-readmes.js
'section/nethereum-package-b',
],
},
],
}
{section}/overview is the entry pointnethereum-*.md pages go here. These are auto-generated from READMEs and serve as API reference, not learning materialcode-generation and similar reference-style pages go in the Guides group closest to their topic, not at the top levelCore Foundation:
Signing & Key Management:
Smart Contracts:
DevChain:
Every overview.md MUST include a guide table at the bottom listing all guides in the section, grouped by sub-category. This is how learners discover guides from the overview page. Format:
## Guides
### Sub-Group Name
| Guide | What You'll Learn |
|---|---|
| [Guide Title](guide-slug) | One-line description |
Every guide MUST lead with the simplest web3.Eth.* approach before showing advanced options. The design philosophy is: web3.Eth.* is a complete simple path for every common task. A developer should read the first 30 seconds of any guide, copy the simple code, and have it work — fees, nonce, gas all handled automatically. Deeper APIs are there when needed but never required.
:::tip The Simple Way PatternEvery guide that involves a web3.Eth operation MUST open with a tip callout showing 2-5 lines of the simplest working code:
:::tip The Simple Way
\`\`\`csharp
var receipt = await web3.Eth.GetEtherTransferService()
.TransferEtherAndWaitForReceiptAsync("0xRecipient", 1.11m);
\`\`\`
That's it. Fees, gas, nonce — all automatic.
:::
Rules for the tip:
var web3 = ... setup)Advanced or optional sections MUST be clearly labeled so beginners know they can skip them:
web3.Eth Simple Path MapThe overview page for any section that uses web3.Eth MUST include a simple path table. The Core Foundation reference table:
| Task | Simple Path |
|---|---|
| Get ETH balance | web3.Eth.GetBalance.SendRequestAsync(address) |
| Get ERC-20 balance | web3.Eth.ERC20.GetContractService(addr).BalanceOfQueryAsync(owner) |
| Get ERC-721 balance | web3.Eth.ERC721.GetContractService(addr).BalanceOfQueryAsync(owner) |
| Send ETH | web3.Eth.GetEtherTransferService().TransferEtherAndWaitForReceiptAsync(to, amount) |
| Send transaction | web3.Eth.TransactionManager.SendTransactionAndWaitForReceiptAsync(input) |
| Get block | web3.Eth.Blocks.GetBlockWithTransactionsByNumber.SendRequestAsync(num) |
| Get transaction | web3.Eth.Transactions.GetTransactionByHash.SendRequestAsync(hash) |
| Get receipt | web3.Eth.Transactions.GetTransactionReceipt.SendRequestAsync(hash) |
| Convert units | Web3.Convert.FromWei(value) / Web3.Convert.ToWei(value) |
| Resolve ENS | web3.Eth.GetEnsService().ResolveAddressAsync("vitalik.eth") |
| Multicall batch | web3.Eth.GetMultiQueryHandler() |
| Delegate EOA (EIP-7702) | web3.Eth.GetEIP7022AuthorisationService().AuthoriseRequestAndWaitForReceiptAsync(contract) |
| Check if smart account | web3.Eth.GetEIP7022AuthorisationService().IsDelegatedAccountAsync(address) |
| Get delegate contract | web3.Eth.GetEIP7022AuthorisationService().GetDelegatedAccountAddressAsync(address) |
| Revoke delegation | web3.Eth.GetEIP7022AuthorisationService().RemoveAuthorisationRequestAndWaitForReceiptAsync() |
Key message after the table: "For every row above, Nethereum handles gas estimation, nonce management, EIP-1559 fee calculation, and transaction signing automatically. You only override when you need to."
The overview must mention these built-in typed services — no ABI needed:
web3.Eth.ERC20 — balances, transfers, allowances, metadataweb3.Eth.ERC721 — NFT ownership, metadata, enumerationweb3.Eth.ERC1155 — multi-token balances and batch operationsweb3.Eth.GetEIP7022AuthorisationService() — EIP-7702 delegation lifecycle (delegate, check, get delegate, revoke)EIP7022SponsorAuthorisationService — sponsored delegation (another account pays gas)The fee estimation guide MUST open with: "Fees are automatic. You probably don't need this guide." The structure should be:
Any guide that covers read-only operations (balance queries, block queries, transaction lookups) MUST note: "These are all read-only queries — no gas, no signing, no fees needed."
EIP-7702 is a first-class Nethereum feature with dedicated high-level services. The EIP-7702 guide and any overview referencing it MUST surface the FULL lifecycle:
AuthoriseRequestAndWaitForReceiptAsync(contract)IsDelegatedAccountAsync(address)GetDelegatedAccountAddressAsync(address)RemoveAuthorisationRequestAndWaitForReceiptAsync()EIP7022SponsorAuthorisationService (sponsor pays gas)AuthoriseBatchSponsoredRequestAndWaitForReceiptAsync(keys, contract)AuthorisationList to any FunctionMessage to delegate + execute in one transactionAuthorisationGasCalculator.CalculateGasForAuthorisationDelegation() (automatic in transaction manager)IEthExternalSigner.SignAsync()The overview guide tables MUST list EVERY guide in the section. During Core Foundation validation, the EIP-7702 guide (sidebar_position 13) was missing from the Transaction Deep Dives table — this is the exact kind of gap to catch. After creating or updating any guide, verify it appears in the overview tables.
A guide is NOT a code dump with headers. Every guide must teach, not just show.
Code dump (BAD):
## Encode a String
\`\`\`csharp
var encoded = RlpEncoder.EncodeElement(dogBytes);
\`\`\`
## Encode an Integer
\`\`\`csharp
var encoded = RlpEncoder.EncodeElement(valueBytes);
\`\`\`
Guide (GOOD):
## Why RLP?
RLP is how Ethereum serializes data for the wire — transactions, blocks, and
state trie nodes are all RLP-encoded before hashing or transmitting. You'll
encounter RLP when building raw transactions, verifying Merkle proofs, or
working with the state trie directly.
Most developers never call RLP directly — `Web3` handles it for you when
sending transactions. Use these APIs when you need to:
- Build raw signed transactions offline
- Verify block header proofs
- Decode data returned by `debug_traceTransaction`
## Encode Structured Data
RLP handles two things: byte arrays and lists of byte arrays. Everything
in Ethereum gets reduced to one of these.
\`\`\`csharp
// Encode a string — first convert to bytes, then RLP-wrap
string dog = "dog";
byte[] encoded = RlpEncoder.EncodeElement(dog.ToBytesForRLPEncoding());
\`\`\`
The encoded output is `0x83646f67` — the prefix `0x83` means "byte string
of length 3", followed by the UTF-8 bytes of "dog".
Every guide MUST have these elements. Score each guide against this list:
## Header → code block → ## Header → code block is a code dump, not a guide. The text must teach — explain concepts, warn about gotchas, connect to the reader's mental model. All explanatory text must be factual and verifiable against actual Nethereum source code — never hallucinate API behavior, parameter names, or default values.Guides are NOT independent articles — they form a connected path through the section. A learner reads them in order and each guide builds on the previous one.
The Core Foundation section is the validated reference template. When validating any section, read the Core Foundation guides first to see the standard in action. Then apply the same patterns.
Journey requirements:
Next Steps must follow the learning sequence — the first link in "Next Steps" should be the NEXT guide in the sidebar order. Additional links can point to related topics, but the primary link guides the learner forward through the progression.
Prose must be helpful and factual, never hallucinated — every explanation must come from:
TransactionManagerBase.cs)NEVER write commentary that sounds authoritative but isn't verifiable. If you're unsure about behavior, check the source code first.
Context flows between guides — early guides can mention concepts explored in later guides ("We'll cover fee estimation in detail in the Fee Estimation guide — for now, Nethereum handles it automatically"). Later guides can reference earlier ones ("As we saw in Query Balance, balances are returned in Wei").
sidebar_position values must match the learning order within each sub-group. Essentials: 1-6, Deep Dives: 7-12, Keys/Encoding: 13-18, Transport: 19-20 (for Core Foundation as example).
No standalone guides — every guide must have at least 2 links in Next Steps connecting it to other guides in the section. At least one link should point forward in the sequence.
Every guide MUST open with 2-3 sentences that answer WHY and WHEN before any code appears. The opening establishes context for the learner and connects to what they already know from previous guides.
BAD opening (jumps straight to code):
# Query Blocks and Transactions
## Connect to Ethereum
\`\`\`csharp
var web3 = new Web3("https://mainnet.infura.io/v3/YOUR-PROJECT-ID");
\`\`\`
GOOD opening (establishes WHY and connects to journey):
# Query Blocks and Transactions
After sending transactions (as covered in [Transfer Ether](guide-send-eth) and
[Send Transactions](guide-send-transaction)), you'll want to inspect what happened
on-chain. This guide covers querying blocks, looking up transactions by hash,
reading receipts to check success/failure, and detecting whether an address is
a contract or a regular account.
Pattern examples from the validated Core Foundation guides:
| Guide | Opening Pattern |
|---|---|
| Query Balance | :::tip The Simple Way with 3-line ETH/ERC-20/ERC-721 patterns + "The most common first step in any Ethereum application..." |
| Unit Conversion | Already focused on the simple path (Web3.Convert) — no changes needed |
| Fee Estimation | "Fees are automatic. When you send a transaction with web3.Eth, Nethereum estimates EIP-1559 fees for you." Then "The Default: You Probably Don't Need This Guide" section |
| Send ETH | :::tip The Simple Way with 2-line transfer + "Sending ETH from one address to another is the most fundamental write operation..." Advanced sections under "## More Control" |
| Send Transactions | "The TransactionManager handles gas estimation, nonce management, and EIP-1559 fees automatically — you just provide the recipient, data, and optionally a value." |
| Query Blocks | "All queries in this guide are read-only — no gas, signing, or fees needed." |
| EIP-7702 | :::tip The Simple Way with delegate + check + get delegate + revoke (4 operations) + "For sponsored delegation, use EIP7022SponsorAuthorisationService" |
| Transaction Types | "Most of the time, Nethereum picks the right type automatically — you only need this guide when constructing raw transactions..." |
| Transaction Hash | "Every signed transaction has a deterministic hash — you can calculate it before broadcasting..." |
| Decode Transactions | "When you retrieve a transaction from the blockchain (as in Query Blocks), its Input field contains the raw ABI-encoded function call..." |
The formula:
These problems were identified during Core Foundation validation and must be checked in every section:
Assert-style code in guides — test code like Assert.Equal(expected, actual) or undefined variables from test fixtures does NOT belong in guide examples. Guides show realistic application code, not test assertions. If the source is a test, adapt it to show Console.WriteLine or meaningful variable usage.
Repeated boilerplate without cross-reference — if 5 guides all start with var web3 = new Web3(url), the later guides should say "Connect to Ethereum as shown in Getting Started" or simply show the line with a brief note, not a full "## Connect to Ethereum" section every time.
Reference disguised as a guide — a page that lists every transaction type with its fields but doesn't teach when to use each one is a reference page, not a guide. Guides answer "which one should I pick?" with decision tables and scenarios.
Dead-end guides — guides that end abruptly without Next Steps or that only link to unrelated sections. Every guide must connect back into its section's learning path.
Orphan concepts — mentioning a concept (like "EIP-1559 fees") without either explaining it or linking to the guide that does. The learner should never hit an unexplained term.
Code dumps — a section that is just ## Header followed immediately by a code block, repeated for every feature, with no explanatory text between them. Every code block MUST have at least 1-2 sentences BEFORE it explaining what we're about to do and why, and optionally a sentence AFTER explaining the output, what to watch for, or what the code connects to. The text must guide the reader through the code, not just label it. All explanatory text must reference actual Nethereum API behavior verified against source code — never hallucinate behavior or parameter names.
Entirely hallucinated READMEs — a README that documents a completely fictional API surface. During DeFi validation, the Nethereum.X402 README was 100% hallucinated: X402Service, X402Client, X402PaymentHeader, X402PaymentProposal, X402PaymentRequired attribute, IPaymentValidator, FacilitatorDiscoveryClient, IPaymentEventHandler, AddX402() — NONE existed in source code. The actual API (X402HttpClient, X402Middleware, RoutePaymentConfig, X402TransferWithAuthorisation3009Service) was completely different. Stage 2 MUST verify every class name against source, not spot-check. When a README smells wrong (aspirational API design, no matching tests), treat the entire file as suspect and rewrite from integration tests.
Wrong generic type parameters — MultiSendInput vs MultiSendFunctionInput<TFunctionMessage> is not a minor typo — it's a completely different API pattern. During DeFi validation, the GnosisSafe README used a non-existent MultiSendInput class and MultiSendOperationType enum (actual: ContractOperationType), and property To (actual: Target). Always verify generic type signatures, not just class names. Search for class ClassName AND class ClassName< to catch generic variants.
Wrong method return types — the Uniswap README showed CalculatePricesFromSqrtPriceX96 (plural) returning a tuple with .Item1/.Item2. The actual method is CalculatePriceFromSqrtPriceX96 (singular) returning a single decimal. Verify method signatures including return types, not just names. A method that returns decimal is fundamentally different from one returning (decimal, decimal).
Overview simple path tables propagating hallucinations — when a README is hallucinated, the overview page's simple path table, guide tip callouts, and skill examples all copy the same wrong API. After fixing any README, immediately check and fix all downstream artifacts: overview table, guide pages, plugin skills. Search for the old (wrong) class/method names across all doc files to catch every instance.
src/{Package}/README.md.docs/{section}/guide-*.md.Plugin skills (plugins/nethereum-skills/skills/) serve AI models as well as users. A skill must contain enough context that an AI model understands:
Every code example in guides, skills, and READMEs must be backed by a passing test tagged with [NethereumDocExample].
[NethereumDocExample] AttributeLocated in src/Nethereum.Documentation/NethereumDocExampleAttribute.cs (namespace Nethereum.Documentation). Uses a DocSection enum to ensure section names match exactly:
[Fact]
[NethereumDocExample(DocSection.CoreFoundation, "send-eth", "Transfer ETH with EIP-1559 fees", Order = 2)]
public async void ShouldTransferEtherEIP1559() { ... }
Parameters:
DocSection section — enum: CoreFoundation, Signing, SmartContracts, DeFi, EvmSimulator, InProcessNode, AccountAbstraction, DataIndexing, MudFramework, WalletUI, Consensus, ClientExtensionsstring useCase — slug matching the guide/skill name (e.g., "send-eth", "fee-estimation", "erc20-tokens")string title — human-readable title for the examplestring SkillName — optional, defaults to useCase (since guide/skill/test use cases should align)int Order — ordering within a use case (when multiple tests per use case)When creating doc examples:
[NethereumDocExample][NethereumDocExample] across test assembliesThe /commit skill (.claude/commands/commit.md) enforces documentation propagation:
The attribute lives in the standalone Nethereum.Documentation project (netstandard2.0, zero dependencies). To use it:
For xUnit test projects (already referencing Nethereum.XUnitEthereumClients):
XUnitEthereumClients references Nethereum.Documentationusing Nethereum.Documentation; to the test fileFor console test projects or any other project:
<ProjectReference Include="..\..\src\Nethereum.Documentation\Nethereum.Documentation.csproj" /> to the .csprojusing Nethereum.Documentation; to the source fileUser-facing skills are distributed as a Claude Code Plugin at plugins/nethereum-skills/. This is a single installable plugin that bundles all Nethereum user skills together. Users install it once with /plugin install nethereum-skills and all skills become auto-discoverable.
plugins/nethereum-skills/
├── .claude-plugin/
│ └── plugin.json ← manifest (name, version, description, keywords)
└── skills/
├── send-eth/
│ └── SKILL.md
├── erc20/
│ └── SKILL.md
├── events/
│ └── SKILL.md
└── ... ← one skill per use case (or grouped tightly related use cases)
After installation, skills are:
erc20 skill activates)/nethereum-skills:send-eth, /nethereum-skills:erc20, etc.Internal development skills (like this one) stay in .claude/skills/ — they are NOT part of the plugin.
This workflow can span multiple sessions. At the start of each invocation:
PROGRESS.md exists for this sectionAfter completing each stage, update PROGRESS.md with:
Goal: Identify every real-world task a developer would want to accomplish with this section's packages.
plugins/nethereum-skills/skills/ to see what already exists. Don't duplicate.| # | Use Case | Guide Page | Plugin Skill | NuGet Packages | Playground Link |
|---|
Each use case should be:
Also note any external references the guide pages should link to:
Goal: Every README referenced by the use cases must be 100% accurate. Every code example must compile.
For each NuGet package referenced in the use case table:
Find the README: src/{PackageName}/README.md
Find the .csproj: Verify the package name matches the actual project file
Find the test projects: Search tests/ and consoletests/ for test files covering this package. These are the most reliable source of verified, working code. Map them:
| Test File | Type | What It Tests | Network? |
|---|---|---|---|
| tests/Nethereum.XXX.UnitTests/SomeTest.cs | Unit | Feature X | No |
| tests/Nethereum.XXX.IntegrationTests/OtherTest.cs | Integration | Feature Y | Yes |
Common test project locations:
tests/Nethereum.{Package}.UnitTests/ — unit tests (no network)tests/Nethereum.{Package}.IntegrationTests/ — integration tests (need devchain)tests/Nethereum.Contracts.IntegrationTests/ — many packages tested here (ERC20, Multicall, ErrorReason, etc.)tests/Nethereum.Signer.UnitTests/ — transaction signing, EIP-712, EIP-155consoletests/ — demo/console test programsCross-reference every code example in the README against source code:
For each code snippet in the README:
Grep for class ClassName AND class ClassName< — does it exist? Correct namespace? Is it generic?Grep for the method signature — correct parameters? Correct return type? A method returning decimal is NOT the same as one returning a tuple.Target vs To)ContractOperationType vs hallucinated MultiSendOperationType)CRITICAL: If more than 2 classes in a README cannot be found in source, the entire README is likely hallucinated. Stop spot-checking and instead:
Grep for all public class/interface/enum)Compile-check: For each code example, verify it compiles. Prefer verifying against existing test code rather than creating new throwaway projects — if a test already exercises the same API, that's sufficient proof the example works. Only create a minimal .csx or console project for examples that have no corresponding test. If the example needs a running node, verify it compiles but note "requires running node".
Identify missing test coverage: For each package feature, check if a test exists. If a feature is documented but has no test, flag it. If a feature has a test but is undocumented, that's a missing-documentation gap. The test file is the best source for writing the documentation example.
Scan for missing functionality (critical — run every time):
For each package, systematically compare what's in the source vs what's in the README:
a. List all public classes in the package source directory (src/{PackageName}/). Use Grep for public class, public static class, public abstract class, public interface, public enum, public record.
b. Cross-reference against the README: For each public class/interface/enum found in source, check if it appears anywhere in the README. Build a table:
| Class/Interface | Source File | In README? | Importance |
|---|
c. Flag missing high-value APIs: Focus on classes that represent major features users would want to discover:
ABIEncode that wrap low-level primitives — these are what users actually wantd. Categorize gaps by severity:
ABIEncode class, EIP-712 encoding in ABI package)e. Skip internal/infrastructure classes that aren't meant for direct consumer use (e.g., internal factories, test helpers).
Check playground alignment: If a playground example exists for this package, verify the README's examples are consistent with it.
## Package: Nethereum.XXX
README: src/Nethereum.XXX/README.md
.csproj: ✅ Package name matches
Status: ✅ Valid / ⚠️ Issues Found / ❌ Major Problems
### Verified APIs
- ClassName.MethodName — ✅ src/Nethereum.XXX/File.cs:123
- ClassName.OtherMethod — ✅ src/Nethereum.XXX/File.cs:456
### Compilation Results
- Example 1 (line 30-45): ✅ Compiles
- Example 2 (line 60-80): ❌ Error CS1061: 'Web3' does not contain 'FakeMethod'
### Issues Found
- Line 45: `SomeClass.FakeMethod()` — ❌ does not exist. Actual: `RealMethod()`
- Line 67: Missing parameter `BlockParameter` — actual signature requires it
### Missing Functionality (not in README)
- 🔴 ABIEncode — high-level abi.encode/abi.encodePacked equivalent, completely undocumented
- 🔴 Eip712TypedDataEncoder — EIP-712 typed data encoding/hashing, not in ABI guide
- 🟠 FeeSuggestionService — EIP-1559 fee estimation, undocumented
- 🟡 WaitStrategy — retry/polling utility, undocumented
### Fixes Required
1. [exact description of each fix with before/after code]
2. [missing functionality to add with draft content]
Goal: Apply all approved fixes to the README files in the Nethereum repo.
Docusaurus package doc pages (nethereum-*.md) are AUTO-GENERATED from READMEs. NEVER manually edit the generated doc pages — they will be overwritten.
The pipeline works like this:
src/{PackageName}/README.md in the Nethereum reposcripts/sync-readmes.js copies READMEs → Docusaurus docs/<section>/nethereum-*.mdTo update package documentation:
src/{PackageName}/README.md in the Nethereum repocd "C:/Users/SuperDev/Documents/Repos/Nethereum.Documentation"
node scripts/sync-readmes.js "C:/Users/SuperDev/Documents/Repos/Nethereum"
npm run buildFiles you CAN manually create/edit in the Docusaurus repo:
docs/{section}/guide-*.md) — these are NOT generated by the sync scriptoverview.md files — section overview pagesPROGRESS.md — progress trackingsidebars.ts — sidebar configurationFiles you must NEVER manually edit:
docs/{section}/nethereum-*.md file — these are regenerated by sync-readmes.jssrc/{PackageName}/README.mdsync-readmes.js to regenerate Docusaurus pagesdocs/{section}/guide-*.md — guide pages may reference the wrong APIdocs/{section}/overview.md — simple path tables may use the wrong class/method namesplugins/nethereum-skills/skills/*/SKILL.md — plugin skills may have copied the wrong examplesnpm run build to verify no broken linksPROGRESS.md with fixes appliedNo gate here — proceed to Stage 4 after fixes are applied and verified.
Goal: Create polished guide pages that TEACH, not just show code.
For each use case from the approved table:
Create the guide page at docs/{section}/{guide-name}.md
Apply the Guide Quality Checklist (from the top of this document). Every guide MUST score 8/10 or higher on:
:::tip The Simple Way callout at the top (if guide involves a web3.Eth operation)Every guide page must also have:
title, sidebar_label, sidebar_position, description:::tip Claude Code ... /plugin install ...) to guide pages — plugin installation instructions will be provided separately in dedicated setup documentationSelf-review as a user: After writing, re-read the guide and ask:
Do NOT:
Update sidebars.ts following the Sidebar Structure Standard:
collapsed: falsenethereum-*.md package pages go under a "Package Reference" sub-category (ALWAYS last)sidebar_position in each guide's frontmatter to match the new orderUpdate the section overview.md to include a guide table at the bottom, grouped by sub-category, linking every guide with a one-line description of what the learner will learn.
Verify the learning journey — read all guides in sidebar order and confirm:
Goal: Read every guide in the section IN ORDER as a learner would, and verify the journey makes sense.
This stage was established during Core Foundation validation and is MANDATORY for every section.
Read every guide in sidebar order — start from the first guide in the first sub-group and read through to the last. For each guide, evaluate:
| Check | What to look for |
|---|---|
| Simple path first | Does it have a :::tip The Simple Way callout (if applicable)? Does it lead with the simplest web3.Eth approach? |
| Opening | Does it explain WHY and WHEN in 2-3 sentences before any code? |
| Advanced labeling | Are optional/advanced sections clearly marked ("More Control:", "Advanced:")? |
| Connection backward | Does it reference earlier guides where concepts were introduced? |
| Connection forward | Does Next Steps point to the next guide in sequence as its first link? |
| Factual prose | Is every claim verifiable against source code or Ethereum specs? |
| No code dumps (CRITICAL) | Does every code block have guiding text BEFORE it (what and why) and AFTER it (result, gotcha, or connection)? A guide that is just header→code→header→code is a code dump and MUST be rewritten with teaching prose. All prose must reference actual verified API behavior — never hallucinate. |
| No assert-style code | Are examples realistic app code, not test assertions? |
| No orphan concepts | Is every technical term either explained or linked? |
| Read-only callout | For query guides: does it note "no gas, signing, or fees needed"? |
| Service coverage | Are all relevant high-level services surfaced? (ERC20/721/1155, EIP-7702 delegate/check/revoke, ENS, Multicall) |
Build a journey report — for each guide, note:
Guide: guide-name.md (position N)
Opening: ✅ Good / ❌ Missing WHY/WHEN / ⚠️ Weak
Backward links: ✅ References guide-X, guide-Y / ❌ No backward references
Forward links: ✅ Next Steps → guide-next / ❌ Dead end or wrong target
Prose quality: ✅ Factual / ⚠️ Vague claims / ❌ Hallucinated content
Issues: [specific problems]
Fix all issues — apply the Guide Opening Pattern and Anti-Patterns checklist from the Guide Quality Standard section above.
Re-read the full journey after fixes to confirm it flows naturally.
A learner should be able to:
Goal: Create a user-facing plugin skill for each use case (or group of tightly related use cases).
Skills go in the plugin directory, NOT in .claude/skills/ (that's for internal dev skills only).
For each skill to create:
plugins/nethereum-skills/skills/{skill-name}/---