What makes tech-tutorial notable?

1.6K downloads. Trust evidence available

How should tech-tutorial be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

tech-tutorial

Plans, drafts, and refines technical tutorials for developers

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.6k

Updated

Oct 10, 2026

Version

1.9.19

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.6K downloads reported by the source. Last updated 10/10/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 10, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 10, 2026
Adoption signal: 1.6K downloadsadoption · observed Oct 10, 2026
Latest release: 1.9.19release · observed Aug 26, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-scribe-tech-tutorial

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: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-tech-tutorial/snapshot"

Documentation

CLAWHUB

144,936 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: tech-tutorial
description: Plans, drafts, and refines technical tutorials for developers
version: 1.9.8
triggers:
  - tutorial
  - technical-writing
  - code-examples
  - developer-docs
  - getting-started
  - writing step-by-step guides or getting-started walkthroughs backed by working code
metadata: {"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"]}}}
source: claude-night-market
source_plugin: scribe
---

> **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.


# Tech Tutorial

A good technical tutorial has one goal: move a reader from not knowing
how to do something to being able to do it.
That requires working code, concrete steps, and honest acknowledgment
of where things go wrong.
This skill guides you through outlining, drafting, and verifying a
tutorial that meets that standard.

## When To Use

- Writing a getting-started guide for a library, CLI tool, or API
- Creating a step-by-step walkthrough that readers follow at a terminal
- Explaining a technical concept through a hands-on exercise
- Producing a how-to that complements API reference documentation

## When NOT To Use

- Generating API reference docs (use `scribe:doc-generator`)
- Cleaning up existing prose (use `scribe:slop-detector`)
- Producing high-level architecture overviews without runnable steps
- Writing conceptual essays without hands-on components

## Methodology

### Step 1: Scope and Audience

Before writing a single line, answer these questions:

- Who is this for? (experience level, assumed prior knowledge)
- How many readers? How often will each one read it?
- What will they build or accomplish by the end?
- **What is the one sentence they must walk away with?**
  (the thesis — not the topic)
- What is the single prerequisite the reader must have installed?
- What is explicitly out of scope?

Write these answers down as a header block in the draft.
If you cannot answer the "what will they accomplish" question
in one sentence, the scope is too broad. If you cannot state
the thesis in one sentence, the tutorial is not ready to draft.

The audience size and read frequency feed the reader-time
budget (see `scribe:slop-detector` module `document-economy.md`).
A tutorial that 500 developers will read once is a 40-hour
reader-budget asset; spend the writing time accordingly.

### Step 2: Outline

Load: `@modules/outline-structure.md`

Produce a section-by-section outline before drafting prose.
Each section entry must include a one-line description of what
the reader does or learns in that section.
See the outline module for the standard section order and
length targets per section type.

### Step 3: Draft Code Examples Firs

_meta.json

{
  "ownerId": "kn7d107jg9jv602h9ytsegydq184a42s",
  "slug": "nm-scribe-tech-tutorial",
  "version": "1.9.19",
  "publishedAt": 1787750536651
}

modules/code-examples.md

---
module: code-examples
category: artifact-generation
dependencies: []
estimated_tokens: 550
---

# Writing Effective Code Examples

Code examples are the primary content of a technical tutorial.
Write and run each snippet before embedding it in the document.
A tutorial with untested code is broken.

## The Testing Rule

Every code block that the reader is expected to run must be tested
in a real environment before publication.
This means:

1. Run the command in a clean shell or container
2. Confirm the output matches what you claim
3. Record the exact output to quote in the tutorial
4. Note any version-specific behavior

If you cannot test a snippet, mark it clearly as untested:

```markdown
<!-- Note: untested on Windows; verified on macOS 14.3 -->
```

Never present guessed output as verified.

## Formatting Rules

Use fenced code blocks with a language identifier on every block:

```markdown
```bash
npm install express
```
```

Common language identifiers:

| Content Type | Identifier |
|--------------|------------|
| Shell commands | `bash` |
| Python | `python` |
| JavaScript/Node | `javascript` |
| YAML config | `yaml` |
| JSON output | `json` |
| Generic output | `text` |

Do not use `sh` as an identifier; use `bash` or `zsh` explicitly.

## Output Blocks

Show expected output after every command that produces visible output.
Use a `text` block with the label "Output:" on its own line:

```markdown
Run the server:

```bash
node server.js
```

Output:

```text
Server running on http://localhost:3000
```
```

If output is long, truncate with `...` and show the key lines:

```text
Downloading packages...
...
Successfully installed 14 packages in 2.3s
```

## Annotation Guidelines

Annotate only the non-obvious parts.
Over-annotation creates noise that pushes readers past the code.

Good annotation targets:

- A flag or option whose name does not explain itself
- A value the reader must substitute for their own
- A syntax form they may not have seen before

Mark substitution points with angle brackets:

```bash
git remote add origin [email protected]:<your-username>/<repo-name>.git
```

Do not annotate things that the code makes self-evident.

## Handling Errors in Examples

When showing an expected error (to teach debugging), be explicit:

```markdown
Running this command before installing dependencies will fail:

```bash
node server.js
```

Output:

```text
Error: Cannot find module 'express'
```

Install dependencies first, then retry.
```

Never silently show error output without explaining it.

## Long Code Example Handling

For files longer than 30 lines, show only the relevant portion:

```markdown
In `config/database.js`, update the connection string (line 12):

```javascript
// config/database.js (excerpt)
const connection = {
  host: process.env.DB_HOST,
  port: 5432,
  database: process.env.DB_NAME,
};
```
```

Provide a link to the full file in a repository if one exists.

## Verify Your Examples Work

Before including any example,

modules/outline-structure.md

---
module: outline-structure
category: artifact-generation
dependencies: []
estimated_tokens: 500
---

# Tutorial Outline and Structure

A tutorial outline is a contract with the reader: it says what they
will do and in what order.
Write the outline before drafting any prose.
If an outline entry is hard to describe in one line, the section
is too large and needs splitting.

## Standard Section Order

Most technical tutorials follow this sequence:

1. **Title** - What the reader will build or accomplish
2. **Prerequisites** - What they must have installed or know
3. **What You Will Build** - One paragraph, concrete outcome
4. **Setup** - Environment configuration steps
5. **Core Steps** - The numbered sequence of actions
6. **Verify It Works** - How to confirm success
7. **Troubleshooting** - Two to four common failure modes
8. **Next Steps** - One or two natural follow-on tasks

Not every tutorial needs all eight sections.
Short tutorials (under 500 words) can omit Next Steps and
merge Verify with the final core step.

## Length Targets per Section

| Section | Target Length |
|---------|---------------|
| Title | 5-10 words |
| Prerequisites | 30-60 words |
| What You Will Build | 50-100 words |
| Setup | 50-150 words |
| Each Core Step | 30-80 words |
| Verify It Works | 30-60 words |
| Troubleshooting | 50-150 words |
| Next Steps | 20-40 words |

## Prerequisite Section Rules

State prerequisites as a list of specific, verifiable items.
Vague prerequisites waste the reader's time.

```markdown
BAD:
- Basic programming knowledge
- Familiarity with the command line

GOOD:
- Python 3.11 or later (`python3 --version`)
- A GitHub account with SSH access configured
- `curl` available on your system
```

Each prerequisite should be verifiable in under 30 seconds.
If the reader cannot confirm it with a single command, add
the command.

## Core Steps Structure

Each step in the numbered sequence should follow this pattern:

1. One sentence describing what the reader does
2. The command or code block to run
3. The expected output or result (required for commands)
4. One optional sentence explaining why, if non-obvious

Keep explanatory prose after the code, not before it.
The reader runs first, then reads why.

## Troubleshooting Section

Cover the two to four errors most likely to occur.
Structure each entry as:

```markdown
### Error: [exact error message or symptom]

**Cause**: [one sentence]

**Fix**: [one to three steps]
```

Do not include every possible error.
Focus on the errors that newcomers hit in the first ten minutes.

## Outline Validation Checklist

Before drafting:

- [ ] Every section has a one-line description of reader action
- [ ] Prerequisites are specific and verifiable
- [ ] Core steps are numbered and ordered
- [ ] Troubleshooting has at least two entries planned
- [ ] Total planned length is under 2000 words for a starter guide

modules/progressive-complexity.md

---
module: progressive-complexity
category: artifact-generation
dependencies: []
estimated_tokens: 480
---

# Building Complexity Gradually

The most common tutorial failure is starting too hard.
The reader gets lost before the baseline works, gives up, and
blames the tool.
Start with the minimum that produces a visible result.
Add variation only after that baseline is solid.

## The Minimal Example First

The first working example should be the shortest possible program
that demonstrates the core concept.
It need not be production-quality; it must be correct and runnable.

```markdown
BAD: Start with a full web server including auth, logging,
and database connections.

GOOD: Start with a server that returns "Hello, World!" on port 3000.
```

The minimal example answers one question: does this thing work?
Once the reader sees it working, they are ready to learn more.

## The Layering Model

Introduce complexity in layers.
Each layer adds one new concept or one new component.
A reader should be able to stop at any layer and have
a working system.

Layer pattern:

1. **Baseline** - The minimal working example
2. **First extension** - Add one realistic feature
3. **Second extension** - Add error handling or configuration
4. **Production pattern** - Show what the real thing looks like

Not every tutorial needs all four layers.
A focused tutorial may only need baseline plus one extension.

## Pacing Rules

- Complete one layer before describing the next
- State what you are about to add before adding it
- Do not introduce two new concepts in a single step
- Run the code after each layer to show it still works

```markdown
BAD:
"Now we will add authentication, a database connection,
and rate limiting..."

GOOD:
"The server works. Now add a database connection.
Authentication comes in the next section."
```

## When to Introduce Alternatives

Introduce alternative approaches only after the primary path works.
The reader needs one good path before they can evaluate tradeoffs.

```markdown
BAD: "You could use Redis or Memcached or an in-memory store here."

GOOD: "We use Redis here. Once this works, see [link] for
the Memcached variant."
```

## Complexity Signals to Watch For

Signs that a section has become too complex:

- A step has more than one code block with no "run this" between them
- You are explaining a concept that requires another concept first
- The expected output section requires more prose than the step itself
- You find yourself writing "before we continue, you should know..."

When you see these signals, split the section or move the prerequisite
knowledge into the Prerequisites section.

## End-State Clarity

The reader must know what they are building toward before they start.
State the end state in the "What You Will Build" section as a concrete
description, not a list of features:

```markdown
BAD:
"You will learn authentication, sessions, and middleware."

GOOD:
"By the end of this tutorial, you will have a Node.js server
that acc

Github ReposUpdated 15h agoRank 70

AionUi

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!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

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

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.