---
name: version-aware-workflow
description: "Use when researching fast-moving projects. Version-first."
version: 1.0.0
author: Hermes Agent
license: MIT
platforms: [linux]
metadata:
  hermes:
    tags: [freshness, research, versioning, fast-moving, staleness]
    related_skills: [research-driven-debugging, better-search, deep-research]
---

# Version-Aware Workflow — Don't Get Burned by Stale Info

Fast-moving AI/ML projects (ComfyUI, LTX Video, Open WebUI, Hermes Agent, Qwen, etc.) change weekly. APIs break, nodes get renamed, workflows from last month don't run today. A web search finds a blog post from March, and the agent confidently gives broken instructions.

This skill encodes the workflow to prevent that.

## Core Rules (Apply to Any Fast-Moving Project)

### 1. Date-Gated Searches by Default

For any project that releases weekly or monthly, append recency operators to searches:

```
after:2026-06-01
"July 2026"
"last month"
site:github.com/{owner}/{repo} (release OR changelog)
```

A 4-month-old tutorial is archaeology. A 2-month-old blog post is suspect. Only official release notes and docs survive longer.

### 2. Version-First, Not Solution-First

Before searching "how to do X":
1. Check what version is INSTALLED (pip show, git log -1, docker inspect, `hermes --version`)
2. Check what version is CURRENT (GitHub releases page, PyPI)
3. If installed != current, the fix may be different

### 3. Release Notes Before Random Fixes

When something breaks:
1. Check the project's GitHub releases/changelog FIRST
2. The breakage is often documented as an intentional change
3. Only then search for error messages

### 4. Test One Atomic Step Before Building the Whole Plan

Do NOT design a 10-step workflow and execute all 10. Step 7 will fail because step 1's assumptions were wrong.

Instead:
1. Verify step 1 actually works (run it, check output)
2. Only then write step 2
3. Repeat

### 5. Prefer Official Docs Over Tutorials

A blog post from February titled "How to use ComfyUI MultiGPU" is almost certainly wrong today. The project's own README, docs site, or GitHub releases page is more likely current.

Priority order for sources:
1. Project's own GitHub releases / changelog
2. Project's own docs site / README
3. Official HuggingFace model cards
4. Recent GitHub issues (last 30 days) with maintainer comments
5. Community (Reddit, Discord) — only if dated within 14 days
6. Blog posts / tutorials — only if dated within 30 days AND cross-referenced

### 6. Check HuggingFace for Max Precision

When downloading models for a workflow, always check HuggingFace for higher precision variants. Download BOTH: what the workflow references (so it works as-is) AND the max precision version (for future quality switching).

Precision hierarchy: bf16 > fp16 > fp8 > int8 > GGUF Q4 > GGUF Q2

Procedure:
1. Read the workflow to identify model filenames
2. Search HuggingFace for the same model without fp8/GGUF suffixes
3. Check file sizes — bf16 is roughly 2x fp8, 4x GGUF Q4
4. Download both variants to the correct directories
5. Leave the workflow untouched — it uses the fp8 ref; bf16 is on disk for later

## When to Apply

Trigger on ANY of:
- ComfyUI (nodes, workflows, custom nodes, models)
- LTX Video (any version)
- Open WebUI
- Hermes Agent itself
- Qwen Image / Qwen models
- Any project with weekly+ release cadence
- User explicitly says "this is moving fast" or "things have changed"

## Pitfalls

- **Don't trust your training data.** If you "know" how to do something but haven't verified it works on the CURRENT version, you're guessing. Search.
- **Don't chain assumptions.** Each unverified step multiplies failure probability.
- **Don't skip the version check.** It takes 5 seconds and saves hours of debugging.
- **Don't treat all search results equally.** A GitHub release from yesterday beats a Medium article from January. Weight by source type and date.
- **The user's frustration is the signal.** If they say "you find old info and think it works" — you violated this skill. Stop, check versions, re-search with date filters.

## Related

- `research-driven-debugging` — When a build or config fails, dispatch research
- `better-search` — Medium-depth web research dispatcher
- `deep-research` — Exhaustive deep web research