flow-beta

Execute beta refactor TODOs with multi-LLM regression audits and wrap-up gates.

12|2|Updated Nov 27, 2024
One-click install
npx skills add https://github.com/Pionpill/retikz --skill flow-beta
Or copy as Structured Prompt for Agentā–¼
Please help me install this Agent Skill.
Skill: flow-beta
Source: https://github.com/Pionpill/retikz/tree/main/.agents/skills/flow-beta
Command: npx skills add https://github.com/Pionpill/retikz --skill flow-beta

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents beta refactors from silently introducing regressions by enforcing a structured 3-stage workflow with mandatory multi-LLM review, especially for breaking changes.

Core Features & Use Cases

  • Beta-only refactor execution: Guides implementation of plan TODOs in the retikz beta window with guardrails against scope creep (no new features/IR/public fields).
  • Multi-LLM safety net: Runs equivalence and benefit audits to confirm ā€œno regressionā€ and ā€œactually better,ā€ with stricter requirements for breaking/visible changes.
  • Controlled wrap-up: Requires roadmap check-off and, when applicable, changelog BREAKING sections and migration guidance.

Quick Start

Use the flow-beta skill to execute one registered beta plan TODO end-to-end from implementation through multi-LLM evaluation to wrap-up with required halting gates.

Frequently Asked Questions about flow-beta

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent regressions when executing beta refactors with breaking changes?ā–¼

Prevent regressions during beta refactors by enforcing a structured workflow with mandatory multi-LLM regression and equivalence audits. This approach confirms no regressions and verifies the change is actually better before allowing wrap-up.

What is multi-LLM regression testing for code refactoring?ā–¼

Multi-LLM regression testing runs independent equivalence and benefit audits to confirm code refactoring introduces no regressions and is actually better. It enforces BLOCKING, WARNING, and INFO convergence from two separate LLM evaluations before passing.

How do I execute a beta refactor plan TODO end-to-end?ā–¼

Execute a beta refactor plan TODO through implementation, mandatory multi-LLM regression evaluation, and final wrap-up. The workflow enforces hard gates on test, lint, and tsc success before allowing progression to the next stage.

Can I introduce breaking changes during a beta refactor window?ā–¼

Breaking changes are allowed during the beta refactor window if they include migration documentation. The workflow enforces stricter requirements for breaking items, requiring changelog BREAKING sections and roadmap check-off completion.

Does beta refactoring with multi-LLM evaluation work without adding new features?ā–¼

Beta refactoring focuses strictly on implementing plan TODOs with guardrails against scope creep. It explicitly prevents adding new features, IR, or public fields, ensuring changes remain isolated to the registered beta plan.

Why does my beta refactor workflow require convergence from two independent LLM audits?ā–¼

Two independent LLM audits provide a safety net by cross-validating refactor equivalence and benefits. Requiring convergence on BLOCKING, WARNING, and INFO statuses prevents silent regressions that a single evaluation might miss.