Skill

Skill lythos-labs/lythoskill/packages/lythoskill-red-green-release/skill

User-acceptance-driven release workflow using heredoc patch files. Each iteration produces a timestamped pr-<timestamp>-<desc>.sh that self-archives after execution. No tag without explicit user LGTM. Supports rollback via archived backups.From its SKILL.md

Install

npx -y skills add lythos-labs/lythoskill --skill skill

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.9 KB, 855 tokens by cl100k_base, as published. Nobody here has run it

Red-Green Release Workflow

No tag without LGTM. Every change is a self-archiving patch. Every state is rollback-able.

Typical Scenarios

This skill shines when the agent does not have direct filesystem or git access to the user's project. Typical setups:

Web chat + Repomix: User pastes a Repomix dump of their codebase into a web chat. The agent proposes changes as pr-*.sh heredoc patches. The user copies the patch locally and runs bash pr-*.sh.
Distributed / async review: Patches are posted in issues, emailed, or shared via web UI for a human to review and apply manually.
No git on target: Environments (e.g., bare-metal servers, deployed configs) where git revert is unavailable — .bak files provide rollback.

In these scenarios the agent cannot git commit, git diff, or write files directly. The heredoc patch is the only viable delivery format.

Core Principles

User acceptance drives releases — "LGTM" / "对了" / "就是这样" → then and only then commit + tag.
Atomic patches — Each iteration = one pr-<timestamp>-<desc>.sh with heredoc content replacement.
Self-archiving — Patch copies itself to archived-patches/ and deletes itself after execution.
Rollback-ready — Every patch backs up originals before modifying. Rollback = restore backup.

Workflow (4 Phases)

Phase 1 — Plan: Understand requirement, describe approach, user confirms design. Phase 2 — Create Patch (dry-run): Write pr-<timestamp>-<desc>.sh containing backup + heredoc replacement + self-archive logic. Show to user for review. User says "apply it" → proceed. Phase 3 — Apply & Test: Execute patch (bash pr-*.sh). Restart service. User tests. If issues → back to Phase 2 with a new patch. Iterate until green. Phase 4 — Accept & Tag: User says LGTM →

git add -A
git commit -m "<summary>"
git tag -a <tag> -m "<summary>"

Patch File Format

Naming

pr-<timestamp>-<description>.sh

Forbidden words in description: final, done, fix, ok. These words encourage skipping the red-green test cycle by implying pre-verified success.

Template

#!/bin/bash
# PR: <timestamp>-<description>
# 1. Create archive directory
mkdir -p archived-patches
# 2. Backup current files (for rollback)
cp src/target.ts "archived-patches/target.ts.$(date +%Y%m%d).bak"
# 3. Apply changes (declarative full-file replacement via heredoc)
cat > src/target.ts << 'PATCH_EOF'
// Full replacement content here — exact file state after patch
PATCH_EOF
# 4. Self-archive: copy patch to archive, then delete from root
cp "$0" "archived-patches/$(basename "$0")"
rm "$0"

⚠️ Heredoc delimiter (PATCH_EOF) must be quoted in the cat command to prevent variable expansion. See references/archive-format.md for multi-file patches and escaping rules.

Supporting References

Read these only when the specific topic arises:

When you need to…	Read
See complete heredoc syntax, multi-file patches, and escaping rules	references/archive-format.md
Understand the 4-phase workflow in detail	references/phase-details.md
See conversation examples of red-green iterations	references/conversation-examples.md

What ships with it: 3 files

4.3 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most ship operate skills give in 855 tokens

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07

Document a rollback plan before deploymentin 41 of 779, across 22 files
Update the changelogin 21 of 779, across 19 files
Run the test suitein 20 of 779
Create an annotated git tagin 20 of 779
Clean up feature flags after full rolloutin 18 of 779, across 10 files
Verify deployment health after launchin 18 of 779, across 10 files
Test both feature flag statesin 17 of 779, across 9 files
Verify the working tree is cleanin 17 of 779
Make database migrations backward-compatiblein 16 of 779, across 8 files
Set up error monitoring before launchin 15 of 779, across 7 files
Monitor metrics at each rollout stagein 14 of 779, across 5 files
Create a GitHub releasein 14 of 779

Said here and by no other author read

produce one self-archiving patch file per iteration
back up original files before modifying them
ensure every state is rollback-able
write descriptive patch names excluding forbidden words
show the patch to the user for review before applying
execute the patch script using bash

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.