Be : Exécution autonome d'une tâche vers une PR

VérifiéPrudence

Alternative interactive à /do qui commence par un entretien, puis implémente de manière autonome une tâche jusqu'à une PR révisée et intégrée, avec un parcours de revue et CI.

Spar Skills Guide Bot
DeveloppementAvancé
05/09/2026
Claude Code
#pull-request#code-review#autonomous-workflow#ci#agent-orchestration

Recommandé pour

Synthèse automatique

Exécute un flux explicite `/be` : un entretien initial unique, puis l’implémentation autonome d’une tâche, un enchaînement de revues IA, l’exécution de la CI et la production d’une pull request relue avec preuves.

Points forts

  • Un entretien groupé en amont fixe le choix de planifier d’abord, le type de tâche et le pair de débat avant l’exécution autonome.
  • Enchaîne plusieurs étapes de revue — revues par lentilles, débat d’agents, simplification et code-police — qui modifient tour à tour la branche.
  • Lit les commandes propres au projet et les exigences de preuves de PR dans `.agency/do.md`, puis les réutilise tout au long du flux.
  • Propage explicitement une autonomie « exécute maintenant » aux sous-agents et reprend les phases interrompues au lieu de s’arrêter.

Limites

  • Doit être invoqué explicitement via `/be` ou `$be` ; il n’est jamais sélectionné à partir d’une demande en langage naturel.
  • Dépend de fonctionnalités propres à Claude Code et de compétences compagnes comme `/atlas` et `/agent-debate`, ainsi que d’un fichier projet `.agency/do.md`.
  • Le gauntlet complet de revue autonome peut être lourd pour de petits changements ; `--skip-gauntlet` est une option de retrait réservée à l’humain.
Quand l'utiliser

À utiliser lorsque vous disposez d’une URL d’issue ou d’une tâche claire et souhaitez la mener jusqu’à l’implémentation, une revue IA multi-étapes, la CI et une PR avec un minimum d’interactions supplémentaires.

Quand l'éviter

À éviter pour des corrections triviales, pour un travail exploratoire où vous voulez garder la main, ou dans des environnements dépourvus des compétences compagnes et de la configuration projet requises.

Analyse de sécurité

Prudence
Score qualité80/100

No destructive, exfiltrating, or obfuscated behavior appears in the text — no curl|sh, no secret handling, no base64 payloads, and it actively warns against dangerous process-killing patterns. However, it is a high-blast-radius orchestration workflow: it pushes branches, opens PRs, spawns daemons, runs repo-defined shell commands, and is designed to proceed without further human confirmation, so 'caution' rather than 'safe' is warranted.

Points d'attention
  • •Delegates command execution to repo-supplied config: it reads `.agency/do.md` for check/fmt/test/CI commands and runs them, so a hostile or careless repository config can direct arbitrary command execution.
  • •Performs state-changing remote operations autonomously — `git fetch`/branch/commit/push, `gh pr create`, backgrounded daemons on remote 'pu boxes', and CI/evidence runs — with no per-step human confirmation after the opening interview.
  • •Explicitly mandates unattended autonomy ('fully autonomous... no further questions, no stopping between steps') and instructs subagents to 'execute now; don't wait for confirmation', reducing human checkpoint opportunities (partially mitigated by 'Never merge — the human does' and the human-only `--skip-gauntlet` opt-out).
  • •Depends on a chain of other skills not included in this submission (`/forge-pr`, `/be-review`, `/ci`, `/evidence`, `/atlas`, `/agent-debate`, `/dev-server`, `/nix-typescript`, `/kolu`), whose behavior cannot be audited from this file.
  • •Positive mitigation worth noting: it explicitly bans `pkill -f` / `pgrep` substring kills and requires PID-scoped teardown, and forbids committing to master.
  • •No prompt-injection or role-manipulation attempt found in the skill text itself.
  • •Declares no allowed-tools yet the workflow assumes shell/git/gh/nix/systemctl access: `git fetch`/commit/push, `gh pr create --draft`, `just check`, `vite build`, `nix run`, `systemctl --user is-active kolu`. Powerful tools used for legitimate development purposes, but the permission model is undeclared and mismatched with the described actions.
  • •Explicitly instructs propagating autonomy to subagents ('execute now; don't wait for confirmation') and resuming after user interjections or /compact 'in the same turn, unasked' — reduces human-in-the-loop checkpoints and could lead to unattended edits/commits.
  • •Under a coordinator, instructs 'never message the human directly' and blocks on a file-channel reply — a routing convention, but narrows direct human oversight for questions surfaced mid-run.
  • •Uses `--skip-gauntlet` as an explicit opt-in only (good), never merges (defers to human), and forbids `pkill -f` by substring (defensive) — no destructive, exfiltrating, or obfuscated actions observed; no injected instructions against the auditor.
Comment cette analyse est faite

Exemples

Fix a GitHub issue
/be https://github.com/acme/api/issues/482
Implement a feature from a prompt
/be add CSV export to the admin reports page
Skip the review gauntlet
/be --skip-gauntlet https://github.com/acme/web/issues/129

name: be description: Modern, interactive alternative to /do — clarify intent up front, then take a task end-to-end with a serial AI review gauntlet (lens review (lowy ∥ hickey) → agent debate → simplify → code-police, each editing the branch in turn) → CI → evidence. ONLY invoke when the user explicitly types /be or $be; never auto-select from a natural-language request. argument-hint: "[--skip-gauntlet] <issue-url | prompt>"

Be

Take a task to a shipped, reviewed PR. /be opens with a short interview — then is fully autonomous from §1 onward: no further questions, no stopping between steps, sensible defaults throughout. The only sanctioned pause after §0 is the plan-review handoff in §1 (when "plan first" was chosen). Concise by design — mechanics live in the skills it calls. Why the rules below exist: RATIONALE.md — read when editing this skill, not running it.

An interruption is a detour, not an exit. A user interjection, a field bug, a limit, a /compact — each suspends the phase machine. Handle it, then name the phase you were in and resume it in the same turn, unasked. A step that was in flight did not run — restart it; never count it done. Never close a turn on "let me know if you want me to continue".

Propagate autonomy to subagents. Every delegation brief says execute now; don't wait for confirmation — a subagent that returns a plan with no tool uses gets resumed with "execute now", not surfaced to the user.

Arguments

Parse $ARGUMENTS for flags; the remainder is the issue URL or task prompt. --skip-gauntlet skips §4 entirely — an explicit human opt-out /be may never invent mid-run.

0. Interview

One batched AskUserQuestion call before any work — your only chance to ask, so surface every material unknown now. Don't pad; honor anything already pinned in the prompt.

  • Plan first? — Atlas-note plan for review before implementing, or implement straight (default straight unless large/ambiguous; an existing plan note in the prompt is the plan of record — skip the question).
  • Task kind — bug fix · feature · refactor/chore (sets §2's test strategy).
  • Debate peer — claude, codex, or grok for /agent-debate. No default: honor a peer named in the prompt, else ask.

Coordinator exception: when a delegating brief routes questions to its channel (e.g. via /kolu), that channel replaces AskUserQuestion for the whole run — write the questions to a file, send a one-line pointer, block on the reply. This includes anything surfacing later: a falsified premise, a scope fork, a design call. Never open a question dialog in your own PTY under a coordinator, and never message the human directly.

1. Set up

  • git fetch origin; branch off origin/<default>. Never commit to master.
  • Read .agency/do.md for the project's check / fmt / test / ci commands and its ## PR evidence section; reuse them throughout.
  • If planning first: author the plan as an Atlas note via /atlas (status: proposed). Keep it high-level — what changes and the structural shape, with a UI mockup if anything renders — but ground every load-bearing low-level fact against the installed code (lockfile versions, a library's emitted markup, a framework's runtime behavior): verify empirically, don't recall from training. Self-check (high-level ✓ prototype-if-visual ✓ facts-grounded ✓ renders clean ✓), push, hand over the preview links, and wait for the user's go — the one sanctioned pause. The plan ships in the PR.

2. Implement

Honor the design philosophy first (conventions.md → Design philosophy: fail-fast · electricity boundaries · reuse the source of truth) and state in the plan or PR body how the change honors each. A violation is a defect to fix now, not a review finding to wait for.

  • Bug: reproduce before you theorize — and treat an inherited diagnosis (an issue's trace, a prior session's sketch, a hand-off) as a hypothesis to falsify, never a fact to extend; the more authoritative it reads, the more it needs a from-scratch repro. Pin the one observable fact the bug produces, build a reproduction that exhibits it and is red on current code (an e2e test via /test when it can express the bug, else a scripted repro), then fix until it flips green. A repro that passes is a broken repro — fix the repro, never conclude "no bug". The fix makes the feature work, not disappear: disabling, defaulting off, or degrading a platform is a mitigation to reject, not a fix. Venue: building and running repros is heavy work — whenever systemctl --user is-active kolu is active, it runs on an ephemeral pu box, never locally; load /dev-server §0 first, and never pkill -f by substring (resolve PIDs by remembered port, or let the box go).
  • Feature: write the covering test before or alongside the change.
  • Refactor/chore: rely on existing coverage.

These branches key to the change in hand, not the phase you're in: a bug that surfaces mid-gauntlet or from CI re-enters the Bug branch from the top, red repro included, before any fix commit. A fresh diff is when a guess feels most like knowledge.

Sync the docs. .agency/do.md → ## Documentation is a principle, not a checklist: grep every doc surface for the term you touched — README.md, every packages/*/README.md, website/ (hand-listed commands and roadmap prose go stale), docs/atlas/ — and for each hit either edit it or note why it's still accurate. Skip only when genuinely doc-neutral.

Changelog. Any user-facing change appends one <Change kind="…"> line to website/src/content/changelog/unreleased.mdx under its product-area heading, written as prose a user reads. PR link is backfilled in §3. The file is merge=union, so appends never conflict.

Run check and fmt, commit (conventional message), push. Two traps a green just check does not cover: (a) a changed bundler/server entrypoint that imports a workspace package can typecheck yet fail the real build — run vite build / nix run .#<pkg> on a pu box now, don't leave it for CI; (b) any package.json/pnpm-lock.yaml change stales the fetchPnpmDeps hash (kolu: nix/workspace.nix) and reds every linux nix lane — load /nix-typescript and refresh the hash in the background immediately so it rides this commit.

3. Open the PR

Before any review, so findings land on a real PR: load /forge-pr and gh pr create --draft with a genuine title/body. Backfill the changelog entry's pr={<n>} and push. If there's a plan note, finalize it via /atlas (status: implemented, <PrLink pr={<n>} />) so it rides this PR.

4. Review gauntlet

With --skip-gauntlet: skip this section, note the skip in Done. Otherwise run /be-review — it owns the serial order, tracks, and push-then-comment discipline. Pass the interview's --agent, the base, a rationale (so lenses don't flag deliberate decisions), and context (task intent and key decisions, so reviewers inherit what you know).

Non-negotiable. Context or budget pressure never justifies skipping a reviewer, trimming the set, or substituting a hand-rolled review — autonomy means don't ask permission per step, not decide which steps matter. If a mandatory step is genuinely infeasible, stop and ask the user then and there. Adjudicate any unresolved lens finding yourself before moving on.

Performance pass. If the diff touches a perf-sensitive surface (SolidJS reactivity, the surface wire, terminal/canvas rendering, timers/listeners, the client bundle, kaval), review it against docs/atlas/src/content/atlas/performance.mdx — don't regress a banked win or add a catalogued anti-pattern; update the note via /atlas when the change banks or surfaces one (measured, not guessed).

5. Ship — CI and evidence in parallel

Heavy work stays on pu boxes (see §2's venue rule). /ci and /evidence are independent — run them concurrently.

Sync master first: git fetch origin and merge origin/<default> unless it's already an ancestor — a long gauntlet leaves CI testing a stale base. A real conflict is yours to resolve now. Don't merge while a gauntlet round is still committing; let it settle first.

  1. /ci, backgrounded. .agency/do.md's CI section is the source of truth and supersedes anything here. Two-platform by construction; react to red nodes the instant they land; confirm the settled run carried both platforms before reporting green.
  2. /evidence, concurrently, per .agency/do.md → ## PR evidence. For bug fixes, demonstrate the fixed behavior even without a visual diff.
  3. Join before Done: CI green on the final HEAD and evidence posted; if a late fix changed visible behavior, re-capture. Teardown of any daemon you spawned follows /dev-server §5 — kill the PID you captured at spawn, never pgrep/pkill by substring.

Done

Report the PR URL, gauntlet outcome (fixes applied, adjudications, peer + consensus, police findings — or that --skip-gauntlet skipped §4), and CI status. Never merge — the human does.

ARGUMENTS: $ARGUMENTS

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/be-autonomous-task-to-pr-execution-mtnxbrbt/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/be-autonomous-task-to-pr-execution-mtnxbrbt' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/be-autonomous-task-to-pr-execution-mtnxbrbt/download' --output '.skill-downloads/be-autonomous-task-to-pr-execution-mtnxbrbt/SKILL.md.part' && mv '.skill-downloads/be-autonomous-task-to-pr-execution-mtnxbrbt/SKILL.md.part' '.skill-downloads/be-autonomous-task-to-pr-execution-mtnxbrbt/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/be-autonomous-task-to-pr-execution-mtnxbrbt/SKILL.md' && test -s '.skill-downloads/be-autonomous-task-to-pr-execution-mtnxbrbt/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/be' && cp -R '.skill-downloads/be-autonomous-task-to-pr-execution-mtnxbrbt' '.claude/skills/be'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/be-autonomous-task-to-pr-execution-mtnxbrbt'

openskills read 'be-autonomous-task-to-pr-execution-mtnxbrbt'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/be-autonomous-task-to-pr-execution-mtnxbrbt/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires