Option

Überprüfen Sie den Zustand von Compound Engineering und die lokale Repo-Konfiguration.

...Alle erweitern
10
Zeit aktualisiert 26. August 2026

Über ce-setup

Ein schlanker Health-Check und Konfigurationsassistent für das Compound Engineering-Plugin. Er überprüft, ob eine Umgebung und ein Repository korrekt eingerichtet sind, meldet, welche optionalen Tool-Funktionen verfügbar sind, und bereinigt oder aktualisiert die repo-lokalen Konfigurationsdateien. Wichtig ist, dass es keine Abhängigkeiten massenhaft installiert: Fehlende Tools werden als optionale Funktionen angezeigt, sodass der Benutzer nur die Workflows installieren kann, die er tatsächlich nutzt. Es dient zur Überprüfung der Einrichtung, zur Fehlerbehebung bei fehlenden optionalen Tools oder zur Einbindung eines Repositorys.

Der Workflow läuft in drei Phasen ab. In der Diagnosephase ermittelt er die installierte Plugin-Version, sofern die Plattform diese bereitstellt, und führt anschließend ein mitgeliefertes Skript zur Zustandsprüfung (oder ein entsprechendes Inline-Äquivalent) aus. Die Inline-Prüfungen suchen mit dem Befehl -v nach optionalen Tools (agent-browser, gh, jq, ast-grep, ffmpeg), ermitteln das Repo-Stammverzeichnis mit `git rev-parse --show-toplevel`, suchen nach einer veralteten Datei `compound-engineering.local.md, prüfen, ob „.compound-engineering/config.local.yaml“ existiert und in der Git-Ignore-Liste enthalten ist, und vergleichen die Beispielkonfiguration mit der mitgelieferten „references/config-template.yaml“. Fehlende optionale Tools werden ausdrücklich nicht als Einrichtungsfehler behandelt.

Phase zwei wird nur ausgeführt, wenn ein repo-lokales Problem vorliegt: eine veraltete lokale Markdown-Konfiguration, eine config.local.yaml, die nicht sicher von Git ignoriert wird, oder eine fehlende/veraltete Beispielkonfiguration. Sie kann die veraltete Datei entfernen, die Datei „.compound-engineering/config.local.example.yaml“ anhand der Vorlage aktualisieren, optional eine neue „config.local.yaml“ erstellen (wobei zunächst alles auskommentiert ist) und vorschlagen, „.compound-engineering/*.local.yaml“ zur „.gitignore“-Datei hinzuzufügen. Jeder Änderungsschritt wird durch eine blockierende Frage über das Fragetool der Plattform gesteuert (AskUserQuestion in Claude Code, mit dokumentierten Fallbacks für Codex, Antigravity und Pi), und der Skill führt niemals stillschweigend eine automatische Konfiguration durch. Eine abschließende Zusammenfassung listet die angewendeten Korrekturen, die übersprungenen Korrekturen sowie eventuell fehlende optionale Tools auf.

FAQ

Installiert dieser Skill alle optionalen Abhängigkeiten für mich?

Nein. Es handelt sich um einen Zustandscheck, nicht um ein Installationsprogramm, und die Masseninstallation von Abhängigkeiten wird bewusst vermieden. Fehlende Tools werden als optionale Funktionen gemeldet, sodass Sie nur die Workflows installieren können, die Sie tatsächlich nutzen.

Nach welchen optionalen Tools sucht der integrierte Zustandscheck?

Er prüft mithilfe des Befehls -v nach agent-browser, gh, jq, ast-grep und ffmpeg. Fehlende Tools werden gemeldet, gelten jedoch nicht als Installationsfehler.

Wann wird tatsächlich mit der Behebung von Problemen begonnen?

Nur wenn ein repo-lokales Problem vorliegt: eine veraltete „compound-engineering.local.md“, eine „config.local.yaml“, die nicht in der Git-Ignore-Liste steht, oder eine fehlende/veraltete „config.local.example.yaml“. Trifft keiner dieser Fälle zu, wird gemeldet, dass die Einrichtung abgeschlossen ist.

Wird es meine Dateien ohne Rückfrage ändern?

Nein. Jede Korrektur – das Löschen der veralteten Konfiguration, das Erstellen einer lokalen Konfiguration oder das Bearbeiten von .gitignore – wird durch eine abfragende Frage gesichert und nur fortgesetzt, wenn Sie zustimmen. Es findet niemals eine automatische Konfiguration im Hintergrund statt.

Wie wird sichergestellt, dass die lokale Konfiguration nicht in die Versionskontrolle gelangt?

Wenn „.compound-engineering/config.local.yaml“ existiert, aber nicht von „.gitignore“ abgedeckt ist, bietet das Tool an, „.compound-engineering/*.local.yaml“ an die „.gitignore“-Datei im Repo-Stammverzeichnis anzuhängen, ohne nicht relevante Inhalte zu überschreiben.

Alle Dateien

3Dateien references/config-template.yaml 3,3KB Anzeigen scripts/check-health 5,7KB Anzeigen SKILL.md 5,5 KB Anzeigen
Auf GitHub ansehen

Interaction Method

Ask each question below using the platform's blocking question tool: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded), request_user_input in Codex, ask_question in Antigravity CLI (agy), ask_user in Pi (requires the pi-ask-user extension). Fall back to a numbered list on the host's user-visible chat surface only when no blocking tool exists in the harness or the call errors. Never silently skip or auto-configure.

ce-setup is a lightweight health check and repo-local config helper. It does not bulk-install every optional dependency. Missing tools are reported as optional capabilities so the user can install only the workflows they use.

Artifact Root Resolution

Every Compound Engineering skill that writes or reads an artifact directory (solutions, plans, ideation, and the other CE-owned trees) resolves its root through the rule below. ce-setup carries the canonical statement and reports the resolved root so an operator can confirm where artifacts land before running other skills.

Resolve the CE artifact root <root> before composing any artifact path.

  • Read docs_root from <repo-root>/.compound-engineering/config.yaml only (<repo-root> = git rev-parse --show-toplevel). Do not read it from config.local.yaml. Unset -> <root> is docs, exactly as before.
  • Validate a set value: a repo-relative directory whose real, symlink-resolved path stays inside the repo and is neither the repo root nor under .git/. Otherwise stop with an error naming docs_root and the value -- never fall back to docs.
  • Use <root> as the sole artifact location: create it if absent, compose each path as <root>/<subdir> with this skill's own subdirectory, and never also read docs.

Phase 1: Diagnose

Step 1: Determine Plugin Version

Detect the installed compound-engineering plugin version by reading the plugin metadata or manifest when the platform exposes it. If the version cannot be determined, skip this step.

If a version is found, pass it to the check script via --version. Otherwise omit the flag.

Step 2: Run the Health Check

Before running the script, display:

Compound Engineering -- checking your environment...

Run the bundled check script. Set SKILL_DIR to the absolute directory you loaded this ce-setup SKILL.md from — the Bash tool's CWD is the user's project, not the skill dir, so a bare scripts/ path will not resolve:

SKILL_DIR="<absolute path of the directory containing this SKILL.md>";if [ -f "$SKILL_DIR/scripts/check-health" ]; then bash "$SKILL_DIR/scripts/check-health" --version VERSION; else echo "Bundled health script not found at $SKILL_DIR/scripts/check-health; run the inline checks from ce-setup instead."; fi

Use the same command without --version VERSION if Step 1 could not determine a version.

If the script is unavailable, run the inline equivalent listed in references/repo-fixes.md.

Display the diagnostic output to the user. Missing optional tools are not setup failures. The health report includes the resolved artifact root and which config layer supplied it (per Artifact Root Resolution above); surface that line so the operator can confirm where CE artifacts will be written. Missing config.yaml is a reported absence, not a project issue.

Step 3: Decide Whether Fixes Are Needed

Report-gated repo-local remediations apply only to the checkout the health report diagnosed; if Phase 2 will write a different writable checkout, diagnose that checkout first, while session-level findings such as plugin version and optional tools remain from this session's Phase 1.

After the health report, decide Phase 2 from writable-checkout availability:

  • If this session has a writable git checkout, run Phase 2 locally, including when project_issues is 0. Phase 2 always refreshes the example and always offers to create config.yaml when that file is missing.
  • If this session has no writable checkout, but the user named a repository and the harness exposes a remote repo-work surface with a writable checkout, run Phase 2 on that surface instead and report the remote repo-local fixes in Phase 3.
  • Otherwise skip Phase 2 and go to Phase 3, saying repo-local writes were skipped because no writable checkout is available.

Also remediate these project issues when the report names them:

  • obsolete compound-engineering.local.md
  • .compound-engineering/config.local.yaml exists but is not safely gitignored
  • .compound-engineering/config.example.yaml is missing or outdated
  • the health report marks the ce-work skill implementation engine unavailable or invalid, detects retired scalar routing keys, or reports malformed dormant work_engine_preferences
  • the health report marks docs_root invalid (Invalid docs_root ...) — CE artifacts will not be written until it is fixed

If optional tools are missing, do not offer a bulk install. The diagnostic already printed the relevant install command or project URL. Say: "Install optional tools only for the workflows you use."

Phase 2: Fix Repo-Local Issues

Read references/repo-fixes.md from this skill's directory before making any repo-local change. It carries Steps 4-8: removing the obsolete compound-engineering.local.md, refreshing the example config, offering to create config.yaml, repairing invalid work_engine_preferences and docs_root, and the two .gitignore offers.

All paths there resolve from the repository root (git rev-parse --show-toplevel), not the current working directory. Maintaining the generated example files is the work Phase 2 does on its own — refreshing config.example.yaml and removing the superseded config.local.example.yaml. Every change to a user-owned file is offered and applied only if the user approves.

Phase 3: Summary

User-runnable invocation rendering. In setup summaries, default to /ce-setup; use $ce-setup only when the active host is Codex or explicitly documents dollar-prefixed skill invocation. On oh-my-pi (omp), use /skill:ce-setup. Render only the invocation as inline code and output one form only.

Display a brief summary:

✅ Compound Engineering setup completeFixed:     <repo-local fixes applied, or none>Skipped:   <repo-local fixes declined, or none>Optional:  <missing optional tools, or all available>Run `<rendered invocation>` anytime to re-check.

Alle Dateien

0 Dateien

ce-setup installieren

Laden Sie die Skill-Dateien herunter und entpacken Sie sie in Ihr Verzeichnis „.claude/skills/“.

ZIP herunterladen

Klonen Sie das Repository und kopieren Sie die Skill-Dateien in Ihr Projekt.

git clone https://github.com/EveryInc/compound-engineering-plugin/blob/main/skills/ce-setup/SKILL.md # Copy SKILL.md to your .claude/skills/ directory

Kopieren Kopieren
Schnelle Einrichtung: Kopiere den Skill-Ordner nach .claude/skills/. Claude erkennt den Skill automatisch und nutzt ihn.

Ähnliche Skills

github-project-management
Zeit aktualisiert 29. Juni 2026
using-git-worktrees
Zeit aktualisiert 29. Juni 2026
readme-blueprint-generator
Zeit aktualisiert 5. Juli 2026
finishing-a-development-branch
Zeit aktualisiert 29. Juni 2026
OR