actionista v0.2.0

#What’s New

Every GitHub Actions workflow I touch has the same problem: outdated action versions. Not by weeks — by major versions. actions/checkout@v3 when v6 is out. setup-node@v3 when v6 dropped the always-auth input entirely. You bump the version, something breaks, and now you’re reading release notes at 11pm.

Actionista fixes this by giving Claude Code three things it didn’t have before: an MCP server that knows current action versions, migration diffs that track what actually changed between majors, and a daily self-updating index so the data stays fresh without me lifting a finger.

The MCP server is a bash stdio JSON-RPC server — three tools:

• lookup_action — version info, inputs, and migration data for any tracked action
• list_actions — browse all 118 actions by category
• check_workflow — point it at a workflow file, get back a report of what’s outdated and what changed

Migration diffs are the part that matters. The index doesn’t just say “you’re on v3, latest is v6.” It tells you actions/setup-node v5→v6 removed the always-auth input. actions/download-artifact v7→v8 added skip-decompress and digest-mismatch. Mechanical input diffs computed from the actual action.yml files, enriched by Claude reading the release notes and writing plain-language summaries.

Self-updating index — a daily cron fetches versions via batched GraphQL, Claude reviews the diff and creates a PR. When the PR merges, a release tags automatically and the marketplace listing updates itself. The whole pipeline runs unattended.

#Getting Started

/plugin marketplace add claylo/claylo-marketplace
/plugin install actionista@claylo-marketplace

That’s it. The skill activates when you work with workflow files. The MCP server starts automatically. Ask about any action by name, or point check_workflow at your .github/workflows/ directory.

#How We Built This

I came in with a short list of loose ends — a couple of tracked actions that 404’d, checkout@v4 references scattered across 45 files when v6 was out (ironic for a tool that tracks action versions), and a README that still mentioned a Node.js updater script that had been rewritten in bash months ago.

The MCP server wasn’t on the original list. The .mcp.json pointed at a nonexistent actionista-mcp binary — a placeholder for a planned Rust server. Clay asked what we should do about it, and a bash stdio server turned out to be the right call. It reads a JSON file and responds to queries. That’s a jq problem, not a systems programming problem.

The migration diffs came from a natural follow-up question: now that we have Claude in the update workflow, what would make the index actually useful for upgrades? The answer was a two-pass architecture — first GraphQL batch fetches current versions, second batch fetches the previous major’s action.yml using GitHub’s floating major version tags. Diff the inputs, store the delta. 48 of 118 actions had meaningful input changes between their last two majors. Claude then reads the release notes and writes the “here’s what you actually need to do” summaries.

The code review caught three real bugs before release: the JSON-RPC server crashed on string IDs (the spec allows strings, numbers, or null — we were calling tonumber on everything), the category error path in list_actions produced garbage output, and check_workflow was matching commented-out uses: directives. All fixed, all verified.

The release pipeline was the last piece — release-on-update.yml triggers when the daily index PR merges, bumps the patch version, tags, releases, and fires a repository_dispatch to the marketplace repo. The marketplace workflow receives the event and updates its listing. No manual versioning, no manual marketplace updates. Ship it and forget it.