docs: rewrite four advanced eBPF tutorials

.agents/skills/bpf-tutorial-writing-style/SKILL.md

@@ -19,6 +19,7 @@ Introduce information at the point where the reader needs it. Compilation follow
 
 ## Tell one useful story
 
+- Position the lesson at the narrowest useful capability that the executable really provides. Keep the title, opening, CLI, normal execution path, output, and test focused on that same capability. For example, a tool that learns one domain's A record and checks one TCP port is a minimal DNS-derived IP allowlist rather than a general DNS-aware firewall.
 - Open with the concrete question the tool answers. A short factual setup is often enough; avoid invented stories.
 - Near the first mention of eBPF, use one natural sentence to say that it runs verified programs at kernel hooks and can send selected state to user space.
 - Introduce the relevant kernel subsystem and new feature when the running example needs them. State when the feature entered Linux and what it enabled.
@@ -33,6 +34,8 @@ Introduce information at the point where the reader needs it. Compilation follow
 - Keep each paragraph focused on one job. Connect facts through cause, sequence, or contrast instead of listing them like a specification.
 - Write Chinese naturally from the same facts instead of translating English sentence by sentence. Use restrained punctuation and spaces between Chinese text and Latin letters or numbers.
 - Keep technical names, code identifiers, commands, numbers, output, versions, and references exact.
+- Match operational terms to behavior. Call a tool a profiler when it collects a profile such as sampled call paths or a distribution, an index when it maintains a searchable or ordered index, and a policy tool when it actually enforces a decision.
+- For a stateful policy, teach the complete trust chain: which event creates candidate state, which fields correlate later events, which checks admit state, how time or deletion retires it, and which hook makes the final decision. Give poisoning, stale-state, and bypass resistance the space required to explain the mechanism.
 
 Use this Chinese paragraph only as a voice reference for connected rhythm, restrained symbols, and technical density:
 

.agents/skills/find-bpf-tutorial-topic/SKILL.md

@@ -53,6 +53,8 @@ For every serious candidate, write five short fields:
 
 Defer an idea when these fields remain vague. A helper name alone is not a tutorial topic.
 
+Before marking a feature-driven candidate ready, verify the complete API path against the target kernel. Check the intended BPF program type, map fields, helpers or kfunc sets, sleepability, locking, and verifier restrictions together; a selftest using another program type is not evidence that the proposed hook can use the same API. Build and load the smallest representative probe in KVM when static inspection leaves doubt. If the target program type cannot use the feature, choose a scenario where it can instead of routing data through user space solely to make the API appear in the example.
+
 ## Score value
 
 Score from evidence, then subtract costs. Keep the breakdown in working notes and place the final score in `TUTORIAL_IDEAS.md`.
@@ -80,6 +82,7 @@ A candidate can become `ready` only when:
 - the repository does not already teach the same flow;
 - the example can fit one coherent tutorial;
 - primary sources establish the technical claims;
+- the intended program type can load every required map and API on the target kernel;
 - required kernel, architecture, privilege, and hardware conditions are known;
 - the likely maintenance burden is proportionate to its value.
 

.agents/skills/write-bpf-production-tutorial/SKILL.md

@@ -19,6 +19,8 @@ Read these inputs before writing:
 
 Collect the facts the reader needs: the problem, the kernel/user-space flow, feature versions, requirements, commands, real output, cleanup, scope, and references. Add alternatives when they help the reader choose or understand the mechanism. Keep every claim grounded in the code, tests, captured output, or a primary source. Preserve an existing draft before a from-scratch rewrite.
 
+Write down the narrowest useful description supported by the normal execution path before drafting. Use it to align the title, opening, CLI, output, and test. For stateful security examples, include the correlation key, admission checks, state lifetime, enforcement point, and the negative cases exercised by the test.
+
 Make the example a small useful tool. Its normal mode works on a reader-selected process, cgroup, interface, or other real target. A deterministic demo or integration test may create its own workload. Keep the CLI compact and keep infrastructure details out of public text.
 
 Build and run the example when the environment supports it. Use `$test-bpf-tutorial-kvm` for kernel features that need the repository's KVM environment. Runtime details support the tutorial; local workspace paths, VM names, shared repositories, caches, prompts, and agent traces stay private.
@@ -57,6 +59,8 @@ Inspect both files and the diff instead of trusting the model's final message. C
 
 - both languages are complete and tell the same technical story;
 - the opening reads like a tutorial rather than an abstract or feature list;
+- every mechanism promised by the title and introduction appears in the executable path, and a feature-driven lesson both uses and explains the named API;
+- the title and opening describe the narrowest useful behavior proven by the normal mode and test, without expanding a focused allowlist, profiler, index, capture tool, or monitor into a broader product category;
 - the relevant eBPF and kernel background appears before details that depend on it;
 - the high-level mechanism is explained before code sections;
 - compilation/execution is AFTER code analysis;