Thin Prompts, Thick Artifacts, Thin Skills: Thariq’s Claude Code Framework
Claude Code engineer Thariq (@trq212) posted the ideal prompting stack: thin prompts, thick artifacts + context, thin skills. Good vs bad examples, progressive disclosure, and how it differs from Garry Tan’s thin harness.
Claude CodeAgent SkillsPrompt EngineeringThariq ShihiparArtifacts
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.
Claude Code engineer at Anthropic; built the Fable launch video pipeline, HTML-over-Markdown advocacy, and the “map is not the territory” field guide.
How is this different from Garry Tan?
Tan splits code vs markdown (thin hardness, fat skills). Thariq splits entry point vs depth — skills should be thin at the SKILL.md layer even when the skill folder is fat with scripts and references.
What loads by default in skills?
Name + when-to-fire description (~tens of tokens per skill). Full SKILL.md body loads only on match via progressive disclosure.
What counts as a thick artifact?
HTML specs, JSON EDLs, diagrams, test matrices, shareable Claude Code Artifacts — durable objects, not chat prose. Jul 16, 2026: artifacts can also pull live MCP data on every view — artifact MCP connectors.
What did Thariq promise next?
Good vs bad skill examples — covered in the sections below with copy-paste patterns.
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.
Layer
Role
Thin or thick?
Top cookie — prompt
States what you want done now
Thin
Filling — artifacts + context
Carries the actual specification, history, and constraints
Thick
Bottom cookie — skill
Tells the agent when to pull a playbook and where deeper files live
Thin
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:
Vague territory — use “interview me” so Claude surfaces constraints you forgot to type.
Known territory — one-line intent plus a pointer to an artifact or file.
Good thin prompt (known territory)
text
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)
text
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:
text
I need [outcome]. Interview me until you have a spec worth writing to specs/[name].html.
Repeatable workflow:
text
/ship-feature — scope is tickets/ENG-442.md only. Stop if tests fail twice.
Verification gate (map/territory check):
text
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
Source
What it carries
Token behavior
CLAUDE.md
Standing project rules, stack, conventions
Always-on — keep lean
Indexed codebase
Real territory — types, tests, configs
Retrieved on demand
MCP tools
Live APIs, Figma, databases
Tool schemas + results
Session history
Decisions, failed attempts, tradeoffs
Compacts over time
Artifacts
HTML specs, dashboards, diagrams
Persistent, shareable
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)
html
<!-- 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 < 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.
Discovery scan — model sees skill name + description (~20–50 tokens each).
Match — task fits the description.
Load — full SKILL.md body enters context.
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)
markdown
---
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)
markdown
---
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`
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
Bad description
Good description
Text
Helps with code
Run scripts/review-pr.sh when user asks for PR review before merge
Trigger
Never fires or fires on everything
Fires on /review, “review my PR”, merge requests
Token cost
Wastes scan slots
~30 tokens, high precision
When scripts in skills beat prose
Task
Put in SKILL.md prose?
Put in scripts/?
“Run eslint with our config”
No
Yes — scripts/lint.sh
“Why we avoid nested ternaries here”
Yes — 3 lines in gotchas
No
“Call Twilio with retry logic”
No
Yes — deterministic
“When to escalate to human”
Yes — judgment
No
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)
Specs live in artifacts; depth lives in skill directories and code
You can run gstack-style fat workflowsand 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.
“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.
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.
