DEV Community: Yechua Silva

AMD Had Zero Agent Skills. I Built the First 10.

Yechua Silva — Fri, 10 Jul 2026 02:47:28 +0000

NVIDIA has 428+ agent skills on skills.sh. AMD had zero. This is the story of building the first open-source collection of agent skills for AMD ROCm GPU workloads — and why it matters for the entire AI ecosystem.

The Problem

If you've used AI coding agents like Claude Code, OpenCode, Cursor, or Codex, you've probably encountered agent skills — reusable instruction sets that teach agents how to perform specific tasks. Skills are the building blocks of agent workflows: "set up my GPU", "deploy vLLM", "run YOLO inference", "check PPE compliance".

The agent skills ecosystem is powered by skills.sh, a registry that indexes skill repositories from GitHub. When you run npx skills add owner/repo, the CLI clones the repo and installs skills into your agent's configuration directory.

Here's the problem:

GPU Vendor	Agent Skills on skills.sh
NVIDIA	428+
AMD	0

Zero. Not a single skill for AMD ROCm. If you're a developer using AMD MI300X, MI250, or even a Radeon RX 7900 with an AI coding agent, you had nothing. Every GPU setup, every Docker configuration, every inference deployment required manual documentation lookup and copy-paste.

The Solution

I built amd-rocm-skills — 10 production-ready agent skills covering the full AMD ROCm GPU workflow:

Core (4 skills)

Skill	What it does
`rocm-setup`	Install, verify, and configure ROCm on AMD GPUs with PyTorch. Auto-detects NVIDIA CUDA and CPU fallback.
`rocm-docker`	Docker with AMD GPU passthrough (`--device=/dev/kfd`), NVIDIA runtime, and CPU profiles. docker-compose multi-profile.
`vllm-rocm-deploy`	Deploy vLLM for LLM/VLM inference on ROCm. InternVL2, Qwen2-VL, LLaVA. OpenAI-compatible API.
`yolo-rocm-deploy`	YOLOv8 on PyTorch ROCm. Inference, model export (ONNX, TorchScript), benchmarking.

Pipeline (3 skills)

Skill	What it does
`video-pipeline-rocm`	Video inference pipeline with GStreamer + ROCm. RTSP capture, hardware decode (AMD VCN / NVIDIA NVDEC), frame extraction, batch inference.
`vlm-rocm-inference`	VLM inference directly with PyTorch on ROCm. InternVL2, Qwen2-VL. Multimodal (text + image).
`rocm-benchmark`	GPU benchmarking: matmul, memory bandwidth, inference latency, VRAM monitoring. ROCm + CUDA + CPU comparison.

Industrial (3 skills)

Skill	What it does
`ppe-detection-pipeline`	PPE (Personal Protective Equipment) detection in video for industrial safety. YOLOv8 + tracking + alerts (webhook, MQTT, log). Multi-camera, multi-GPU.
`ds132-compliance`	Chilean DS 132 mining safety compliance checker. Zone-based EPP requirements, audit logging, compliance reports.
`rocm-troubleshoot`	Diagnostics and troubleshooting for ROCm. Error codes, compatibility checks, quick fixes, optimization checklist.

Architecture

agentskills.io Specification

Every skill follows the agentskills.io specification — the open standard for agent skills:

skills/<skill-name>/
├── SKILL.md          # Required: YAML frontmatter + instructions
├── scripts/          # Required: executable Python/Bash scripts
└── references/       # Optional: technical documentation

The SKILL.md frontmatter uses only standard, portable fields:

---
name: rocm-setup
description: >
  Install, verify, and configure AMD ROCm on Linux for AI/ML workloads
  with PyTorch. Use this skill when setting up AMD GPUs (MI300X, MI250,
  RX 7900) for GPU-accelerated PyTorch, verifying ROCm installation, or
  diagnosing GPU detection issues. Keywords: rocm, amd, gpu, pytorch,
  hip, setup, mi300x, detect-gpu, rocm-smi, rocminfo, cuda, check-rocm
license: Apache-2.0
compatibility: >
  Compatible with Claude Code, OpenCode, Codex, Cursor, Cline, Roo Code,
  Windsurf, Gemini CLI, and Kiro CLI. Requires Linux with AMD ROCm or
  NVIDIA CUDA GPU (CPU fallback supported).
metadata:
  version: "1.1.0"
  author: yechua-silva
---

No Claude Code-specific fields. No context: fork, no agent: Explore, no model: claude-sonnet-*. Every skill works identically across 9+ agents.

Multi-GPU Design

The key differentiator: every skill supports three backends with automatic detection.

# Auto-detection pattern used across all skills
import torch

if torch.cuda.is_available():
    if torch.version.hip:
        backend = "rocm"        # AMD ROCm
        device = "cuda:0"       # torch.cuda works on both!
    elif torch.version.cuda:
        backend = "cuda"        # NVIDIA CUDA
        device = "cuda:0"
    else:
        backend = "cpu"
        device = "cpu"

This is the critical insight: PyTorch's torch.cuda API works on both AMD ROCm and NVIDIA CUDA. There is no torch.rocm. ROCm uses the standard torch.cuda namespace transparently. Use torch.version.hip to distinguish AMD from NVIDIA.

Component	AMD ROCm	NVIDIA CUDA	CPU
PyTorch	`torch.cuda` + `torch.version.hip`	`torch.cuda` + `torch.version.cuda`	`device='cpu'`
vLLM	`vllm-openai-rocm`	`vllm-openai`	`--device cpu`
Docker	`--device /dev/kfd --device /dev/dri`	`--gpus all`	No flags
Video decode	VAAPI / VCN	NVDEC	avdec (software)

Docker Multi-Profile

The rocm-docker skill includes a docker-compose.yml with three profiles:

# AMD ROCm
docker compose --profile rocm up -d

# NVIDIA CUDA
docker compose --profile nvidia up -d

# CPU fallback
docker compose --profile cpu up -d

Agent Compatibility

Agent	Supported	How
Claude Code	✅	`.claude/skills/`
OpenCode	✅	`.agents/skills/`
Codex	✅	`.codex/skills/`
Cursor	✅	`.cursor/skills/`
Cline	✅	`.cline/skills/`
Roo Code	✅	`.roo/skills/`
Windsurf	✅	`.windsurf/skills/`
Gemini CLI	✅	`.gemini/skills/`
Kiro CLI	✅	`.kiro/skills/`

Quick Start

Install all skills

# List available skills
npx skills add yechua-silva/amd-rocm-skills --list

# Install a single skill
npx skills add yechua-silva/amd-rocm-skills --skill rocm-setup --agent opencode --yes

# Install all skills in multiple agents
npx skills add yechua-silva/amd-rocm-skills -a claude-code -a opencode -a cursor --yes

Example: Setting up an AMD MI300X

After installing the rocm-setup skill, just tell your agent:

"Set up this AMD server for GPU workloads"

The agent will:

Run detect-gpu.py to identify your backend (ROCm, CUDA, or CPU)
Run check-rocm.sh for a full health check
Install ROCm if missing
Configure environment variables (HIP_VISIBLE_DEVICES, ROCm_PATH)
Verify PyTorch can access the GPU
Run a smoke test (tensor allocation, matmul, memory info)

Example: PPE Detection Pipeline

After installing ppe-detection-pipeline:

"Detect PPE in this RTSP stream and alert when workers are missing helmets"

The agent will:

Auto-detect GPU backend (ROCm / CUDA / CPU)
Load YOLOv8 model for PPE detection
Track persons across frames with IoU matching
Check compliance per person (hardhat, vest, gloves, glasses, boots)
Send alerts via webhook, MQTT, or log
Export annotated video + JSON results

Technical Deep Dive: Multi-GPU Detection

The detect-gpu.py script (from rocm-setup) is the foundation of all 10 skills. It detects the GPU backend in three levels:

# Level 1: PyTorch
import torch
if torch.cuda.is_available():
    if hasattr(torch.version, 'hip') and torch.version.hip:
        backend = "ROCM"
        device_name = torch.cuda.get_device_name(0)
        # e.g., "AMD Instinct MI300X"
    elif torch.version.cuda:
        backend = "CUDA"
        device_name = torch.cuda.get_device_name(0)
        # e.g., "NVIDIA A100-SXM-80GB"

# Level 2: System commands
import subprocess
if backend == "unknown":
    try:
        result = subprocess.run(["rocm-smi", "--showproductname"],
                                capture_output=True, text=True)
        if result.returncode == 0:
            backend = "ROCM"
    except FileNotFoundError:
        pass

    try:
        result = subprocess.run(["nvidia-smi", "--query-gpu=name",
                                "--format=csv,noheader"],
                                capture_output=True, text=True)
        if result.returncode == 0:
            backend = "CUDA"
    except FileNotFoundError:
        pass

# Level 3: CPU fallback
if backend == "unknown":
    backend = "CPU"

This three-level detection ensures every skill works on any machine — whether you have an MI300X with 192GB HBM3, an RTX 4090, or just a laptop CPU.

Industry Standard Compliance

This isn't just a collection of scripts. It's built to industry standards:

✅ agentskills.io specification — the canonical format for agent skills
✅ skills.sh registry — auto-indexed, discoverable via npx skills add
✅ skills.sh.json — groupings for organized discovery (Core, Pipeline, Industrial)
✅ CONTRIBUTING.md — quality checklist, naming conventions, PR process
✅ CODE_OF_CONDUCT.md — Contributor Covenant 2.1
✅ AGENTS.md — agent-facing overview
✅ Apache 2.0 license — permissive, commercial-friendly

Quality Checklist (from CONTRIBUTING.md)

Before any skill is merged:

[ ] name field matches directory name (kebab-case)
[ ] description includes keywords for agent matching
[ ] description includes trigger phrases ("Use when...")
[ ] compatibility is a string, not a YAML list
[ ] No Claude Code-specific fields (context, agent, model, hooks)
[ ] Scripts are executable (chmod +x)
[ ] No hardcoded secrets or API keys
[ ] No references to specific projects (keep it agnostic)
[ ] Related skills cross-referenced in ## Related Skills section
[ ] SKILL.md under 1000 lines

The Numbers

Metric	Value
Skills	10
Total lines of content	~32,000
Scripts (Python + Bash)	26
Reference documents	23
Compatible agents	9+
GPU backends	3 (ROCm + CUDA + CPU)
License	Apache 2.0
References to specific projects	0 (fully agnostic)

Why This Matters

The AI ecosystem has a GPU diversity problem. NVIDIA dominates not just hardware, but the entire software tooling stack — documentation, tutorials, community, and now agent skills. AMD's MI300X is a phenomenal chip (192GB HBM3, competitive with H100 for many workloads), but the developer experience gap is real.

Agent skills are the newest frontier of this gap. When a developer asks Claude Code to "set up my AMD GPU for PyTorch", the agent should know how. Without a skill, it hallucinates or gives generic advice. With a skill, it follows a tested, verified workflow.

10 skills won't close a 428-skill gap. But it's a start — and it's open source.

Contributing

Want to add a skill? Here's how:

Fork the repo
Create skills/your-skill-name/SKILL.md with frontmatter
Add scripts/ with executable Python/Bash
Add references/ with technical docs
Ensure multi-GPU support (ROCm + CUDA + CPU)
Submit a PR

See CONTRIBUTING.md for the full guide.

Skills I'd love to see contributed

rocm-tuning — ROCm performance tuning (HIPBLAS, RCCL, MIOpen)
onnx-rocm — ONNX Runtime with ROCm execution provider
fsdp-rocm — Fully Sharded Data Parallel on AMD GPU
triton-rocm — Triton kernels on ROCm
composable-kernel — AMD CK for custom kernels

Install Now

npx skills add yechua-silva/amd-rocm-skills --list

Repo: github.com/yechua-silva/amd-rocm-skills

License: Apache 2.0

Built during AMD Developer Hackathon Act II — Pista Unicornio. If you're using AMD GPUs with AI agents, I'd love to hear your feedback.

ZyroCLI: An Orchestrator That Gives AI Agents a Memory — and a Conscience

Yechua Silva — Tue, 30 Jun 2026 14:48:27 +0000

The Problem: Every AI Session Starts at Zero

If you've used AI coding assistants, you know the loop:

You describe your project.
The agent writes code.
You close the session.
Tomorrow, you start over.

The agent doesn't remember architectural decisions. It doesn't know why you chose PostgreSQL over MongoDB. It doesn't recall that auth.go was refactored last week. Every conversation is stateless — and stateless agents produce inconsistent, repetitive, and often conflicting code.

This isn't a tooling problem. It's a memory problem.

What ZyroCLI Actually Does

ZyroCLI is an orchestrator for OpenCode that runs a full software development pipeline (SDD) through specialized AI agents. It doesn't replace your IDE or your chat interface. It sits between you and the agent, enforcing structure, persistence, and safety.

The pipeline has five macro-phases:

Phase	What happens
PRE-F0	Alignment, domain modeling, architectural triage
F0	Research: patterns, libraries, skills discovery
F1	Specification: technical PRD with deep modules
F2	Design: component breakdown into atomic tasks
F3	Implementation: code + tests with verification loops
F4	Closure: archive, lint, final build

Each phase is executed by a different agent skill, with its own LLM model, its own security policy, and its own memory context.

Four Design Decisions Worth Understanding

1. Causal Memory (Not Chat History)

Most tools append messages to a context window and hope for the best. ZyroCLI stores decisions as facts in a causal graph (HelixDB, graph + vector database).

Each fact is a node. Relationships like CAUSED, PRECEDES, and CONTRADICTS are edges. Before every phase, the orchestrator queries the graph for relevant context. After every phase, it extracts new facts and resolves contradictions.

Why a graph? Because "we chose JWT over session cookies" is a decision that causes downstream constraints. A vector search finds semantically similar facts. A graph traversal finds causally related ones. You need both.

2. Agent-as-Validator (Separation of Opinion and Execution)

The Python agent never writes to the database. It returns a AgentDecision (validated by Pydantic), and the Go orchestrator decides whether to execute it.

This matters because unconstrained agents hallucinate tools, skip phases, and corrupt state. Separating "what the agent thinks" from "what actually runs" is the same pattern we use in human code review — but automated and enforced.

3. Security by Phase (Boundari)

Not every phase needs the same permissions. The research agent (F0) gets read-only access. The implementation agent (F3) gets write access but requires approval for dangerous commands. Policies are YAML-defined and loaded dynamically.

This is the principle of least privilege applied to AI agents. An agent researching libraries shouldn't be able to rm -rf your repo.

4. Hybrid Search with Local Embeddings

Memory queries use vector ANN + BM25 + RRF fusion. Embeddings run locally via Ollama (nomic-embed-text, 768d, GPU via Vulkan). If Ollama isn't available, it degrades gracefully to BM25.

Local embeddings mean your project context never leaves your machine. For teams working with proprietary code, this isn't optional.

The Boomerang Cycle: Micro-Execution Inside Each Phase

Each macro-phase runs an internal 6-step cycle (Memory → Think → Delegate → Git Check → Quality → Save). But not all phases need all steps.

ZyroCLI v3.1.0 implements a Phase Skip Matrix:

           MEMORY  THINK  DELEGATE  GIT CHECK  QUALITY  SAVE
PRE-F0  │   ✅      ✅      ✅        —          —       ✅
F0      │   ✅      ✅      ✅        —          —       ✅
F1      │   ✅      ✅      ✅        —          —       ✅
F2      │   ✅      ✅      ✅        —          —       ✅
F3      │   ✅      ✅      ✅        ✅         ✅      ✅
F4      │   ✅      —       ✅        ✅         —       ✅

F0-F2 are research/design — no git validation needed. F3 is implementation — needs tests and quality gates. F4 is closure — archive only. This cuts ~40% of overhead versus running all six steps unconditionally.

Benchmarks: The Honest Numbers

We ran 24 completed sessions (3 incremental features × 3 iterations × 3 approaches) using DeepSeek V4 Flash via OpenCode Zen (free tier).

Metric	Plain OpenCode	gentle-ai	ZyroCLI
Tokens Input	199,817	262,069	213,391
Tests Generated	0%	0%	27-66% coverage
Modularity	1 file	1 file	2-3 files
Avg Time	34s	41s	121s

What this means:

ZyroCLI uses fewer input tokens than gentle-ai (-35%) because causal memory injects filtered context instead of dumping the entire chat history.
It's the only approach that generates tests automatically and refactors into multiple files.
It's 2.5× slower. The Boomerang cycle has real overhead. For quick one-off tasks, plain OpenCode is faster.
For multi-file features where consistency matters, the tradeoff is worth it.

Architecture at a Glance

Human ──→ ZyroCLI (Go) ──→ OpenCode (AI Agents)
              │                     │
              ├── HelixDB (graphs)  ├── PydanticAI (validation)
              ├── Boundari (security) ├── Boomerang (execution cycle)
              └── Causal Memory     └── Skills (16 specialized agents)

The Go orchestrator handles scheduling, security, and persistence. The Python agents handle reasoning, planning, and code generation. The boundary between them is strict by design.

Who Is This For?

ZyroCLI is not for everyone.

Use it if:

You're building features that span multiple files and sessions.
You need architectural consistency across AI-generated code.
You want automated tests and quality gates without manual prompting.
You work with proprietary code and need local embeddings.

Don't use it if:

You need a quick one-file script. The overhead isn't worth it.
You prefer manual control over every line of AI-generated code.
You're on hardware that can't run Ollama locally.

How It Helped Build Real Projects

ZyroCLI was dogfooded to develop two other projects:

Cadence: An autonomous job search agent with multi-agent debate (Advocate + Critic + Judge), semantic caching, and zero-cost architecture. The SDD pipeline ensured the LangGraph orchestrator, PydanticAI agents, and browser automation layers stayed consistent across 20+ nodes.
AgentTrail: A cryptographic audit trail SDK for EU AI Act compliance. The F1-F2 phases generated the technical specification for SHA-256 chaining and Ed25519 signatures before any code was written.

In both cases, the pipeline prevented the "agent amnesia" that usually hits after session 3.

Getting Started

# Install
curl -sSL https://github.com/yechua-silva/zyrocli/releases/latest/download/install.sh | bash
zyrocli install
zyrocli doctor

# Create a handoff
cat > handoff.yaml << 'EOF'
project:
  name: my-api
  description: REST API with JWT auth
  technologies: [Go, PostgreSQL, JWT]
EOF

# Run the pipeline
zyrocli init handoff.yaml
zyrocli run --phase F0

The TUI (zyrocli without args) walks you through model selection, GPU detection, and per-agent LLM routing.

The Bigger Picture

AI-assisted development in 2026 is shifting from "generate code faster" to "generate consistent code across sessions." The bottleneck isn't typing speed — it's context management.

ZyroCLI treats this as an infrastructure problem. Memory, security, and execution control are first-class concerns, not afterthoughts. The result is an agent that remembers why it built things the way it did — and can explain it to the next agent, or to you, six months later.

Links:

MIT License. Contributions welcome.