Thin Prompts, Thick Artifacts, Thin Skills: Thariq’s Claude Code Framework

On July 16, 2026, Thariq Shihipar (@trq212) — engineer on the Claude Code team at Anthropic, previously YC W20 — posted a nine-line framework that hit ~82.4K views before breakfast:

ideal prompting technique is:

• thin prompts
• thick artifacts + context
• thin skills

The tweet landed in a week already crowded with prompting discourse: Ethan Mollick’s specs-not-tricks thread, Thariq’s own map-is-not-the-territory field guide, and a long-running debate about how much instruction belongs in SKILL.md versus CLAUDE.md versus the prompt itself. This post unpacks what each layer means, why Matthew Berman pulled Garry Tan’s older “thin harness, fat skills” framing into the replies, and the good vs bad examples Thariq said he was still working on — inferred here from Anthropic’s public guidance, Thariq’s March 2026 skills essay, and patterns across explainx.ai’s agent skills corpus.

TL;DR: what people are asking

The ice-cream sandwich mental model

In the reply thread, Thariq used an ice-cream sandwich metaphor: thin cookies on top and bottom, thick filling in the middle.

The mistake most teams make is reversing it: a thick prompt (re-stating the whole PRD every session), thin context (no CLAUDE.md, no artifacts, no indexed files), and a thick skill (600 lines of generic advice that should live in references or scripts). That stack burns tokens, duplicates information, and — per Thariq’s map/territory framing — creates a map that drifts from the codebase without anyone noticing until a capable model executes the wrong assumption at scale.

Layer 1: thin prompts

A thin prompt states goal, constraints, and pointers — not a rehash of everything the project already knows.

Thariq’s public workshop pattern (Code w/ Claude Extended, May 2026) gives two modes:

1. Vague territory — use “interview me” so Claude surfaces constraints you forgot to type.
2. Known territory — one-line intent plus a pointer to an artifact or file.

Good thin prompt (known territory)

Implement the migration in specs/auth-v2.html.
Constraints: no new deps, preserve session cookies for mobile clients.
Run scripts/validate-migration.sh after edits.

Bad thick prompt (duplicates context)

We use TypeScript 5.4, React 19, pnpm, ESLint with our custom config,
tabs not spaces, always write tests, our API uses snake_case in JSON,
please migrate auth to the new schema described below [pastes 400 lines
of schema + repeats CLAUDE.md rules already in the repo]...

The bad version belongs split across CLAUDE.md (standing rules), specs/auth-v2.html (artifact), and a thin skill for migrations — not in every user message. This aligns with Skills vs Hooks vs Prompts: if it applies to every task, it is not prompt material.

Copy-paste thin prompt templates

Exploratory work:

I need [outcome]. Interview me until you have a spec worth writing to specs/[name].html.

Repeatable workflow:

/ship-feature — scope is tickets/ENG-442.md only. Stop if tests fail twice.

Verification gate (map/territory check):

Before editing: restate the plan in your own words and list assumptions about files you have not read.

Layer 2: thick artifacts + context

Thick does not mean “paste more into the prompt.” It means durable, structured objects the agent (and humans) can re-read across sessions.

What counts as thick context

Thariq has argued repeatedly that HTML beats Markdown for specs humans and agents both consume — diagrams, mockups, clickable code paths. That predates and complements Claude Code Artifacts: the artifact is the specification; the prompt just points at it.

Good thick artifact (HTML spec excerpt)

<!-- specs/checkout-redesign.html -->
<h2>Goal</h2>
<p>Single-page checkout; remove step 2 for logged-in users.</p>
<h2>Constraints</h2>
<ul>
  <li>Stripe Payment Element only — no custom card fields</li>
  <li>LCP &lt; 2.5s on 4G (see PERF.md)</li>
</ul>
<h2>Out of scope</h2>
<p>Gift cards — tracked in ENG-501</p>

Bad “artifact” (chat prose that evaporates)

A long assistant message from three sessions ago that nobody saved to a file. The next agent session cannot see it. Territory changed; map gone.

Thick artifact patterns from production Claude Code use

Thariq’s Fable launch video pipeline is the reference implementation: final-edit.json (edit decision list), Whisper transcripts, Remotion components, Figma MCP round-trips — all artifacts the orchestration prompt pointed at rather than re-described. Loop engineering extends the same idea: the loop reads durable state (git diff, CI status, artifact checksum) each tick; the prompt inside the loop stays thin.

Layer 3: thin skills

Here is where the Garry Tan reply matters. @MatthewBerman quoted Tan’s “thin harness, fat skills” line — and Thariq pushed back partially: it depends what skills do.

Thariq’s clarification in the thread:

• Scripts in skills — great. Deterministic actions belong in scripts/, not prose.
• Progressive disclosure — great. Point to references/, assets/, nested markdown.
• Most SKILL.md files are too big — the entry point should be thin.

That is not anti-skill. It is anti-encyclopedia SKILL.md. Read alongside Garry Tan’s gstack factory and his thin hardness / fat skills essay: Tan puts judgment and workflow in markdown and brittle logic in code. Thariq adds: put depth in the skill folder, not the skill front page.

How dynamic skill loading works

Per Claude Code’s progressive disclosure model:

1. Discovery scan — model sees skill name + description (~20–50 tokens each).
2. Match — task fits the description.
3. Load — full SKILL.md body enters context.
4. Deeper pull — skill points to references/api.md, scripts/lint.sh, etc.

With 20 installed skills, idle overhead is roughly 1,000 tokens of descriptions — not 20 × full skill bodies. A thick SKILL.md breaks that economics the moment it triggers.

Good vs bad skill examples (Thariq’s promised breakdown)

Thariq told @kalepail he was “Working on it!” for public good/bad pairs. Below is explainx.ai’s read consistent with Thariq’s March 2026 “Lessons from Building Claude Code: How We Use Skills” guidance and agent markdown file conventions.

Bad: bloated SKILL.md (anti-pattern)

---
name: deploy
description: Deploy the application to production
---

# Deploy Skill

## General coding principles
Always write clean code. Use meaningful variable names...
[300 lines of generic advice]

## Full AWS CLI reference
[200 lines pasted from docs]

## Our company's entire history
[stuff that belongs in Notion]

Why it fails: duplicates model priors, duplicates CLAUDE.md, front-loads tokens on every deploy match, no scripts, no progressive disclosure, description too vague to trigger reliably.

Good: thin SKILL.md + fat folder (Thariq-aligned)

---
name: deploy-staging
description: >-
  Deploy current branch to staging via scripts/deploy-staging.sh.
  Use when user says "ship to staging" or PR is labeled deploy-staging.
---

# Deploy staging

## Gotchas
- Requires AWS_PROFILE=staging — never prod
- Migrations run automatically; rollback is manual (see references/rollback.md)

## Files
- Run: `scripts/deploy-staging.sh`
- Env schema: `references/env-staging.md`
- Post-deploy checks: `scripts/smoke-staging.sh`

Folder layout:

.claude/skills/deploy-staging/
├── SKILL.md              # ~35 lines
├── scripts/
│   ├── deploy-staging.sh
│   └── smoke-staging.sh
└── references/
    ├── env-staging.md
    └── rollback.md

Why it works: thin entry, gotchas section (Thariq Tip #2), filesystem as context (Tip #3), executable scripts (Tip #8), description specific enough to trigger without under/over-firing.

Bad vs good: skill description field

When scripts in skills beat prose

This is the same thin hardness / fat judgment split Garry Tan describes — Thariq just insists the markdown entry stays thin while the folder can be fat.

Reconciling Thariq vs Garry Tan (no whiplash required)

You can run gstack-style fat workflows and Thariq-style thin SKILL.md files: each slash command skill points to references/ instead of inlining the CEO review checklist. The context / prompt / loop / harness stack still applies — this framework is where bytes live, not a replacement for loop engineering.

Practical stack for a Claude Code project

project/
├── CLAUDE.md                    # thin — standing rules only
├── specs/
│   └── feature-x.html           # thick artifact
├── .claude/skills/
│   └── feature-x/
│       ├── SKILL.md             # thin entry (~40 lines)
│       ├── scripts/
│       └── references/
└── artifacts/                   # shared HTML, JSON, diagrams

Session flow:

1. Thin prompt: Implement specs/feature-x.html. Use feature-x skill.
2. Thick context: CLAUDE.md + indexed repo + artifact HTML loaded.
3. Thin skill: triggers on description match; agent reads references/ as needed.
4. Verify: agent restates plan; hook or script validates output.

For team distribution of vetted thin skills, see explainx.ai security-first skill registry and browse installs at /skills.

What people are still arguing about

“If skills are thin, why have them at all?” Because repeatability and gotchas are territory-specific. The model will not reliably remember that staging deploys require AWS_PROFILE=staging unless it is encoded once. Thin means entry point, not useless.

“Should I delete my 500-line skills?” Audit first. Move API dumps to references/, generic advice to CLAUDE.md or delete it, keep gotchas and triggers. Matt Pocock’s v1.0 progressive disclosure cut tokens ~63% with the same refactor.

“Is CLAUDE.md a prompt or context?” Context — but it must stay thin too. If CLAUDE.md is 2,000 lines, you have a thick prompt permanently pinned to every message. Split procedures into skills; split specs into artifacts.

Update — July 16, 2026: @anthrupad's minimal-prompt probe — ask Fable for its top 3 favorite video games ten times; thick self-analysis from a thin prompt.

Update — July 25, 2026: Thariq’s follow-up — Claude 5 context engineering (80%+ system-prompt cut for Opus 5 / Fable 5, /doctor). Pairs with the Opus 5 launch.

Related reading on explainx.ai

• Thariq — Jevons paradox in mathematics (Aug 2026)
• AI burnout — focus and followthrough
• Claude 5 context engineering — Thariq /doctor (Jul 25)
• Claude Opus 5 launch
• Claude Cookbook guide — PTC, agents, HN debate (Jul 24)
• Fable/Mythos favorite video games — @anthrupad experiment
• Map is not the territory — Thariq’s Fable field guide
• Skills vs Hooks vs Prompts: when to use each
• What are agent skills? Complete guide
• Claude Code Artifacts — shareable sessions
• HTML over Markdown in Claude Code — Thariq
• Loop engineering for coding agents
• Garry Tan gstack skills factory
• Agent markdown files — SKILL.md, CLAUDE.md, and more
• Context / prompt / loop / harness stack
• Ethan Mollick — specs not tricks
• Uncle Bob's AI coding gauntlet: tests, not reviews

Official: Anthropic Claude Code docs · Thariq on X

This post analyzes Thariq’s July 16, 2026 framework tweet and public thread replies (~82.4K views at time of writing). Skill loading behavior, Artifacts availability, and model defaults change frequently — verify against your Claude Code version and project settings before treating any example as permanent.