DEV Community: 张文超

A State Model for AI Image Workflows That Don't Lose Context

张文超 — Fri, 24 Jul 2026 09:28:34 +0000

Most AI image interfaces are optimized for one event: submit an input and receive an output. Real creative work is a sequence. A user generates a draft, chooses one result, edits it, removes a background, enhances it, compares versions, and finally exports a file.

If each step is modeled as an isolated form submission, the application loses the relationships that make the workflow useful. The user has to upload the same image again, reconstruct the prompt, and guess which version should be edited next.

The fix is not another image tool. It is a small state model that treats every result as part of a task lineage.

Separate tasks, runs, and assets

A practical model needs at least three entities:

Task: the user's durable intent, such as creating a product hero image.
Run: one model or editing operation, including its inputs and settings.
Asset: a source image or result file that can be reused by later runs.

The important relationship is that a run consumes assets and produces assets. A result is not just a URL returned by a provider; it is an asset with provenance.

type ImageRun = {
  id: string
  taskId: string
  operation: string
  prompt: string | null
  inputAssetIds: string[]
  outputAssetIds: string[]
  model: string
  settings: Record<string, unknown>
  status: 'queued' | 'running' | 'succeeded' | 'failed'
}

This makes "continue from this result" a normal operation: create a new run whose input is the selected output asset. There is no download-upload round trip and no ambiguous current file.

Make result selection explicit

Generating four images does not mean all four are equally important. Store the user's selection instead of inferring it from the most recent timestamp.

A task can have:

a selected working asset;
an optional final asset;
an ordered history of runs;
a delivery specification.

The selected working asset is the default input for the next operation. The final asset is the version that passed review. These are different states: a user may continue editing a promising result without declaring it finished.

Preserve the delivery contract

The task should also keep the requirements that determine whether an image is done:

type DeliverySpec = {
  width?: number
  height?: number
  format: 'png' | 'jpg' | 'webp'
  maxBytes?: number
  background?: 'transparent' | 'opaque' | 'either'
  protectedElements?: string[]
}

Finalization can then validate dimensions, format, file size, and required visual constraints before enabling the final download. This is more reliable than treating the last generated image as the deliverable.

Keep provider details behind the run

Different image providers return different job identifiers, status shapes, and result payloads. Normalize those differences inside the run layer. The user-facing task should not depend on a provider's temporary response format.

Useful fields to retain include:

provider job ID;
model and resolution;
normalized cost;
raw error category;
retry relationship;
timestamps for queue, start, and completion.

This also makes retries safer. A retry should create a new run connected to the failed run, not silently overwrite its evidence.

Treat export as a state transition

Export is often implemented as a plain download button. In a result-first workflow it is better modeled as:

select a final asset;
validate it against the delivery spec;
choose filename and output format;
create an export record;
download the exported artifact.

That record answers a useful operational question later: which exact file did the user deliver?

I am applying this model in ImgFast Workspace, where the primary flow is Create → Continue → Final → Download. The implementation details will vary by stack, but the durable idea is the same: preserve the lineage between intent, inputs, runs, results, and delivery.

When the data model reflects that sequence, the UI becomes simpler. The next action can be attached to a visible result, history becomes explainable, and "final" stops being whichever file happens to be newest.

Designing a Version-Aware Game Wiki for Early Access

张文超 — Mon, 20 Jul 2026 21:25:07 +0000

Early Access games create a documentation problem that ordinary wikis do not handle well: the facts can change faster than search results, community posts, and copied tables are updated. A page can look polished and still be wrong for the current build.

I have been working on an independent Subnautica 2 player wiki, and the most useful engineering lesson has been to treat every guide, map marker, and item row as versioned data rather than timeless prose. This post describes the workflow without assuming any particular framework.

1. Put provenance next to the fact

For every structured record, keep at least:

the game build or patch it was checked against;
the source type: official note, in-game observation, or community report;
the observation date;
a confidence state such as verified, provisional, or disputed;
a stable identifier that survives display-name changes.

A user should not have to trust a page because it looks complete. They should be able to see whether a coordinate came from the current build and whether another player can reproduce it.

2. Separate stable identity from mutable labels

Names, descriptions, recipes, and locations may change. Use an internal key as the identity and keep display text as versioned attributes. This prevents an item rename from creating a second logical entity or breaking every inbound link.

The same rule helps with localization: English and translated labels point to one entity, while the source and verification state remain shared.

3. Model maps as evidence, not decoration

An interactive map should not be a pile of pins. A useful marker contains coordinates, category, build, evidence, verification state, and a short player-facing note. If a patch moves or removes the object, preserve the history and mark the old observation as superseded.

This also makes filters honest. “Show verified markers for the current build” is a meaningful query; “show everything ever imported” is not.

4. Make guides depend on structured facts

Low-spoiler guides are easier to maintain when routes reference item and location records instead of duplicating them. When a resource moves, the dependency graph tells you which guides need review.

A practical review queue can be generated after every patch:

ingest official patch notes;
map changed nouns to stable entity IDs;
flag affected recipes, markers, and guides;
verify the highest-impact facts in game;
publish the new state while retaining the previous build.

5. Design for uncertainty

Not every fact can be verified immediately. Hiding uncertainty encourages accidental certainty. I prefer explicit labels:

Verified: reproduced for the stated build;
Provisional: credible but not reproduced;
Disputed: conflicting observations exist;
Superseded: valid in an older build, not current.

These labels are more useful than a single “last updated” date because one page can contain facts with different evidence quality.

6. Give players task-oriented entry points

Players rarely arrive wanting “the database.” They want to unblock a task: find a resource, understand a recipe, plan a vehicle route, or check whether an old guide still applies.

The public navigation should therefore expose task views—map, items, blueprints, creatures, guides, updates, and FAQ—while the data layer stays normalized underneath. As a working example, the Subnautica 2 Wiki combines those views and publishes current-build context for players. Disclosure: I maintain this independent resource; it is not an official game site.

7. Add regression checks for content

Content can break like code. Useful automated checks include:

every current recipe references existing item IDs;
every public marker has coordinates and a build;
no verified current fact points only to a superseded source;
localized pages resolve to the same canonical entity;
guide links do not point to removed routes;
sitemap and canonical URLs match the public information architecture.

These checks do not prove that a coordinate is correct, but they prevent many silent consistency failures.

Closing thought

The key shift is simple: build an evidence system that renders a wiki, not a collection of pages that happens to contain facts. Early Access makes uncertainty unavoidable. Good architecture makes that uncertainty visible, reviewable, and inexpensive to update.

Five checks for a useful browser-based crosshair preview

张文超 — Wed, 15 Jul 2026 14:52:07 +0000

A crosshair editor looks simple until the preview and the exported profile stop agreeing. If you are building or evaluating a browser-based editor, these are the checks that make the interface useful instead of decorative.

1. Treat the profile code as derived state

The visible controls should be the source of truth. When color, opacity, outlines, center dot, inner lines, outer lines, or error settings change, regenerate the profile code from the same state used by the preview.

Avoid maintaining a separate editable code string unless you also have a tested parser and a clear conflict-resolution rule. Two sources of truth create hard-to-explain mismatches.

2. Preview more than the standing state

A static center preview misses movement and firing error behavior. Provide distinct standing, moving, and firing states so users can see whether the lines expand too far or whether feedback becomes distracting.

The goal is not to reproduce every frame of the game. It is to expose the relationships between the configured values before the user imports the profile.

3. Use backgrounds as contrast tests

A black grid is helpful for alignment, but it hides visibility problems. Include bright, dark, warm, and cool scenes. The user should be able to find the first background where the center becomes difficult to track.

I used this checklist while reviewing the Crosshair Maker codes and presets workflow. Its editor keeps the generated profile code synchronized with the controls, offers standing, moving, and firing previews, and lets the same setup be checked against three backgrounds.

4. Make presets editable states, not dead examples

A preset is most useful when it loads into the same editor as a hand-built setup. Users can start from a dot, a compact static style, or a dynamic example, then inspect which values produced it.

Label presets as starting points. Do not imply that one setting is universally best or that a preset belongs to a professional player unless you have a reliable source.

5. Keep the in-client verification step visible

A web preview cannot guarantee identical rendering at every resolution or after every game update. The final workflow should end with copying the profile code, importing it into the game, and checking it at the user's normal resolution.

That limitation belongs in the product, not in fine print. It sets the right expectation and gives users a clear next step when a preview looks different in the client.

A compact implementation contract

A useful first version should support:

one state model for controls, preview, and generated code;
separate standing, moving, and firing previews;
several contrast backgrounds;
editable presets;
copy and reset actions;
an explicit in-client verification note.

Crosshair Maker is an independent tool and is not affiliated with or endorsed by Riot Games. VALORANT is a trademark of Riot Games, Inc.

A practical checklist for validating Palworld 1.0 breeding data

张文超 — Wed, 15 Jul 2026 13:30:44 +0000

When a breeding result stops matching an older guide, the fastest fix is usually not trying more random parent pairs. First verify which game version and dataset the calculator is using.

What I check

Supported game version. A calculator should say whether it targets Palworld 1.0 or an earlier dataset.
Pinned source data. Look for a source release, commit, dataset date, or checksum instead of a vague “updated” badge.
Both lookup directions. Parents → Child helps when you already own two Pals. Target → Parents is better when you know the offspring you want.
Special rules. Fixed pairs, same-species results, and gender-direction exceptions should not be flattened into one average-rank formula.
Explicit limits. Species outcomes are different from passive inheritance, IV inheritance, mutation, cake timing, or shortest-route planning.

A small tool built around that workflow

I built PalBreed as a free, no-sign-in Palworld 1.0 breeding calculator. It supports both lookup directions and currently indexes 44,851 parent relationships.

The more useful part for debugging is its data status page: it publishes the supported game version, dataset date, upstream release and commit, SHA-256 checksums, regression cases, and known limits.

For players who want to inspect the whole relationship index rather than run one calculation, there is also a searchable breeding combinations list.

PalBreed is an independent community tool and is not affiliated with Pocketpair. It currently calculates species outcomes only; it does not simulate passives, IVs, mutation, cake timing, shortest paths, or personal inventory.

A Practical Workflow for Reusable AI Image Prompts

张文超 — Mon, 13 Jul 2026 20:39:22 +0000

Most AI image experiments fail for a boring reason: the prompt is treated as a one-off sentence instead of a reusable specification.

A reliable image workflow is closer to a small build system. It separates the parts that should stay stable from the parts that change between runs, records what produced each result, and gives reviewers something concrete to compare.

This post describes a lightweight approach that works for product screenshots, article covers, social cards, diagrams, and campaign variants.

1. Start with a prompt contract

Before writing prose, define the fields your workflow actually needs:

subject: the main object or scene
purpose: cover, product mockup, ad, illustration, or reference asset
composition: camera angle, framing, negative space, hierarchy
style: photographic, editorial, diagrammatic, 3D, flat illustration
palette: named colors or brand tokens
text policy: no text, exact text, or editable placeholder
aspect ratio: tied to the destination slot
constraints: forbidden elements, privacy boundaries, brand rules

A prompt contract prevents the common failure mode where every revision rewrites the whole prompt and accidentally changes three unrelated decisions.

2. Store variables separately from the template

Keep the reusable instruction as a template and pass the changing values as data.

{
  "subject": "a compact browser-based image workspace",
  "purpose": "developer tutorial cover",
  "composition": "editor panel on the left, generated variations on the right",
  "style": "clean editorial product illustration",
  "palette": ["#111827", "#2563EB", "#F8FAFC"],
  "text_policy": "no embedded text",
  "aspect_ratio": "16:9",
  "constraints": ["no logos", "no watermarks", "no fake UI labels"]
}

This makes prompts diffable. A reviewer can see that a new run changed only the composition or palette instead of trying to infer changes from a paragraph.

3. Make reference images explicit

Reference images should have roles, not just filenames.

For example:

reference A controls layout
reference B controls material and lighting
reference C controls color only

If the model supports multiple references, state which visual properties may transfer from each source. Also state what must not transfer. This reduces accidental copying of text, logos, faces, or irrelevant background details.

4. Generate a small, intentional batch

More output is not always more information. I usually generate three variants with one controlled difference:

safe composition with clear hierarchy
more expressive composition using the same palette
simplified composition optimized for small-screen cropping

The batch becomes an experiment instead of a slot machine. If every variant changes subject, style, camera, and color simultaneously, you learn almost nothing from the comparison.

5. Score the result against the destination

An image can look good and still fail its job. Review it against the actual slot:

Does the focal point survive the mobile crop?
Is there enough quiet space for a headline added later?
Does the image still read at thumbnail size?
Are UI details plausible without pretending to be a literal screenshot?
Are hands, text, charts, and small objects visually coherent?
Does the file meet the expected dimensions and weight?

For Chinese teams testing GPT Image 2, I use the GPT Image 2 中文生成器 as one workspace for prompt drafts, reference-image runs, saved prompts, and reusable scene templates. The important part is not the specific interface; it is keeping the prompt, references, output, and revision history together.

6. Save the winning prompt as a versioned asset

A useful saved record includes:

id: tutorial-cover-browser-workspace-v3
model: gpt-image-2
ratio: 16:9
references:
  - layout-grid.png
prompt_template: tutorial-cover-v2
variables:
  subject: browser-based image workspace
  palette: dark-blue-neutral
review:
  mobile_crop: pass
  embedded_text: none
  brand_fit: pass

This is enough to recreate the direction later without pretending that image generation is perfectly deterministic.

7. Treat post-processing as part of the pipeline

The generated master is rarely the final delivery asset. A practical pipeline may still need to:

crop to the exact content slot
export WebP or AVIF
create 1x and 2x variants
strip unnecessary metadata
verify contrast after the page overlay is applied
keep the original master for future crops

Do not bake headlines into the image unless the destination truly requires it. HTML text is easier to edit, localize, test, and make accessible.

A compact operating loop

The full loop can stay simple:

define the slot
fill the prompt contract
assign reference-image roles
generate three controlled variants
review at final crop sizes
save the winning prompt and metadata
optimize the delivery files

That small amount of structure turns image generation from repeated improvisation into a workflow a team can reuse, review, and improve.

A practical checklist for formatting LinkedIn posts before you publish

张文超 — Sun, 12 Jul 2026 19:08:59 +0000

LinkedIn posts are usually written in a messy place first: a notes app, a doc, a Slack draft, or directly inside the composer. The problem is not just grammar. The final post has to survive line breaks, character limits, hooks, links, hashtags, mentions, and the fact that Unicode styles can make text harder to read if they are overused.

Here is the checklist I use before copying a post into LinkedIn.

1. Make the hook readable without decoration

If the first two lines only work because they are bold, the hook is weak. Write the hook in plain text first, then add emphasis only if it helps scanning.

A useful hook usually does one of these:

names a specific problem
states a concrete result
contrasts two workflows
asks a question the audience already has

2. Keep styled text rare

Unicode bold and italic can be useful, but they are not the same as semantic HTML. Screen readers may spell out some styled characters, search behavior can be inconsistent, and copied text can look strange in other tools.

I keep styling to:

one short bold phrase near the top
section labels when the post is long
no styling inside URLs, emails, hashtags, or @mentions

3. Check the post shape before checking the words

A LinkedIn post often fails because of shape, not content. Before editing sentence by sentence, zoom out:

Are there too many one-line paragraphs?
Is every bullet doing real work?
Does the post still make sense if someone reads only the first and last paragraph?
Is the CTA visible without being shouty?

4. Protect links, hashtags, and mentions

This is the easiest place to break a post. Do not apply Unicode styling to:

URLs
email addresses
@mentions
hashtags
code snippets
product names that must be searchable exactly

I usually format the body first, then paste links and hashtags back in plain text.

5. Preview before posting

The composer is not a great drafting environment. A preview step helps catch issues like a hook that wraps badly on mobile, a post that crosses the 3000-character limit, or a styled phrase that looks heavier than expected.

I built a small free workbench for this workflow: Social Text Tools LinkedIn Text Formatter. It lets you draft LinkedIn text, apply Unicode styles, keep sensitive tokens plain with safe mode, preview the result, and copy the final version.

The main habit is simple: finish the message in plain language first, then use formatting to improve scanning. Formatting should make a good post easier to read, not hide a weak one.

Compress an MP4 in the browser before you upload it

张文超 — Fri, 03 Jul 2026 13:44:14 +0000

Most video upload problems are not editing problems. They are file-size problems.

Someone has a screen recording, a quick phone clip, or a short demo, and the destination has a hard limit: an email attachment, a support form, a chat app, a course platform, or a social upload flow. The common reaction is to open a full editor, guess an export preset, wait, check the output, and then repeat.

A simpler workflow is to start with the target file size.

A practical target-size workflow

Keep the original video.
Decide the real limit you need to stay under.
Leave a little buffer instead of aiming exactly at the limit.
Compress to that target.
Reopen the output and check text, faces, motion, and audio before sending it.

That last step matters because tight targets are tradeoffs. A short 1080p clip can often shrink cleanly. A long, noisy, high-motion recording may need a lower resolution or a less aggressive target. No browser tool or encoder can make every video hit every size without visible loss.

Why browser-local compression helps

For quick sharing tasks, I prefer tools that do not require uploading the original video to a remote compression queue first. It reduces friction for private review clips, internal demos, customer support recordings, and files that simply do not need to leave the browser before export.

I have been using CompressMP4 for this exact case. It lets you choose a percentage or a target MB, processes the selected video in the browser, and gives you a smaller MP4 download without requiring an account for the public compressor.

When this is a good fit

You need a smaller MP4 for email, chat, a form, or a social upload.
You know the target size but do not want to think in bitrate settings.
You want a quick browser workflow rather than a full video editor.
You are working with a file where local browser processing is preferable to a server-side upload queue.

When to use something else

Use a full editor or transcoding tool if you need batch jobs, exact codec control, subtitles, trimming, watermarks, team presets, or server-side automation. For very large or long videos, local browser compression can also be slower than a dedicated desktop or server workflow.

For the common "this video is too large to send" case, though, starting with a target size is usually the fastest path.

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.