> ## Content Index
> Fetch the complete content index at: https://www.groktop.us/llms.txt
> Use this file to discover other available public pages before exploring further.

# I'd Rather Build Skills Than Write Prompts
- URL: https://www.groktop.us/skills-over-prompts/
- Published: 2026-11-07T14:30:58.000Z
- Updated: 2026-11-07T14:30:58.000Z
- Description: I put the effort into reusable skills so I can have natural conversations with AI. Here is what v0.9.0 adds, and how to find the skills that fit your work.
- Author: Magnus Hedemark
- Tags: AI-agents, open source

I don’t want every conversation with AI to start as a writing assignment.

Sometimes I type a few words. Sometimes I dictate a rambling explanation of what I’m trying to do, including the doubts and half-formed ideas. I want to spend my attention on the work, not on finding the perfect arrangement of words that will persuade an agent to approach it properly.

I’ve put a lot of effort into the instructions before those conversations begin. That work lives somewhere I can reuse it: my agent skills library. A skill is a reusable package that tells an agent when and how to approach a particular kind of work, with supporting material it can consult or run.

I’ve released [version 0.9.0 of that library](https://github.com/magnus919/agent-skills/releases/tag/v0.9.0?ref=groktop.us), adding 16 new skill packages and substantial improvements to the existing collection. There are tools for learning, interviews, meetings, product decisions, design, software engineering, and quite a bit more. What excites me is how those capabilities change the work I can take on.

It’s getting easier to describe what I want and have an agent bring a serious working method to the conversation.

## More than myself

I’ve led departments of more than 300 people. I know what it feels like to have a team with a wide range of expertise, and I also know how much of that experience is human. I miss that human element when I’m working with agents.

In terms of what I can produce, though, a good agent harness, a capable model, and this skills collection make me feel like much more than myself. The harness is the software that gives the model a working environment: tools, files, context, and a way to carry work forward. The skills give it methods for the particular job.

Together, they let me operate almost like the CEO of my own little company. I can set a direction, ask for specialist work, challenge the result, and decide what happens next. If I can imagine something and explain it, much of the time I can get surprisingly far toward doing it.

I still make the decisions and judge the results. The difference is how much specialist work I can bring into those decisions. I couldn’t get the same experience from a bare general-purpose agent and a hopeful prompt.

## Why I keep reaching for product-discovery

I have ideas. Plenty of them. What I want from an agent is a conversation that helps me understand the idea well enough to make a decision about it. [Product-discovery](https://github.com/magnus919/agent-skills/blob/v0.9.0/product-discovery/SKILL.md?ref=groktop.us) gives that conversation somewhere to go.

Suppose I bring it a product brief for a file-sharing service. The brief promises that deleting a file removes it immediately. A few paragraphs later, it promises that users can recover anything they deleted by mistake.

The [artifact-first interview method](https://github.com/magnus919/agent-skills/blob/v0.9.0/product-discovery/references/artifact-first-interview.md?ref=groktop.us) tells the agent to read the brief before asking questions and choose the uncertainty most likely to change an important decision. In this case, the deletion and recovery promises need to be reconciled. The agent asks me to resolve the conflict: should deletion be permanent immediately, or should there be a recovery period? Then it waits for my answer.

If I say recovery matters, we’ve learned something that affects how deletion should work. Perhaps the file moves into a recoverable state first. Perhaps a separate permanent-delete operation is needed. The next question follows from that answer. We’re working through the behavior together, one decision at a time, rather than marching through a questionnaire that was written before I said anything.

The agent keeps a record of the decisions and the remaining gaps. When we stop, I get proposed changes to the affected passages, with the reasoning behind them. I can see what changed and why. The rest of my document stays intact.

That’s why I reach for it. I can arrive with a rough brief and have a focused conversation that makes the thinking clearer. I don’t have to design the interview myself before asking for help.

So what did I put into the skill to make that kind of exchange possible?

## What’s inside the package matters

You’ve probably seen instructions that start with something like “You are a world-class product manager with twenty years of experience.” Fine. Now what? What does that person notice? What questions do they ask? How do they decide whether an answer is good enough to act on?

That’s the part I want in a skill. Giving the agent an impressive job title leaves an awful lot of the job unexplained. I want to give it the practices that make someone good at the work.

Open one of my skill directories and you’ll find a Markdown file called `SKILL.md`. Think of it as the front door. It explains what the skill is for, when the agent should use it, how to begin, and which supporting material to open as the work develops. The [agent-skills skill](https://github.com/magnus919/agent-skills/blob/v0.9.0/agent-skills/SKILL.md?ref=groktop.us) is what I use to build these packages. I began with that skill, then built others that could help me develop more sophisticated skills. The collection has grown through that same process.

What sits behind that front door is where things get interesting.

### Methodologies: how to approach the work

A methodology gives the agent a sequence of decisions and a reason for making them in that order. That sounds a little dry until you’ve watched a project charge ahead with the wrong understanding of the problem.

The same [product-discovery](https://github.com/magnus919/agent-skills/blob/v0.9.0/product-discovery/SKILL.md?ref=groktop.us) skill also handles discovery beyond a draft review. When planning stakeholder interviews, it helps identify the people who know how the work happens, the people affected by a change, the people who understand the implementation, and the people who can approve it. Those can be four very different groups.

Suppose a manager asks for a dashboard. The people doing the work may already have three dashboards and a spreadsheet they trust more than any of them. The skill’s [stakeholder-mapping method](https://github.com/magnus919/agent-skills/blob/v0.9.0/product-discovery/references/stakeholder-mapping.md?ref=groktop.us) directs attention to those people early. It asks who will support the result, whose workflow will change, and who has tried to solve this before. The manager’s request becomes the beginning of an investigation.

The agent has a way to discover why the spreadsheet exists before helping you commission dashboard number four.

### References: room for the difficult parts

The entry file can only carry so much detail before it becomes a chore to navigate. My skills use reference files to give particular problems the space they need. The entry point tells the agent when each reference applies, so it can bring the relevant material into the conversation as needed.

Product-discovery has separate references for interviewing, conflicting requirements, power dynamics, limited stakeholder time, and the ways an AI interviewer can become too agreeable. Those are different problems. A conversation with a rushed operator needs a different approach from a room in which nobody wants to contradict the person who controls the budget.

One of my favorite examples is the [gap-detection reference](https://github.com/magnus919/agent-skills/blob/v0.9.0/product-discovery/references/gap-detection.md?ref=groktop.us). It teaches the agent to notice apparently harmless phrases such as “most of the time,” “ideally,” and “we’ll figure that out later.” There’s usually something worth asking about behind them. “Most of the time” invites a conversation about the exceptions. “User-friendly” invites a question about who struggles with the current system and what they’re trying to do.

That gives an agent something much more useful to do with an answer than summarize it neatly. It can recognize an opening for the next question. As I discussed in [my earlier piece on skills and agent interfaces](https://www.groktop.us/stop-asking-for-mcp/), the way an agent finds and accesses its capabilities is part of the design. Here, the supporting knowledge is organized around the situations in which it becomes useful.

### Templates: make the reasoning survive the conversation

After a good conversation, someone still has to turn what was learned into something people can use. This is where templates earn their place.

Product-discovery’s [interpretation log](https://github.com/magnus919/agent-skills/blob/v0.9.0/product-discovery/templates/interpretation-log.md?ref=groktop.us) records what a stakeholder said, how that statement became a requirement, which other interpretations were considered, and whether anyone confirmed the result. It also tracks whether the requirement was stated directly, implied, interpreted, or inferred.

Return to the file-sharing brief. If I decide that accidental deletions must be recoverable, the agent can record my answer alongside the proposed change to the requirement. A reviewer can see where the decision came from, which other approaches were considered, and which details still need an answer. If somebody later asks why a supposedly deleted file is still recoverable, we have a trail back to the choice that created that behavior.

The agent can maintain these records while you have the conversation. You don’t have to stop every few minutes to fill out a form. Later, when somebody asks why a decision was made, the answer is still there.

### Scripts: do the repeatable work

Some parts of a task benefit from executable code. If a skill needs to inspect files, collect measurements, or check a structured artifact, a small script can give the agent a repeatable way to do it.

The new [code-review skill](https://github.com/magnus919/agent-skills/blob/v0.9.0/code-review/SKILL.md?ref=groktop.us) includes a scope tool that inspects a proposed change. It reports the size of the change, the kinds of files involved, paths that may deserve particular attention, and whether source changes came with test changes. The review method then uses that information to organize the work.

A change to authorization logic deserves attention even if it is small. A large collection of generated files needs a different kind of inspection. Having a script collect the shape of the change lets the agent spend its reasoning on where the risk is and how to investigate it. The skill also includes a checker for the review record, so the account of the review can be checked for required structure.

The code and its instructions travel together when you install the skill, so the agent has the same mechanics available the next time you ask for a review.

### Evaluations: give the skill something to answer for

Once I’ve written a skill, I want to see how it behaves on a real kind of problem. Evaluations supply example tasks, expected outcomes, and observable things to look for in the result.

The [catalog’s evaluation requirements](https://github.com/magnus919/agent-skills/blob/v0.9.0/agent-skills/references/repository-evaluations.md?ref=groktop.us) call for representative cases, including difficult or ambiguous situations. The skill-building method also tests when a skill should activate and when a nearby request belongs to a different skill. Routing matters: a personal planning conversation and a product requirements interview can sound similar while needing quite different methods.

One of the [product-discovery evaluation cases](https://github.com/magnus919/agent-skills/blob/v0.9.0/product-discovery/evals/evals.json?ref=groktop.us) gives the agent a confident author who insists that a dashboard will improve retention. The expected behavior is to ask one question about the evidence behind that belief. Another supplies conflicting answers about how archived projects can be found and restored, then checks whether the agent exposes the contradiction instead of quietly inventing a new recovery mechanism.

The cases describe what to look for. Running them and inspecting the results tells you how the agent actually behaved. You can compare that work before and after an improvement to the skill. Did the questions get better? Did it make irrelevant edits? Did it quietly decide something the human still needed to choose?

This is how a skill can improve through use. When an agent misses something important, there’s a place to capture that failure and an exercise that can reveal whether the next version handles it better. Over time, I can put more of what I’ve learned into the package instead of relying on myself to remember it in every prompt.

Not every skill needs a script, and the supporting files vary with the work. The common ambition is depth: give the agent the methods, materials, and checks it needs to take on the specialty seriously.

![A person's intention branches into research, building, writing, and review, then returns as learning to a shared library.](https://storage.ghost.io/c/f1/0e/f10e80f4-9285-43fc-acd4-35910a12c5f0/content/images/2026/11/inline.png)

A conceptual view of the workflow: describe the work, draw on relevant methods, review the result, and carry useful learning forward.

## Before an idea becomes a project

The [customer-problem work added in this release](https://github.com/magnus919/agent-skills/pull/771?ref=groktop.us) takes that care upstream. Before we turn an idea into requirements, it asks about the problem’s severity, how often it happens, how people deal with it today, and which kinds of customers experience it differently.

Say I’m considering a paid newsletter for people in a particular industry. The interesting question is what those people need to decide and how they currently get the information to decide it. I might hear that the idea sounds useful. I might also learn that someone already spends hours assembling the same information every week, or pays for an unsatisfactory alternative. Those details give us a much better conversation about value, audience, and what to investigate next.

The skill keeps stated preferences, reported behavior, observed behavior, and costly commitments separate in the evidence record. It preserves contradictory accounts too. If experienced practitioners are comfortable with their current sources while newcomers are struggling, we may be looking at a much more specific audience than the original idea suggested. That is worth finding out while the idea is still cheap to change.

There’s a [customer evidence ledger](https://github.com/magnus919/agent-skills/blob/v0.9.0/product-discovery/templates/customer-evidence-ledger.md?ref=groktop.us) for keeping track of why you believe a market needs something. It holds the claim, the customer segment, the source, the observed behavior or commitment, contradictions, and the decision the evidence affects. When a promising idea starts collecting enthusiastic feedback, that structure helps you keep track of what people have actually done.

Once the problem is clearer, the skill can route experiment design, measurement, strategy, or financial questions to the relevant parts of the library. The new [solo-startup skill](https://github.com/magnus919/agent-skills/blob/v0.9.0/solo-startup/SKILL.md?ref=groktop.us) adds the practical constraint of what one person can sell, deliver, support, and afford. The conversation develops as the work develops.

And this is one skill in a catalog now containing [194 skill packages, including nested skills](https://github.com/magnus919/agent-skills/compare/v0.8.0...v0.9.0?ref=groktop.us). The reason I spend this much care on them is that I want to be able to reach for that depth when I need it.

## Carry the thinking into the next job

Suppose the newsletter investigation turns up a promising audience. Now I have to explain the value, design the experience, and work out how the business operates. I want what we learned about those readers to inform all of that. This release strengthens several of those handoffs.

The [design workflow improvements](https://github.com/magnus919/agent-skills/pull/802?ref=groktop.us) carry the work from discovery through visual direction, prototypes, and implementation. For a newsletter site, that might mean taking an agreed reading experience through to the page someone actually opens on their phone. The agent should ask questions appropriate to the stage, offer concrete alternatives, retain approved choices, and reuse the relevant components and shared design settings, such as colors and spacing, when it builds. Otherwise, you can approve one direction and receive something quite different in the finished interface.

The [positioning and copy changes](https://github.com/magnus919/agent-skills/pull/807?ref=groktop.us) connect customer evidence to a message brief and actual replacement copy. What readers struggled to find during discovery should shape the promise on the subscription page. The agent has a method for developing alternate openings, explaining the value, addressing objections, and checking the supporting claims.

The same care extends to businesses that earn money from referrals. The [SEO measurement work](https://github.com/magnus919/agent-skills/pull/805?ref=groktop.us) follows visibility toward business outcomes rather than stopping at traffic. It separates an outbound click to a partner’s site from the sale you eventually hope to earn, and asks how you’ll connect those records. The related [commercial-model additions](https://github.com/magnus919/agent-skills/pull/806?ref=groktop.us) ask who does the work, how a paid outcome is defined, and when money actually arrives. The same principle applies: carry the reasoning far enough to support a real decision.

This is why I keep enriching existing skills. A lesson from an article, a video, or a difficult piece of work can become part of the method I use next time. Over time, the library accumulates more than instructions. It accumulates things I’ve learned to look for.

Some of the new arrivals apply the same approach to familiar professional tasks. [teach-me](https://github.com/magnus919/agent-skills/blob/v0.9.0/teach-me/SKILL.md?ref=groktop.us) uses small diagnostic tasks and feedback to find out what you understand and where to work next. [job-interview-coaching](https://github.com/magnus919/agent-skills/blob/v0.9.0/job-interview-coaching/SKILL.md?ref=groktop.us) supports whole-transcript critique and targeted rehearsal, so you can practice the part of an answer that needs attention.

[meetings](https://github.com/magnus919/agent-skills/blob/v0.9.0/meetings/SKILL.md?ref=groktop.us) covers purpose, participation, facilitation, and faithful decisions. [amazon-memo](https://github.com/magnus919/agent-skills/blob/v0.9.0/amazon-memo/SKILL.md?ref=groktop.us) helps develop a decision brief, a press-release-and-FAQ exercise, or a narrative memo. These are all things people do regularly, with plenty of room for better preparation and judgment.

## A catalog that works together

Coordinating those specialties is a job of its own. For software delivery, I regularly use [Neckbeard](https://github.com/magnus919/agent-skills/blob/v0.9.0/neckbeard/SKILL.md?ref=groktop.us), which gives the agent a method for carrying a project across those boundaries. Neckbeard’s entry file is unchanged in this release; several of the specialists it routes to have become stronger.

Neckbeard can send requirements work to product-discovery, behavior and interaction questions to product-design-and-ux, debugging to systematic-debugging, testing to qa-methodology, and verification to verification-methodology. Each specialist brings its own methods and supporting material to the part of the job it understands.

That is why I encourage installing the full collection. Individual skills can be useful on their own. The connections become more useful when the specialist a skill calls for is actually available.

This release also adds [harness-engineering](https://github.com/magnus919/agent-skills/blob/v0.9.0/harness-engineering/SKILL.md?ref=groktop.us) and [multi-agent-coordination](https://github.com/magnus919/agent-skills/blob/v0.9.0/multi-agent-coordination/SKILL.md?ref=groktop.us). They tackle the practical questions behind a group of agents: who owns the work, what context travels with it, how results get integrated, what happens after a failure, and when parallel work is worth the cost. That includes deciding whether the work benefits from several agents or whether a single agent can handle it more effectively.

The more specialized additions go deeper into particular jobs: [performance-optimization](https://github.com/magnus919/agent-skills/blob/v0.9.0/performance-optimization/SKILL.md?ref=groktop.us) starts with measurements and bottlenecks, [unsloth](https://github.com/magnus919/agent-skills/blob/v0.9.0/unsloth/SKILL.md?ref=groktop.us) supports adapting models to particular tasks, and [system-one](https://github.com/magnus919/agent-skills/blob/v0.9.0/system-one/SKILL.md?ref=groktop.us) puts bounded model judgments inside conventional software. You can browse the [full release](https://github.com/magnus919/agent-skills/releases/tag/v0.9.0?ref=groktop.us) as those needs come up. You don’t need to memorize it.

I haven’t. There are skills I’ve forgotten I made. A compatible agent can discover relevant skills from their descriptions and load more detail when needed. The agent still needs the tools and access required for the task. Once those are in place, contextual discovery lets me spend less time remembering the catalog and more time describing the work.

## Install the collection, then try five

You’ll need an agent that supports installing skills. Check yours against the [installation guide](https://github.com/magnus919/agent-skills/blob/v0.9.0/README.md?ref=groktop.us#installation); it covers the supported agents and their setup. For example, with Node.js 22.20 or newer, npm, and Git installed, this installs the full collection globally for Codex:

```
npx skills add magnus919/agent-skills --skill '*' --agent codex --global --yes
```

Use the agent identifier from the guide for your own harness. Rerunning the full installation command refreshes the collection and picks up new additions. The update command alone updates skills you already installed; it doesn’t subscribe you to new ones. Start a fresh session unless your agent documents automatic refresh, and keep personal modifications in a fork or separate skill so an update doesn’t replace them.

Then try something like this:

> Look through the installed skills catalog and the work history you can actually access. Recommend five skills most likely to improve how we work together. For each, explain why it fits, give me one real task to try, and tell me about any missing tools or access. Don’t invent work history.

If the agent doesn’t have that history, tell it what you do and where you get stuck. Use whatever wording feels natural. You’re looking for a few useful places to begin.

After you’ve used them, come back with what happened:

> These three helped; these two didn’t fit. Based on what we learned, what are the next five worth trying?

That conversation is part of the process. You’re learning which methods suit your work, and giving the agent better context for helping you.

I got to where I am in life in large part because of open source. Some things I build are personal enough, or valuable enough to a particular project, that I keep them private. Most of these skills don’t need to be secret. I’m happy to [share them under the MIT license](https://github.com/magnus919/agent-skills/blob/v0.9.0/LICENSE.md?ref=groktop.us).

I want people to try them, find the useful parts, and discover what they can do with them. For me, the biggest change has been feeling that I can describe more ambitious work without first becoming an expert in every part of it.

That’s where I’d rather put the effort: building capabilities I can return to, then having the conversation about what to do next.