work-from-beta

Étoiles16

Forks4

Mis à jour25 juin 2026 à 04:07

Set the session to work off the BETA branch. Use when the user says "work from beta" (or "work off beta", "start from beta"). Fetches everything, prunes, and starts a fresh working branch rebased on the latest origin/BETA; for the rest of the session all work is committed to that branch and PR'd into BETA when complete. A stopgap until branch selection exists on mobile so the user doesn't have to send the full setup prompt every time.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

TheAngryRaven

TheAngryRaven/DovesDataViewer

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name

work-from-beta

description

Work From Beta

A tiny session-setup skill. When the user says "work from beta", do the setup below, then reply with the exact ready line — and treat the BETA workflow as the standing convention for the rest of the session.

On invocation — do this immediately

Fetch and prune:
```
git fetch --all --prune --tags
```
Start a fresh working branch rebased on the latest origin/BETA (do not work directly on BETA or main):
```
git checkout -B claude/<short-task-slug> origin/BETA
```
If you don't have a task yet, use a generic slug like claude/beta-work and rename later, or branch when the first task arrives — the point is the branch is based on the just-fetched origin/BETA.
- If the working tree is dirty, stop and ask before resetting — don't discard the user's uncommitted work.
Reply with exactly this line and nothing else:
```
Ready and working from beta branch
```

Standing convention for the rest of the session

Once invoked, this holds for every task until the session ends or the user says otherwise:

Base all work on the latest origin/BETA (re-fetch if a task starts much later).
Commit work to the working branch, never push to BETA or main directly.
When a piece of work is complete, open a PR into BETA (base BETA, head the working branch). Owner/repo: TheAngryRaven/DovesDataViewer. Use the GitHub MCP tools (mcp__github__create_pull_request) in the remote/web environment, or gh locally. Do not open PRs into main.
Use a new task-specific branch per distinct piece of work, each off the current origin/BETA.

That's it — this exists so the user can type "work from beta" instead of pasting the whole branch-setup prompt on mobile.

Plus depuis ce dépôt

même dépôt

beta-release-review

TheAngryRaven/DovesDataViewer

Deep, multi-agent release-gate review of a BETA → main pull request (the release PR), posted as a report comment on the PR. Use when the user asks to "review the beta to main PR", "review the release PR", "is beta ready to merge into main", "release review", or "gate the release". Reviews the PR DIFF (everything on BETA since it diverged from main), runs fixed dimensions with adversarial verification, and produces a severity-sorted report plus an explicit GO / GO-WITH-FIXES / NO-GO verdict — then posts it as a PR comment. For a whole-codebase audit use `codebase-review`; for an arbitrary working diff use the built-in `code-review`.

2026-06-2516

beta-release-prep

TheAngryRaven/DovesDataViewer

Prepare the BETA branch for release into main. Use when the user wants to "prep beta", "cut a release", "get beta ready for main", or "do release prep". Researches every commit between the last release tag and BETA to verify the CHANGELOG is complete and to build release notes, creates a release branch off BETA, flips the eye-in-the-sky coach plugin from the BETA git dependency to the published production npm package, sets the version in package.json to match the topmost unreleased CHANGELOG heading, dates that heading to today, runs the green-before-merge checks, opens a PR into BETA, ensures a BETA→main PR exists whose body is copy-paste-ready release notes, and opens a follow-up "flip coach back to BETA" PR to merge after release. Documents the manual post-release tag + back-merge of main into BETA. Never creates tags.

2026-06-2516

codebase-review

TheAngryRaven/DovesDataViewer

Deep, multi-agent professional code-review audit of the WHOLE codebase (not the working diff). Use when the user asks for a "deep dive", "harsh review", "audit", "professional review", "find all the issues", or otherwise wants a prioritized backlog of everything wrong with the project — architecture/modularity, coupling, god files, security, performance, testing/regression coverage, and CI. Produces a single severity-sorted Markdown report. For reviewing the current diff/PR instead, use the built-in `code-review` skill.

2026-06-2416

name

work-from-beta

description

Work From Beta

On invocation — do this immediately

Fetch and prune:
```
git fetch --all --prune --tags
```
Start a fresh working branch rebased on the latest origin/BETA (do not work directly on BETA or main):
```
git checkout -B claude/<short-task-slug> origin/BETA
```
If you don't have a task yet, use a generic slug like claude/beta-work and rename later, or branch when the first task arrives — the point is the branch is based on the just-fetched origin/BETA.
- If the working tree is dirty, stop and ask before resetting — don't discard the user's uncommitted work.
Reply with exactly this line and nothing else:
```
Ready and working from beta branch
```

Standing convention for the rest of the session

Once invoked, this holds for every task until the session ends or the user says otherwise:

Base all work on the latest origin/BETA (re-fetch if a task starts much later).
Commit work to the working branch, never push to BETA or main directly.
When a piece of work is complete, open a PR into BETA (base BETA, head the working branch). Owner/repo: TheAngryRaven/DovesDataViewer. Use the GitHub MCP tools (mcp__github__create_pull_request) in the remote/web environment, or gh locally. Do not open PRs into main.
Use a new task-specific branch per distinct piece of work, each off the current origin/BETA.

That's it — this exists so the user can type "work from beta" instead of pasting the whole branch-setup prompt on mobile.