DEV Community: 张文超

How I stopped collecting random agent skills and started building reusable workflow collections

张文超 — Mon, 18 May 2026 01:49:43 +0000

Most people do not have a skill discovery problem for very long.

After a few days with Claude Code, Codex, Cursor, or other agent tools, the problem changes.

You find a few useful skills on GitHub. You install some. You bookmark others. Then your setup turns into a pile of disconnected commands, repos, and half-remembered SKILL.md files.

That is where I started too.

The missing piece was not "more skills". It was a better way to organize skills around repeatable work.

The real problem: skills without workflow context

A single skill can be useful on its own.

But in real work, skills usually come in groups:

research + synthesis + writing
SEO analysis + content planning + localization
design review + image generation + asset upload
bug triage + reproduction + code review

If those groups only live in your memory, you keep rebuilding the same workflow every week.

That is why I started thinking in collections instead of one-off installs.

1. Save skills by job, not by hype

The easiest mistake is collecting skills because they look impressive.

A better filter is:

"Would I install this again for a specific job?"

If the answer is yes, put it into a workflow bucket.

For example:

content workflow
landing page workflow
image workflow
code review workflow
growth workflow

That makes a skill directory much more useful, because you are no longer asking "What is popular?" You are asking "What helps with this job?"

2. Evaluate the skill before you add it to a workflow

I also stopped saving skills based on repo names alone.

Before a skill goes into one of my workflow collections, I want to inspect:

what the skill actually promises to do
whether the SKILL.md is specific or vague
whether the file tree suggests real implementation or just a thin wrapper
whether the install command is clear
whether there are any comments, ratings, or other signals worth checking

That is why I like directories that let me inspect the skill before I install it. Lately I have been using Agent Skills Finder collections as the place where I group candidate skills by workflow after checking the details first.

It is still a discovery and evaluation layer, not a security audit. I still review third-party code and instructions before enabling anything in a real workspace.

3. Keep the collection small enough to be reusable

The goal is not to create a giant archive.

The goal is to create small, reusable sets that match the way you actually work.

I have found that 3 to 7 skills per collection is usually enough.

More than that, and the collection becomes a wishlist instead of a workflow.

A useful collection should answer one practical question:

"If I need to do this job tomorrow, which skills would I reach for first?"

4. Write one sentence for why each skill belongs there

This sounds minor, but it matters.

If you cannot explain why a skill belongs in a collection, it probably does not belong there yet.

A one-line note is often enough:

"Use this to inspect repo structure before editing."
"Use this for draft generation after keyword clustering."
"Use this after code review to create release notes."

That short explanation becomes the bridge between a list of skills and a workflow that someone else can actually reuse.

5. Revisit collections after real usage, not right after discovery

The best time to refine a workflow collection is after you used it in actual work.

That is when you notice:

which skills overlap too much
which ones look good but are never actually used
which missing step keeps forcing you back to manual work
which skill deserves to move into a different collection

This is also why I no longer treat discovery as the finish line.

Discovery is only step one. Reuse is the real test.

Final thought

For agent tooling, the hard part is not finding one more skill.

The hard part is turning a scattered set of installs into a workflow you can repeat, share, and improve.

Once I started organizing skills as collections tied to real jobs, the whole setup became much easier to use.

How I turned one-off AI image prompts into reusable templates for social and product visuals

张文超 — Mon, 18 May 2026 01:43:42 +0000

Most prompt advice focuses on how to get one good image.

That helps when you are exploring. It is much less useful when you need to make visuals every week for product updates, blog covers, social posts, launch cards, or e-commerce campaigns.

The real problem is usually not prompt quality. It is workflow repeatability.

If a prompt works once, can you turn it into something the next person on your team can reuse without starting from a blank box again?

Here is the lightweight system I have been using to make AI image prompts more reusable.

1. Stop saving prompts as plain text snippets

A prompt alone is missing too much context.

When I revisit an old prompt a week later, I usually need answers to these questions:

What job was this image doing?
Which aspect ratio was it designed for?
Was it meant for a social card, product visual, ad draft, or blog cover?
Did it need empty space for text?
Which parts looked reliable, and which parts still needed manual review?

Without that context, even a strong prompt becomes hard to reuse.

So instead of saving only the text, save a small template unit:

the prompt
the best output image
the intended use case
the aspect ratio
the visual constraints
a short note on what should change next time

That turns a prompt from a lucky result into a reusable asset.

2. Separate the fixed structure from the changing variables

For recurring visuals, I now split prompts into two parts.

Fixed structure:

layout
camera angle or composition
subject type
spacing for headline or CTA
lighting direction
background rules

Variables:

campaign theme
product name
seasonal details
color direction
audience-specific language
reference image

This makes it much easier to create variants without rewriting the entire prompt every time.

For example, a template for a product launch card can keep the same composition and text-safe area, while only changing the product context, color palette, and campaign angle.

3. Organize prompts by visual job, not by style buzzwords

A lot of prompt libraries become hard to use because they are grouped by style labels like "cinematic", "modern", or "minimalist".

That is not usually how teams work.

The more useful structure is by output job:

blog cover
social post
promo banner
product concept image
comparison visual
infographic draft
thumbnail

That is also why template-driven tools feel more practical than generic generators when the goal is real content production.

If I need a starting point for a campaign visual, I would rather open a category of reusable prompt workflows than stare at an empty prompt box. Lately I have been testing that approach in GPT Image Prompt, mainly because the template view is closer to how actual content work is organized.

It is still a draft workspace, not a final approval system. You still need to review text rendering, brand accuracy, product details, and rights before publishing anything externally.

4. Use the output as part of the next input

One thing that changed my workflow a lot: once a visual direction works, the generated image should become part of the next round.

That means:

reuse the same prompt with smaller edits
attach the last good image as a reference
keep a note about what should stay stable
only change one or two variables at a time

This reduces the common problem where every new attempt drifts into a completely different composition.

For social and product visuals, that stability matters more than novelty.

5. Review templates like code, not like inspiration

If a prompt is going to be reused, review it the same way you would review a reusable component:

Is the output consistent?
Does it fail in predictable ways?
Does it leave enough room for copy?
Does it break when you swap in a different product or theme?
Can someone else on the team use it without extra explanation?

That mindset makes AI image work a lot less random.

Final thought

The useful shift is simple: stop treating image prompts as one-time instructions and start treating them as reusable templates for recurring visual jobs.

Once you do that, AI image generation becomes much more practical for newsletters, product updates, social content, and e-commerce drafts.

How I Evaluate Agent Skills Before Installing Them

张文超 — Fri, 15 May 2026 10:10:04 +0000

Most agent skills are still discovered through scattered GitHub repositories, screenshots, and chat recommendations. That makes the install step easy to rush and the evaluation step easy to skip.

After a few avoidable bad installs, I settled on a simple review workflow before I enable any third-party skill in Claude Code, Codex, Cursor, OpenClaw, or a similar agent setup.

What I check first

I read the actual SKILL.md instead of stopping at the repository name.
I compare the install command with the tool I am using right now.
I inspect the file tree so I know how large the skill is and what it touches.
I look for author context, stars, comments, ratings, or any other community signal.
I save the good candidates somewhere instead of repeating the same search next week.

Why this matters

A lot of skill discovery still happens through random links. That is fine for inspiration, but it is a weak way to make installation decisions.

If I cannot quickly inspect the instructions, the file layout, and the surrounding signals, I am much more likely to install something I do not actually understand.

My current workflow

I now start from a directory view, shortlist a few relevant skills by workflow, open each detail page, compare the instructions side by side, and only then decide what to install in a real workspace.

One directory that makes this easier is Agent Skills Finder:
https://agentskillsfinder.com/?utm_source=target_4_dev_to_tech_blog

It is a searchable directory for discovering agent skills before you install them. You can inspect real SKILL.md files, compare install commands, review file trees, and check community signals before enabling a third-party skill.

Who this is useful for

This workflow is especially useful if you regularly switch between Claude Code, Codex, Cursor, OpenClaw, or other agent tools and do not want every install decision to start from scratch.

It is also useful for teams that want a more repeatable way to compare third-party skills before they enter a shared workflow.

The point

A good skill workflow starts with inspection, not impulse. If you can evaluate the actual files and instructions first, you make fewer bad installs and build a more reusable skill stack over time.

A practical prompt workflow for repeatable AI marketing visuals

张文超 — Mon, 11 May 2026 08:14:09 +0000

Most AI image experiments start the same way: you write a prompt, get one interesting result, tweak a few words, and then lose track of what actually worked.

That is fine for play. It breaks down when you need to produce the same kind of visual every week: launch graphics, product mockups, blog covers, social cards, ad concepts, or simple infographics.

The useful shift is to stop treating the prompt as a single text box and start treating it as a small workflow.

1. Start with the job, not the style

Before writing any prompt, define the visual job:

What is this image supposed to help someone understand?
Where will it appear?
What aspect ratio does that surface expect?
Does the image need empty space for a headline or UI overlay?
Which parts must be reviewed manually before publishing?

For example, "a futuristic illustration" is too loose. "A 16:9 blog cover for a post about API image generation, with clear empty space on the left for a title" is much easier to iterate.

2. Separate stable constraints from variables

A reusable prompt should have two layers.

Stable constraints:

format and aspect ratio
subject
composition
brand or product context
text-safe area
lighting or material rules
things to avoid

Variables:

audience
campaign theme
color direction
object details
seasonal or product-specific copy
image reference

That split makes it easier to reuse one workflow for multiple outputs without rewriting everything.

3. Keep a reference prompt library

The biggest time sink is not writing prompts. It is rediscovering prompts you already wrote.

A useful library does not need to be complex. Save:

the prompt
the output image
the category or use case
what you would change next time
whether the result was safe enough for public use

If you work on marketing or product content, categories like poster, social card, product concept, infographic, app screenshot style, and event visual are more useful than generic style tags.

4. Use generated results as inputs

Once you get a strong direction, the result should become part of the next iteration. Reference-image workflows are useful because they let you keep composition, subject shape, or mood while changing the next prompt.

That is also why I like tools that combine prompt examples, reference images, and history instead of only giving me an empty prompt box. I have been testing this workflow in GPT Image Prompt, which keeps the generator, examples, saved prompts, and previous results close together.

The product is still best treated as a draft and exploration workspace. You still need to review text, brand accuracy, rights, and final production quality yourself.

5. Review before reuse

Before reusing a prompt, check:

Does it produce consistent composition?
Does it preserve important product details?
Does it make text or labels that need correction?
Is the result acceptable as a draft, or only as inspiration?
Can the prompt be turned into a template for future work?

This review step is what turns a good accident into a repeatable asset.

Final thought

For AI visuals, the prompt is only one part of the system. The repeatable value comes from the loop around it: template, prompt, reference image, output, review, and saved history.

Once that loop exists, image generation becomes less random and much easier to use in real content work.

Agent Skills Are Getting Easier to Build, But Still Hard to Use

张文超 — Mon, 13 Apr 2026 08:34:45 +0000

Agent Skills Are Getting Easier to Build, But Still Hard to Use

If you have spent any time with agent skills recently, you have probably had the same experience.

You find a promising skill on GitHub. Then you open another one. Then five more. One repo has a good SKILL.md but weak install instructions. Another looks useful but gives you no clear signal about whether it is still worth installing. A third might solve only part of your workflow, so now you also need two more skills and some way to remember how they fit together.

That is the real bottleneck right now.

The problem is no longer that agent skills do not exist. The problem is that using them well still takes too much manual work.

Anthropic describes skills as folders that include instructions, scripts, and resources that agents can load when needed, and its SDK docs describe them as SKILL.md-based packages that Claude can invoke autonomously when relevant. OpenAI is pushing in a similar direction, with reusable skills in hosted and local shell environments, plus subagent workflows for more complex work. In other words, this is no longer a niche pattern. It is becoming part of how modern coding agents are extended and organized. :contentReference[oaicite:0]{index=0}

But once you move from the idea of skills to actually using them, the friction shows up fast.

Where people get stuck with agent skills

1. Discovery is still messy

The ecosystem is growing quickly. One public curated repository already describes itself as a collection of 1000+ agent skills across Claude Code, Codex, Gemini CLI, Cursor, and more. That sounds great until you are the person trying to find the right one for a real task. :contentReference[oaicite:1]{index=1}

Most users are still doing some version of this:

search GitHub
open repos one by one
guess from repo names
skim SKILL.md
copy install commands by hand
hope they picked the right thing

That is not a smooth workflow. It is directory hunting.

2. Installability and discoverability are inconsistent

This is one of the least glamorous problems, but it wastes a lot of time.

You can see ecosystem issues where local skills are not recognized automatically, forcing users to read the SKILL.md manually and follow the workflow by hand. You can also see cases where individual skills were not exposed as separate installable entries, so users could not discover or install them cleanly. Even tool authors are discussing where skill files should land because a standard discovery path is still emerging. :contentReference[oaicite:2]{index=2}

That means the work is often not “use the skill.”

It is “figure out how this particular skill expects to be found.”

3. It is hard to judge a skill before you install it

A GitHub repo can tell you almost nothing about whether a skill is worth your time.

Stars help a little, but not much. A repo title helps even less. What people actually need before installing is more practical:

what this skill really does
how it is meant to be used
what files it includes
whether it overlaps with another option
whether other users found it useful

Without that, installation becomes trial and error.

4. Real work usually needs more than one skill

A single skill rarely completes an end-to-end workflow.

You might use one skill for search, another for content cleanup, another for document output, and another for review. OpenAI’s subagent documentation points in the same direction: useful agent workflows are often multi-step and parallel, not single-command tricks. :contentReference[oaicite:3]{index=3}

The practical problem is not just finding one skill. It is building a repeatable stack of skills that works together.

5. Good skills are easy to lose

Even after you find something useful, the next problem appears a week later:

“Where was that skill I used for this?”

Most people end up with browser tabs, bookmarks, notes, or a half-remembered repo name. That is a bad retrieval system for something you expect to reuse.

What should exist instead

A good agent-skill product should reduce four kinds of friction:

Discovery friction: help people search by task, category, and workflow, not just repo name
Decision friction: help people inspect a skill before installation
Reuse friction: help people save good skills and return to them later
Workflow friction: help people group multiple skills into something repeatable

That is exactly why Agent Skills Finder is useful.

Why Agent Skills Finder is worth recommending

Agent Skills Finder is not trying to be “yet another list of GitHub repos.”

Its core job is much more practical: help users move from “I need a skill” to “I know which one to install, and why.” That product direction is explicit in the current PRD, and the implemented feature set follows that idea closely. :contentReference[oaicite:4]{index=4}

Here is what makes it valuable in real use.

1. It gives people more than one way to find a skill

Instead of forcing users to search GitHub blindly, the site supports browsing from the homepage, hot lists, new lists, categories, tags, and search results. It uses a category and tag structure so users can narrow by workflow direction before opening individual skill pages. :contentReference[oaicite:5]{index=5}

That matters because most users do not start with a repo name.

They start with a job to do.

2. It turns the skill page into a decision page

This is the strongest part of the product.

The skill detail page is not just a link-out page. It is built to help users decide before installing. According to the current product spec, users can review:

structured overview content
how-to-use and FAQ sections
install commands
recursive GitHub file tree
text file previews
SKILL.md by default
signals like favorites, ratings, comments, added date, and category
related skills for comparison :contentReference[oaicite:6]{index=6}

That changes the experience from “open repo and guess” to “inspect first, install second.”

3. It solves the “I found it once, now where is it?” problem

The site includes favorites and a dedicated favorites page, with an Install all flow so useful skills are not lost after the first discovery. That turns scattered one-off finds into a reusable shortlist. :contentReference[oaicite:7]{index=7}

This is a simple feature, but it fixes a common failure point in day-to-day use.

4. It treats workflows as first-class, not accidental

One of the smartest decisions in Agent Skills Finder is the collection model.

Users can create private or public collections, add skills to them, include external GitHub SKILL.md sources, and generate install commands from collection pages. In practice, this means people can turn “these three or four skills I use together” into a repeatable workflow instead of a mental note. :contentReference[oaicite:8]{index=8}

That is closer to how real users work.

They do not just reuse a skill.

They reuse a sequence.

5. It adds community signals where GitHub alone is weak

The product also supports ratings and comments on skill detail pages, which gives later users more than raw star counts to work with. That is useful because a skill can look active on GitHub and still be a poor fit for a specific workflow. User feedback adds practical context. :contentReference[oaicite:9]{index=9}

6. It lowers the cost of growing the directory

When users do not find a skill, they can submit one from a GitHub repo URL, skill directory URL, or direct SKILL.md URL, then track review status from their own submissions page. That makes the directory easier to expand without asking users to leave the product. :contentReference[oaicite:10]{index=10}

That is how a useful directory stays useful.

The bigger point

Agent skills are clearly becoming part of the standard toolkit for coding agents and agent workflows. The vendors are moving in that direction. The community is producing more and more skills. The ecosystem is broadening across tools and platforms. :contentReference[oaicite:11]{index=11}

But the user experience is still fragmented.

That is why a product like Agent Skills Finder matters.

It does not try to replace skills.

It makes skills easier to evaluate, organize, and actually use.

For anyone who has already felt the pain of searching GitHub, comparing vague repos, copying install commands, and losing track of useful workflow pieces, this is the kind of layer the ecosystem needs.

Try it

If you are exploring agent skills and want a faster way to go from discovery to installation, start here:

Home: https://agentskillsfinder.com/
Categories: https://agentskillsfinder.com/categories
Hot skills: https://agentskillsfinder.com/hot
New skills: https://agentskillsfinder.com/new
Collections: https://agentskillsfinder.com/collections

The value is straightforward:

find faster, judge earlier, save what works, and turn scattered skills into a workflow you can actually reuse.