Skip to content
Back to skills

Beginner Friendly Writeup

ASecurity

Turn internal knowledge into clean, shareable guides for newcomers. Use when the user asks for a write-up, explainer, or guide that someone else will read — especially if they don't know the system.

  • 36 stars
  • 0 votes
  • 0 copies
  • 4 views
  • Added September 10, 2026
ai-agentsgobashgitdocumentation

Security analysis

A100/100

Scanned September 10, 2026

npx -y skills add theheavenlyd3mon/hermes-profiles --skill beginner-friendly-writeup --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Beginner Friendly Writeup?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Beginner Friendly Writeup
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/theheavenlyd3mon-beginner-friendly-writeup/badge)](https://www.skillsdirectory.com/skills/theheavenlyd3mon-beginner-friendly-writeup)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: beginner-friendly-writeup
description: Turn internal knowledge into clean, shareable guides for newcomers. Use when the user asks for a write-up, explainer, or guide that someone else will read — especially if they don't know the system.
triggers:
  - "write up for someone"
  - "explain this for someone new"
  - "make a guide"
  - "shareable doc"
  - "someone doesnt know how"
  - "beginner guide"
  - "how to explain"
---

# Beginner-Friendly Write-Up

Turn internal/complex knowledge into clean, shareable documents that work for someone who has never seen the system before.

## When to Use

- User asks for a "write up" or "guide" to share with others
- User says "for someone who doesn't know" or "for someone new"
- Converting internal documentation into public-facing content
- Creating onboarding materials

## The Methodology

### 1. Lead With Why

Don't start with setup steps. Start with what the reader gets out of it.

**Bad:** "First, create a directory at ~/Vault/."
**Good:** "Hermes agents accumulate knowledge across hundreds of sessions. Without a persistent store, that knowledge dies. Obsidian gives you a knowledge graph your agent reads and writes automatically."

The reader needs to care before they'll follow steps.

### 2. Big Picture Diagram (Early)

Within the first 3 sections, include a simple ASCII or text diagram showing how the pieces fit together. Readers need a mental model before they handle details.

```
┌─────────┐     ┌─────────┐     ┌─────────┐
│  Agent   │────▶│  Store   │────▶│  UI     │
└─────────┘     └─────────┘     └─────────┘
  does work       saves it        you see it
```

Label each box with what it DOES, not what it IS.

### 3. Numbered Steps With Exact Commands

Every step has:
- A clear action verb in the heading ("Create the vault", not "Vault creation")
- The exact command or file to create
- A copy-paste ready code block
- A "why" sentence after the code block

```bash
hermes profile create researcher
```

> This creates `~/.hermes/profiles/researcher/` with its own config, memory, and skills.

### 4. Copy-Paste Ready Content

If the reader needs to write a config file, SOUL.md, or schema — give them the FULL text they can paste. Don't describe what should go in it; hand them the document.

**Bad:** "Add a section about confidence levels to your SOUL.md."
**Good:** (full SOUL.md with confidence levels already written in)

### 5. Concrete Examples of Good vs Bad

Abstract advice doesn't stick. Show the difference:

**Bad approach (what chatbots do):**
> "Here are the top 10 tools according to [blog]..."

**Good approach (what the agent does):**
> "I searched GitHub stars, recent commits, and open issues. Tool A has 15K stars but 300 open issues. Tool B has 5K stars but active development..."

The reader immediately understands the methodology without you explaining it.

### 6. Strip Internal Specifics

Remove anything that's specific to YOUR setup:
- ❌ Your vault paths (`~/Hermes Vault/Hermes/icarus/`)
- ❌ Your agent names (`senna`, `foreman`, `researcher`)
- ❌ Your model choices (`deepseek-v4-pro`)
- ❌ Your channel IDs (`#research-lab`)
- ❌ Your team structure (10-agent team)
- ✅ Generic paths (`~/Hermes Vault/`)
- ✅ Role descriptions ("the research agent")
- ✅ Model categories ("cost-effective model" or "whatever you have access to")
- ✅ Generic channel names ("your research channel")

The reader should be able to substitute their own details without editing the structure.

### 7. Troubleshooting Table

End with a table of the 5-8 most common problems and their fixes. Pull these from real issues encountered during setup, not hypothetical ones.

| Problem | Fix |
|---------|-----|
| Agent doesn't write to vault | Check OBSIDIAN_VAULT_PATH is set |
| Entries not showing in Obsidian | Make sure FABRIC_DIR points INSIDE the vault |

### 8. Quick Reference Table

A scannable summary at the end — env vars, config values, directory conventions. Readers will come back to this table after the initial read.

| Variable | Example | Purpose |
|----------|---------|---------|
| `OBSIDIAN_VAULT_PATH` | `~/Hermes Vault` | Where the vault root is |

### 9. Progressive Disclosure

Structure the document so someone can stop at any section and have a working setup:

- **Steps 1-3:** Minimum viable setup (it works)
- **Steps 4-5:** Better setup (connected, persistent)
- **Step 6:** First test (verify it works)
- **Optional sections:** Advanced usage, customization

Don't front-load advanced concepts. Let the reader level up.

### 10. Closing Attribution

End with a one-liner linking back to the tool/platform. Keeps it professional and gives the reader a path to learn more.

---

## Document Template

```markdown
# Setting Up [Thing] in Hermes

> One-line pitch — what the reader gets.

---

## Why [Thing]?
2-3 sentences on the problem it solves.

## The Big Picture
ASCII diagram showing how pieces fit together.

## Step 1: [Action Verb]
Exact commands + copy-paste content.

## Step 2: [Action Verb]
...

(repeat for each step)

## Step N: First Run
How to verify everything works.

---

## [Optional] Advanced Usage
Customization, extensions, power-user features.

## Troubleshooting
| Problem | Fix |
|---------|-----|

## Quick Reference
| Item | Value | Purpose |
|------|-------|---------|

---

*Built with [Hermes Agent](https://hermes.nousresearch.com) by Nous Research.*
```

## Checklist Before Sharing

- [ ] Would someone with ZERO context understand this?
- [ ] Are all commands copy-paste ready?
- [ ] Are internal specifics stripped (paths, names, IDs)?
- [ ] Is there a big-picture diagram?
- [ ] Are there concrete good-vs-bad examples?
- [ ] Is there a troubleshooting table?
- [ ] Is there a quick reference table?
- [ ] Can the reader stop at any step and have a working setup?
- [ ] Does it lead with WHY, not HOW?

## Examples

Two guides produced with this methodology:
- `hermes-obsidian-setup-guide.md` — Obsidian as a second brain for Hermes
- `hermes-researcher-profile-guide.md` — Research agent profile and workflow

Both are on the Desktop, share-ready, zero internal references.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.