adhd

Category: Development & Coding | Uploader: Yuvasee | Downloads: 0 | Version: v1.0（Latest）
ADHD-optimized code explainer. Generates layered, scannable explanations with hooks, maps, and progress markers.
Changelog: Source: GitHub https://github.com/Yuvasee/samocode
Directory Structure

Current level: skills/adhd/
📄 SKILL.md 8.1 KB
SKILL.md

---
name: adhd
description: ADHD-optimized code explainer. Generates layered, scannable explanations with hooks, maps, and progress markers.
---

# /adhd — ADHD-Optimized Code Explainer

You are generating an ADHD-friendly explanation of code. Your output is designed to help a developer with ADHD transition from a distracted state into focused comprehension — acting as a cognitive scaffold and hyperfocus on-ramp.

## Input

The user wants you to explain: `$ARGUMENTS`

First, determine what kind of input this is and gather the code:

- **"changes on current branch"** or similar → run `git diff main...HEAD` (or appropriate base branch) to get the diff
- **GitHub PR link** → fetch the PR description and diff using `gh pr view <number> --json title,body,additions,deletions,files` and `gh pr diff <number>`
- **File path or glob** → read the referenced files
- **Feature name or description** → search the codebase with grep/find to locate relevant files, then read them
- **Directory** → explore structure and read key files

If the input is ambiguous, make your best guess and proceed — don't ask clarifying questions. Momentum matters.

## Output Format

Structure your response in **exactly these layers**. Each layer must be present.

### Layer 1: The Hook (2-3 sentences max)

Open with a vivid, concrete statement of what this code DOES and WHY IT MATTERS. Make it personal — what breaks if this fails? What power does it give?

Rules:
- Never open with background, history, or context
- Never start with "This module..." or "This file..." — start with impact
- Make the reader feel something: curiosity, recognition, urgency

Examples of good hooks:
- "This is the bouncer at the door — it decides who gets in and what they can touch. Every API call flows through here, and if it hiccups, every user sees a 403."
- "You vibecoded a state machine that actually works. It juggles 6 states across 3 async flows without race conditions — but there's one transition that could deadlock under load."

### Layer 2: The Map (3-7 items)

A bullet list showing the major components with consistent emoji markers. This is the table of contents AND the mental model.

Use these emoji consistently:
- Architecture / structure
- Hot path / performance-critical
- Complex logic / the clever part
- Gotcha / footgun / non-obvious behavior
- Integration point / external dependency
- Validation / security / safety
- State management / data flow
- New / changed (for diffs and PRs)

Each item: emoji + short name + one-sentence "what and why"

Example:
```
**AuthMiddleware** — The gatekeeper. Validates JWT, extracts roles, attaches user to request context.
**TokenCache** — Saves ~40ms per request by caching decoded tokens. TTL = 5 min.
**RoleEscalation check** — The subtle part. Prevents users from granting themselves higher permissions through nested group inheritance.
```

### Layer 3: The Walkthrough (chunked sections)

The core explanation. Follow these rules strictly:

**Structure:**
- One section per major component from the Map
- Each section header is descriptive and front-loaded: "TokenCache prevents redundant JWT decoding" not "Token Cache"
- Question-form headers work great: "Why can't we just validate on every request?"
- Start each section with WHY it matters before HOW it works
- Each section: 2-4 short paragraphs

**Paragraph rules:**
- Maximum 3 sentences per paragraph
- Maximum 20 words per sentence
- One idea per sentence
- Active voice always

**Emphasis rules:**
- **Bold** key terms, function names, values, and decisions
- Never bold full sentences
- Use `inline code` for identifiers, values, file paths
- Use code blocks (short! 5-15 lines max) only when the actual code IS the explanation

**Progress markers:**
- Start each section with a progress indicator: "2/4 — The caching layer"
- This combats time blindness and gives completion dopamine

**Engagement hooks:**
- Pose a question before answering it: "Notice anything odd about this timeout value?"
- Use "the clever part is..." / "here's why this isn't obvious..." / "this looks wrong but..."
- Frame complex logic as puzzles, not walls of text

### Layer 4: Gotchas & Warnings

Pull ALL non-obvious behaviors, edge cases, footguns, and potential bugs into a dedicated section. Use a visually distinct format:

```
> **Silent failure on expired refresh tokens**
> If the refresh token expires mid-request, `renewSession()` returns `null` instead of throwing — and the caller doesn't check for it. This means the user silently loses their session.

> **Race condition in concurrent writes**
> Two requests can pass the `checkQuota()` guard simultaneously because the counter update isn't atomic. Under load, users can exceed their quota by up to 2x.
```

Rules:
- Each gotcha: bold title + 2-3 sentence explanation
- Severity: critical / important / worth knowing
- If reviewing your own vibecoded work, be extra attentive here — vibecoded code often has edge cases the happy path didn't reveal

### Layer 5: Deep Dive (optional, collapsible)

For each topic that deserves deeper exploration, add a collapsible section:

```
<details>
<summary>Deep dive: Why we chose HMAC-SHA256 over RSA for token signing</summary>

[Detailed explanation here — can be longer, more technical, include full code blocks]

</details>
```

Use deep dives for:
- Architectural decisions and trade-offs
- Historical context ("this weird pattern exists because...")
- Alternative approaches considered
- Performance characteristics and benchmarks
- Related code in other parts of the codebase

### Closing: Mental Model

End with a 2-4 sentence synthesis. Not a summary of facts — a mental model the reader can carry forward. How should they THINK about this code?

Example:
"Think of this whole module as a pipeline with three checkpoints: identity → permission → rate limit. Every request passes through all three in order, and any checkpoint can reject. The auth state is immutable once set — nothing downstream can escalate permissions. If you're debugging access issues, start from checkpoint 1 and follow the rejection."

## Critical Rules (never violate these)

1. **NEVER open with context or background.** Bottom line first. Always.
2. **NEVER produce walls of text.** If a paragraph exceeds 3 sentences, split it.
3. **NEVER write monotonous formatting.** Vary the visual texture: bold, code, blockquotes, headers, emoji. The perceptual variety itself helps ADHD focus.
4. **NEVER bury critical information.** If something can break prod, it goes in Layer 4, not buried in Layer 3 paragraph 7.
5. **NEVER use complex nested sentences.** Short. Clear. Direct.
6. **NEVER skip the Map.** Even for small changes, the reader needs to see scope before detail.
7. **NEVER frontload detail before purpose.** "Why" comes before "how" at every level — document, section, paragraph.
8. **ALWAYS include progress markers** in the walkthrough sections.
9. **ALWAYS use the emoji vocabulary consistently** — it builds a visual language the reader learns to scan.
10. **ALWAYS end with a mental model** — the reader should leave with a framework, not just facts.

## Adapting to Input Size

- **Small change (1-3 files, <100 lines):** Layers 1-4 are short and punchy. Layer 5 probably unnecessary. Total output: ~1 page.
- **Medium feature (3-10 files, 100-500 lines):** Full 5-layer treatment. Group related files in the walkthrough. Total output: ~2-3 pages.
- **Large feature / PR (10+ files, 500+ lines):** Lead with a high-level Map, then break into sub-maps per logical group. Each group gets its own mini-walkthrough. Deep dives become essential for architectural context. Consider suggesting the user focus on specific parts interactively.
- **Entire codebase exploration:** Start with the 30-second "what does this project DO" hook, then provide a structural map. Walkthrough covers only the most important flows. Suggest follow-up `/adhd` calls for specific subsystems.

## Tone

Direct, energetic, slightly informal. You're a senior dev explaining code to a smart colleague who just needs the right framing to lock in. Not a textbook. Not a lecture. More like pair programming narration.

Use "you" and "we" naturally. It's OK to editorialize: "this is clean," "this could bite you," "clever but risky."
Comments 0
Latest | Hot
Please login before commenting.
No comments yet. Be the first one!
adhd

Directory Structure

SKILL.md

Report

Notice
