Introducing yottacode-skills: Reusable Agent Workflows for Real Engineering Work

AI coding agents are most useful when they do more than answer one prompt at a time.

Real engineering work has repeatable loops: understand the problem, investigate the codebase, plan the change, implement it safely, run tests, review the diff, capture follow-up work, and hand off what changed. Those loops should not depend on remembering the perfect prompt every time.

That is why we created yottacode-skills: the official public Agent Skills catalog for yottacode.

What is yottacode-skills?

yottacode-skills is a free, curated repository of reusable agent workflows that yottacode can install with the official/<name> source shortcut.

Each skill is a small playbook for a specific kind of work. Instead of starting from a blank prompt, a skill gives the agent a clear operating pattern: when to use it, what steps to follow, what evidence to gather, what mistakes to avoid, and what output should look like.

The repository follows the broader skills.sh / npx skills ecosystem layout:

skills/
  diagnose/
    SKILL.md
  security-auditor/
    SKILL.md
  writing-plans/
    SKILL.md

That structure keeps skills readable, versionable, and easy to review. A skill is not hidden model behavior. It is plain text you can inspect before you use it.

Why skills matter

Good agent workflows are not just about having a powerful model. They are about giving the agent the right process for the job.

A debugging session should not look like a code-generation session. A security review should not look like a feature implementation. A plan-writing task should not silently drift into editing files before the approach is agreed.

Skills make those differences explicit.

For example:

The goal is simple: make repeatable engineering behavior reusable.

Practical workflows, not prompt theater

The initial catalog is intentionally engineering-focused. These are the kinds of workflows developers run every week:

• clarify a non-obvious change before planning it;
• debug a failure without guessing;
• review a Dockerfile for caching, security, image size, and reproducibility;
• investigate Git history with blame, pickaxe, and bisect;
• capture architectural decisions and durable project documentation;
• profile performance problems with baseline measurements;
• verify a fix before calling it done.

That last point matters. A useful skill should push the agent toward concrete evidence: tests run, files inspected, risks checked, assumptions called out. It should reduce vague assistant behavior, not add more of it.

Public by default

We made yottacode-skills public because agent workflows should be inspectable.

If a skill influences how an agent plans, edits, tests, or reviews code, developers should be able to read it. Public skills also make collaboration easier: teams can fork the catalog, adapt a workflow to their environment, or contribute improvements back upstream.

This is especially important for workflows that touch security, release readiness, and code review. The process should not be a black box.

Getting started

Browse the catalog on GitHub:

• Repository: github.com/yottadynamics/yottacode-skills

Then try a skill that matches the work in front of you:

official/diagnose
official/security-scanner
official/writing-plans

Use diagnose when something is broken. Use writing-plans when a change is broad enough that the approach should be designed before code changes begin. Use security-scanner when you need a concrete scan rather than a purely manual review.

What comes next

yottacode-skills is the beginning of an open skills catalog, not the final shape of one.

We plan to keep adding practical workflows, improve the existing ones as they are used on real projects, and make discovery and installation smoother inside yottacode itself.

If you build with AI coding agents, the interesting question is no longer only “which model should I use?” It is also “what repeatable engineering workflows should my agent know how to run?”

yottacode-skills is where we are starting to answer that in public.

— The YottaDynamics Team