Claude Code Skills Worth Trying: From Vague Idea to Finished Feature

I’ve tried out a lot of Claude Code skills, and a few of them are especially useful when you combine them into a workflow.

Not because they magically make the model better at coding, but because they help with the annoying parts around coding: figuring out what you actually want, avoiding unnecessary complexity, keeping a design consistent, and remembering where you left off.

So instead of just listing the skills, I wanted to put together a practical example.

Imagine we’re adding AI-generated collections to a bookmark manager. The user pastes a link, the app figures out where it belongs, and maybe creates a collection if there isn’t a good one already.

Simple idea. Plenty of decisions hiding underneath it.

We’ll use a few skills to work through those decisions, build the feature, and make it easier to come back to later.

You’ll need Claude Code and the skills you want to use installed. Each repository has its own installation instructions, so follow those rather than assuming they all use the same setup.

The skills covered here are:

• Matt Pocock’s skills for grilling, domain modeling, and handoffs.
• Ponytail for keeping implementations simple.
• UI/UX Pro Max for design guidance and a persistent design system.
• Hallmark for more distinctive interface structure.
• i-have-adhd for making the current task and next action easier to follow.
• Caveman for more concise working conversations.

You don’t need all of them. The point is to give each one a specific job.

1. Figure out what you actually want with grill-me

The first thing I’d do is not ask Claude to implement the feature.

“Add AI-generated collections” sounds specific enough until you start thinking about what should happen when the AI isn’t sure, when a collection already exists, or when the user has manually organized something.

That’s where grill-me comes in.

It uses the underlying grilling skill to turn the discussion into a decision tree. Instead of asking a giant list of unrelated questions, it asks the questions that can be answered now, then uses those answers to determine what needs to be asked next.

Start with something like:

/grill-me

I want to add AI-generated collections to my bookmark manager.

The user should be able to paste a URL and have the app suggest
or choose an appropriate collection.

Help me work out the behavior before we implement anything.
Inspect the existing codebase for facts you can determine yourself.
Ask me about product decisions, not things you can find in the code.

The important part is that Claude should inspect the project rather than making you explain every existing function.

It might discover that collections already have a creation function, that bookmarks can belong to multiple collections, or that there’s an existing metadata-fetching pipeline.

Those are facts about the codebase.

The questions for you are things like:

• Should the AI apply suggestions automatically or ask first?
• Should it prefer existing collections?
• Is it allowed to create new collections?
• Should it ever reorganize bookmarks the user already sorted?

Those are product decisions.

Let the questions happen in rounds

Suppose you decide that the AI should prefer existing collections and only create a new one when there isn’t a reasonable match.

Now there’s a new question: what counts as a reasonable match?

Maybe you want a confidence threshold. Maybe you’d rather have the AI suggest a new collection and let you approve it. Maybe the user should be able to turn automatic creation off entirely.

The grilling workflow is useful because those questions depend on the earlier decision. There’s no reason to spend ten minutes discussing deletion behavior for automatically created collections before deciding whether automatic creation is even allowed.

Keep going until the important branches are resolved.

For a tiny utility, this may be more process than you need. For a feature with several possible behaviors, it can save a lot of “well, that’s not what I meant” halfway through implementation.

2. Preserve the important decisions with grill-with-docs

If the feature is going to be more than a quick experiment, I’d use grill-with-docs instead of a plain grilling session.

This combines the structured interview with domain-modeling, so the important terminology and decisions don’t just disappear into chat history.

For example:

/grill-with-docs

Help me define the AI collection feature for this bookmark manager.

Inspect the existing code and documentation first.
Clarify the important domain concepts and behavior.
Keep the documentation focused on decisions and terminology
that will matter when I return to this project later.

One thing I like about the domain-modeling approach is that it challenges vague terminology.

For example, what does “collection” actually mean in this app?

Is it a folder for bookmarks? A tag-like grouping? Can a bookmark belong to more than one? Is an AI-generated collection different from a manually created one, or is the only difference how it was created?

Those distinctions matter because they affect the data model and the behavior.

The skill can maintain a CONTEXT.md glossary for domain terminology. That file is meant to explain what things mean, not become a giant implementation spec.

It can also create ADRs, or architecture decision records, for decisions that are genuinely worth preserving.

For example, if you decide:

AI suggestions never modify manually organized bookmarks without approval.

That might be worth documenting if it affects several parts of the system and would be surprising to someone reading the code later.

The distinction is useful:

Glossary: What does “collection” mean?

ADR: Why did we decide AI should not reorganize manually sorted bookmarks automatically?

Not every little choice needs an ADR. The idea is to preserve the reasoning that would otherwise be easy to lose.

3. Ask Ponytail to find the smallest implementation

Now that the behavior is clearer, it’s tempting to tell Claude to build the whole thing.

Before doing that, I’d bring in Ponytail.

Its general philosophy is to think like the laziest competent senior developer.

Not lazy as in “do a shitty job.” Lazy as in:

Why are we creating six abstractions and a new service when the project already has most of what we need?

Ask it to review the plan first:

Use Ponytail to review the implementation plan for this feature.

Look for existing code, platform features, or dependencies we can reuse.
Identify unnecessary abstractions or infrastructure.
Recommend the smallest implementation that satisfies the requirements.

Do not simplify away validation, security, error handling, or
the behavior we agreed on.

For our bookmark manager, maybe the app already has:

• A URL metadata fetcher.
• A collection creation function.
• A bookmark-to-collection relationship.
• An existing AI provider abstraction.

If so, we probably don’t need a separate “AI Collection Orchestration Service” with its own plugin architecture and twelve interfaces.

Maybe we just need to add a classification step to the existing save flow.

That’s the kind of simplification I want.

Use the review skills after implementation

Ponytail also includes related skills such as ponytail-review, ponytail-audit, and ponytail-debt.

After implementing the feature, I’d use the review to look for unnecessary complexity in the diff:

Use ponytail-review on the changes for the AI collection feature.

Look for unnecessary abstractions, duplicated logic, and code
that could be replaced with existing project functionality.

Preserve the agreed behavior and correctness requirements.

The debt skill is interesting for deliberate shortcuts.

Maybe we decide that a simple classification call is enough for now, but we know we might need a more sophisticated system if the library grows to tens of thousands of bookmarks.

That doesn’t mean we need to build the sophisticated system today. It means we can record why the simple approach was chosen and what would make us revisit it.

4. Establish the design direction with UI/UX Pro Max

Once the behavior is settled, I’d work on the interface.

UI/UX Pro Max gives Claude a searchable design knowledge base covering styles, palettes, typography, UX guidance, chart choices, and stack-specific implementation recommendations.

For our example, I’d ask it to establish the design direction before touching the UI:

Use ui-ux-pro-max to establish a design direction for
the AI collection feature in this bookmark manager.

The app uses React and Tailwind and supports dark mode.

I want the feature to feel like a natural part of the existing app,
not a separate AI dashboard.

Recommend the interaction pattern, typography, colors, spacing,
and component guidance. Do not implement anything yet.

The part I find especially useful is the ability to persist a design system.

UI/UX Pro Max can generate a project-level MASTER.md containing the overall design direction, with page-specific overrides where needed.

That gives Claude something to refer back to instead of reinventing the visual style every time you work on another page.

For example, the bookmark manager’s main page, settings page, and collection editor should all feel like the same product.

The goal is to avoid the classic AI frontend situation where one page looks great and the next looks like it came from a completely different app.

5. Use Hallmark for the page structure

This is where I’d bring in Hallmark.

Hallmark focuses on structural variety, not just changing colors and fonts. Its goal is to avoid the same generic AI-generated page composition being reused for everything.

It has workflows for building, auditing, redesigning, and studying designs.

For our bookmark manager, I’d give it a different job from UI/UX Pro Max:

Use Hallmark to design the AI collection interaction using
the design direction we just established.

Keep the agreed palette and typography.

Focus on a clear, distinctive layout and interaction flow
that fits the existing bookmark manager.

Do not replace the design system with a different theme.
Do not redesign unrelated parts of the app.

UI/UX Pro Max establishes the practical design foundation.

Hallmark works on the actual composition and structure.

We don't want both skills independently deciding what the app should look like and fighting over the design system.

Use study when you have a reference

Hallmark’s study mode is also interesting if you have a screenshot or URL of an interface you like.

You can ask it to analyze the design “DNA”: the layout structure, typography, color direction, and visual hierarchy.

For example:

Use Hallmark study mode on this screenshot.

Explain the layout structure, spacing, typography, and visual hierarchy
that make it work.

I want to use those principles for my bookmark manager,
not copy the original design.

That is a useful way to learn from a reference without just asking Claude to recreate it.

Hallmark also has a component-specific workflow, so you can ask it to improve a modal or button without turning the request into a full-page redesign.

6. Keep the working conversation manageable

At this point, the feature is being implemented, and this is where a couple of smaller skills could make the day-to-day experience nicer.

Use i-have-adhd to keep the next action obvious

i-have-adhd is an output-style skill that changes how Claude presents work.

It tries to lead with the next action, break multi-step work into smaller tasks, keep the current state visible, and suppress unrelated tangents.

For example:

/i-have-adhd

Help me finish this feature.

Show the current task, what is already complete, and the
single next action. Keep unrelated ideas in a later section.

Instead of getting a giant explanation about everything that could possibly happen next, you get something closer to:

Step 3 of 5 complete: Collection classification is implemented. Next: test what happens when the AI returns an invalid collection ID. Dependency cleanup can wait.

That’s the kind of thing I find useful when I’m bouncing between projects and need to know what to do right now.

It still allows fuller explanations when you ask for them, so it isn’t supposed to make every answer tiny at the expense of being useful.

Use Caveman when Claude gets too wordy

Caveman is for a slightly different problem: reducing unnecessary prose.

Its basic skill compresses Claude’s explanations while preserving important technical details like code, commands, error messages, exact names, numbers, and words that change the meaning of instructions.

For example:

Use Caveman lite for this implementation session.

Keep explanations concise, but preserve exact commands,
error messages, and important technical details.

So instead of an essay explaining a small React issue, you might get:

New object ref each render. Prop identity changes. Memoize stable value.

The project has different modes, including lite, full, and ultra, and can switch back to clearer prose when something is ambiguous, safety-critical, or needs a proper explanation.

It also has related skills for concise commits, reviews, memory-file compression, and token statistics.

One thing worth keeping in mind: fewer output tokens doesn’t automatically mean the same percentage reduction in total session cost. The instructions have overhead, and input and reasoning tokens still count.

The basic concise-output skill is also separate from the repo’s larger optional proxy/engine and Cloud-related tooling. I’d distinguish those before installing the whole stack.

7. Create a handoff before ending the session

Now imagine the feature is mostly done, but the integration tests are failing and you’re done for the day.

This is where Matt Pocock’s handoff skill comes in.

It creates a Markdown handoff document in the OS temporary directory so another session or agent can pick up the important context.

I’d use something like:

/handoff

The AI collection feature is mostly implemented.

Preserve:
- The current task and completed work.
- The decisions we made about collection behavior.
- The data model and why we chose it.
- The failing integration tests.
- The single next action.

Reference existing plans, specs, ADRs, or commits where useful
instead of copying everything into the handoff.

The idea is to preserve the important state without dumping the entire chat into the next session.

It’s context portability, not magic context-window compression.

A handoff can still lose details, so if the reasoning behind a rejected approach matters, I’d explicitly ask it to preserve that. I’d also check the file before sharing it elsewhere if the conversation contained anything sensitive.

8. Resume with handoff + i-have-adhd

handoff preserves the important context.

i-have-adhd makes that context easier to act on when you come back.

In the next session, I’d point Claude at the generated handoff file and say:

/i-have-adhd

Read the handoff file and help me resume.

Show the current state, then give me the first concrete action.
Keep unrelated ideas in a later section.

That should make it easier to reopen a project and avoid spending the first part of the session reconstructing what happened yesterday.

For someone who has several projects going at once, that sounds pretty damn useful.

The workflow, all together

Here’s the order I’d try:

Stage	Skill	Job
Clarify the idea	grill-me	Work out the behavior before coding.
Preserve decisions	grill-with-docs	Document terminology and important trade-offs.
Simplify the plan	Ponytail	Find the smallest implementation that satisfies the requirements.
Establish design	UI/UX Pro Max	Create a consistent visual and UX foundation.
Design the interface	Hallmark	Improve structure and composition without replacing the design system.
Implement	i-have-adhd / Caveman	Keep the current task clear and the conversation manageable.
Review	ponytail-review	Look for unnecessary complexity in the changes.
End the session	handoff	Preserve the important context for next time.
Resume	handoff + i-have-adhd	Reconstruct the state and identify the next action.

You don’t have to use every stage every time.

If I’m making a tiny utility, I might just use Ponytail and a concise output style.

If I’m building a feature with complicated behavior, I’d spend more time grilling and documenting the decisions.

If I’m working on a frontend, I’d use the design skills, but I wouldn’t ask both of them to independently invent the entire visual direction.

The useful part is giving each skill a clear responsibility.

A few things to keep in mind

Avoid treating the workflow as a mandatory process. The whole point is to make building things easier, not turn a small feature into a ceremony involving six agents and a stack of documents.

The combination: grilling → documentation → simple implementation → handoff.

The result is that you're getting from “I have an idea” to “I know what I’m building,” without losing the decisions or accidentally turning a small project into a giant architecture exercise.

Comments

[Reid Marlow]

Chaining handoff into an ADHD-styled task breakdown matches how context rot actually happens across sessions. If you dump raw history, the next run burns half its prompt re-evaluating decisions you already settled. Writing the current state plus the single next step into temporary storage gives the next process an entry point instead of a puzzle. Pairing that with Ponytail simplifies things earlier in the pipe, since an agent with fewer moving parts has fewer failure modes to document at the end of the day.