DEV Community: PromptMaster

What to Put in Your CLAUDE.md (and What to Leave Out)

PromptMaster — Sun, 21 Jun 2026 09:37:47 +0000

A great CLAUDE.md is not the longest one. It is the one where every line changes what Claude does. The whole skill is knowing what belongs in it — and, just as importantly, what does not.

The sections that earn their place

Start with a one or two line project description and your stack, with version numbers. Claude infers a lot from your code, but it will not guess that you are on Next.js 15 instead of 14, or which ORM you chose.

Then a directory map — not every file, just the top-level layout with a note on what each part holds. After that: the build and test commands, the conventions a formatter does not enforce, and critically, the things not to touch.

# Project: Acme Dashboard
Next.js 15 (App Router), TypeScript, Drizzle ORM, Vitest.

## Structure
src/app/        # routes and pages
src/lib/        # shared utilities, db client
db/migrations/  # generated - never hand-edit

## Commands
Build:  npm run build
Test:   npm run test

## Conventions
- API routes return { data, error } - never throw to client
- Server components by default

## Do not touch
- db/migrations/ is generated. Never edit by hand.

Every line in that file would cause a mistake if removed. That is the bar.

What to leave out

This is where most files go wrong. Two kinds of content waste your budget:

Personality instructions. "Act as a senior engineer," "think step by step," "be thorough." These feel productive but change nothing — Claude already does them. General advice that does not prevent a specific mistake is pure noise.

Rules a tool already enforces. If you have a formatter or linter, do not restate what it enforces. Wire it into a hook instead, and keep CLAUDE.md for what tools cannot enforce.

The one-line test

For every line, ask: "If I remove this, will Claude make a mistake?" If yes, keep it. If no, delete it.

This single question, applied ruthlessly, is the difference between a file Claude follows and one it ignores. A bloated file buries the rules that matter in noise, so Claude cannot tell which line is the important one. Pruning is not tidying — it is what makes the file work.

Why brevity is performance

CLAUDE.md loads into Claude's context every session, and performance degrades as context fills. A leaner file is not just easier to read — it makes Claude more reliable, because the rules that matter are not competing with filler for attention. Short is not a style choice here. It is a performance requirement.

Free starter: The format, a complete annotated example, and the one-line test are all on a free cheat sheet: CLAUDE.md Quick-Start Cheat Sheet

Go deeper: The full guide covers the entire configuration stack — hooks, subagents, commands, skills and plugins — with real-world walkthroughs and a 30-day plan: CLAUDE.md: The Complete Claude Code Configuration Guide

What is the one rule in your CLAUDE.md that has saved you the most? Share it in the comments.

What Is CLAUDE.md? A Practical Guide to Configuring Claude Code

PromptMaster — Sun, 21 Jun 2026 09:36:53 +0000

If you use Claude Code, there is one file that quietly shapes every session: CLAUDE.md. Most developers either do not have one or have one that works against them. Here is what it actually is, in plain terms.

The file Claude reads every session

CLAUDE.md is a markdown file that Claude Code reads at the start of every conversation. Think of it as your project's constitution — the source of truth for how your specific repository works. Because Claude reads it every time, you stop re-explaining your stack, your conventions, and your commands on every task.

Why it exists

Without a CLAUDE.md, every session starts cold. Claude can read your code, but it cannot infer the things that live outside the code: that you are on Next.js 15 and not 14, that a directory is generated and must never be edited, that your team has a particular commit style. You end up explaining these again and again, slightly differently each time, so the output drifts. CLAUDE.md captures that knowledge once, somewhere Claude always sees it.

Where it lives, and how to start

Put CLAUDE.md in the root of your project. You do not have to write it from a blank page — the /init command analyses your codebase and generates a starter, detecting your build tools, test framework, and existing patterns:

$ claude
> /init

Treat the result as a foundation, not a finished product. The real value comes from refining it as you learn what Claude gets wrong without guidance.

What belongs in it

A good CLAUDE.md is short and specific:

A one-line stack description, with versions — Claude will not guess Next.js 15 over 14
A directory map — the top-level layout and what each part holds
The build and test commands
The conventions a newcomer could not infer from the code
A "do not touch" section — generated files, migrations, protected paths

Here is a compact example:

# Project: Acme Dashboard
Next.js 15 (App Router), TypeScript, Drizzle ORM, Vitest.

## Structure
src/app/        # routes and pages
db/migrations/  # generated - never hand-edit

## Commands
Build:  npm run build
Test:   npm run test

## Do not touch
db/migrations/ is generated. Never edit by hand.

Why it is the highest-leverage file

Because CLAUDE.md loads on every single session, its quality compounds. A precise file pays off thousands of times over a project's life — every task starts from a correct understanding. A bloated one taxes every interaction. Few files in your repo have this much leverage, which is why it is worth getting right before anything else.

The bottom line

CLAUDE.md is a small, durable investment: write your project's real context once, keep it lean, and every session starts from a correct picture. It is also the foundation the rest of Claude Code's configuration — commands, hooks, subagents, skills — builds on.

Free starter: The format, a complete annotated example, and the one-line test are all on a free cheat sheet: CLAUDE.md Quick-Start Cheat Sheet

What does your CLAUDE.md look like right now — lean and sharp, or a bit of a dumping ground? Curious to hear in the comments.

The Claude Code Configuration Stack: Beyond CLAUDE.md

PromptMaster — Sun, 21 Jun 2026 09:35:43 +0000

Most people use Claude Code like a smarter autocomplete. But it is a fully programmable system, with a stack of configuration mechanisms that each solve a different problem. Knowing which to reach for is what separates chatting with the tool from engineering it.

CLAUDE.md — persistent context

The foundation. Read every session, it holds what is always true about your project: the stack, the conventions, what not to touch. Get this right first; everything else builds on it.

Slash commands — reusable actions

A prompt template you invoke by name. Anything you type repeatedly — a review checklist, a commit format — becomes a command you trigger with a slash. The easiest mechanism to create, and immediately useful.

# .claude/commands/review.md
Review the staged changes for correctness, security,
style and test coverage. Report findings by severity.

Subagents — delegated work

A separate Claude instance with its own context window. When a task needs heavy exploration — "go read the codebase and tell me how auth works" — a subagent does the reading in its own context and returns just the answer, keeping your main session clean.

Hooks — deterministic enforcement

An event-driven script that runs real code. Where CLAUDE.md asks Claude to follow a rule, a hook enforces it at the system level — blocking a dangerous command, running a formatter after every edit. For anything that must never go wrong, a hook is a guarantee, not a request.

Skills and plugins

Skills hold on-demand capability that loads only when relevant, keeping CLAUDE.md lean. Plugins bundle commands, subagents, hooks and skills into a single versioned unit you can share across a team. Together they let a configuration scale from a solo project to an organisation.

Which tool, when

The framework is simple:

CLAUDE.md — for what is always true
Slash command — for what you repeat
Skill — for what loads on demand
Subagent — for what should stay out of your context
Hook — for what must be enforced
Plugin — to package and share it all

When you are unsure, ask what kind of thing you are dealing with — persistent context, a repeated action, an enforced rule, delegated work — and the right tool follows from the question.

The bottom line

You do not need all of this on day one. Start with CLAUDE.md, add commands and skills as you notice repetition, reach for hooks when you need enforcement, and package it into a plugin only once it is worth sharing. The teams getting the most from Claude Code treat it as a programmable platform — and they got there one layer at a time.

Free starter: The format, a complete annotated example, and the one-line test are all on a free cheat sheet: CLAUDE.md Quick-Start Cheat Sheet

Which part of the stack have you actually used so far — just CLAUDE.md, or have you got into hooks and subagents? Curious where people are.

Why Claude Code Ignores Your CLAUDE.md (And How to Fix It)

PromptMaster — Sun, 21 Jun 2026 09:34:49 +0000

You wrote a detailed CLAUDE.md, and Claude Code still gets things wrong — wrong convention, touches files it should not, ignores rules you clearly wrote down. The cause is almost never that the rules are missing. It is that they are buried.

The over-specified file problem

CLAUDE.md loads into Claude's context every single session, and performance degrades as that context fills. When the file grows too long, something counterintuitive happens: Claude starts ignoring parts of it. The important rules get lost in the noise, and the genuinely critical instructions sit too deep to reliably influence output.

A bloated file does not just waste tokens. It actively makes Claude less reliable, because it cannot tell which of your hundred lines is the one that matters.

The trap of good intentions

It always starts reasonably: "let me put everything relevant in here." But relevant is a low bar. The file grows until it is impossible to scan, full of duplication, and so noisy that the truly important rules carry no weight. More content felt like more control. It was the opposite.

The fix: prune ruthlessly

Run every line through one question: "If I remove this, will Claude make a mistake?" If the answer is no, the line is noise — delete it.

And if something only matters in a specific situation rather than always, it does not belong in the always-loaded file at all. That is what skills and subdirectory CLAUDE.md files are for — they load on demand, only when relevant.

Let Claude fetch what it needs

Instead of embedding everything, tell Claude how to pull context when it needs it. Rather than pasting an entire API guide into the file:

# Wasteful - embeds the whole file every session:
@docs/api-guide.md

# Better - Claude reads it only when relevant:
For Stripe integration work, read docs/stripe-guide.md

The second form costs almost nothing until the moment it is needed.

The result

A pruned CLAUDE.md is often a third of the length and many times more effective. The rules that matter are no longer competing with noise, so Claude actually follows them. If your CLAUDE.md is being ignored, the fix is almost never to add emphasis — it is to cut until only what matters remains.

Free starter: The format, a complete annotated example, and the one-line test are all on a free cheat sheet: CLAUDE.md Quick-Start Cheat Sheet

Have you hit the point where Claude started ignoring your CLAUDE.md? How long had it gotten? Curious to compare notes below.

Why Most Custom AI Skills Never Run (And the One Fix)

PromptMaster — Sat, 20 Jun 2026 07:59:42 +0000

There is a quiet failure mode with AI agent skills that almost everyone hits: you build a custom skill, it looks perfect, and it simply never runs. No error, no warning. It just sits there unused. The reason is remarkably consistent, and so is the fix.

The failure is silent

Unlike a bug that throws an error, a skill that never triggers gives you nothing to debug. You ask for the thing the skill was built for, the agent does something reasonable without it, and you never realize the skill was skipped. That silence is what makes this so common — people do not even know it is happening.

The cause is almost always the description

An agent chooses which skills to use by reading their descriptions and matching them against your request. If the description does not match how you phrased things, the skill is skipped. And most descriptions are written too narrowly — as a label for the task rather than a map of how people ask for it.

"Reviews pull requests" is a label. But you do not always say "pull request." You say "check this," "look this over," "audit my code." None of those match, so the skill never fires.

The one fix

Write the description around the language you actually use, and list the synonyms:

description: Reviews code for bugs, style and security. Use when
  the user asks to review, check, audit or look over code, a pull
  request, a diff, or a specific file.

This matches nearly any natural phrasing of the request. It is the single highest-leverage change you can make to a skill, and it fixes the large majority of "my skill does not work" cases.

How to confirm it is fixed

Test the way you actually talk. Phrase a few casual, natural requests — the way you would on a busy afternoon — and watch whether the skill loads. If a reasonable request misses, add those exact words to the description and try again. A couple of rounds and it fires every time.

Prevent it from the start

The habit that prevents the silent failure entirely: write the description first, before the body, around real phrasing. It forces you to think about when the skill should fire before you think about what it does. Get the trigger right, and all the careful work inside the skill finally gets used.

The bottom line

Most custom skills do not fail because they are badly written. They fail because they are never triggered, and that comes down to one field. Write descriptions around how you actually ask, test with natural phrasing, and your skills stop gathering dust.

Free starter: The format, a working template, and the description technique are all on a free cheat sheet: AI Agent Skills Quick-Start Cheat Sheet

Go deeper: The full guide covers the complete specification, five build walkthroughs, ten production-ready templates, security, and a 30-day plan: AI Agent Skills: The Complete SKILL.md Standard Guide

What is your experience — have your custom skills been firing reliably, or silently sitting unused? Curious to compare notes below.

What Is SKILL.md? A Practical Guide to AI Agent Skills

PromptMaster — Sat, 20 Jun 2026 07:58:46 +0000

If you work with AI coding agents, you have probably seen SKILL.md mentioned and wondered what it actually is. In a matter of months it went from one company's feature to a standard adopted across Claude Code, Cursor, Codex CLI, Gemini CLI and more. Here is the plain explanation, with no hype.

What a skill actually is

A skill is a folder containing a SKILL.md file that teaches an AI agent to do a specific task well. Instead of re-explaining your conventions, your workflow, or your standards every single session, you write them down once. The agent reads them automatically whenever they are relevant.

Think of it as the onboarding note you would give a capable colleague taking over a task — except you write it once, and every agent that supports the standard reads it.

Why it caught on

Before skills, every agent started from zero each session. You re-explained your code review standards, your documentation style, the quirks of your project — over and over. A skill captures that knowledge permanently. And because SKILL.md is a shared format, the same skill works across every agent that supports it. Write once, use everywhere. That combination — solving a real shared problem, simply — is why it spread so fast.

The anatomy of a SKILL.md

Every SKILL.md has two parts.

The frontmatter is YAML metadata between two lines of three dashes. It has two required fields: a name (short, lowercase, hyphenated) and a description (what the skill does and, crucially, when to use it).

The body is plain markdown — the actual instructions. The steps, the order, the conventions, the things to check.

The frontmatter tells the agent when to use the skill. The body tells it how.

The three types of skill

Skills range from simple to powerful:

Markdown-only skills are pure instructions — conventions and checklists, no code. This is where most people start, and it already covers a huge range of useful tasks.
Skills with scripts add shell or Python the agent can run, for tasks that need real execution rather than guidance.
API-calling skills reach external services — fetching data, posting updates, integrating tools into the workflow.

You do not need to start complex. A markdown-only skill that encodes how you like code reviewed, or commits written, or docs formatted, is genuinely useful on day one.

The field that decides everything

Of the two required fields, the description matters far more than people expect. The agent decides whether to load a skill by reading its description and matching it against what you asked. Write the description too narrowly and the skill never fires — no matter how good the instructions inside are.

The fix is to write the description around the words you would actually type, including the synonyms. Not "Reviews pull requests" but "Reviews code for bugs, style and security. Use when the user asks to review, check, audit or look over code, a pull request, a diff or a file." That one habit prevents most "my skill does not work" problems.

The bottom line

A skill is a small, durable investment: a markdown file that teaches your agent something, once, and applies it consistently across every agent you use. Start with whatever you explain most often, get the description right, and you will wonder how you worked without it.

Free starter: The format, a working template, and the description technique are all on a free cheat sheet: AI Agent Skills Quick-Start Cheat Sheet

What is the first skill you would write — the thing you explain to your AI most often? Curious to hear in the comments.

How to Write a SKILL.md That Actually Triggers

PromptMaster — Sat, 20 Jun 2026 07:57:57 +0000

You wrote a skill. The instructions are clear, the logic is sound, and your AI agent never uses it. This is the most common frustration with AI agent skills, and the cause is almost never the body of the skill. It is the description.

How an agent decides to use a skill

When you make a request, the agent scans the descriptions of your installed skills and compares them to what you asked. If a description matches closely enough, it loads that skill. If nothing matches, it proceeds without one — even a great skill sitting right there.

The description is the entire matching mechanism. Everything else in the skill is the work it does; the description decides whether that work ever happens.

The usual culprit: too narrow

Most skills that never fire have a description that is too specific. "Reviews pull requests" only matches if you literally mention a pull request. Ask the agent to "check this file" or "look over my code" and it misses, because those exact words are not in the description. The skill works fine. You just never trigger it.

The fix: describe how you actually ask

Rewrite the description around the words you would naturally type, and list the synonyms.

Weak:

description: Reviews pull requests.

Strong:

description: Reviews code for bugs, style and security. Use when
  the user asks to review, check, audit or look over code, a pull
  request, a diff, or a specific file.

The strong version matches almost any natural phrasing. That is the whole technique.

A checklist for every description

Before you consider a skill finished, run its description through five questions:

Does it name the task in plain language a user would actually use?
Does it list the synonyms — the different ways you might ask?
Does it say when to use the skill, not just what it does?
Would it match a casual request, not only the formal phrasing?
Is it specific enough not to fire on unrelated requests?

Five comfortable answers means the skill will trigger when you need it.

Test it like a user

After writing a description, test it the way you actually talk on a busy day — not the careful phrasing you would use if you were trying to make it work. Phrase a few natural requests and watch whether the skill fires. If a reasonable request misses, add those words to the description and try again. Two or three rounds and it triggers reliably.

Write the description first

The habit that prevents all of this: write the description before the body. It forces you to think about when the skill should fire before you think about what it should do. Get that right, and the careful instructions you write actually get used.

Free starter: The format, a working template, and the description technique are all on a free cheat sheet: AI Agent Skills Quick-Start Cheat Sheet

Have you had a skill that quietly never fired? What was the description? Happy to help debug it in the comments.

Building Your First AI Agent Skill: From Markdown to APIs

PromptMaster — Sat, 20 Jun 2026 07:57:07 +0000

AI agent skills are easier to build than they look, and they scale from a simple markdown file to something that runs scripts and calls APIs. Here is a practical walkthrough of the whole spectrum, starting from the simplest useful skill.

Start simple: a markdown-only skill

The simplest skill is a folder with a single SKILL.md inside. No code. Just frontmatter and instructions.

code-reviewer/
  SKILL.md

The SKILL.md has frontmatter (a name and a description) and a markdown body with the instructions. For a code reviewer, the body might be an ordered checklist: check correctness first, then security, then style, then tests, and report findings grouped by severity with the file and line cited.

That is a complete, useful skill. Most of the value in skills lives at exactly this level — encoding the conventions you would otherwise repeat every session.

Level up: a skill with scripts

When a task needs real execution rather than guidance, add scripts to the folder:

code-reviewer/
  SKILL.md
  scripts/
    check.py

The SKILL.md instructs the agent to run the script as part of the task. Now the skill does not just advise — it acts. This is the step from a skill that tells the agent how to think to one that performs a concrete operation.

Go further: an API-calling skill

The most capable skills reach external services — fetching data, posting updates, integrating a tool into the agent's workflow. Structurally it is still a SKILL.md plus the code to make the calls, but now the skill connects your agent to the outside world.

A useful safety note: skills that run commands or call APIs are exactly where you want to be deliberate about scope. Restrict what the skill can touch, review what it does, and treat third-party skills with the same caution you would any code you run.

The three steps that never change

Regardless of complexity, building a skill is always the same three steps:

Create the folder with a SKILL.md inside.
Write the frontmatter — name and description. Invest in the description; it decides whether the skill ever fires.
Write the body — the instructions, and references to any scripts.

Then test it by phrasing real requests and confirming it triggers. Widen the description wherever a natural request misses.

Where the value compounds

Your first skill is one capability. A library of them — markdown skills for conventions, script skills for operations, API skills for integrations — quietly upgrades every agent you use. Start with a markdown-only skill today, and add complexity only when a task actually needs it.

Free starter: The format, a working template, and the description technique are all on a free cheat sheet: AI Agent Skills Quick-Start Cheat Sheet

What would your first script-backed skill do? Drop the idea in the comments and I will suggest how to structure it.

The SCAMP Framework for Cinematic AI Video

PromptMaster — Sat, 20 Jun 2026 07:28:50 +0000

The people getting cinematic results from Seedance 2.0 are not better writers. They are more specific.

Cinematic output comes from a structured prompt, and that structure is learnable. Here's the framework.

The five-part structure: SCAMP

Every cinematic prompt answers five questions. Think of it as SCAMP:

S — Subject
C — Camera
A — Atmosphere
M — Mood
P — Palette

Address all five and Seedance has a complete creative brief to work from, instead of blanks to fill in with averages.

Subject: be specific and visual

Not "a person" but "a weathered fisherman in a yellow raincoat." The more precisely you define the subject, the less the model has to guess, and the closer the output lands to what you imagined. Specific, visual nouns and adjectives do the heavy lifting here.

Camera: the element most people skip

This is what separates amateur prompts from cinematic ones. Specify the shot size and the movement:

close-up · wide establishing shot · slow dolly in · aerial drone · handheld tracking

Use exactly one primary camera move per prompt for predictable results — multiple conflicting moves confuse the model.

Atmosphere: set the scene's conditions

Time of day, weather, light source: golden hour, dense fog, neon-lit rain, harsh midday sun. Atmosphere is where a scene gets its sense of place and time, and it dramatically changes the emotional read of the same subject.

Mood and Palette: the emotional layer

Mood is the feeling you want the viewer to have — tense, serene, triumphant, melancholic. Palette is the colour direction — warm amber and teal, desaturated greys, vivid neon. Naming a palette is one of the fastest ways to make output look intentional rather than accidental.

See all five elements in action with 50 free cinematic prompts across 10 genres, plus the full framework explained.
Grab the free Seedance Starter Kit →

Putting it together

Here's SCAMP in a single prompt:

Subject      → a weathered fisherman in a yellow raincoat
Camera       → slow dolly in from a wide shot
Atmosphere   → storm-lashed dawn, crashing waves
Mood         → quiet defiance
Palette      → cold desaturated blues, one warm lantern glow

Assembled into one line:

A weathered fisherman in a yellow raincoat, slow dolly in from a
wide shot, at storm-lashed dawn with crashing waves, a mood of
quiet defiance, in cold desaturated blues with one warm lantern glow.

Every element is answered, and the result is a direction, not a guess.

The fastest way to improve

Writing one good prompt teaches you the structure. Having thousands of proven ones lets you produce consistently without starting from a blank page each time.

The Seedance 2.0 Prompt Bible gives you 3,000 cinematic prompts across 30 genres, every one written with the SCAMP framework — copy, adapt, create.
Get the complete bundle →

Why Your Seedance Videos Look Generic (And How to Fix It)

PromptMaster — Fri, 19 Jun 2026 15:56:24 +0000

You type a few words into Seedance 2.0, hit generate, and get something flat, generic and forgettable. Then you see what other creators are making — cinematic, deliberate, alive — and wonder what they know that you don't.

The answer is simple, and it has nothing to do with the model.

The problem is never the tool

Seedance 2.0 is one of the most capable AI video models available. It supports multi-shot continuity, native audio, and director-level camera control. The gap between your output and a cinematic one is not the model's ceiling — it's the instruction you give it.

A vague prompt forces the model to guess, and guessing produces generic results.

What a vague prompt looks like

"A city at night."
"A person walking on a beach."
"A dragon flying."

These describe a subject and nothing else. The model has to invent the camera, the lighting, the mood, the colour and the motion — and its invention is an average of everything it has seen, which is the definition of generic.

The five things every cinematic prompt specifies

Cinematic prompts answer five questions the vague ones leave blank:

Subject — who or what, described with specific visual detail
Camera — the shot and movement; the single most skipped element
Atmosphere — time of day, weather, light source
Mood — the emotional tone
Palette — the colour direction

Miss one and the output drifts. Hit all five and the model has a complete creative direction.

The same idea, rewritten

Start with the vague version:

A detective in a city at night.

Now make it cinematic:

A detective in a trench coat walking down a rain-soaked alley at
night, neon signs reflecting in puddles, steam rising from a
manhole, slow dolly shot following from behind, film noir mood,
high contrast with deep shadows in red and blue.

Same idea — but now the model knows exactly what to build.

Want the full framework plus 50 ready-to-use cinematic prompts across 10 genres?
Grab the free Seedance Starter Kit →

Why Your Suno Tracks Sound Like AI (and How to Fix It)

PromptMaster — Wed, 17 Jun 2026 15:28:56 +0000

Suno is one of the most accessible music tools ever built. You type a description, press generate, and in under a minute you have a finished track with vocals, instrumentation, and production. The barrier to starting is almost zero.

The barrier to getting results worth keeping is higher than most tutorials admit.

I've spent years making music with AI tools, with 50+ albums distributed to Spotify, Apple Music, and the major platforms. The difference between a track that screams "AI generated" and one that just sounds like music is not the tool — it's how many decisions you make before the tool does. Here's what actually changes that.

The core reason AI sounds like AI

When your prompt is vague, Suno fills every gap with the most statistically average choice. Vague in, average out. A track assembled from a hundred average decisions sounds exactly like what it is: a machine guessing at what you probably wanted.

AI music sounds like AI music when the tool is making all the decisions. It sounds like music when a person has made enough decisions that the tool is implementing a vision rather than inventing one from scratch.

Everything below is a way to take decisions back from the tool.

Fix 1 — Trade vagueness for specifics

"Upbeat pop song" gives Suno almost nothing, so it returns the average of a million upbeat pop songs. Name the tempo feel, the instrumentation, the era, the energy, the vocal character. The more specific you are, the less Suno has to guess, and the more the result reflects an actual intention instead of a default.

This is the single highest-leverage change most people can make, and it costs nothing but a few more words.

Fix 2 — Direct the structure, don't let it be invented

A track that wanders is a track where Suno decided the arrangement for you. You can take that back with structural tags in the lyrics field — telling it explicitly where the intro, verses, chorus, instrumental breaks, and outro go.

The moment you specify structure, Suno stops guessing the shape of the song and starts executing yours. The same prompt with a directed structure and without it can sound like two different acts of work — because it is.

Fix 3 — Work in genres you actually know

Here's the principle that matters most, and it's the one tool-focused tutorials never mention: AI democratized generation, but it did not democratize judgement.

Anyone can generate a track. Only someone who knows a genre can tell whether the result is good, hear what's wrong, and know what to change. If you love and understand tech house, your ear catches the things that make a tech house track land or fall flat — and you can direct Suno toward the first. In a genre you don't know, you're as lost as the machine.

Your musical taste is not a nice-to-have here. It's the entire edge.

Fix 4 — Iterate with intent, not luck

Generating ten versions and keeping your favorite is gambling. Generating a version, identifying the one specific thing that's wrong, and changing the prompt to address it — that's producing.

Each iteration should be a decision: the vocals are too far forward, the energy drops in the second half, the intro is too long. Name the problem, adjust, regenerate. That's the loop that turns a promising generation into a finished track.

The pattern underneath all four

Notice that every fix is the same move: take a decision away from the tool and make it yourself. Specifics, structure, genre judgement, intentional iteration — they're four faces of one principle. The people whose AI music sounds like music aren't using a secret model. They're directing, where everyone else is generating.

And the best part: the more you do it, the more it becomes instinct. You stop thinking about it as "prompting an AI" and start thinking about it as making a track, with a very fast collaborator who happens to have no taste of its own. The taste is your job. That's good news — it means the thing that makes your tracks yours can't be automated away.

Free: I put the practical core of this — the prompt anatomy, the metatag tricks for structure, and 5 tested genre recipes — into a free Prompt Starter Kit. It's the fastest way to start directing instead of generating: The Suno Prompt Starter Kit

What genre do you work in, and does your Suno output sound like you yet? Curious where people are getting stuck.

Suno Metatags: The Structure Tricks Most People Never Find

PromptMaster — Wed, 17 Jun 2026 15:27:05 +0000

Most people use Suno's lyrics field for one thing: lyrics. That's the biggest missed opportunity in the whole tool.

That field is also where you direct the structure of a track — and structure is what separates a song that's been arranged from a loop that just keeps going. After 50+ released albums, structural metatags are the single trick I'd hand a beginner first, because they change results immediately and almost nobody discovers them on their own.

What metatags actually are

Metatags are structural markers you place in the lyrics field, in square brackets, to tell Suno what part of the song is happening. [Intro], [Verse], [Chorus], [Bridge], [Outro] — they're an architectural map. Without them, Suno decides the arrangement for you, and "decides" usually means "averages." With them, it executes the shape you laid out.

You're not writing more; you're directing more.

The two tags that punch above their weight

A few structural tags do a disproportionate amount of work.

[Instrumental] gives the track room to breathe. Drop it between two chorus sections and you get a real instrumental break — space, dynamics, a moment that isn't wall-to-wall vocals. It's the difference between a track that feels arranged and one that feels crammed.

[Choir] layers texture onto a hook. Used on the main hook, it adds a sense of scale and lift that a single vocal line can't reach on its own. It's a small tag with an outsized effect on how produced a track feels.

These two are the ones people light up about once they try them, because the improvement is instant and obvious.

A worked example

For an electronic track, a structured lyrics field might look like this:

[Intro]
[Verse]
Short repeating lyric or hook
[Chorus]
[Choir]
Main hook
[Instrumental]
[Verse]
[Chorus]
[Choir]
[Outro]

Read what that map does. The intro establishes the sound before any vocal enters. The choir layers texture on the hook. The instrumental gives the track space between the two chorus sections. The outro resolves cleanly instead of fading on a guess. The result is a track that's been directed, not just generated.

Why this works at all

The reason structural tags improve results is the same reason specific prompts beat vague ones: they give Suno less to decide and more to execute.

When the arrangement is vague, Suno fills it with average decisions — the most statistically likely option at every fork. When you specify the structure explicitly, Suno executes your structure, and the output reflects choices instead of defaults. The tags are how you move a track from "the machine's best guess" to "the thing I actually meant."

Start simple

You don't need an elaborate map. Even just [Intro], [Verse], [Chorus], [Outro] on a track that previously had no structure will sound noticeably more intentional. Add [Instrumental] for breathing room and [Choir] on the hook, and you've got most of the benefit with five tags. Build from there as your ear tells you what the track is missing.

That's the heart of it: the lyrics field isn't a place to type words and hope. It's a console for directing the architecture of the song — and once you use it that way, your tracks stop sounding generated and start sounding arranged.

Free: The complete metatag reference — all the structural tags explained, plus the 6-part prompt anatomy and 5 full genre recipes — is in my free Prompt Starter Kit: The Suno Prompt Starter Kit

What's the first structural tag you'd add to a track that currently just loops? For me it's almost always [Instrumental].