{"id":"1519cf32-8ce5-4783-918c-b6be297cd249","entityType":"agent","slug":"clawhub-athola-nm-scribe-tech-tutorial","name":"tech-tutorial","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-scribe-tech-tutorial","canonicalPath":"/agent/clawhub-athola-nm-scribe-tech-tutorial","generatedAt":"2026-10-10T10:42:46.502Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T06:17:35.012Z","emptyReason":null},"description":"Plans, drafts, and refines technical tutorials for developers","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.6K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-scribe-tech-tutorial","sourceUrl":"https://clawhub.ai/athola/nm-scribe-tech-tutorial","homepage":"https://clawhub.ai/athola/skills/nm-scribe-tech-tutorial","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-scribe-tech-tutorial","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-scribe-tech-tutorial","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":64,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"tech-tutorial technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T06:17:35.012Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T06:17:35.012Z","emptyReason":null},"stars":null,"forks":null,"downloads":1625,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"1.6K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T06:17:35.011Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T06:17:35.012Z","lastCrawledAt":"2026-10-10T06:17:35.011Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T06:17:35.011Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:22:16.651Z","changelog":"Release v1.9.19","fileCount":6,"zipByteSize":9402},{"version":"1.9.17","createdAt":"2026-07-30T05:42:12.196Z","changelog":"Release v1.9.17","fileCount":6,"zipByteSize":9522},{"version":"1.9.16","createdAt":"2026-07-14T19:59:01.551Z","changelog":"Release v1.9.16","fileCount":6,"zipByteSize":9587},{"version":"1.9.14","createdAt":"2026-06-30T18:06:37.146Z","changelog":"Release v1.9.14","fileCount":6,"zipByteSize":9489},{"version":"1.9.13","createdAt":"2026-06-27T16:24:20.080Z","changelog":"Release v1.9.13","fileCount":6,"zipByteSize":9512},{"version":"1.9.12","createdAt":"2026-06-19T03:20:04.059Z","changelog":"Release v1.9.12","fileCount":6,"zipByteSize":9501},{"version":"1.0.2","createdAt":"2026-05-09T02:20:31.744Z","changelog":"Release v1.9.5","fileCount":6,"zipByteSize":9121},{"version":"1.0.1","createdAt":"2026-05-06T14:22:02.819Z","changelog":"Release v1.9.4","fileCount":5,"zipByteSize":7914}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-scribe-tech-tutorial","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-scribe-tech-tutorial` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/athola/nm-scribe-tech-tutorial before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-tech-tutorial/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-tech-tutorial/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-tech-tutorial/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-tech-tutorial/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-tech-tutorial/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-tech-tutorial/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T10:42:46.498Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-tech-tutorial/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-tech-tutorial/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-tech-tutorial/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-tech-tutorial/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T06:17:35.012Z","emptyReason":null},"readme":"Skill: tech-tutorial\n\nOwner: athola\n\nSummary: Plans, drafts, and refines technical tutorials for developers\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:22:16.651Z | user\n\nRelease v1.9.19\n\nv1.9.17 | 2026-07-30T05:42:12.196Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:59:01.551Z | user\n\nRelease v1.9.16\n\nv1.9.14 | 2026-06-30T18:06:37.146Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:24:20.080Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:20:04.059Z | user\n\nRelease v1.9.12\n\nv1.0.2 | 2026-05-09T02:20:31.744Z | user\n\nRelease v1.9.5\n\nv1.0.1 | 2026-05-06T14:22:02.819Z | user\n\nRelease v1.9.4\n\nv1.0.0 | 2026-04-20T15:01:40.723Z | auto\n\n- Initial release of the \"tech-tutorial\" skill for planning, drafting, and refining technical tutorials for developers.\n- Provides a structured methodology with clear steps: scope definition, outline creation, code example validation, prose drafting, progressive complexity, slop check, and a final quality gate.\n- Integrates with other scribe tools for slop detection and API documentation.\n- Includes checklist-driven quality requirements and detailed instructions for writing practical, hands-on tutorials.\n- Designed to help produce step-by-step, code-driven guides with rigorous testing and clear learning outcomes.\n\nArchive index:\n\nArchive v1.9.19: 6 files, 9402 bytes\n\nFiles: modules/code-examples.md (3345b), modules/outline-structure.md (2900b), modules/progressive-complexity.md (3224b), skill-card.md (2039b), SKILL.md (6227b), _meta.json (143b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: tech-tutorial\ndescription: Plans, drafts, and refines technical tutorials for developers\nversion: 1.9.8\ntriggers:\n  - tutorial\n  - technical-writing\n  - code-examples\n  - developer-docs\n  - getting-started\n  - writing step-by-step guides or getting-started walkthroughs backed by working code\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Tech Tutorial\n\nA good technical tutorial has one goal: move a reader from not knowing\nhow to do something to being able to do it.\nThat requires working code, concrete steps, and honest acknowledgment\nof where things go wrong.\nThis skill guides you through outlining, drafting, and verifying a\ntutorial that meets that standard.\n\n## When To Use\n\n- Writing a getting-started guide for a library, CLI tool, or API\n- Creating a step-by-step walkthrough that readers follow at a terminal\n- Explaining a technical concept through a hands-on exercise\n- Producing a how-to that complements API reference documentation\n\n## When NOT To Use\n\n- Generating API reference docs (use `scribe:doc-generator`)\n- Cleaning up existing prose (use `scribe:slop-detector`)\n- Producing high-level architecture overviews without runnable steps\n- Writing conceptual essays without hands-on components\n\n## Methodology\n\n### Step 1: Scope and Audience\n\nBefore writing a single line, answer these questions:\n\n- Who is this for? (experience level, assumed prior knowledge)\n- How many readers? How often will each one read it?\n- What will they build or accomplish by the end?\n- **What is the one sentence they must walk away with?**\n  (the thesis — not the topic)\n- What is the single prerequisite the reader must have installed?\n- What is explicitly out of scope?\n\nWrite these answers down as a header block in the draft.\nIf you cannot answer the \"what will they accomplish\" question\nin one sentence, the scope is too broad. If you cannot state\nthe thesis in one sentence, the tutorial is not ready to draft.\n\nThe audience size and read frequency feed the reader-time\nbudget (see `scribe:slop-detector` module `document-economy.md`).\nA tutorial that 500 developers will read once is a 40-hour\nreader-budget asset; spend the writing time accordingly.\n\n### Step 2: Outline\n\nLoad: `@modules/outline-structure.md`\n\nProduce a section-by-section outline before drafting prose.\nEach section entry must include a one-line description of what\nthe reader does or learns in that section.\nSee the outline module for the standard section order and\nlength targets per section type.\n\n### Step 3: Draft Code Examples First\n\nLoad: `@modules/code-examples.md`\n\nWrite the code before the prose.\nEach snippet must run against a real environment before it\nappears in the tutorial.\nAnnotate only the non-obvious lines.\nSee the code examples module for formatting and error-handling rules.\n\n### Step 4: Draft Prose Around the Code\n\nProse exists to explain what the code does and why.\nFollow these rules:\n\n- One paragraph per step: what to run, what it does, what to expect\n- State the expected output after each command block\n- Use second person (\"you\") consistently throughout\n- Do not narrate what the reader will do next; just present the next step\n\n### Step 5: Build Complexity Gradually\n\nLoad: `@modules/progressive-complexity.md`\n\nStart with the minimal working example.\nIntroduce variations and edge cases only after the baseline works.\nSee the progressive complexity module for the layering rules\nand pacing guidance.\n\n### Step 6: Slop Check\n\nAfter drafting, run:\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix all tier-1 findings before proceeding.\nPay particular attention to:\n\n- Tier-1 vocabulary slop (see `scribe:slop-detector` word lists)\n- Tricolon adjective clusters (\"fast, efficient, and reliable\")\n- Participial tail-loading (sentences ending with \", enabling ...\")\n\n### Step 7: Quality Gate\n\nVerify the completed tutorial against this checklist:\n\nContent:\n- [ ] All code blocks tested and produce the stated output\n- [ ] Prerequisites section lists exact versions where relevant\n- [ ] Every step states the expected result\n- [ ] Troubleshooting section covers at least two common failure modes\n\nSentence-level:\n- [ ] No tier-1 slop words\n- [ ] Em dash count is under 2 per 1000 words\n- [ ] Bullet ratio is under 40%\n- [ ] Line length wraps at 80 characters\n\nDocument-level (document-economy module):\n- [ ] Thesis from Step 1 appears in the lead paragraph\n- [ ] Thesis echoed at the close (and ideally mid-tutorial)\n- [ ] No \"in summary\" section that re-lists what just happened\n- [ ] No section opens by restating its heading\n\n## Required TodoWrite Items\n\n1. `tech-tutorial:scope-defined` - Audience, goal, and out-of-scope noted\n2. `tech-tutorial:outline-approved` - Section outline confirmed\n3. `tech-tutorial:code-tested` - All snippets verified against a real env\n4. `tech-tutorial:prose-drafted` - Walkthrough text written\n5. `tech-tutorial:slop-scanned` - Slop detector passed\n6. `tech-tutorial:quality-verified` - Quality gate checklist cleared\n7. `tech-tutorial:user-approved` - Final approval received\n\n## Module Reference\n\n- See `modules/outline-structure.md` for section order and length targets\n- See `modules/code-examples.md` for snippet formatting and annotation rules\n- See `modules/progressive-complexity.md` for pacing and layering guidance\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| scribe:slop-detector | After drafting, before approval |\n| scribe:doc-generator | For companion API reference sections |\n| scribe:style-learner | To match an existing tutorial voice |\n\n## Exit Criteria\n\n- Tutorial outline confirmed before drafting begins\n- All code snippets tested in a real environment\n- Slop score below 1.5 (clean)\n- Quality gate checklist passed\n- User approval received\n\nFile v1.9.19:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-tech-tutorial\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787750536651\n}\n\nFile v1.9.19:modules/code-examples.md\n\n---\nmodule: code-examples\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 550\n---\n\n# Writing Effective Code Examples\n\nCode examples are the primary content of a technical tutorial.\nWrite and run each snippet before embedding it in the document.\nA tutorial with untested code is broken.\n\n## The Testing Rule\n\nEvery code block that the reader is expected to run must be tested\nin a real environment before publication.\nThis means:\n\n1. Run the command in a clean shell or container\n2. Confirm the output matches what you claim\n3. Record the exact output to quote in the tutorial\n4. Note any version-specific behavior\n\nIf you cannot test a snippet, mark it clearly as untested:\n\n```markdown\n<!-- Note: untested on Windows; verified on macOS 14.3 -->\n```\n\nNever present guessed output as verified.\n\n## Formatting Rules\n\nUse fenced code blocks with a language identifier on every block:\n\n```markdown\n```bash\nnpm install express\n```\n```\n\nCommon language identifiers:\n\n| Content Type | Identifier |\n|--------------|------------|\n| Shell commands | `bash` |\n| Python | `python` |\n| JavaScript/Node | `javascript` |\n| YAML config | `yaml` |\n| JSON output | `json` |\n| Generic output | `text` |\n\nDo not use `sh` as an identifier; use `bash` or `zsh` explicitly.\n\n## Output Blocks\n\nShow expected output after every command that produces visible output.\nUse a `text` block with the label \"Output:\" on its own line:\n\n```markdown\nRun the server:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nServer running on http://localhost:3000\n```\n```\n\nIf output is long, truncate with `...` and show the key lines:\n\n```text\nDownloading packages...\n...\nSuccessfully installed 14 packages in 2.3s\n```\n\n## Annotation Guidelines\n\nAnnotate only the non-obvious parts.\nOver-annotation creates noise that pushes readers past the code.\n\nGood annotation targets:\n\n- A flag or option whose name does not explain itself\n- A value the reader must substitute for their own\n- A syntax form they may not have seen before\n\nMark substitution points with angle brackets:\n\n```bash\ngit remote add origin git@github.com:<your-username>/<repo-name>.git\n```\n\nDo not annotate things that the code makes self-evident.\n\n## Handling Errors in Examples\n\nWhen showing an expected error (to teach debugging), be explicit:\n\n```markdown\nRunning this command before installing dependencies will fail:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nError: Cannot find module 'express'\n```\n\nInstall dependencies first, then retry.\n```\n\nNever silently show error output without explaining it.\n\n## Long Code Example Handling\n\nFor files longer than 30 lines, show only the relevant portion:\n\n```markdown\nIn `config/database.js`, update the connection string (line 12):\n\n```javascript\n// config/database.js (excerpt)\nconst connection = {\n  host: process.env.DB_HOST,\n  port: 5432,\n  database: process.env.DB_NAME,\n};\n```\n```\n\nProvide a link to the full file in a repository if one exists.\n\n## Verify Your Examples Work\n\nBefore including any example, run this checklist:\n\n- [ ] Command produces the stated output\n- [ ] Tested in the same environment as the reader will use\n- [ ] Language identifier is present on the fenced block\n- [ ] Output block follows every command with visible output\n- [ ] Substitution points use angle bracket notation\n- [ ] Untested blocks carry an explicit disclaimer\n\nFile v1.9.19:modules/outline-structure.md\n\n---\nmodule: outline-structure\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 500\n---\n\n# Tutorial Outline and Structure\n\nA tutorial outline is a contract with the reader: it says what they\nwill do and in what order.\nWrite the outline before drafting any prose.\nIf an outline entry is hard to describe in one line, the section\nis too large and needs splitting.\n\n## Standard Section Order\n\nMost technical tutorials follow this sequence:\n\n1. **Title** - What the reader will build or accomplish\n2. **Prerequisites** - What they must have installed or know\n3. **What You Will Build** - One paragraph, concrete outcome\n4. **Setup** - Environment configuration steps\n5. **Core Steps** - The numbered sequence of actions\n6. **Verify It Works** - How to confirm success\n7. **Troubleshooting** - Two to four common failure modes\n8. **Next Steps** - One or two natural follow-on tasks\n\nNot every tutorial needs all eight sections.\nShort tutorials (under 500 words) can omit Next Steps and\nmerge Verify with the final core step.\n\n## Length Targets per Section\n\n| Section | Target Length |\n|---------|---------------|\n| Title | 5-10 words |\n| Prerequisites | 30-60 words |\n| What You Will Build | 50-100 words |\n| Setup | 50-150 words |\n| Each Core Step | 30-80 words |\n| Verify It Works | 30-60 words |\n| Troubleshooting | 50-150 words |\n| Next Steps | 20-40 words |\n\n## Prerequisite Section Rules\n\nState prerequisites as a list of specific, verifiable items.\nVague prerequisites waste the reader's time.\n\n```markdown\nBAD:\n- Basic programming knowledge\n- Familiarity with the command line\n\nGOOD:\n- Python 3.11 or later (`python3 --version`)\n- A GitHub account with SSH access configured\n- `curl` available on your system\n```\n\nEach prerequisite should be verifiable in under 30 seconds.\nIf the reader cannot confirm it with a single command, add\nthe command.\n\n## Core Steps Structure\n\nEach step in the numbered sequence should follow this pattern:\n\n1. One sentence describing what the reader does\n2. The command or code block to run\n3. The expected output or result (required for commands)\n4. One optional sentence explaining why, if non-obvious\n\nKeep explanatory prose after the code, not before it.\nThe reader runs first, then reads why.\n\n## Troubleshooting Section\n\nCover the two to four errors most likely to occur.\nStructure each entry as:\n\n```markdown\n### Error: [exact error message or symptom]\n\n**Cause**: [one sentence]\n\n**Fix**: [one to three steps]\n```\n\nDo not include every possible error.\nFocus on the errors that newcomers hit in the first ten minutes.\n\n## Outline Validation Checklist\n\nBefore drafting:\n\n- [ ] Every section has a one-line description of reader action\n- [ ] Prerequisites are specific and verifiable\n- [ ] Core steps are numbered and ordered\n- [ ] Troubleshooting has at least two entries planned\n- [ ] Total planned length is under 2000 words for a starter guide\n\nFile v1.9.19:modules/progressive-complexity.md\n\n---\nmodule: progressive-complexity\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 480\n---\n\n# Building Complexity Gradually\n\nThe most common tutorial failure is starting too hard.\nThe reader gets lost before the baseline works, gives up, and\nblames the tool.\nStart with the minimum that produces a visible result.\nAdd variation only after that baseline is solid.\n\n## The Minimal Example First\n\nThe first working example should be the shortest possible program\nthat demonstrates the core concept.\nIt need not be production-quality; it must be correct and runnable.\n\n```markdown\nBAD: Start with a full web server including auth, logging,\nand database connections.\n\nGOOD: Start with a server that returns \"Hello, World!\" on port 3000.\n```\n\nThe minimal example answers one question: does this thing work?\nOnce the reader sees it working, they are ready to learn more.\n\n## The Layering Model\n\nIntroduce complexity in layers.\nEach layer adds one new concept or one new component.\nA reader should be able to stop at any layer and have\na working system.\n\nLayer pattern:\n\n1. **Baseline** - The minimal working example\n2. **First extension** - Add one realistic feature\n3. **Second extension** - Add error handling or configuration\n4. **Production pattern** - Show what the real thing looks like\n\nNot every tutorial needs all four layers.\nA focused tutorial may only need baseline plus one extension.\n\n## Pacing Rules\n\n- Complete one layer before describing the next\n- State what you are about to add before adding it\n- Do not introduce two new concepts in a single step\n- Run the code after each layer to show it still works\n\n```markdown\nBAD:\n\"Now we will add authentication, a database connection,\nand rate limiting...\"\n\nGOOD:\n\"The server works. Now add a database connection.\nAuthentication comes in the next section.\"\n```\n\n## When to Introduce Alternatives\n\nIntroduce alternative approaches only after the primary path works.\nThe reader needs one good path before they can evaluate tradeoffs.\n\n```markdown\nBAD: \"You could use Redis or Memcached or an in-memory store here.\"\n\nGOOD: \"We use Redis here. Once this works, see [link] for\nthe Memcached variant.\"\n```\n\n## Complexity Signals to Watch For\n\nSigns that a section has become too complex:\n\n- A step has more than one code block with no \"run this\" between them\n- You are explaining a concept that requires another concept first\n- The expected output section requires more prose than the step itself\n- You find yourself writing \"before we continue, you should know...\"\n\nWhen you see these signals, split the section or move the prerequisite\nknowledge into the Prerequisites section.\n\n## End-State Clarity\n\nThe reader must know what they are building toward before they start.\nState the end state in the \"What You Will Build\" section as a concrete\ndescription, not a list of features:\n\n```markdown\nBAD:\n\"You will learn authentication, sessions, and middleware.\"\n\nGOOD:\n\"By the end of this tutorial, you will have a Node.js server\nthat accepts a username and password, issues a signed JWT,\nand rejects requests without a valid token.\"\n```\n\nThe end state should be verifiable: the reader can check that they\nachieved it by running one command or visiting one URL.\n\nFile v1.9.19:skill-card.md\n\n## Description:\n\nPlans, drafts, and refines technical tutorials for developers.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and technical writers use this skill to plan, draft, and verify hands-on tutorials with scoped audience goals, tested code examples, expected outputs, troubleshooting, and quality checks.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may propose install commands, terminal commands, or commands copied from a user-provided draft.\n\nMitigation: Review proposed commands before execution and test tutorial snippets in a real environment before publishing them.\n\nRisk: The artifact references a separate Claude Code plugin for the full experience.\n\nMitigation: Assess the referenced plugin separately before installing or relying on it.\n\n## Reference(s):\n\n- [ClawHub Skill Page](https://clawhub.ai/athola/skills/nm-scribe-tech-tutorial)\n- [Claude Night Market Scribe Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/scribe)\n- [Code Examples Module](modules/code-examples.md)\n- [Outline Structure Module](modules/outline-structure.md)\n- [Progressive Complexity Module](modules/progressive-complexity.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown with fenced code blocks, command examples, checklists, and tutorial prose]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May propose commands or snippets that should be reviewed and tested before publication or execution.]\n\n## Skill Version(s):\n\n1.9.19 (source: ClawHub release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.17: 6 files, 9522 bytes\n\nFiles: modules/code-examples.md (3345b), modules/outline-structure.md (2900b), modules/progressive-complexity.md (3224b), skill-card.md (2384b), SKILL.md (6227b), _meta.json (143b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: tech-tutorial\ndescription: Plans, drafts, and refines technical tutorials for developers\nversion: 1.9.8\ntriggers:\n  - tutorial\n  - technical-writing\n  - code-examples\n  - developer-docs\n  - getting-started\n  - writing step-by-step guides or getting-started walkthroughs backed by working code\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Tech Tutorial\n\nA good technical tutorial has one goal: move a reader from not knowing\nhow to do something to being able to do it.\nThat requires working code, concrete steps, and honest acknowledgment\nof where things go wrong.\nThis skill guides you through outlining, drafting, and verifying a\ntutorial that meets that standard.\n\n## When To Use\n\n- Writing a getting-started guide for a library, CLI tool, or API\n- Creating a step-by-step walkthrough that readers follow at a terminal\n- Explaining a technical concept through a hands-on exercise\n- Producing a how-to that complements API reference documentation\n\n## When NOT To Use\n\n- Generating API reference docs (use `scribe:doc-generator`)\n- Cleaning up existing prose (use `scribe:slop-detector`)\n- Producing high-level architecture overviews without runnable steps\n- Writing conceptual essays without hands-on components\n\n## Methodology\n\n### Step 1: Scope and Audience\n\nBefore writing a single line, answer these questions:\n\n- Who is this for? (experience level, assumed prior knowledge)\n- How many readers? How often will each one read it?\n- What will they build or accomplish by the end?\n- **What is the one sentence they must walk away with?**\n  (the thesis — not the topic)\n- What is the single prerequisite the reader must have installed?\n- What is explicitly out of scope?\n\nWrite these answers down as a header block in the draft.\nIf you cannot answer the \"what will they accomplish\" question\nin one sentence, the scope is too broad. If you cannot state\nthe thesis in one sentence, the tutorial is not ready to draft.\n\nThe audience size and read frequency feed the reader-time\nbudget (see `scribe:slop-detector` module `document-economy.md`).\nA tutorial that 500 developers will read once is a 40-hour\nreader-budget asset; spend the writing time accordingly.\n\n### Step 2: Outline\n\nLoad: `@modules/outline-structure.md`\n\nProduce a section-by-section outline before drafting prose.\nEach section entry must include a one-line description of what\nthe reader does or learns in that section.\nSee the outline module for the standard section order and\nlength targets per section type.\n\n### Step 3: Draft Code Examples First\n\nLoad: `@modules/code-examples.md`\n\nWrite the code before the prose.\nEach snippet must run against a real environment before it\nappears in the tutorial.\nAnnotate only the non-obvious lines.\nSee the code examples module for formatting and error-handling rules.\n\n### Step 4: Draft Prose Around the Code\n\nProse exists to explain what the code does and why.\nFollow these rules:\n\n- One paragraph per step: what to run, what it does, what to expect\n- State the expected output after each command block\n- Use second person (\"you\") consistently throughout\n- Do not narrate what the reader will do next; just present the next step\n\n### Step 5: Build Complexity Gradually\n\nLoad: `@modules/progressive-complexity.md`\n\nStart with the minimal working example.\nIntroduce variations and edge cases only after the baseline works.\nSee the progressive complexity module for the layering rules\nand pacing guidance.\n\n### Step 6: Slop Check\n\nAfter drafting, run:\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix all tier-1 findings before proceeding.\nPay particular attention to:\n\n- Tier-1 vocabulary slop (see `scribe:slop-detector` word lists)\n- Tricolon adjective clusters (\"fast, efficient, and reliable\")\n- Participial tail-loading (sentences ending with \", enabling ...\")\n\n### Step 7: Quality Gate\n\nVerify the completed tutorial against this checklist:\n\nContent:\n- [ ] All code blocks tested and produce the stated output\n- [ ] Prerequisites section lists exact versions where relevant\n- [ ] Every step states the expected result\n- [ ] Troubleshooting section covers at least two common failure modes\n\nSentence-level:\n- [ ] No tier-1 slop words\n- [ ] Em dash count is under 2 per 1000 words\n- [ ] Bullet ratio is under 40%\n- [ ] Line length wraps at 80 characters\n\nDocument-level (document-economy module):\n- [ ] Thesis from Step 1 appears in the lead paragraph\n- [ ] Thesis echoed at the close (and ideally mid-tutorial)\n- [ ] No \"in summary\" section that re-lists what just happened\n- [ ] No section opens by restating its heading\n\n## Required TodoWrite Items\n\n1. `tech-tutorial:scope-defined` - Audience, goal, and out-of-scope noted\n2. `tech-tutorial:outline-approved` - Section outline confirmed\n3. `tech-tutorial:code-tested` - All snippets verified against a real env\n4. `tech-tutorial:prose-drafted` - Walkthrough text written\n5. `tech-tutorial:slop-scanned` - Slop detector passed\n6. `tech-tutorial:quality-verified` - Quality gate checklist cleared\n7. `tech-tutorial:user-approved` - Final approval received\n\n## Module Reference\n\n- See `modules/outline-structure.md` for section order and length targets\n- See `modules/code-examples.md` for snippet formatting and annotation rules\n- See `modules/progressive-complexity.md` for pacing and layering guidance\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| scribe:slop-detector | After drafting, before approval |\n| scribe:doc-generator | For companion API reference sections |\n| scribe:style-learner | To match an existing tutorial voice |\n\n## Exit Criteria\n\n- Tutorial outline confirmed before drafting begins\n- All code snippets tested in a real environment\n- Slop score below 1.5 (clean)\n- Quality gate checklist passed\n- User approval received\n\nFile v1.9.17:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-tech-tutorial\",\n  \"version\": \"1.9.17\",\n  \"publishedAt\": 1785390132196\n}\n\nFile v1.9.17:modules/code-examples.md\n\n---\nmodule: code-examples\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 550\n---\n\n# Writing Effective Code Examples\n\nCode examples are the primary content of a technical tutorial.\nWrite and run each snippet before embedding it in the document.\nA tutorial with untested code is broken.\n\n## The Testing Rule\n\nEvery code block that the reader is expected to run must be tested\nin a real environment before publication.\nThis means:\n\n1. Run the command in a clean shell or container\n2. Confirm the output matches what you claim\n3. Record the exact output to quote in the tutorial\n4. Note any version-specific behavior\n\nIf you cannot test a snippet, mark it clearly as untested:\n\n```markdown\n<!-- Note: untested on Windows; verified on macOS 14.3 -->\n```\n\nNever present guessed output as verified.\n\n## Formatting Rules\n\nUse fenced code blocks with a language identifier on every block:\n\n```markdown\n```bash\nnpm install express\n```\n```\n\nCommon language identifiers:\n\n| Content Type | Identifier |\n|--------------|------------|\n| Shell commands | `bash` |\n| Python | `python` |\n| JavaScript/Node | `javascript` |\n| YAML config | `yaml` |\n| JSON output | `json` |\n| Generic output | `text` |\n\nDo not use `sh` as an identifier; use `bash` or `zsh` explicitly.\n\n## Output Blocks\n\nShow expected output after every command that produces visible output.\nUse a `text` block with the label \"Output:\" on its own line:\n\n```markdown\nRun the server:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nServer running on http://localhost:3000\n```\n```\n\nIf output is long, truncate with `...` and show the key lines:\n\n```text\nDownloading packages...\n...\nSuccessfully installed 14 packages in 2.3s\n```\n\n## Annotation Guidelines\n\nAnnotate only the non-obvious parts.\nOver-annotation creates noise that pushes readers past the code.\n\nGood annotation targets:\n\n- A flag or option whose name does not explain itself\n- A value the reader must substitute for their own\n- A syntax form they may not have seen before\n\nMark substitution points with angle brackets:\n\n```bash\ngit remote add origin git@github.com:<your-username>/<repo-name>.git\n```\n\nDo not annotate things that the code makes self-evident.\n\n## Handling Errors in Examples\n\nWhen showing an expected error (to teach debugging), be explicit:\n\n```markdown\nRunning this command before installing dependencies will fail:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nError: Cannot find module 'express'\n```\n\nInstall dependencies first, then retry.\n```\n\nNever silently show error output without explaining it.\n\n## Long Code Example Handling\n\nFor files longer than 30 lines, show only the relevant portion:\n\n```markdown\nIn `config/database.js`, update the connection string (line 12):\n\n```javascript\n// config/database.js (excerpt)\nconst connection = {\n  host: process.env.DB_HOST,\n  port: 5432,\n  database: process.env.DB_NAME,\n};\n```\n```\n\nProvide a link to the full file in a repository if one exists.\n\n## Verify Your Examples Work\n\nBefore including any example, run this checklist:\n\n- [ ] Command produces the stated output\n- [ ] Tested in the same environment as the reader will use\n- [ ] Language identifier is present on the fenced block\n- [ ] Output block follows every command with visible output\n- [ ] Substitution points use angle bracket notation\n- [ ] Untested blocks carry an explicit disclaimer\n\nFile v1.9.17:modules/outline-structure.md\n\n---\nmodule: outline-structure\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 500\n---\n\n# Tutorial Outline and Structure\n\nA tutorial outline is a contract with the reader: it says what they\nwill do and in what order.\nWrite the outline before drafting any prose.\nIf an outline entry is hard to describe in one line, the section\nis too large and needs splitting.\n\n## Standard Section Order\n\nMost technical tutorials follow this sequence:\n\n1. **Title** - What the reader will build or accomplish\n2. **Prerequisites** - What they must have installed or know\n3. **What You Will Build** - One paragraph, concrete outcome\n4. **Setup** - Environment configuration steps\n5. **Core Steps** - The numbered sequence of actions\n6. **Verify It Works** - How to confirm success\n7. **Troubleshooting** - Two to four common failure modes\n8. **Next Steps** - One or two natural follow-on tasks\n\nNot every tutorial needs all eight sections.\nShort tutorials (under 500 words) can omit Next Steps and\nmerge Verify with the final core step.\n\n## Length Targets per Section\n\n| Section | Target Length |\n|---------|---------------|\n| Title | 5-10 words |\n| Prerequisites | 30-60 words |\n| What You Will Build | 50-100 words |\n| Setup | 50-150 words |\n| Each Core Step | 30-80 words |\n| Verify It Works | 30-60 words |\n| Troubleshooting | 50-150 words |\n| Next Steps | 20-40 words |\n\n## Prerequisite Section Rules\n\nState prerequisites as a list of specific, verifiable items.\nVague prerequisites waste the reader's time.\n\n```markdown\nBAD:\n- Basic programming knowledge\n- Familiarity with the command line\n\nGOOD:\n- Python 3.11 or later (`python3 --version`)\n- A GitHub account with SSH access configured\n- `curl` available on your system\n```\n\nEach prerequisite should be verifiable in under 30 seconds.\nIf the reader cannot confirm it with a single command, add\nthe command.\n\n## Core Steps Structure\n\nEach step in the numbered sequence should follow this pattern:\n\n1. One sentence describing what the reader does\n2. The command or code block to run\n3. The expected output or result (required for commands)\n4. One optional sentence explaining why, if non-obvious\n\nKeep explanatory prose after the code, not before it.\nThe reader runs first, then reads why.\n\n## Troubleshooting Section\n\nCover the two to four errors most likely to occur.\nStructure each entry as:\n\n```markdown\n### Error: [exact error message or symptom]\n\n**Cause**: [one sentence]\n\n**Fix**: [one to three steps]\n```\n\nDo not include every possible error.\nFocus on the errors that newcomers hit in the first ten minutes.\n\n## Outline Validation Checklist\n\nBefore drafting:\n\n- [ ] Every section has a one-line description of reader action\n- [ ] Prerequisites are specific and verifiable\n- [ ] Core steps are numbered and ordered\n- [ ] Troubleshooting has at least two entries planned\n- [ ] Total planned length is under 2000 words for a starter guide\n\nFile v1.9.17:modules/progressive-complexity.md\n\n---\nmodule: progressive-complexity\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 480\n---\n\n# Building Complexity Gradually\n\nThe most common tutorial failure is starting too hard.\nThe reader gets lost before the baseline works, gives up, and\nblames the tool.\nStart with the minimum that produces a visible result.\nAdd variation only after that baseline is solid.\n\n## The Minimal Example First\n\nThe first working example should be the shortest possible program\nthat demonstrates the core concept.\nIt need not be production-quality; it must be correct and runnable.\n\n```markdown\nBAD: Start with a full web server including auth, logging,\nand database connections.\n\nGOOD: Start with a server that returns \"Hello, World!\" on port 3000.\n```\n\nThe minimal example answers one question: does this thing work?\nOnce the reader sees it working, they are ready to learn more.\n\n## The Layering Model\n\nIntroduce complexity in layers.\nEach layer adds one new concept or one new component.\nA reader should be able to stop at any layer and have\na working system.\n\nLayer pattern:\n\n1. **Baseline** - The minimal working example\n2. **First extension** - Add one realistic feature\n3. **Second extension** - Add error handling or configuration\n4. **Production pattern** - Show what the real thing looks like\n\nNot every tutorial needs all four layers.\nA focused tutorial may only need baseline plus one extension.\n\n## Pacing Rules\n\n- Complete one layer before describing the next\n- State what you are about to add before adding it\n- Do not introduce two new concepts in a single step\n- Run the code after each layer to show it still works\n\n```markdown\nBAD:\n\"Now we will add authentication, a database connection,\nand rate limiting...\"\n\nGOOD:\n\"The server works. Now add a database connection.\nAuthentication comes in the next section.\"\n```\n\n## When to Introduce Alternatives\n\nIntroduce alternative approaches only after the primary path works.\nThe reader needs one good path before they can evaluate tradeoffs.\n\n```markdown\nBAD: \"You could use Redis or Memcached or an in-memory store here.\"\n\nGOOD: \"We use Redis here. Once this works, see [link] for\nthe Memcached variant.\"\n```\n\n## Complexity Signals to Watch For\n\nSigns that a section has become too complex:\n\n- A step has more than one code block with no \"run this\" between them\n- You are explaining a concept that requires another concept first\n- The expected output section requires more prose than the step itself\n- You find yourself writing \"before we continue, you should know...\"\n\nWhen you see these signals, split the section or move the prerequisite\nknowledge into the Prerequisites section.\n\n## End-State Clarity\n\nThe reader must know what they are building toward before they start.\nState the end state in the \"What You Will Build\" section as a concrete\ndescription, not a list of features:\n\n```markdown\nBAD:\n\"You will learn authentication, sessions, and middleware.\"\n\nGOOD:\n\"By the end of this tutorial, you will have a Node.js server\nthat accepts a username and password, issues a signed JWT,\nand rejects requests without a valid token.\"\n```\n\nThe end state should be verifiable: the reader can check that they\nachieved it by running one command or visiting one URL.\n\nFile v1.9.17:skill-card.md\n\n## Description: <br>\nPlans, drafts, and refines technical tutorials for developers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and technical writers use this skill to plan, draft, and quality-check hands-on tutorials, getting-started guides, CLI walkthroughs, and API learning paths backed by working code. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Generated tutorial commands or code examples could be incorrect, unsafe for the user's environment, or presented with unverified output. <br>\nMitigation: Review generated commands and test code snippets in a real or isolated environment before publishing or running them. <br>\nRisk: The skill text mentions a separate Claude Code plugin that may include agents, hooks, or commands outside this artifact. <br>\nMitigation: Evaluate and install that plugin separately instead of treating this skill card as coverage for the plugin's behavior. <br>\n\n\n## Reference(s): <br>\n- [ClawHub Skill Page](https://clawhub.ai/athola/skills/nm-scribe-tech-tutorial) <br>\n- [Publisher Profile](https://clawhub.ai/user/athola) <br>\n- [Clawdis Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/scribe) <br>\n- [Tutorial Outline and Structure](modules/outline-structure.md) <br>\n- [Writing Effective Code Examples](modules/code-examples.md) <br>\n- [Building Complexity Gradually](modules/progressive-complexity.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration, Guidance] <br>\n**Output Format:** [Markdown tutorial drafts, outlines, code blocks, command examples, checklists, and review guidance] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Generated tutorial commands and code examples should be reviewed and tested before use.] <br>\n\n## Skill Version(s): <br>\n1.9.17 (source: server release metadata; artifact frontmatter says 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.16: 6 files, 9587 bytes\n\nFiles: modules/code-examples.md (3345b), modules/outline-structure.md (2900b), modules/progressive-complexity.md (3224b), skill-card.md (2636b), SKILL.md (6227b), _meta.json (143b)\n\nFile v1.9.16:SKILL.md\n\n---\nname: tech-tutorial\ndescription: Plans, drafts, and refines technical tutorials for developers\nversion: 1.9.8\ntriggers:\n  - tutorial\n  - technical-writing\n  - code-examples\n  - developer-docs\n  - getting-started\n  - writing step-by-step guides or getting-started walkthroughs backed by working code\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Tech Tutorial\n\nA good technical tutorial has one goal: move a reader from not knowing\nhow to do something to being able to do it.\nThat requires working code, concrete steps, and honest acknowledgment\nof where things go wrong.\nThis skill guides you through outlining, drafting, and verifying a\ntutorial that meets that standard.\n\n## When To Use\n\n- Writing a getting-started guide for a library, CLI tool, or API\n- Creating a step-by-step walkthrough that readers follow at a terminal\n- Explaining a technical concept through a hands-on exercise\n- Producing a how-to that complements API reference documentation\n\n## When NOT To Use\n\n- Generating API reference docs (use `scribe:doc-generator`)\n- Cleaning up existing prose (use `scribe:slop-detector`)\n- Producing high-level architecture overviews without runnable steps\n- Writing conceptual essays without hands-on components\n\n## Methodology\n\n### Step 1: Scope and Audience\n\nBefore writing a single line, answer these questions:\n\n- Who is this for? (experience level, assumed prior knowledge)\n- How many readers? How often will each one read it?\n- What will they build or accomplish by the end?\n- **What is the one sentence they must walk away with?**\n  (the thesis — not the topic)\n- What is the single prerequisite the reader must have installed?\n- What is explicitly out of scope?\n\nWrite these answers down as a header block in the draft.\nIf you cannot answer the \"what will they accomplish\" question\nin one sentence, the scope is too broad. If you cannot state\nthe thesis in one sentence, the tutorial is not ready to draft.\n\nThe audience size and read frequency feed the reader-time\nbudget (see `scribe:slop-detector` module `document-economy.md`).\nA tutorial that 500 developers will read once is a 40-hour\nreader-budget asset; spend the writing time accordingly.\n\n### Step 2: Outline\n\nLoad: `@modules/outline-structure.md`\n\nProduce a section-by-section outline before drafting prose.\nEach section entry must include a one-line description of what\nthe reader does or learns in that section.\nSee the outline module for the standard section order and\nlength targets per section type.\n\n### Step 3: Draft Code Examples First\n\nLoad: `@modules/code-examples.md`\n\nWrite the code before the prose.\nEach snippet must run against a real environment before it\nappears in the tutorial.\nAnnotate only the non-obvious lines.\nSee the code examples module for formatting and error-handling rules.\n\n### Step 4: Draft Prose Around the Code\n\nProse exists to explain what the code does and why.\nFollow these rules:\n\n- One paragraph per step: what to run, what it does, what to expect\n- State the expected output after each command block\n- Use second person (\"you\") consistently throughout\n- Do not narrate what the reader will do next; just present the next step\n\n### Step 5: Build Complexity Gradually\n\nLoad: `@modules/progressive-complexity.md`\n\nStart with the minimal working example.\nIntroduce variations and edge cases only after the baseline works.\nSee the progressive complexity module for the layering rules\nand pacing guidance.\n\n### Step 6: Slop Check\n\nAfter drafting, run:\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix all tier-1 findings before proceeding.\nPay particular attention to:\n\n- Tier-1 vocabulary slop (see `scribe:slop-detector` word lists)\n- Tricolon adjective clusters (\"fast, efficient, and reliable\")\n- Participial tail-loading (sentences ending with \", enabling ...\")\n\n### Step 7: Quality Gate\n\nVerify the completed tutorial against this checklist:\n\nContent:\n- [ ] All code blocks tested and produce the stated output\n- [ ] Prerequisites section lists exact versions where relevant\n- [ ] Every step states the expected result\n- [ ] Troubleshooting section covers at least two common failure modes\n\nSentence-level:\n- [ ] No tier-1 slop words\n- [ ] Em dash count is under 2 per 1000 words\n- [ ] Bullet ratio is under 40%\n- [ ] Line length wraps at 80 characters\n\nDocument-level (document-economy module):\n- [ ] Thesis from Step 1 appears in the lead paragraph\n- [ ] Thesis echoed at the close (and ideally mid-tutorial)\n- [ ] No \"in summary\" section that re-lists what just happened\n- [ ] No section opens by restating its heading\n\n## Required TodoWrite Items\n\n1. `tech-tutorial:scope-defined` - Audience, goal, and out-of-scope noted\n2. `tech-tutorial:outline-approved` - Section outline confirmed\n3. `tech-tutorial:code-tested` - All snippets verified against a real env\n4. `tech-tutorial:prose-drafted` - Walkthrough text written\n5. `tech-tutorial:slop-scanned` - Slop detector passed\n6. `tech-tutorial:quality-verified` - Quality gate checklist cleared\n7. `tech-tutorial:user-approved` - Final approval received\n\n## Module Reference\n\n- See `modules/outline-structure.md` for section order and length targets\n- See `modules/code-examples.md` for snippet formatting and annotation rules\n- See `modules/progressive-complexity.md` for pacing and layering guidance\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| scribe:slop-detector | After drafting, before approval |\n| scribe:doc-generator | For companion API reference sections |\n| scribe:style-learner | To match an existing tutorial voice |\n\n## Exit Criteria\n\n- Tutorial outline confirmed before drafting begins\n- All code snippets tested in a real environment\n- Slop score below 1.5 (clean)\n- Quality gate checklist passed\n- User approval received\n\nFile v1.9.16:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-tech-tutorial\",\n  \"version\": \"1.9.16\",\n  \"publishedAt\": 1784059141551\n}\n\nFile v1.9.16:modules/code-examples.md\n\n---\nmodule: code-examples\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 550\n---\n\n# Writing Effective Code Examples\n\nCode examples are the primary content of a technical tutorial.\nWrite and run each snippet before embedding it in the document.\nA tutorial with untested code is broken.\n\n## The Testing Rule\n\nEvery code block that the reader is expected to run must be tested\nin a real environment before publication.\nThis means:\n\n1. Run the command in a clean shell or container\n2. Confirm the output matches what you claim\n3. Record the exact output to quote in the tutorial\n4. Note any version-specific behavior\n\nIf you cannot test a snippet, mark it clearly as untested:\n\n```markdown\n<!-- Note: untested on Windows; verified on macOS 14.3 -->\n```\n\nNever present guessed output as verified.\n\n## Formatting Rules\n\nUse fenced code blocks with a language identifier on every block:\n\n```markdown\n```bash\nnpm install express\n```\n```\n\nCommon language identifiers:\n\n| Content Type | Identifier |\n|--------------|------------|\n| Shell commands | `bash` |\n| Python | `python` |\n| JavaScript/Node | `javascript` |\n| YAML config | `yaml` |\n| JSON output | `json` |\n| Generic output | `text` |\n\nDo not use `sh` as an identifier; use `bash` or `zsh` explicitly.\n\n## Output Blocks\n\nShow expected output after every command that produces visible output.\nUse a `text` block with the label \"Output:\" on its own line:\n\n```markdown\nRun the server:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nServer running on http://localhost:3000\n```\n```\n\nIf output is long, truncate with `...` and show the key lines:\n\n```text\nDownloading packages...\n...\nSuccessfully installed 14 packages in 2.3s\n```\n\n## Annotation Guidelines\n\nAnnotate only the non-obvious parts.\nOver-annotation creates noise that pushes readers past the code.\n\nGood annotation targets:\n\n- A flag or option whose name does not explain itself\n- A value the reader must substitute for their own\n- A syntax form they may not have seen before\n\nMark substitution points with angle brackets:\n\n```bash\ngit remote add origin git@github.com:<your-username>/<repo-name>.git\n```\n\nDo not annotate things that the code makes self-evident.\n\n## Handling Errors in Examples\n\nWhen showing an expected error (to teach debugging), be explicit:\n\n```markdown\nRunning this command before installing dependencies will fail:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nError: Cannot find module 'express'\n```\n\nInstall dependencies first, then retry.\n```\n\nNever silently show error output without explaining it.\n\n## Long Code Example Handling\n\nFor files longer than 30 lines, show only the relevant portion:\n\n```markdown\nIn `config/database.js`, update the connection string (line 12):\n\n```javascript\n// config/database.js (excerpt)\nconst connection = {\n  host: process.env.DB_HOST,\n  port: 5432,\n  database: process.env.DB_NAME,\n};\n```\n```\n\nProvide a link to the full file in a repository if one exists.\n\n## Verify Your Examples Work\n\nBefore including any example, run this checklist:\n\n- [ ] Command produces the stated output\n- [ ] Tested in the same environment as the reader will use\n- [ ] Language identifier is present on the fenced block\n- [ ] Output block follows every command with visible output\n- [ ] Substitution points use angle bracket notation\n- [ ] Untested blocks carry an explicit disclaimer\n\nFile v1.9.16:modules/outline-structure.md\n\n---\nmodule: outline-structure\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 500\n---\n\n# Tutorial Outline and Structure\n\nA tutorial outline is a contract with the reader: it says what they\nwill do and in what order.\nWrite the outline before drafting any prose.\nIf an outline entry is hard to describe in one line, the section\nis too large and needs splitting.\n\n## Standard Section Order\n\nMost technical tutorials follow this sequence:\n\n1. **Title** - What the reader will build or accomplish\n2. **Prerequisites** - What they must have installed or know\n3. **What You Will Build** - One paragraph, concrete outcome\n4. **Setup** - Environment configuration steps\n5. **Core Steps** - The numbered sequence of actions\n6. **Verify It Works** - How to confirm success\n7. **Troubleshooting** - Two to four common failure modes\n8. **Next Steps** - One or two natural follow-on tasks\n\nNot every tutorial needs all eight sections.\nShort tutorials (under 500 words) can omit Next Steps and\nmerge Verify with the final core step.\n\n## Length Targets per Section\n\n| Section | Target Length |\n|---------|---------------|\n| Title | 5-10 words |\n| Prerequisites | 30-60 words |\n| What You Will Build | 50-100 words |\n| Setup | 50-150 words |\n| Each Core Step | 30-80 words |\n| Verify It Works | 30-60 words |\n| Troubleshooting | 50-150 words |\n| Next Steps | 20-40 words |\n\n## Prerequisite Section Rules\n\nState prerequisites as a list of specific, verifiable items.\nVague prerequisites waste the reader's time.\n\n```markdown\nBAD:\n- Basic programming knowledge\n- Familiarity with the command line\n\nGOOD:\n- Python 3.11 or later (`python3 --version`)\n- A GitHub account with SSH access configured\n- `curl` available on your system\n```\n\nEach prerequisite should be verifiable in under 30 seconds.\nIf the reader cannot confirm it with a single command, add\nthe command.\n\n## Core Steps Structure\n\nEach step in the numbered sequence should follow this pattern:\n\n1. One sentence describing what the reader does\n2. The command or code block to run\n3. The expected output or result (required for commands)\n4. One optional sentence explaining why, if non-obvious\n\nKeep explanatory prose after the code, not before it.\nThe reader runs first, then reads why.\n\n## Troubleshooting Section\n\nCover the two to four errors most likely to occur.\nStructure each entry as:\n\n```markdown\n### Error: [exact error message or symptom]\n\n**Cause**: [one sentence]\n\n**Fix**: [one to three steps]\n```\n\nDo not include every possible error.\nFocus on the errors that newcomers hit in the first ten minutes.\n\n## Outline Validation Checklist\n\nBefore drafting:\n\n- [ ] Every section has a one-line description of reader action\n- [ ] Prerequisites are specific and verifiable\n- [ ] Core steps are numbered and ordered\n- [ ] Troubleshooting has at least two entries planned\n- [ ] Total planned length is under 2000 words for a starter guide\n\nFile v1.9.16:modules/progressive-complexity.md\n\n---\nmodule: progressive-complexity\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 480\n---\n\n# Building Complexity Gradually\n\nThe most common tutorial failure is starting too hard.\nThe reader gets lost before the baseline works, gives up, and\nblames the tool.\nStart with the minimum that produces a visible result.\nAdd variation only after that baseline is solid.\n\n## The Minimal Example First\n\nThe first working example should be the shortest possible program\nthat demonstrates the core concept.\nIt need not be production-quality; it must be correct and runnable.\n\n```markdown\nBAD: Start with a full web server including auth, logging,\nand database connections.\n\nGOOD: Start with a server that returns \"Hello, World!\" on port 3000.\n```\n\nThe minimal example answers one question: does this thing work?\nOnce the reader sees it working, they are ready to learn more.\n\n## The Layering Model\n\nIntroduce complexity in layers.\nEach layer adds one new concept or one new component.\nA reader should be able to stop at any layer and have\na working system.\n\nLayer pattern:\n\n1. **Baseline** - The minimal working example\n2. **First extension** - Add one realistic feature\n3. **Second extension** - Add error handling or configuration\n4. **Production pattern** - Show what the real thing looks like\n\nNot every tutorial needs all four layers.\nA focused tutorial may only need baseline plus one extension.\n\n## Pacing Rules\n\n- Complete one layer before describing the next\n- State what you are about to add before adding it\n- Do not introduce two new concepts in a single step\n- Run the code after each layer to show it still works\n\n```markdown\nBAD:\n\"Now we will add authentication, a database connection,\nand rate limiting...\"\n\nGOOD:\n\"The server works. Now add a database connection.\nAuthentication comes in the next section.\"\n```\n\n## When to Introduce Alternatives\n\nIntroduce alternative approaches only after the primary path works.\nThe reader needs one good path before they can evaluate tradeoffs.\n\n```markdown\nBAD: \"You could use Redis or Memcached or an in-memory store here.\"\n\nGOOD: \"We use Redis here. Once this works, see [link] for\nthe Memcached variant.\"\n```\n\n## Complexity Signals to Watch For\n\nSigns that a section has become too complex:\n\n- A step has more than one code block with no \"run this\" between them\n- You are explaining a concept that requires another concept first\n- The expected output section requires more prose than the step itself\n- You find yourself writing \"before we continue, you should know...\"\n\nWhen you see these signals, split the section or move the prerequisite\nknowledge into the Prerequisites section.\n\n## End-State Clarity\n\nThe reader must know what they are building toward before they start.\nState the end state in the \"What You Will Build\" section as a concrete\ndescription, not a list of features:\n\n```markdown\nBAD:\n\"You will learn authentication, sessions, and middleware.\"\n\nGOOD:\n\"By the end of this tutorial, you will have a Node.js server\nthat accepts a username and password, issues a signed JWT,\nand rejects requests without a valid token.\"\n```\n\nThe end state should be verifiable: the reader can check that they\nachieved it by running one command or visiting one URL.\n\nFile v1.9.16:skill-card.md\n\n## Description: <br>\nPlans, drafts, and refines technical tutorials for developers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and technical writers use this skill to plan, draft, and verify hands-on tutorials for libraries, CLI tools, APIs, and developer workflows. It emphasizes scoped outcomes, tested code examples, progressive complexity, expected outputs, troubleshooting, and quality checks. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Generated tutorials may include code or shell commands that are unsuitable for the user's environment. <br>\nMitigation: Review generated commands and test runnable examples in an environment where execution is acceptable before publishing or sharing the tutorial. <br>\nRisk: The skill can activate on broad documentation requests even when a hands-on tutorial is not the right format. <br>\nMitigation: Confirm the intended output is a step-by-step technical tutorial before applying the workflow. <br>\nRisk: The artifact expects a companion slop-detector review for its quality gate. <br>\nMitigation: Run the referenced companion review when available, or apply an equivalent prose-quality review before final approval. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-scribe-tech-tutorial) <br>\n- [Project homepage from skill metadata](https://github.com/athola/claude-night-market/tree/master/plugins/scribe) <br>\n- [Tutorial outline and structure module](artifact/modules/outline-structure.md) <br>\n- [Code examples module](artifact/modules/code-examples.md) <br>\n- [Progressive complexity module](artifact/modules/progressive-complexity.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Markdown, Code, Shell commands, Guidance] <br>\n**Output Format:** [Markdown with fenced code blocks, expected output blocks, checklists, and troubleshooting sections] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May include tutorial outlines, tested code snippets, TODO items, quality gates, and review guidance.] <br>\n\n## Skill Version(s): <br>\n1.9.16 (source: ClawHub release evidence; artifact frontmatter reports 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.14: 6 files, 9489 bytes\n\nFiles: modules/code-examples.md (3345b), modules/outline-structure.md (2900b), modules/progressive-complexity.md (3224b), skill-card.md (2294b), SKILL.md (6227b), _meta.json (143b)\n\nFile v1.9.14:SKILL.md\n\n---\nname: tech-tutorial\ndescription: Plans, drafts, and refines technical tutorials for developers\nversion: 1.9.8\ntriggers:\n  - tutorial\n  - technical-writing\n  - code-examples\n  - developer-docs\n  - getting-started\n  - writing step-by-step guides or getting-started walkthroughs backed by working code\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Tech Tutorial\n\nA good technical tutorial has one goal: move a reader from not knowing\nhow to do something to being able to do it.\nThat requires working code, concrete steps, and honest acknowledgment\nof where things go wrong.\nThis skill guides you through outlining, drafting, and verifying a\ntutorial that meets that standard.\n\n## When To Use\n\n- Writing a getting-started guide for a library, CLI tool, or API\n- Creating a step-by-step walkthrough that readers follow at a terminal\n- Explaining a technical concept through a hands-on exercise\n- Producing a how-to that complements API reference documentation\n\n## When NOT To Use\n\n- Generating API reference docs (use `scribe:doc-generator`)\n- Cleaning up existing prose (use `scribe:slop-detector`)\n- Producing high-level architecture overviews without runnable steps\n- Writing conceptual essays without hands-on components\n\n## Methodology\n\n### Step 1: Scope and Audience\n\nBefore writing a single line, answer these questions:\n\n- Who is this for? (experience level, assumed prior knowledge)\n- How many readers? How often will each one read it?\n- What will they build or accomplish by the end?\n- **What is the one sentence they must walk away with?**\n  (the thesis — not the topic)\n- What is the single prerequisite the reader must have installed?\n- What is explicitly out of scope?\n\nWrite these answers down as a header block in the draft.\nIf you cannot answer the \"what will they accomplish\" question\nin one sentence, the scope is too broad. If you cannot state\nthe thesis in one sentence, the tutorial is not ready to draft.\n\nThe audience size and read frequency feed the reader-time\nbudget (see `scribe:slop-detector` module `document-economy.md`).\nA tutorial that 500 developers will read once is a 40-hour\nreader-budget asset; spend the writing time accordingly.\n\n### Step 2: Outline\n\nLoad: `@modules/outline-structure.md`\n\nProduce a section-by-section outline before drafting prose.\nEach section entry must include a one-line description of what\nthe reader does or learns in that section.\nSee the outline module for the standard section order and\nlength targets per section type.\n\n### Step 3: Draft Code Examples First\n\nLoad: `@modules/code-examples.md`\n\nWrite the code before the prose.\nEach snippet must run against a real environment before it\nappears in the tutorial.\nAnnotate only the non-obvious lines.\nSee the code examples module for formatting and error-handling rules.\n\n### Step 4: Draft Prose Around the Code\n\nProse exists to explain what the code does and why.\nFollow these rules:\n\n- One paragraph per step: what to run, what it does, what to expect\n- State the expected output after each command block\n- Use second person (\"you\") consistently throughout\n- Do not narrate what the reader will do next; just present the next step\n\n### Step 5: Build Complexity Gradually\n\nLoad: `@modules/progressive-complexity.md`\n\nStart with the minimal working example.\nIntroduce variations and edge cases only after the baseline works.\nSee the progressive complexity module for the layering rules\nand pacing guidance.\n\n### Step 6: Slop Check\n\nAfter drafting, run:\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix all tier-1 findings before proceeding.\nPay particular attention to:\n\n- Tier-1 vocabulary slop (see `scribe:slop-detector` word lists)\n- Tricolon adjective clusters (\"fast, efficient, and reliable\")\n- Participial tail-loading (sentences ending with \", enabling ...\")\n\n### Step 7: Quality Gate\n\nVerify the completed tutorial against this checklist:\n\nContent:\n- [ ] All code blocks tested and produce the stated output\n- [ ] Prerequisites section lists exact versions where relevant\n- [ ] Every step states the expected result\n- [ ] Troubleshooting section covers at least two common failure modes\n\nSentence-level:\n- [ ] No tier-1 slop words\n- [ ] Em dash count is under 2 per 1000 words\n- [ ] Bullet ratio is under 40%\n- [ ] Line length wraps at 80 characters\n\nDocument-level (document-economy module):\n- [ ] Thesis from Step 1 appears in the lead paragraph\n- [ ] Thesis echoed at the close (and ideally mid-tutorial)\n- [ ] No \"in summary\" section that re-lists what just happened\n- [ ] No section opens by restating its heading\n\n## Required TodoWrite Items\n\n1. `tech-tutorial:scope-defined` - Audience, goal, and out-of-scope noted\n2. `tech-tutorial:outline-approved` - Section outline confirmed\n3. `tech-tutorial:code-tested` - All snippets verified against a real env\n4. `tech-tutorial:prose-drafted` - Walkthrough text written\n5. `tech-tutorial:slop-scanned` - Slop detector passed\n6. `tech-tutorial:quality-verified` - Quality gate checklist cleared\n7. `tech-tutorial:user-approved` - Final approval received\n\n## Module Reference\n\n- See `modules/outline-structure.md` for section order and length targets\n- See `modules/code-examples.md` for snippet formatting and annotation rules\n- See `modules/progressive-complexity.md` for pacing and layering guidance\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| scribe:slop-detector | After drafting, before approval |\n| scribe:doc-generator | For companion API reference sections |\n| scribe:style-learner | To match an existing tutorial voice |\n\n## Exit Criteria\n\n- Tutorial outline confirmed before drafting begins\n- All code snippets tested in a real environment\n- Slop score below 1.5 (clean)\n- Quality gate checklist passed\n- User approval received\n\nFile v1.9.14:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-tech-tutorial\",\n  \"version\": \"1.9.14\",\n  \"publishedAt\": 1782842797146\n}\n\nFile v1.9.14:modules/code-examples.md\n\n---\nmodule: code-examples\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 550\n---\n\n# Writing Effective Code Examples\n\nCode examples are the primary content of a technical tutorial.\nWrite and run each snippet before embedding it in the document.\nA tutorial with untested code is broken.\n\n## The Testing Rule\n\nEvery code block that the reader is expected to run must be tested\nin a real environment before publication.\nThis means:\n\n1. Run the command in a clean shell or container\n2. Confirm the output matches what you claim\n3. Record the exact output to quote in the tutorial\n4. Note any version-specific behavior\n\nIf you cannot test a snippet, mark it clearly as untested:\n\n```markdown\n<!-- Note: untested on Windows; verified on macOS 14.3 -->\n```\n\nNever present guessed output as verified.\n\n## Formatting Rules\n\nUse fenced code blocks with a language identifier on every block:\n\n```markdown\n```bash\nnpm install express\n```\n```\n\nCommon language identifiers:\n\n| Content Type | Identifier |\n|--------------|------------|\n| Shell commands | `bash` |\n| Python | `python` |\n| JavaScript/Node | `javascript` |\n| YAML config | `yaml` |\n| JSON output | `json` |\n| Generic output | `text` |\n\nDo not use `sh` as an identifier; use `bash` or `zsh` explicitly.\n\n## Output Blocks\n\nShow expected output after every command that produces visible output.\nUse a `text` block with the label \"Output:\" on its own line:\n\n```markdown\nRun the server:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nServer running on http://localhost:3000\n```\n```\n\nIf output is long, truncate with `...` and show the key lines:\n\n```text\nDownloading packages...\n...\nSuccessfully installed 14 packages in 2.3s\n```\n\n## Annotation Guidelines\n\nAnnotate only the non-obvious parts.\nOver-annotation creates noise that pushes readers past the code.\n\nGood annotation targets:\n\n- A flag or option whose name does not explain itself\n- A value the reader must substitute for their own\n- A syntax form they may not have seen before\n\nMark substitution points with angle brackets:\n\n```bash\ngit remote add origin git@github.com:<your-username>/<repo-name>.git\n```\n\nDo not annotate things that the code makes self-evident.\n\n## Handling Errors in Examples\n\nWhen showing an expected error (to teach debugging), be explicit:\n\n```markdown\nRunning this command before installing dependencies will fail:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nError: Cannot find module 'express'\n```\n\nInstall dependencies first, then retry.\n```\n\nNever silently show error output without explaining it.\n\n## Long Code Example Handling\n\nFor files longer than 30 lines, show only the relevant portion:\n\n```markdown\nIn `config/database.js`, update the connection string (line 12):\n\n```javascript\n// config/database.js (excerpt)\nconst connection = {\n  host: process.env.DB_HOST,\n  port: 5432,\n  database: process.env.DB_NAME,\n};\n```\n```\n\nProvide a link to the full file in a repository if one exists.\n\n## Verify Your Examples Work\n\nBefore including any example, run this checklist:\n\n- [ ] Command produces the stated output\n- [ ] Tested in the same environment as the reader will use\n- [ ] Language identifier is present on the fenced block\n- [ ] Output block follows every command with visible output\n- [ ] Substitution points use angle bracket notation\n- [ ] Untested blocks carry an explicit disclaimer\n\nFile v1.9.14:modules/outline-structure.md\n\n---\nmodule: outline-structure\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 500\n---\n\n# Tutorial Outline and Structure\n\nA tutorial outline is a contract with the reader: it says what they\nwill do and in what order.\nWrite the outline before drafting any prose.\nIf an outline entry is hard to describe in one line, the section\nis too large and needs splitting.\n\n## Standard Section Order\n\nMost technical tutorials follow this sequence:\n\n1. **Title** - What the reader will build or accomplish\n2. **Prerequisites** - What they must have installed or know\n3. **What You Will Build** - One paragraph, concrete outcome\n4. **Setup** - Environment configuration steps\n5. **Core Steps** - The numbered sequence of actions\n6. **Verify It Works** - How to confirm success\n7. **Troubleshooting** - Two to four common failure modes\n8. **Next Steps** - One or two natural follow-on tasks\n\nNot every tutorial needs all eight sections.\nShort tutorials (under 500 words) can omit Next Steps and\nmerge Verify with the final core step.\n\n## Length Targets per Section\n\n| Section | Target Length |\n|---------|---------------|\n| Title | 5-10 words |\n| Prerequisites | 30-60 words |\n| What You Will Build | 50-100 words |\n| Setup | 50-150 words |\n| Each Core Step | 30-80 words |\n| Verify It Works | 30-60 words |\n| Troubleshooting | 50-150 words |\n| Next Steps | 20-40 words |\n\n## Prerequisite Section Rules\n\nState prerequisites as a list of specific, verifiable items.\nVague prerequisites waste the reader's time.\n\n```markdown\nBAD:\n- Basic programming knowledge\n- Familiarity with the command line\n\nGOOD:\n- Python 3.11 or later (`python3 --version`)\n- A GitHub account with SSH access configured\n- `curl` available on your system\n```\n\nEach prerequisite should be verifiable in under 30 seconds.\nIf the reader cannot confirm it with a single command, add\nthe command.\n\n## Core Steps Structure\n\nEach step in the numbered sequence should follow this pattern:\n\n1. One sentence describing what the reader does\n2. The command or code block to run\n3. The expected output or result (required for commands)\n4. One optional sentence explaining why, if non-obvious\n\nKeep explanatory prose after the code, not before it.\nThe reader runs first, then reads why.\n\n## Troubleshooting Section\n\nCover the two to four errors most likely to occur.\nStructure each entry as:\n\n```markdown\n### Error: [exact error message or symptom]\n\n**Cause**: [one sentence]\n\n**Fix**: [one to three steps]\n```\n\nDo not include every possible error.\nFocus on the errors that newcomers hit in the first ten minutes.\n\n## Outline Validation Checklist\n\nBefore drafting:\n\n- [ ] Every section has a one-line description of reader action\n- [ ] Prerequisites are specific and verifiable\n- [ ] Core steps are numbered and ordered\n- [ ] Troubleshooting has at least two entries planned\n- [ ] Total planned length is under 2000 words for a starter guide\n\nFile v1.9.14:modules/progressive-complexity.md\n\n---\nmodule: progressive-complexity\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 480\n---\n\n# Building Complexity Gradually\n\nThe most common tutorial failure is starting too hard.\nThe reader gets lost before the baseline works, gives up, and\nblames the tool.\nStart with the minimum that produces a visible result.\nAdd variation only after that baseline is solid.\n\n## The Minimal Example First\n\nThe first working example should be the shortest possible program\nthat demonstrates the core concept.\nIt need not be production-quality; it must be correct and runnable.\n\n```markdown\nBAD: Start with a full web server including auth, logging,\nand database connections.\n\nGOOD: Start with a server that returns \"Hello, World!\" on port 3000.\n```\n\nThe minimal example answers one question: does this thing work?\nOnce the reader sees it working, they are ready to learn more.\n\n## The Layering Model\n\nIntroduce complexity in layers.\nEach layer adds one new concept or one new component.\nA reader should be able to stop at any layer and have\na working system.\n\nLayer pattern:\n\n1. **Baseline** - The minimal working example\n2. **First extension** - Add one realistic feature\n3. **Second extension** - Add error handling or configuration\n4. **Production pattern** - Show what the real thing looks like\n\nNot every tutorial needs all four layers.\nA focused tutorial may only need baseline plus one extension.\n\n## Pacing Rules\n\n- Complete one layer before describing the next\n- State what you are about to add before adding it\n- Do not introduce two new concepts in a single step\n- Run the code after each layer to show it still works\n\n```markdown\nBAD:\n\"Now we will add authentication, a database connection,\nand rate limiting...\"\n\nGOOD:\n\"The server works. Now add a database connection.\nAuthentication comes in the next section.\"\n```\n\n## When to Introduce Alternatives\n\nIntroduce alternative approaches only after the primary path works.\nThe reader needs one good path before they can evaluate tradeoffs.\n\n```markdown\nBAD: \"You could use Redis or Memcached or an in-memory store here.\"\n\nGOOD: \"We use Redis here. Once this works, see [link] for\nthe Memcached variant.\"\n```\n\n## Complexity Signals to Watch For\n\nSigns that a section has become too complex:\n\n- A step has more than one code block with no \"run this\" between them\n- You are explaining a concept that requires another concept first\n- The expected output section requires more prose than the step itself\n- You find yourself writing \"before we continue, you should know...\"\n\nWhen you see these signals, split the section or move the prerequisite\nknowledge into the Prerequisites section.\n\n## End-State Clarity\n\nThe reader must know what they are building toward before they start.\nState the end state in the \"What You Will Build\" section as a concrete\ndescription, not a list of features:\n\n```markdown\nBAD:\n\"You will learn authentication, sessions, and middleware.\"\n\nGOOD:\n\"By the end of this tutorial, you will have a Node.js server\nthat accepts a username and password, issues a signed JWT,\nand rejects requests without a valid token.\"\n```\n\nThe end state should be verifiable: the reader can check that they\nachieved it by running one command or visiting one URL.\n\nFile v1.9.14:skill-card.md\n\n## Description: <br>\nPlans, drafts, and refines technical tutorials for developers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and technical writers use this skill to plan, draft, and refine getting-started guides, terminal walkthroughs, API tutorials, and other hands-on developer documentation backed by working code. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Generated tutorial commands or package-install steps could be incorrect or unsuitable for the user's environment. <br>\nMitigation: Review proposed commands before execution and test runnable snippets in a clean shell or container before publishing them. <br>\nRisk: Tutorials can mislead readers if expected outputs or prerequisites are guessed instead of verified. <br>\nMitigation: Use the skill's quality gate to verify code blocks, exact outputs, prerequisites, and common troubleshooting paths before relying on the tutorial. <br>\n\n\n## Reference(s): <br>\n- [ClawHub Skill Page](https://clawhub.ai/athola/skills/nm-scribe-tech-tutorial) <br>\n- [OpenClaw Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/scribe) <br>\n- [Writing Effective Code Examples](modules/code-examples.md) <br>\n- [Tutorial Outline and Structure](modules/outline-structure.md) <br>\n- [Building Complexity Gradually](modules/progressive-complexity.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, code, shell commands, guidance] <br>\n**Output Format:** [Markdown guidance with tutorial outlines, prose, code blocks, command examples, and verification checklists] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May propose commands or code snippets that should be reviewed and tested before publication.] <br>\n\n## Skill Version(s): <br>\n1.9.14 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.13: 6 files, 9512 bytes\n\nFiles: modules/code-examples.md (3345b), modules/outline-structure.md (2900b), modules/progressive-complexity.md (3224b), skill-card.md (2436b), SKILL.md (6227b), _meta.json (143b)\n\nFile v1.9.13:SKILL.md\n\n---\nname: tech-tutorial\ndescription: Plans, drafts, and refines technical tutorials for developers\nversion: 1.9.8\ntriggers:\n  - tutorial\n  - technical-writing\n  - code-examples\n  - developer-docs\n  - getting-started\n  - writing step-by-step guides or getting-started walkthroughs backed by working code\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Tech Tutorial\n\nA good technical tutorial has one goal: move a reader from not knowing\nhow to do something to being able to do it.\nThat requires working code, concrete steps, and honest acknowledgment\nof where things go wrong.\nThis skill guides you through outlining, drafting, and verifying a\ntutorial that meets that standard.\n\n## When To Use\n\n- Writing a getting-started guide for a library, CLI tool, or API\n- Creating a step-by-step walkthrough that readers follow at a terminal\n- Explaining a technical concept through a hands-on exercise\n- Producing a how-to that complements API reference documentation\n\n## When NOT To Use\n\n- Generating API reference docs (use `scribe:doc-generator`)\n- Cleaning up existing prose (use `scribe:slop-detector`)\n- Producing high-level architecture overviews without runnable steps\n- Writing conceptual essays without hands-on components\n\n## Methodology\n\n### Step 1: Scope and Audience\n\nBefore writing a single line, answer these questions:\n\n- Who is this for? (experience level, assumed prior knowledge)\n- How many readers? How often will each one read it?\n- What will they build or accomplish by the end?\n- **What is the one sentence they must walk away with?**\n  (the thesis — not the topic)\n- What is the single prerequisite the reader must have installed?\n- What is explicitly out of scope?\n\nWrite these answers down as a header block in the draft.\nIf you cannot answer the \"what will they accomplish\" question\nin one sentence, the scope is too broad. If you cannot state\nthe thesis in one sentence, the tutorial is not ready to draft.\n\nThe audience size and read frequency feed the reader-time\nbudget (see `scribe:slop-detector` module `document-economy.md`).\nA tutorial that 500 developers will read once is a 40-hour\nreader-budget asset; spend the writing time accordingly.\n\n### Step 2: Outline\n\nLoad: `@modules/outline-structure.md`\n\nProduce a section-by-section outline before drafting prose.\nEach section entry must include a one-line description of what\nthe reader does or learns in that section.\nSee the outline module for the standard section order and\nlength targets per section type.\n\n### Step 3: Draft Code Examples First\n\nLoad: `@modules/code-examples.md`\n\nWrite the code before the prose.\nEach snippet must run against a real environment before it\nappears in the tutorial.\nAnnotate only the non-obvious lines.\nSee the code examples module for formatting and error-handling rules.\n\n### Step 4: Draft Prose Around the Code\n\nProse exists to explain what the code does and why.\nFollow these rules:\n\n- One paragraph per step: what to run, what it does, what to expect\n- State the expected output after each command block\n- Use second person (\"you\") consistently throughout\n- Do not narrate what the reader will do next; just present the next step\n\n### Step 5: Build Complexity Gradually\n\nLoad: `@modules/progressive-complexity.md`\n\nStart with the minimal working example.\nIntroduce variations and edge cases only after the baseline works.\nSee the progressive complexity module for the layering rules\nand pacing guidance.\n\n### Step 6: Slop Check\n\nAfter drafting, run:\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix all tier-1 findings before proceeding.\nPay particular attention to:\n\n- Tier-1 vocabulary slop (see `scribe:slop-detector` word lists)\n- Tricolon adjective clusters (\"fast, efficient, and reliable\")\n- Participial tail-loading (sentences ending with \", enabling ...\")\n\n### Step 7: Quality Gate\n\nVerify the completed tutorial against this checklist:\n\nContent:\n- [ ] All code blocks tested and produce the stated output\n- [ ] Prerequisites section lists exact versions where relevant\n- [ ] Every step states the expected result\n- [ ] Troubleshooting section covers at least two common failure modes\n\nSentence-level:\n- [ ] No tier-1 slop words\n- [ ] Em dash count is under 2 per 1000 words\n- [ ] Bullet ratio is under 40%\n- [ ] Line length wraps at 80 characters\n\nDocument-level (document-economy module):\n- [ ] Thesis from Step 1 appears in the lead paragraph\n- [ ] Thesis echoed at the close (and ideally mid-tutorial)\n- [ ] No \"in summary\" section that re-lists what just happened\n- [ ] No section opens by restating its heading\n\n## Required TodoWrite Items\n\n1. `tech-tutorial:scope-defined` - Audience, goal, and out-of-scope noted\n2. `tech-tutorial:outline-approved` - Section outline confirmed\n3. `tech-tutorial:code-tested` - All snippets verified against a real env\n4. `tech-tutorial:prose-drafted` - Walkthrough text written\n5. `tech-tutorial:slop-scanned` - Slop detector passed\n6. `tech-tutorial:quality-verified` - Quality gate checklist cleared\n7. `tech-tutorial:user-approved` - Final approval received\n\n## Module Reference\n\n- See `modules/outline-structure.md` for section order and length targets\n- See `modules/code-examples.md` for snippet formatting and annotation rules\n- See `modules/progressive-complexity.md` for pacing and layering guidance\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| scribe:slop-detector | After drafting, before approval |\n| scribe:doc-generator | For companion API reference sections |\n| scribe:style-learner | To match an existing tutorial voice |\n\n## Exit Criteria\n\n- Tutorial outline confirmed before drafting begins\n- All code snippets tested in a real environment\n- Slop score below 1.5 (clean)\n- Quality gate checklist passed\n- User approval received\n\nFile v1.9.13:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-tech-tutorial\",\n  \"version\": \"1.9.13\",\n  \"publishedAt\": 1782577460080\n}\n\nFile v1.9.13:modules/code-examples.md\n\n---\nmodule: code-examples\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 550\n---\n\n# Writing Effective Code Examples\n\nCode examples are the primary content of a technical tutorial.\nWrite and run each snippet before embedding it in the document.\nA tutorial with untested code is broken.\n\n## The Testing Rule\n\nEvery code block that the reader is expected to run must be tested\nin a real environment before publication.\nThis means:\n\n1. Run the command in a clean shell or container\n2. Confirm the output matches what you claim\n3. Record the exact output to quote in the tutorial\n4. Note any version-specific behavior\n\nIf you cannot test a snippet, mark it clearly as untested:\n\n```markdown\n<!-- Note: untested on Windows; verified on macOS 14.3 -->\n```\n\nNever present guessed output as verified.\n\n## Formatting Rules\n\nUse fenced code blocks with a language identifier on every block:\n\n```markdown\n```bash\nnpm install express\n```\n```\n\nCommon language identifiers:\n\n| Content Type | Identifier |\n|--------------|------------|\n| Shell commands | `bash` |\n| Python | `python` |\n| JavaScript/Node | `javascript` |\n| YAML config | `yaml` |\n| JSON output | `json` |\n| Generic output | `text` |\n\nDo not use `sh` as an identifier; use `bash` or `zsh` explicitly.\n\n## Output Blocks\n\nShow expected output after every command that produces visible output.\nUse a `text` block with the label \"Output:\" on its own line:\n\n```markdown\nRun the server:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nServer running on http://localhost:3000\n```\n```\n\nIf output is long, truncate with `...` and show the key lines:\n\n```text\nDownloading packages...\n...\nSuccessfully installed 14 packages in 2.3s\n```\n\n## Annotation Guidelines\n\nAnnotate only the non-obvious parts.\nOver-annotation creates noise that pushes readers past the code.\n\nGood annotation targets:\n\n- A flag or option whose name does not explain itself\n- A value the reader must substitute for their own\n- A syntax form they may not have seen before\n\nMark substitution points with angle brackets:\n\n```bash\ngit remote add origin git@github.com:<your-username>/<repo-name>.git\n```\n\nDo not annotate things that the code makes self-evident.\n\n## Handling Errors in Examples\n\nWhen showing an expected error (to teach debugging), be explicit:\n\n```markdown\nRunning this command before installing dependencies will fail:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nError: Cannot find module 'express'\n```\n\nInstall dependencies first, then retry.\n```\n\nNever silently show error output without explaining it.\n\n## Long Code Example Handling\n\nFor files longer than 30 lines, show only the relevant portion:\n\n```markdown\nIn `config/database.js`, update the connection string (line 12):\n\n```javascript\n// config/database.js (excerpt)\nconst connection = {\n  host: process.env.DB_HOST,\n  port: 5432,\n  database: process.env.DB_NAME,\n};\n```\n```\n\nProvide a link to the full file in a repository if one exists.\n\n## Verify Your Examples Work\n\nBefore including any example, run this checklist:\n\n- [ ] Command produces the stated output\n- [ ] Tested in the same environment as the reader will use\n- [ ] Language identifier is present on the fenced block\n- [ ] Output block follows every command with visible output\n- [ ] Substitution points use angle bracket notation\n- [ ] Untested blocks carry an explicit disclaimer\n\nFile v1.9.13:modules/outline-structure.md\n\n---\nmodule: outline-structure\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 500\n---\n\n# Tutorial Outline and Structure\n\nA tutorial outline is a contract with the reader: it says what they\nwill do and in what order.\nWrite the outline before drafting any prose.\nIf an outline entry is hard to describe in one line, the section\nis too large and needs splitting.\n\n## Standard Section Order\n\nMost technical tutorials follow this sequence:\n\n1. **Title** - What the reader will build or accomplish\n2. **Prerequisites** - What they must have installed or know\n3. **What You Will Build** - One paragraph, concrete outcome\n4. **Setup** - Environment configuration steps\n5. **Core Steps** - The numbered sequence of actions\n6. **Verify It Works** - How to confirm success\n7. **Troubleshooting** - Two to four common failure modes\n8. **Next Steps** - One or two natural follow-on tasks\n\nNot every tutorial needs all eight sections.\nShort tutorials (under 500 words) can omit Next Steps and\nmerge Verify with the final core step.\n\n## Length Targets per Section\n\n| Section | Target Length |\n|---------|---------------|\n| Title | 5-10 words |\n| Prerequisites | 30-60 words |\n| What You Will Build | 50-100 words |\n| Setup | 50-150 words |\n| Each Core Step | 30-80 words |\n| Verify It Works | 30-60 words |\n| Troubleshooting | 50-150 words |\n| Next Steps | 20-40 words |\n\n## Prerequisite Section Rules\n\nState prerequisites as a list of specific, verifiable items.\nVague prerequisites waste the reader's time.\n\n```markdown\nBAD:\n- Basic programming knowledge\n- Familiarity with the command line\n\nGOOD:\n- Python 3.11 or later (`python3 --version`)\n- A GitHub account with SSH access configured\n- `curl` available on your system\n```\n\nEach prerequisite should be verifiable in under 30 seconds.\nIf the reader cannot confirm it with a single command, add\nthe command.\n\n## Core Steps Structure\n\nEach step in the numbered sequence should follow this pattern:\n\n1. One sentence describing what the reader does\n2. The command or code block to run\n3. The expected output or result (required for commands)\n4. One optional sentence explaining why, if non-obvious\n\nKeep explanatory prose after the code, not before it.\nThe reader runs first, then reads why.\n\n## Troubleshooting Section\n\nCover the two to four errors most likely to occur.\nStructure each entry as:\n\n```markdown\n### Error: [exact error message or symptom]\n\n**Cause**: [one sentence]\n\n**Fix**: [one to three steps]\n```\n\nDo not include every possible error.\nFocus on the errors that newcomers hit in the first ten minutes.\n\n## Outline Validation Checklist\n\nBefore drafting:\n\n- [ ] Every section has a one-line description of reader action\n- [ ] Prerequisites are specific and verifiable\n- [ ] Core steps are numbered and ordered\n- [ ] Troubleshooting has at least two entries planned\n- [ ] Total planned length is under 2000 words for a starter guide\n\nFile v1.9.13:modules/progressive-complexity.md\n\n---\nmodule: progressive-complexity\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 480\n---\n\n# Building Complexity Gradually\n\nThe most common tutorial failure is starting too hard.\nThe reader gets lost before the baseline works, gives up, and\nblames the tool.\nStart with the minimum that produces a visible result.\nAdd variation only after that baseline is solid.\n\n## The Minimal Example First\n\nThe first working example should be the shortest possible program\nthat demonstrates the core concept.\nIt need not be production-quality; it must be correct and runnable.\n\n```markdown\nBAD: Start with a full web server including auth, logging,\nand database connections.\n\nGOOD: Start with a server that returns \"Hello, World!\" on port 3000.\n```\n\nThe minimal example answers one question: does this thing work?\nOnce the reader sees it working, they are ready to learn more.\n\n## The Layering Model\n\nIntroduce complexity in layers.\nEach layer adds one new concept or one new component.\nA reader should be able to stop at any layer and have\na working system.\n\nLayer pattern:\n\n1. **Baseline** - The minimal working example\n2. **First extension** - Add one realistic feature\n3. **Second extension** - Add error handling or configuration\n4. **Production pattern** - Show what the real thing looks like\n\nNot every tutorial needs all four layers.\nA focused tutorial may only need baseline plus one extension.\n\n## Pacing Rules\n\n- Complete one layer before describing the next\n- State what you are about to add before adding it\n- Do not introduce two new concepts in a single step\n- Run the code after each layer to show it still works\n\n```markdown\nBAD:\n\"Now we will add authentication, a database connection,\nand rate limiting...\"\n\nGOOD:\n\"The server works. Now add a database connection.\nAuthentication comes in the next section.\"\n```\n\n## When to Introduce Alternatives\n\nIntroduce alternative approaches only after the primary path works.\nThe reader needs one good path before they can evaluate tradeoffs.\n\n```markdown\nBAD: \"You could use Redis or Memcached or an in-memory store here.\"\n\nGOOD: \"We use Redis here. Once this works, see [link] for\nthe Memcached variant.\"\n```\n\n## Complexity Signals to Watch For\n\nSigns that a section has become too complex:\n\n- A step has more than one code block with no \"run this\" between them\n- You are explaining a concept that requires another concept first\n- The expected output section requires more prose than the step itself\n- You find yourself writing \"before we continue, you should know...\"\n\nWhen you see these signals, split the section or move the prerequisite\nknowledge into the Prerequisites section.\n\n## End-State Clarity\n\nThe reader must know what they are building toward before they start.\nState the end state in the \"What You Will Build\" section as a concrete\ndescription, not a list of features:\n\n```markdown\nBAD:\n\"You will learn authentication, sessions, and middleware.\"\n\nGOOD:\n\"By the end of this tutorial, you will have a Node.js server\nthat accepts a username and password, issues a signed JWT,\nand rejects requests without a valid token.\"\n```\n\nThe end state should be verifiable: the reader can check that they\nachieved it by running one command or visiting one URL.\n\nFile v1.9.13:skill-card.md\n\n## Description: <br>\nPlans, drafts, and refines technical tutorials for developers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and technical writers use this skill to plan, draft, and refine hands-on tutorials with scoped audiences, runnable examples, expected outputs, troubleshooting coverage, and quality checks. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill can read and edit repository documentation and agent instruction files, which could introduce inaccurate or unwanted guidance in sensitive repositories. <br>\nMitigation: Use a narrow file scope, request report-only review when edits are not desired, and review proposed documentation changes before accepting them. <br>\nRisk: Tutorials produced by the skill may include code examples or shell commands that affect a user's environment. <br>\nMitigation: Require snippets to be tested in a real or isolated environment and verify stated output before publication. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-scribe-tech-tutorial) <br>\n- [Publisher profile](https://clawhub.ai/user/athola) <br>\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/scribe) <br>\n- [Tutorial outline structure module](artifact/modules/outline-structure.md) <br>\n- [Code examples module](artifact/modules/code-examples.md) <br>\n- [Progressive complexity module](artifact/modules/progressive-complexity.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, code, shell commands, guidance] <br>\n**Output Format:** [Markdown guidance with outlines, draft prose, code blocks, command examples, checklists, and review notes.] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May propose edits to repository documentation and agent instruction files when asked.] <br>\n\n## Skill Version(s): <br>\n1.9.13 (source: server release evidence; artifact frontmatter says 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.12: 6 files, 9501 bytes\n\nFiles: modules/code-examples.md (3345b), modules/outline-structure.md (2900b), modules/progressive-complexity.md (3224b), skill-card.md (2255b), SKILL.md (6227b), _meta.json (143b)\n\nFile v1.9.12:SKILL.md\n\n---\nname: tech-tutorial\ndescription: Plans, drafts, and refines technical tutorials for developers\nversion: 1.9.8\ntriggers:\n  - tutorial\n  - technical-writing\n  - code-examples\n  - developer-docs\n  - getting-started\n  - writing step-by-step guides or getting-started walkthroughs backed by working code\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Tech Tutorial\n\nA good technical tutorial has one goal: move a reader from not knowing\nhow to do something to being able to do it.\nThat requires working code, concrete steps, and honest acknowledgment\nof where things go wrong.\nThis skill guides you through outlining, drafting, and verifying a\ntutorial that meets that standard.\n\n## When To Use\n\n- Writing a getting-started guide for a library, CLI tool, or API\n- Creating a step-by-step walkthrough that readers follow at a terminal\n- Explaining a technical concept through a hands-on exercise\n- Producing a how-to that complements API reference documentation\n\n## When NOT To Use\n\n- Generating API reference docs (use `scribe:doc-generator`)\n- Cleaning up existing prose (use `scribe:slop-detector`)\n- Producing high-level architecture overviews without runnable steps\n- Writing conceptual essays without hands-on components\n\n## Methodology\n\n### Step 1: Scope and Audience\n\nBefore writing a single line, answer these questions:\n\n- Who is this for? (experience level, assumed prior knowledge)\n- How many readers? How often will each one read it?\n- What will they build or accomplish by the end?\n- **What is the one sentence they must walk away with?**\n  (the thesis — not the topic)\n- What is the single prerequisite the reader must have installed?\n- What is explicitly out of scope?\n\nWrite these answers down as a header block in the draft.\nIf you cannot answer the \"what will they accomplish\" question\nin one sentence, the scope is too broad. If you cannot state\nthe thesis in one sentence, the tutorial is not ready to draft.\n\nThe audience size and read frequency feed the reader-time\nbudget (see `scribe:slop-detector` module `document-economy.md`).\nA tutorial that 500 developers will read once is a 40-hour\nreader-budget asset; spend the writing time accordingly.\n\n### Step 2: Outline\n\nLoad: `@modules/outline-structure.md`\n\nProduce a section-by-section outline before drafting prose.\nEach section entry must include a one-line description of what\nthe reader does or learns in that section.\nSee the outline module for the standard section order and\nlength targets per section type.\n\n### Step 3: Draft Code Examples First\n\nLoad: `@modules/code-examples.md`\n\nWrite the code before the prose.\nEach snippet must run against a real environment before it\nappears in the tutorial.\nAnnotate only the non-obvious lines.\nSee the code examples module for formatting and error-handling rules.\n\n### Step 4: Draft Prose Around the Code\n\nProse exists to explain what the code does and why.\nFollow these rules:\n\n- One paragraph per step: what to run, what it does, what to expect\n- State the expected output after each command block\n- Use second person (\"you\") consistently throughout\n- Do not narrate what the reader will do next; just present the next step\n\n### Step 5: Build Complexity Gradually\n\nLoad: `@modules/progressive-complexity.md`\n\nStart with the minimal working example.\nIntroduce variations and edge cases only after the baseline works.\nSee the progressive complexity module for the layering rules\nand pacing guidance.\n\n### Step 6: Slop Check\n\nAfter drafting, run:\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix all tier-1 findings before proceeding.\nPay particular attention to:\n\n- Tier-1 vocabulary slop (see `scribe:slop-detector` word lists)\n- Tricolon adjective clusters (\"fast, efficient, and reliable\")\n- Participial tail-loading (sentences ending with \", enabling ...\")\n\n### Step 7: Quality Gate\n\nVerify the completed tutorial against this checklist:\n\nContent:\n- [ ] All code blocks tested and produce the stated output\n- [ ] Prerequisites section lists exact versions where relevant\n- [ ] Every step states the expected result\n- [ ] Troubleshooting section covers at least two common failure modes\n\nSentence-level:\n- [ ] No tier-1 slop words\n- [ ] Em dash count is under 2 per 1000 words\n- [ ] Bullet ratio is under 40%\n- [ ] Line length wraps at 80 characters\n\nDocument-level (document-economy module):\n- [ ] Thesis from Step 1 appears in the lead paragraph\n- [ ] Thesis echoed at the close (and ideally mid-tutorial)\n- [ ] No \"in summary\" section that re-lists what just happened\n- [ ] No section opens by restating its heading\n\n## Required TodoWrite Items\n\n1. `tech-tutorial:scope-defined` - Audience, goal, and out-of-scope noted\n2. `tech-tutorial:outline-approved` - Section outline confirmed\n3. `tech-tutorial:code-tested` - All snippets verified against a real env\n4. `tech-tutorial:prose-drafted` - Walkthrough text written\n5. `tech-tutorial:slop-scanned` - Slop detector passed\n6. `tech-tutorial:quality-verified` - Quality gate checklist cleared\n7. `tech-tutorial:user-approved` - Final approval received\n\n## Module Reference\n\n- See `modules/outline-structure.md` for section order and length targets\n- See `modules/code-examples.md` for snippet formatting and annotation rules\n- See `modules/progressive-complexity.md` for pacing and layering guidance\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| scribe:slop-detector | After drafting, before approval |\n| scribe:doc-generator | For companion API reference sections |\n| scribe:style-learner | To match an existing tutorial voice |\n\n## Exit Criteria\n\n- Tutorial outline confirmed before drafting begins\n- All code snippets tested in a real environment\n- Slop score below 1.5 (clean)\n- Quality gate checklist passed\n- User approval received\n\nFile v1.9.12:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-tech-tutorial\",\n  \"version\": \"1.9.12\",\n  \"publishedAt\": 1781839204059\n}\n\nFile v1.9.12:modules/code-examples.md\n\n---\nmodule: code-examples\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 550\n---\n\n# Writing Effective Code Examples\n\nCode examples are the primary content of a technical tutorial.\nWrite and run each snippet before embedding it in the document.\nA tutorial with untested code is broken.\n\n## The Testing Rule\n\nEvery code block that the reader is expected to run must be tested\nin a real environment before publication.\nThis means:\n\n1. Run the command in a clean shell or container\n2. Confirm the output matches what you claim\n3. Record the exact output to quote in the tutorial\n4. Note any version-specific behavior\n\nIf you cannot test a snippet, mark it clearly as untested:\n\n```markdown\n<!-- Note: untested on Windows; verified on macOS 14.3 -->\n```\n\nNever present guessed output as verified.\n\n## Formatting Rules\n\nUse fenced code blocks with a language identifier on every block:\n\n```markdown\n```bash\nnpm install express\n```\n```\n\nCommon language identifiers:\n\n| Content Type | Identifier |\n|--------------|------------|\n| Shell commands | `bash` |\n| Python | `python` |\n| JavaScript/Node | `javascript` |\n| YAML config | `yaml` |\n| JSON output | `json` |\n| Generic output | `text` |\n\nDo not use `sh` as an identifier; use `bash` or `zsh` explicitly.\n\n## Output Blocks\n\nShow expected output after every command that produces visible output.\nUse a `text` block with the label \"Output:\" on its own line:\n\n```markdown\nRun the server:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nServer running on http://localhost:3000\n```\n```\n\nIf output is long, truncate with `...` and show the key lines:\n\n```text\nDownloading packages...\n...\nSuccessfully installed 14 packages in 2.3s\n```\n\n## Annotation Guidelines\n\nAnnotate only the non-obvious parts.\nOver-annotation creates noise that pushes readers past the code.\n\nGood annotation targets:\n\n- A flag or option whose name does not explain itself\n- A value the reader must substitute for their own\n- A syntax form they may not have seen before\n\nMark substitution points with angle brackets:\n\n```bash\ngit remote add origin git@github.com:<your-username>/<repo-name>.git\n```\n\nDo not annotate things that the code makes self-evident.\n\n## Handling Errors in Examples\n\nWhen showing an expected error (to teach debugging), be explicit:\n\n```markdown\nRunning this command before installing dependencies will fail:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nError: Cannot find module 'express'\n```\n\nInstall dependencies first, then retry.\n```\n\nNever silently show error output without explaining it.\n\n## Long Code Example Handling\n\nFor files longer than 30 lines, show only the relevant portion:\n\n```markdown\nIn `config/database.js`, update the connection string (line 12):\n\n```javascript\n// config/database.js (excerpt)\nconst connection = {\n  host: process.env.DB_HOST,\n  port: 5432,\n  database: process.env.DB_NAME,\n};\n```\n```\n\nProvide a link to the full file in a repository if one exists.\n\n## Verify Your Examples Work\n\nBefore including any example, run this checklist:\n\n- [ ] Command produces the stated output\n- [ ] Tested in the same environment as the reader will use\n- [ ] Language identifier is present on the fenced block\n- [ ] Output block follows every command with visible output\n- [ ] Substitution points use angle bracket notation\n- [ ] Untested blocks carry an explicit disclaimer\n\nFile v1.9.12:modules/outline-structure.md\n\n---\nmodule: outline-structure\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 500\n---\n\n# Tutorial Outline and Structure\n\nA tutorial outline is a contract with the reader: it says what they\nwill do and in what order.\nWrite the outline before drafting any prose.\nIf an outline entry is hard to describe in one line, the section\nis too large and needs splitting.\n\n## Standard Section Order\n\nMost technical tutorials follow this sequence:\n\n1. **Title** - What the reader will build or accomplish\n2. **Prerequisites** - What they must have installed or know\n3. **What You Will Build** - One paragraph, concrete outcome\n4. **Setup** - Environment configuration steps\n5. **Core Steps** - The numbered sequence of actions\n6. **Verify It Works** - How to confirm success\n7. **Troubleshooting** - Two to four common failure modes\n8. **Next Steps** - One or two natural follow-on tasks\n\nNot every tutorial needs all eight sections.\nShort tutorials (under 500 words) can omit Next Steps and\nmerge Verify with the final core step.\n\n## Length Targets per Section\n\n| Section | Target Length |\n|---------|---------------|\n| Title | 5-10 words |\n| Prerequisites | 30-60 words |\n| What You Will Build | 50-100 words |\n| Setup | 50-150 words |\n| Each Core Step | 30-80 words |\n| Verify It Works | 30-60 words |\n| Troubleshooting | 50-150 words |\n| Next Steps | 20-40 words |\n\n## Prerequisite Section Rules\n\nState prerequisites as a list of specific, verifiable items.\nVague prerequisites waste the reader's time.\n\n```markdown\nBAD:\n- Basic programming knowledge\n- Familiarity with the command line\n\nGOOD:\n- Python 3.11 or later (`python3 --version`)\n- A GitHub account with SSH access configured\n- `curl` available on your system\n```\n\nEach prerequisite should be verifiable in under 30 seconds.\nIf the reader cannot confirm it with a single command, add\nthe command.\n\n## Core Steps Structure\n\nEach step in the numbered sequence should follow this pattern:\n\n1. One sentence describing what the reader does\n2. The command or code block to run\n3. The expected output or result (required for commands)\n4. One optional sentence explaining why, if non-obvious\n\nKeep explanatory prose after the code, not before it.\nThe reader runs first, then reads why.\n\n## Troubleshooting Section\n\nCover the two to four errors most likely to occur.\nStructure each entry as:\n\n```markdown\n### Error: [exact error message or symptom]\n\n**Cause**: [one sentence]\n\n**Fix**: [one to three steps]\n```\n\nDo not include every possible error.\nFocus on the errors that newcomers hit in the first ten minutes.\n\n## Outline Validation Checklist\n\nBefore drafting:\n\n- [ ] Every section has a one-line description of reader action\n- [ ] Prerequisites are specific and verifiable\n- [ ] Core steps are numbered and ordered\n- [ ] Troubleshooting has at least two entries planned\n- [ ] Total planned length is under 2000 words for a starter guide\n\nFile v1.9.12:modules/progressive-complexity.md\n\n---\nmodule: progressive-complexity\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 480\n---\n\n# Building Complexity Gradually\n\nThe most common tutorial failure is starting too hard.\nThe reader gets lost before the baseline works, gives up, and\nblames the tool.\nStart with the minimum that produces a visible result.\nAdd variation only after that baseline is solid.\n\n## The Minimal Example First\n\nThe first working example should be the shortest possible program\nthat demonstrates the core concept.\nIt need not be production-quality; it must be correct and runnable.\n\n```markdown\nBAD: Start with a full web server including auth, logging,\nand database connections.\n\nGOOD: Start with a server that returns \"Hello, World!\" on port 3000.\n```\n\nThe minimal example answers one question: does this thing work?\nOnce the reader sees it working, they are ready to learn more.\n\n## The Layering Model\n\nIntroduce complexity in layers.\nEach layer adds one new concept or one new component.\nA reader should be able to stop at any layer and have\na working system.\n\nLayer pattern:\n\n1. **Baseline** - The minimal working example\n2. **First extension** - Add one realistic feature\n3. **Second extension** - Add error handling or configuration\n4. **Production pattern** - Show what the real thing looks like\n\nNot every tutorial needs all four layers.\nA focused tutorial may only need baseline plus one extension.\n\n## Pacing Rules\n\n- Complete one layer before describing the next\n- State what you are about to add before adding it\n- Do not introduce two new concepts in a single step\n- Run the code after each layer to show it still works\n\n```markdown\nBAD:\n\"Now we will add authentication, a database connection,\nand rate limiting...\"\n\nGOOD:\n\"The server works. Now add a database connection.\nAuthentication comes in the next section.\"\n```\n\n## When to Introduce Alternatives\n\nIntroduce alternative approaches only after the primary path works.\nThe reader needs one good path before they can evaluate tradeoffs.\n\n```markdown\nBAD: \"You could use Redis or Memcached or an in-memory store here.\"\n\nGOOD: \"We use Redis here. Once this works, see [link] for\nthe Memcached variant.\"\n```\n\n## Complexity Signals to Watch For\n\nSigns that a section has become too complex:\n\n- A step has more than one code block with no \"run this\" between them\n- You are explaining a concept that requires another concept first\n- The expected output section requires more prose than the step itself\n- You find yourself writing \"before we continue, you should know...\"\n\nWhen you see these signals, split the section or move the prerequisite\nknowledge into the Prerequisites section.\n\n## End-State Clarity\n\nThe reader must know what they are building toward before they start.\nState the end state in the \"What You Will Build\" section as a concrete\ndescription, not a list of features:\n\n```markdown\nBAD:\n\"You will learn authentication, sessions, and middleware.\"\n\nGOOD:\n\"By the end of this tutorial, you will have a Node.js server\nthat accepts a username and password, issues a signed JWT,\nand rejects requests without a valid token.\"\n```\n\nThe end state should be verifiable: the reader can check that they\nachieved it by running one command or visiting one URL.\n\nFile v1.9.12:skill-card.md\n\n## Description: <br>\nPlans, drafts, and refines technical tutorials for developers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and technical writers use this skill to plan, draft, and verify getting-started guides, hands-on walkthroughs, and technical tutorials backed by runnable code. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill can edit documentation or agent instruction files outside the intended scope. <br>\nMitigation: Name the target files explicitly and request report-only behavior when auditing; review proposed diffs before accepting changes. <br>\nRisk: A tutorial can mislead readers if code examples are not tested in the target environment. <br>\nMitigation: Require tested snippets, exact prerequisite versions, expected output blocks, and explicit notes for any untested platform or command. <br>\n\n\n## Reference(s): <br>\n- [ClawHub Skill Page](https://clawhub.ai/athola/nm-scribe-tech-tutorial) <br>\n- [Project Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/scribe) <br>\n- [Writing Effective Code Examples](modules/code-examples.md) <br>\n- [Tutorial Outline and Structure](modules/outline-structure.md) <br>\n- [Building Complexity Gradually](modules/progressive-complexity.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Guidance] <br>\n**Output Format:** [Markdown with fenced code blocks, checklists, outlines, and prose guidance] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May include tutorial outlines, tested code snippets, expected output blocks, troubleshooting notes, and quality-gate checklist items.] <br>\n\n## Skill Version(s): <br>\n1.9.12 (source: server release metadata; artifact frontmatter reports 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.2: 6 files, 9121 bytes\n\nFiles: modules/code-examples.md (3345b), modules/outline-structure.md (2900b), modules/progressive-complexity.md (3224b), skill-card.md (2219b), SKILL.md (5374b), _meta.json (142b)\n\nFile v1.0.2:SKILL.md\n\n---\nname: tech-tutorial\ndescription: Plan, draft, and refine technical tutorials for developers\nversion: 1.9.5\ntriggers:\n  - tutorial\n  - technical-writing\n  - code-examples\n  - developer-docs\n  - getting-started\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Tech Tutorial\n\nA good technical tutorial has one goal: move a reader from not knowing\nhow to do something to being able to do it.\nThat requires working code, concrete steps, and honest acknowledgment\nof where things go wrong.\nThis skill guides you through outlining, drafting, and verifying a\ntutorial that meets that standard.\n\n## When To Use\n\n- Writing a getting-started guide for a library, CLI tool, or API\n- Creating a step-by-step walkthrough that readers follow at a terminal\n- Explaining a technical concept through a hands-on exercise\n- Producing a how-to that complements API reference documentation\n\n## When NOT To Use\n\n- Generating API reference docs (use `scribe:doc-generator`)\n- Cleaning up existing prose (use `scribe:slop-detector`)\n- Producing high-level architecture overviews without runnable steps\n- Writing conceptual essays without hands-on components\n\n## Methodology\n\n### Step 1: Scope and Audience\n\nBefore writing a single line, answer these questions:\n\n- Who is this for? (experience level, assumed prior knowledge)\n- What will they build or accomplish by the end?\n- What is the single prerequisite the reader must have installed?\n- What is explicitly out of scope?\n\nWrite these answers down as a header block in the draft.\nIf you cannot answer the \"what will they accomplish\" question\nin one sentence, the scope is too broad.\n\n### Step 2: Outline\n\nLoad: `@modules/outline-structure.md`\n\nProduce a section-by-section outline before drafting prose.\nEach section entry must include a one-line description of what\nthe reader does or learns in that section.\nSee the outline module for the standard section order and\nlength targets per section type.\n\n### Step 3: Draft Code Examples First\n\nLoad: `@modules/code-examples.md`\n\nWrite the code before the prose.\nEach snippet must run against a real environment before it\nappears in the tutorial.\nAnnotate only the non-obvious lines.\nSee the code examples module for formatting and error-handling rules.\n\n### Step 4: Draft Prose Around the Code\n\nProse exists to explain what the code does and why.\nFollow these rules:\n\n- One paragraph per step: what to run, what it does, what to expect\n- State the expected output after each command block\n- Use second person (\"you\") consistently throughout\n- Do not narrate what the reader will do next; just present the next step\n\n### Step 5: Build Complexity Gradually\n\nLoad: `@modules/progressive-complexity.md`\n\nStart with the minimal working example.\nIntroduce variations and edge cases only after the baseline works.\nSee the progressive complexity module for the layering rules\nand pacing guidance.\n\n### Step 6: Slop Check\n\nAfter drafting, run:\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix all tier-1 findings before proceeding.\nPay particular attention to:\n\n- Tier-1 vocabulary slop (see `scribe:slop-detector` word lists)\n- Tricolon adjective clusters (\"fast, efficient, and reliable\")\n- Participial tail-loading (sentences ending with \", enabling ...\")\n\n### Step 7: Quality Gate\n\nVerify the completed tutorial against this checklist:\n\n- [ ] All code blocks tested and produce the stated output\n- [ ] Prerequisites section lists exact versions where relevant\n- [ ] Every step states the expected result\n- [ ] Troubleshooting section covers at least two common failure modes\n- [ ] No tier-1 slop words\n- [ ] Em dash count is under 2 per 1000 words\n- [ ] Bullet ratio is under 40%\n- [ ] Line length wraps at 80 characters\n\n## Required TodoWrite Items\n\n1. `tech-tutorial:scope-defined` - Audience, goal, and out-of-scope noted\n2. `tech-tutorial:outline-approved` - Section outline confirmed\n3. `tech-tutorial:code-tested` - All snippets verified against a real env\n4. `tech-tutorial:prose-drafted` - Walkthrough text written\n5. `tech-tutorial:slop-scanned` - Slop detector passed\n6. `tech-tutorial:quality-verified` - Quality gate checklist cleared\n7. `tech-tutorial:user-approved` - Final approval received\n\n## Module Reference\n\n- See `modules/outline-structure.md` for section order and length targets\n- See `modules/code-examples.md` for snippet formatting and annotation rules\n- See `modules/progressive-complexity.md` for pacing and layering guidance\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| scribe:slop-detector | After drafting, before approval |\n| scribe:doc-generator | For companion API reference sections |\n| scribe:style-learner | To match an existing tutorial voice |\n\n## Exit Criteria\n\n- Tutorial outline confirmed before drafting begins\n- All code snippets tested in a real environment\n- Slop score below 1.5 (clean)\n- Quality gate checklist passed\n- User approval received\n\nFile v1.0.2:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-tech-tutorial\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1778293231744\n}\n\nFile v1.0.2:modules/code-examples.md\n\n---\nmodule: code-examples\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 550\n---\n\n# Writing Effective Code Examples\n\nCode examples are the primary content of a technical tutorial.\nWrite and run each snippet before embedding it in the document.\nA tutorial with untested code is broken.\n\n## The Testing Rule\n\nEvery code block that the reader is expected to run must be tested\nin a real environment before publication.\nThis means:\n\n1. Run the command in a clean shell or container\n2. Confirm the output matches what you claim\n3. Record the exact output to quote in the tutorial\n4. Note any version-specific behavior\n\nIf you cannot test a snippet, mark it clearly as untested:\n\n```markdown\n<!-- Note: untested on Windows; verified on macOS 14.3 -->\n```\n\nNever present guessed output as verified.\n\n## Formatting Rules\n\nUse fenced code blocks with a language identifier on every block:\n\n```markdown\n```bash\nnpm install express\n```\n```\n\nCommon language identifiers:\n\n| Content Type | Identifier |\n|--------------|------------|\n| Shell commands | `bash` |\n| Python | `python` |\n| JavaScript/Node | `javascript` |\n| YAML config | `yaml` |\n| JSON output | `json` |\n| Generic output | `text` |\n\nDo not use `sh` as an identifier; use `bash` or `zsh` explicitly.\n\n## Output Blocks\n\nShow expected output after every command that produces visible output.\nUse a `text` block with the label \"Output:\" on its own line:\n\n```markdown\nRun the server:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nServer running on http://localhost:3000\n```\n```\n\nIf output is long, truncate with `...` and show the key lines:\n\n```text\nDownloading packages...\n...\nSuccessfully installed 14 packages in 2.3s\n```\n\n## Annotation Guidelines\n\nAnnotate only the non-obvious parts.\nOver-annotation creates noise that pushes readers past the code.\n\nGood annotation targets:\n\n- A flag or option whose name does not explain itself\n- A value the reader must substitute for their own\n- A syntax form they may not have seen before\n\nMark substitution points with angle brackets:\n\n```bash\ngit remote add origin git@github.com:<your-username>/<repo-name>.git\n```\n\nDo not annotate things that the code makes self-evident.\n\n## Handling Errors in Examples\n\nWhen showing an expected error (to teach debugging), be explicit:\n\n```markdown\nRunning this command before installing dependencies will fail:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nError: Cannot find module 'express'\n```\n\nInstall dependencies first, then retry.\n```\n\nNever silently show error output without explaining it.\n\n## Long Code Example Handling\n\nFor files longer than 30 lines, show only the relevant portion:\n\n```markdown\nIn `config/database.js`, update the connection string (line 12):\n\n```javascript\n// config/database.js (excerpt)\nconst connection = {\n  host: process.env.DB_HOST,\n  port: 5432,\n  database: process.env.DB_NAME,\n};\n```\n```\n\nProvide a link to the full file in a repository if one exists.\n\n## Verify Your Examples Work\n\nBefore including any example, run this checklist:\n\n- [ ] Command produces the stated output\n- [ ] Tested in the same environment as the reader will use\n- [ ] Language identifier is present on the fenced block\n- [ ] Output block follows every command with visible output\n- [ ] Substitution points use angle bracket notation\n- [ ] Untested blocks carry an explicit disclaimer\n\nFile v1.0.2:modules/outline-structure.md\n\n---\nmodule: outline-structure\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 500\n---\n\n# Tutorial Outline and Structure\n\nA tutorial outline is a contract with the reader: it says what they\nwill do and in what order.\nWrite the outline before drafting any prose.\nIf an outline entry is hard to describe in one line, the section\nis too large and needs splitting.\n\n## Standard Section Order\n\nMost technical tutorials follow this sequence:\n\n1. **Title** - What the reader will build or accomplish\n2. **Prerequisites** - What they must have installed or know\n3. **What You Will Build** - One paragraph, concrete outcome\n4. **Setup** - Environment configuration steps\n5. **Core Steps** - The numbered sequence of actions\n6. **Verify It Works** - How to confirm success\n7. **Troubleshooting** - Two to four common failure modes\n8. **Next Steps** - One or two natural follow-on tasks\n\nNot every tutorial needs all eight sections.\nShort tutorials (under 500 words) can omit Next Steps and\nmerge Verify with the final core step.\n\n## Length Targets per Section\n\n| Section | Target Length |\n|---------|---------------|\n| Title | 5-10 words |\n| Prerequisites | 30-60 words |\n| What You Will Build | 50-100 words |\n| Setup | 50-150 words |\n| Each Core Step | 30-80 words |\n| Verify It Works | 30-60 words |\n| Troubleshooting | 50-150 words |\n| Next Steps | 20-40 words |\n\n## Prerequisite Section Rules\n\nState prerequisites as a list of specific, verifiable items.\nVague prerequisites waste the reader's time.\n\n```markdown\nBAD:\n- Basic programming knowledge\n- Familiarity with the command line\n\nGOOD:\n- Python 3.11 or later (`python3 --version`)\n- A GitHub account with SSH access configured\n- `curl` available on your system\n```\n\nEach prerequisite should be verifiable in under 30 seconds.\nIf the reader cannot confirm it with a single command, add\nthe command.\n\n## Core Steps Structure\n\nEach step in the numbered sequence should follow this pattern:\n\n1. One sentence describing what the reader does\n2. The command or code block to run\n3. The expected output or result (required for commands)\n4. One optional sentence explaining why, if non-obvious\n\nKeep explanatory prose after the code, not before it.\nThe reader runs first, then reads why.\n\n## Troubleshooting Section\n\nCover the two to four errors most likely to occur.\nStructure each entry as:\n\n```markdown\n### Error: [exact error message or symptom]\n\n**Cause**: [one sentence]\n\n**Fix**: [one to three steps]\n```\n\nDo not include every possible error.\nFocus on the errors that newcomers hit in the first ten minutes.\n\n## Outline Validation Checklist\n\nBefore drafting:\n\n- [ ] Every section has a one-line description of reader action\n- [ ] Prerequisites are specific and verifiable\n- [ ] Core steps are numbered and ordered\n- [ ] Troubleshooting has at least two entries planned\n- [ ] Total planned length is under 2000 words for a starter guide\n\nFile v1.0.2:modules/progressive-complexity.md\n\n---\nmodule: progressive-complexity\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 480\n---\n\n# Building Complexity Gradually\n\nThe most common tutorial failure is starting too hard.\nThe reader gets lost before the baseline works, gives up, and\nblames the tool.\nStart with the minimum that produces a visible result.\nAdd variation only after that baseline is solid.\n\n## The Minimal Example First\n\nThe first working example should be the shortest possible program\nthat demonstrates the core concept.\nIt need not be production-quality; it must be correct and runnable.\n\n```markdown\nBAD: Start with a full web server including auth, logging,\nand database connections.\n\nGOOD: Start with a server that returns \"Hello, World!\" on port 3000.\n```\n\nThe minimal example answers one question: does this thing work?\nOnce the reader sees it working, they are ready to learn more.\n\n## The Layering Model\n\nIntroduce complexity in layers.\nEach layer adds one new concept or one new component.\nA reader should be able to stop at any layer and have\na working system.\n\nLayer pattern:\n\n1. **Baseline** - The minimal working example\n2. **First extension** - Add one realistic feature\n3. **Second extension** - Add error handling or configuration\n4. **Production pattern** - Show what the real thing looks like\n\nNot every tutorial needs all four layers.\nA focused tutorial may only need baseline plus one extension.\n\n## Pacing Rules\n\n- Complete one layer before describing the next\n- State what you are about to add before adding it\n- Do not introduce two new concepts in a single step\n- Run the code after each layer to show it still works\n\n```markdown\nBAD:\n\"Now we will add authentication, a database connection,\nand rate limiting...\"\n\nGOOD:\n\"The server works. Now add a database connection.\nAuthentication comes in the next section.\"\n```\n\n## When to Introduce Alternatives\n\nIntroduce alternative approaches only after the primary path works.\nThe reader needs one good path before they can evaluate tradeoffs.\n\n```markdown\nBAD: \"You could use Redis or Memcached or an in-memory store here.\"\n\nGOOD: \"We use Redis here. Once this works, see [link] for\nthe Memcached variant.\"\n```\n\n## Complexity Signals to Watch For\n\nSigns that a section has become too complex:\n\n- A step has more than one code block with no \"run this\" between them\n- You are explaining a concept that requires another concept first\n- The expected output section requires more prose than the step itself\n- You find yourself writing \"before we continue, you should know...\"\n\nWhen you see these signals, split the section or move the prerequisite\nknowledge into the Prerequisites section.\n\n## End-State Clarity\n\nThe reader must know what they are building toward before they start.\nState the end state in the \"What You Will Build\" section as a concrete\ndescription, not a list of features:\n\n```markdown\nBAD:\n\"You will learn authentication, sessions, and middleware.\"\n\nGOOD:\n\"By the end of this tutorial, you will have a Node.js server\nthat accepts a username and password, issues a signed JWT,\nand rejects requests without a valid token.\"\n```\n\nThe end state should be verifiable: the reader can check that they\nachieved it by running one command or visiting one URL.\n\nFile v1.0.2:skill-card.md\n\n## Description: <br>\nPlan, draft, and refine technical tutorials for developers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and technical writers use this skill to plan, draft, and refine hands-on tutorials for libraries, CLI tools, APIs, and getting-started workflows. It helps structure outlines, test examples, add expected output, and verify quality before publication. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Tutorial drafts may include shell commands or code snippets that execute in a real project or environment. <br>\nMitigation: Review generated commands before running them, prefer a clean sandbox or container, and avoid exposing sensitive projects or credentials. <br>\nRisk: The broad tutorial-writing trigger may apply to requests that need a narrower documentation scope. <br>\nMitigation: Confirm the audience, goal, prerequisites, and out-of-scope items before drafting. <br>\n\n\n## Reference(s): <br>\n- [Scribe plugin homepage](https://github.com/athola/claude-night-market/tree/master/plugins/scribe) <br>\n- [Code examples module](artifact/modules/code-examples.md) <br>\n- [Outline structure module](artifact/modules/outline-structure.md) <br>\n- [Progressive complexity module](artifact/modules/progressive-complexity.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Markdown, Code, Shell commands, Guidance] <br>\n**Output Format:** [Markdown with fenced code blocks, expected-output blocks, and checklist items] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May include tutorial outlines, runnable snippets, troubleshooting notes, and quality-gate checklists.] <br>\n\n## Skill Version(s): <br>\n1.0.2 (source: release metadata; artifact frontmatter lists 1.9.5) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.1: 5 files, 7914 bytes\n\nFiles: modules/code-examples.md (3345b), modules/outline-structure.md (2900b), modules/progressive-complexity.md (3224b), SKILL.md (5374b), _meta.json (142b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: tech-tutorial\ndescription: Plan, draft, and refine technical tutorials for developers\nversion: 1.9.4\ntriggers:\n  - tutorial\n  - technical-writing\n  - code-examples\n  - developer-docs\n  - getting-started\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Tech Tutorial\n\nA good technical tutorial has one goal: move a reader from not knowing\nhow to do something to being able to do it.\nThat requires working code, concrete steps, and honest acknowledgment\nof where things go wrong.\nThis skill guides you through outlining, drafting, and verifying a\ntutorial that meets that standard.\n\n## When To Use\n\n- Writing a getting-started guide for a library, CLI tool, or API\n- Creating a step-by-step walkthrough that readers follow at a terminal\n- Explaining a technical concept through a hands-on exercise\n- Producing a how-to that complements API reference documentation\n\n## When NOT To Use\n\n- Generating API reference docs (use `scribe:doc-generator`)\n- Cleaning up existing prose (use `scribe:slop-detector`)\n- Producing high-level architecture overviews without runnable steps\n- Writing conceptual essays without hands-on components\n\n## Methodology\n\n### Step 1: Scope and Audience\n\nBefore writing a single line, answer these questions:\n\n- Who is this for? (experience level, assumed prior knowledge)\n- What will they build or accomplish by the end?\n- What is the single prerequisite the reader must have installed?\n- What is explicitly out of scope?\n\nWrite these answers down as a header block in the draft.\nIf you cannot answer the \"what will they accomplish\" question\nin one sentence, the scope is too broad.\n\n### Step 2: Outline\n\nLoad: `@modules/outline-structure.md`\n\nProduce a section-by-section outline before drafting prose.\nEach section entry must include a one-line description of what\nthe reader does or learns in that section.\nSee the outline module for the standard section order and\nlength targets per section type.\n\n### Step 3: Draft Code Examples First\n\nLoad: `@modules/code-examples.md`\n\nWrite the code before the prose.\nEach snippet must run against a real environment before it\nappears in the tutorial.\nAnnotate only the non-obvious lines.\nSee the code examples module for formatting and error-handling rules.\n\n### Step 4: Draft Prose Around the Code\n\nProse exists to explain what the code does and why.\nFollow these rules:\n\n- One paragraph per step: what to run, what it does, what to expect\n- State the expected output after each command block\n- Use second person (\"you\") consistently throughout\n- Do not narrate what the reader will do next; just present the next step\n\n### Step 5: Build Complexity Gradually\n\nLoad: `@modules/progressive-complexity.md`\n\nStart with the minimal working example.\nIntroduce variations and edge cases only after the baseline works.\nSee the progressive complexity module for the layering rules\nand pacing guidance.\n\n### Step 6: Slop Check\n\nAfter drafting, run:\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix all tier-1 findings before proceeding.\nPay particular attention to:\n\n- Tier-1 vocabulary slop (see `scribe:slop-detector` word lists)\n- Tricolon adjective clusters (\"fast, efficient, and reliable\")\n- Participial tail-loading (sentences ending with \", enabling ...\")\n\n### Step 7: Quality Gate\n\nVerify the completed tutorial against this checklist:\n\n- [ ] All code blocks tested and produce the stated output\n- [ ] Prerequisites section lists exact versions where relevant\n- [ ] Every step states the expected result\n- [ ] Troubleshooting section covers at least two common failure modes\n- [ ] No tier-1 slop words\n- [ ] Em dash count is under 2 per 1000 words\n- [ ] Bullet ratio is under 40%\n- [ ] Line length wraps at 80 characters\n\n## Required TodoWrite Items\n\n1. `tech-tutorial:scope-defined` - Audience, goal, and out-of-scope noted\n2. `tech-tutorial:outline-approved` - Section outline confirmed\n3. `tech-tutorial:code-tested` - All snippets verified against a real env\n4. `tech-tutorial:prose-drafted` - Walkthrough text written\n5. `tech-tutorial:slop-scanned` - Slop detector passed\n6. `tech-tutorial:quality-verified` - Quality gate checklist cleared\n7. `tech-tutorial:user-approved` - Final approval received\n\n## Module Reference\n\n- See `modules/outline-structure.md` for section order and length targets\n- See `modules/code-examples.md` for snippet formatting and annotation rules\n- See `modules/progressive-complexity.md` for pacing and layering guidance\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| scribe:slop-detector | After drafting, before approval |\n| scribe:doc-generator | For companion API reference sections |\n| scribe:style-learner | To match an existing tutorial voice |\n\n## Exit Criteria\n\n- Tutorial outline confirmed before drafting begins\n- All code snippets tested in a real environment\n- Slop score below 1.5 (clean)\n- Quality gate checklist passed\n- User approval received\n\nFile v1.0.1:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-tech-tutorial\",\n  \"version\": \"1.0.1\",\n  \"publishedAt\": 1778077322819\n}\n\nFile v1.0.1:modules/code-examples.md\n\n---\nmodule: code-examples\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 550\n---\n\n# Writing Effective Code Examples\n\nCode examples are the primary content of a technical tutorial.\nWrite and run each snippet before embedding it in the document.\nA tutorial with untested code is broken.\n\n## The Testing Rule\n\nEvery code block that the reader is expected to run must be tested\nin a real environment before publication.\nThis means:\n\n1. Run the command in a clean shell or container\n2. Confirm the output matches what you claim\n3. Record the exact output to quote in the tutorial\n4. Note any version-specific behavior\n\nIf you cannot test a snippet, mark it clearly as untested:\n\n```markdown\n<!-- Note: untested on Windows; verified on macOS 14.3 -->\n```\n\nNever present guessed output as verified.\n\n## Formatting Rules\n\nUse fenced code blocks with a language identifier on every block:\n\n```markdown\n```bash\nnpm install express\n```\n```\n\nCommon language identifiers:\n\n| Content Type | Identifier |\n|--------------|------------|\n| Shell commands | `bash` |\n| Python | `python` |\n| JavaScript/Node | `javascript` |\n| YAML config | `yaml` |\n| JSON output | `json` |\n| Generic output | `text` |\n\nDo not use `sh` as an identifier; use `bash` or `zsh` explicitly.\n\n## Output Blocks\n\nShow expected output after every command that produces visible output.\nUse a `text` block with the label \"Output:\" on its own line:\n\n```markdown\nRun the server:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nServer running on http://localhost:3000\n```\n```\n\nIf output is long, truncate with `...` and show the key lines:\n\n```text\nDownloading packages...\n...\nSuccessfully installed 14 packages in 2.3s\n```\n\n## Annotation Guidelines\n\nAnnotate only the non-obvious parts.\nOver-annotation creates noise that pushes readers past the code.\n\nGood annotation targets:\n\n- A flag or option whose name does not explain itself\n- A value the reader must substitute for their own\n- A syntax form they may not have seen before\n\nMark substitution points with angle brackets:\n\n```bash\ngit remote add origin git@github.com:<your-username>/<repo-name>.git\n```\n\nDo not annotate things that the code makes self-evident.\n\n## Handling Errors in Examples\n\nWhen showing an expected error (to teach debugging), be explicit:\n\n```markdown\nRunning this command before installing dependencies will fail:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nError: Cannot find module 'express'\n```\n\nInstall dependencies first, then retry.\n```\n\nNever silently show error output without explaining it.\n\n## Long Code Example Handling\n\nFor files longer than 30 lines, show only the relevant portion:\n\n```markdown\nIn `config/database.js`, update the connection string (line 12):\n\n```javascript\n// config/database.js (excerpt)\nconst connection = {\n  host: process.env.DB_HOST,\n  port: 5432,\n  database: process.env.DB_NAME,\n};\n```\n```\n\nProvide a link to the full file in a repository if one exists.\n\n## Verify Your Examples Work\n\nBefore including any example, run this checklist:\n\n- [ ] Command produces the stated output\n- [ ] Tested in the same environment as the reader will use\n- [ ] Language identifier is present on the fenced block\n- [ ] Output block follows every command with visible output\n- [ ] Substitution points use angle bracket notation\n- [ ] Untested blocks carry an explicit disclaimer\n\nFile v1.0.1:modules/outline-structure.md\n\n---\nmodule: outline-structure\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 500\n---\n\n# Tutorial Outline and Structure\n\nA tutorial outline is a contract with the reader: it says what they\nwill do and in what order.\nWrite the outline before drafting any prose.\nIf an outline entry is hard to describe in one line, the section\nis too large and needs splitting.\n\n## Standard Section Order\n\nMost technical tutorials follow this sequence:\n\n1. **Title** - What the reader will build or accomplish\n2. **Prerequisites** - What they must have installed or know\n3. **What You Will Build** - One paragraph, concrete outcome\n4. **Setup** - Environment configuration steps\n5. **Core Steps** - The numbered sequence of actions\n6. **Verify It Works** - How to confirm success\n7. **Troubleshooting** - Two to four common failure modes\n8. **Next Steps** - One or two natural follow-on tasks\n\nNot every tutorial needs all eight sections.\nShort tutorials (under 500 words) can omit Next Steps and\nmerge Verify with the final core step.\n\n## Length Targets per Section\n\n| Section | Target Length |\n|---------|---------------|\n| Title | 5-10 words |\n| Prerequisites | 30-60 words |\n| What You Will Build | 50-100 words |\n| Setup | 50-150 words |\n| Each Core Step | 30-80 words |\n| Verify It Works | 30-60 words |\n| Troubleshooting | 50-150 words |\n| Next Steps | 20-40 words |\n\n## Prerequisite Section Rules\n\nState prerequisites as a list of specific, verifiable items.\nVague prerequisites waste the reader's time.\n\n```markdown\nBAD:\n- Basic programming knowledge\n- Familiarity with the command line\n\nGOOD:\n- Python 3.11 or later (`python3 --version`)\n- A GitHub account with SSH access configured\n- `curl` available on your system\n```\n\nEach prerequisite should be verifiable in under 30 seconds.\nIf the reader cannot confirm it with a single command, add\nthe command.\n\n## Core Steps Structure\n\nEach step in the numbered sequence should follow this pattern:\n\n1. One sentence describing what the reader does\n2. The command or code block to run\n3. The expected output or result (required for commands)\n4. One optional sentence explaining why, if non-obvious\n\nKeep explanatory prose after the code, not before it.\nThe reader runs first, then reads why.\n\n## Troubleshooting Section\n\nCover the two to four errors most likely to occur.\nStructure each entry as:\n\n```markdown\n### Error: [exact error message or symptom]\n\n**Cause**: [one sentence]\n\n**Fix**: [one to three steps]\n```\n\nDo not include every possible error.\nFocus on the errors that newcomers hit in the first ten minutes.\n\n## Outline Validation Checklist\n\nBefore drafting:\n\n- [ ] Every section has a one-line description of reader action\n- [ ] Prerequisites are specific and verifiable\n- [ ] Core steps are numbered and ordered\n- [ ] Troubleshooting has at least two entries planned\n- [ ] Total planned length is under 2000 words for a starter guide\n\nFile v1.0.1:modules/progressive-complexity.md\n\n---\nmodule: progressive-complexity\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 480\n---\n\n# Building Complexity Gradually\n\nThe most common tutorial failure is starting too hard.\nThe reader gets lost before the baseline works, gives up, and\nblames the tool.\nStart with the minimum that produces a visible result.\nAdd variation only after that baseline is solid.\n\n## The Minimal Example First\n\nThe first working example should be the shortest possible program\nthat demonstrates the core concept.\nIt need not be production-quality; it must be correct and runnable.\n\n```markdown\nBAD: Start with a full web server including auth, logging,\nand database connections.\n\nGOOD: Start with a server that returns \"Hello, World!\" on port 3000.\n```\n\nThe minimal example answers one question: does this thing work?\nOnce the reader sees it working, they are ready to learn more.\n\n## The Layering Model\n\nIntroduce complexity in layers.\nEach layer adds one new concept or one new component.\nA reader should be able to stop at any layer and have\na working system.\n\nLayer pattern:\n\n1. **Baseline** - The minimal working example\n2. **First extension** - Add one realistic feature\n3. **Second extension** - Add error handling or configuration\n4. **Production pattern** - Show what the real thing looks like\n\nNot every tutorial needs all four layers.\nA focused tutorial may only need baseline plus one extension.\n\n## Pacing Rules\n\n- Complete one layer before describing the next\n- State what you are about to add before adding it\n- Do not introduce two new concepts in a single step\n- Run the code after each layer to show it still works\n\n```markdown\nBAD:\n\"Now we will add authentication, a database connection,\nand rate limiting...\"\n\nGOOD:\n\"The server works. Now add a database connection.\nAuthentication comes in the next section.\"\n```\n\n## When to Introduce Alternatives\n\nIntroduce alternative approaches only after the primary path works.\nThe reader needs one good path before they can evaluate tradeoffs.\n\n```markdown\nBAD: \"\n\nArchive v1.0.0: 5 files, 7914 bytes\n\nFiles: modules/code-examples.md (3345b), modules/outline-structure.md (2900b), modules/progressive-complexity.md (3224b), SKILL.md (5374b), _meta.json (142b)","readmeExcerpt":"Skill: tech-tutorial Owner: athola Summary: Plans, drafts, and refines technical tutorials for developers Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:22:16.651Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:42:12.196Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:59:01.551Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:06:37.146Z | user Release v1.9.14 v1.9.13 | 2026-06-27T16:24:20.080Z | user Rel","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"Skill(scribe:slop-detector)"},{"language":"markdown","snippet":"<!-- Note: untested on Windows; verified on macOS 14.3 -->"},{"language":"markdown","snippet":"Run the server:"},{"language":"text","snippet":"Output:"},{"language":"text","snippet":"Downloading packages...\n...\nSuccessfully installed 14 packages in 2.3s"},{"language":"bash","snippet":"git remote add origin git@github.com:<your-username>/<repo-name>.git"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: tech-tutorial\ndescription: Plans, drafts, and refines technical tutorials for developers\nversion: 1.9.8\ntriggers:\n  - tutorial\n  - technical-writing\n  - code-examples\n  - developer-docs\n  - getting-started\n  - writing step-by-step guides or getting-started walkthroughs backed by working code\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Tech Tutorial\n\nA good technical tutorial has one goal: move a reader from not knowing\nhow to do something to being able to do it.\nThat requires working code, concrete steps, and honest acknowledgment\nof where things go wrong.\nThis skill guides you through outlining, drafting, and verifying a\ntutorial that meets that standard.\n\n## When To Use\n\n- Writing a getting-started guide for a library, CLI tool, or API\n- Creating a step-by-step walkthrough that readers follow at a terminal\n- Explaining a technical concept through a hands-on exercise\n- Producing a how-to that complements API reference documentation\n\n## When NOT To Use\n\n- Generating API reference docs (use `scribe:doc-generator`)\n- Cleaning up existing prose (use `scribe:slop-detector`)\n- Producing high-level architecture overviews without runnable steps\n- Writing conceptual essays without hands-on components\n\n## Methodology\n\n### Step 1: Scope and Audience\n\nBefore writing a single line, answer these questions:\n\n- Who is this for? (experience level, assumed prior knowledge)\n- How many readers? How often will each one read it?\n- What will they build or accomplish by the end?\n- **What is the one sentence they must walk away with?**\n  (the thesis — not the topic)\n- What is the single prerequisite the reader must have installed?\n- What is explicitly out of scope?\n\nWrite these answers down as a header block in the draft.\nIf you cannot answer the \"what will they accomplish\" question\nin one sentence, the scope is too broad. If you cannot state\nthe thesis in one sentence, the tutorial is not ready to draft.\n\nThe audience size and read frequency feed the reader-time\nbudget (see `scribe:slop-detector` module `document-economy.md`).\nA tutorial that 500 developers will read once is a 40-hour\nreader-budget asset; spend the writing time accordingly.\n\n### Step 2: Outline\n\nLoad: `@modules/outline-structure.md`\n\nProduce a section-by-section outline before drafting prose.\nEach section entry must include a one-line description of what\nthe reader does or learns in that section.\nSee the outline module for the standard section order and\nlength targets per section type.\n\n### Step 3: Draft Code Examples Firs"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-tech-tutorial\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787750536651\n}"},{"path":"modules/code-examples.md","content":"---\nmodule: code-examples\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 550\n---\n\n# Writing Effective Code Examples\n\nCode examples are the primary content of a technical tutorial.\nWrite and run each snippet before embedding it in the document.\nA tutorial with untested code is broken.\n\n## The Testing Rule\n\nEvery code block that the reader is expected to run must be tested\nin a real environment before publication.\nThis means:\n\n1. Run the command in a clean shell or container\n2. Confirm the output matches what you claim\n3. Record the exact output to quote in the tutorial\n4. Note any version-specific behavior\n\nIf you cannot test a snippet, mark it clearly as untested:\n\n```markdown\n<!-- Note: untested on Windows; verified on macOS 14.3 -->\n```\n\nNever present guessed output as verified.\n\n## Formatting Rules\n\nUse fenced code blocks with a language identifier on every block:\n\n```markdown\n```bash\nnpm install express\n```\n```\n\nCommon language identifiers:\n\n| Content Type | Identifier |\n|--------------|------------|\n| Shell commands | `bash` |\n| Python | `python` |\n| JavaScript/Node | `javascript` |\n| YAML config | `yaml` |\n| JSON output | `json` |\n| Generic output | `text` |\n\nDo not use `sh` as an identifier; use `bash` or `zsh` explicitly.\n\n## Output Blocks\n\nShow expected output after every command that produces visible output.\nUse a `text` block with the label \"Output:\" on its own line:\n\n```markdown\nRun the server:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nServer running on http://localhost:3000\n```\n```\n\nIf output is long, truncate with `...` and show the key lines:\n\n```text\nDownloading packages...\n...\nSuccessfully installed 14 packages in 2.3s\n```\n\n## Annotation Guidelines\n\nAnnotate only the non-obvious parts.\nOver-annotation creates noise that pushes readers past the code.\n\nGood annotation targets:\n\n- A flag or option whose name does not explain itself\n- A value the reader must substitute for their own\n- A syntax form they may not have seen before\n\nMark substitution points with angle brackets:\n\n```bash\ngit remote add origin git@github.com:<your-username>/<repo-name>.git\n```\n\nDo not annotate things that the code makes self-evident.\n\n## Handling Errors in Examples\n\nWhen showing an expected error (to teach debugging), be explicit:\n\n```markdown\nRunning this command before installing dependencies will fail:\n\n```bash\nnode server.js\n```\n\nOutput:\n\n```text\nError: Cannot find module 'express'\n```\n\nInstall dependencies first, then retry.\n```\n\nNever silently show error output without explaining it.\n\n## Long Code Example Handling\n\nFor files longer than 30 lines, show only the relevant portion:\n\n```markdown\nIn `config/database.js`, update the connection string (line 12):\n\n```javascript\n// config/database.js (excerpt)\nconst connection = {\n  host: process.env.DB_HOST,\n  port: 5432,\n  database: process.env.DB_NAME,\n};\n```\n```\n\nProvide a link to the full file in a repository if one exists.\n\n## Verify Your Examples Work\n\nBefore including any example,"},{"path":"modules/outline-structure.md","content":"---\nmodule: outline-structure\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 500\n---\n\n# Tutorial Outline and Structure\n\nA tutorial outline is a contract with the reader: it says what they\nwill do and in what order.\nWrite the outline before drafting any prose.\nIf an outline entry is hard to describe in one line, the section\nis too large and needs splitting.\n\n## Standard Section Order\n\nMost technical tutorials follow this sequence:\n\n1. **Title** - What the reader will build or accomplish\n2. **Prerequisites** - What they must have installed or know\n3. **What You Will Build** - One paragraph, concrete outcome\n4. **Setup** - Environment configuration steps\n5. **Core Steps** - The numbered sequence of actions\n6. **Verify It Works** - How to confirm success\n7. **Troubleshooting** - Two to four common failure modes\n8. **Next Steps** - One or two natural follow-on tasks\n\nNot every tutorial needs all eight sections.\nShort tutorials (under 500 words) can omit Next Steps and\nmerge Verify with the final core step.\n\n## Length Targets per Section\n\n| Section | Target Length |\n|---------|---------------|\n| Title | 5-10 words |\n| Prerequisites | 30-60 words |\n| What You Will Build | 50-100 words |\n| Setup | 50-150 words |\n| Each Core Step | 30-80 words |\n| Verify It Works | 30-60 words |\n| Troubleshooting | 50-150 words |\n| Next Steps | 20-40 words |\n\n## Prerequisite Section Rules\n\nState prerequisites as a list of specific, verifiable items.\nVague prerequisites waste the reader's time.\n\n```markdown\nBAD:\n- Basic programming knowledge\n- Familiarity with the command line\n\nGOOD:\n- Python 3.11 or later (`python3 --version`)\n- A GitHub account with SSH access configured\n- `curl` available on your system\n```\n\nEach prerequisite should be verifiable in under 30 seconds.\nIf the reader cannot confirm it with a single command, add\nthe command.\n\n## Core Steps Structure\n\nEach step in the numbered sequence should follow this pattern:\n\n1. One sentence describing what the reader does\n2. The command or code block to run\n3. The expected output or result (required for commands)\n4. One optional sentence explaining why, if non-obvious\n\nKeep explanatory prose after the code, not before it.\nThe reader runs first, then reads why.\n\n## Troubleshooting Section\n\nCover the two to four errors most likely to occur.\nStructure each entry as:\n\n```markdown\n### Error: [exact error message or symptom]\n\n**Cause**: [one sentence]\n\n**Fix**: [one to three steps]\n```\n\nDo not include every possible error.\nFocus on the errors that newcomers hit in the first ten minutes.\n\n## Outline Validation Checklist\n\nBefore drafting:\n\n- [ ] Every section has a one-line description of reader action\n- [ ] Prerequisites are specific and verifiable\n- [ ] Core steps are numbered and ordered\n- [ ] Troubleshooting has at least two entries planned\n- [ ] Total planned length is under 2000 words for a starter guide"},{"path":"modules/progressive-complexity.md","content":"---\nmodule: progressive-complexity\ncategory: artifact-generation\ndependencies: []\nestimated_tokens: 480\n---\n\n# Building Complexity Gradually\n\nThe most common tutorial failure is starting too hard.\nThe reader gets lost before the baseline works, gives up, and\nblames the tool.\nStart with the minimum that produces a visible result.\nAdd variation only after that baseline is solid.\n\n## The Minimal Example First\n\nThe first working example should be the shortest possible program\nthat demonstrates the core concept.\nIt need not be production-quality; it must be correct and runnable.\n\n```markdown\nBAD: Start with a full web server including auth, logging,\nand database connections.\n\nGOOD: Start with a server that returns \"Hello, World!\" on port 3000.\n```\n\nThe minimal example answers one question: does this thing work?\nOnce the reader sees it working, they are ready to learn more.\n\n## The Layering Model\n\nIntroduce complexity in layers.\nEach layer adds one new concept or one new component.\nA reader should be able to stop at any layer and have\na working system.\n\nLayer pattern:\n\n1. **Baseline** - The minimal working example\n2. **First extension** - Add one realistic feature\n3. **Second extension** - Add error handling or configuration\n4. **Production pattern** - Show what the real thing looks like\n\nNot every tutorial needs all four layers.\nA focused tutorial may only need baseline plus one extension.\n\n## Pacing Rules\n\n- Complete one layer before describing the next\n- State what you are about to add before adding it\n- Do not introduce two new concepts in a single step\n- Run the code after each layer to show it still works\n\n```markdown\nBAD:\n\"Now we will add authentication, a database connection,\nand rate limiting...\"\n\nGOOD:\n\"The server works. Now add a database connection.\nAuthentication comes in the next section.\"\n```\n\n## When to Introduce Alternatives\n\nIntroduce alternative approaches only after the primary path works.\nThe reader needs one good path before they can evaluate tradeoffs.\n\n```markdown\nBAD: \"You could use Redis or Memcached or an in-memory store here.\"\n\nGOOD: \"We use Redis here. Once this works, see [link] for\nthe Memcached variant.\"\n```\n\n## Complexity Signals to Watch For\n\nSigns that a section has become too complex:\n\n- A step has more than one code block with no \"run this\" between them\n- You are explaining a concept that requires another concept first\n- The expected output section requires more prose than the step itself\n- You find yourself writing \"before we continue, you should know...\"\n\nWhen you see these signals, split the section or move the prerequisite\nknowledge into the Prerequisites section.\n\n## End-State Clarity\n\nThe reader must know what they are building toward before they start.\nState the end state in the \"What You Will Build\" section as a concrete\ndescription, not a list of features:\n\n```markdown\nBAD:\n\"You will learn authentication, sessions, and middleware.\"\n\nGOOD:\n\"By the end of this tutorial, you will have a Node.js server\nthat acc"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":1949,"uniquenessScore":43,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T06:17:35.012Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T06:17:35.012Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T10:42:46.502Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}