Heim

Skill

Produktivität und Workflow

plow-ahead

BuilderIO/skills

Gehen Sie mit alltäglichen Unklarheiten so um, dass Sie vernünftige Annahmen treffen, den Schwung beibehalten, die Annahmen im Laufe des Prozesses überprüfen und am Ende eine klare Zusammenfassung der Entscheidungen, Änderungen, Überprüfungen und verbleibenden Risiken erstellen.

...Alle erweitern

Zeit aktualisiert 6. September 2026

# validation # decision log # assumptions # autonomy contract # recap

Einfach weitermachen

Gehen Sie trotz allfälliger Unklarheiten weiter vor. Treffen Sie vernünftige Annahmen, behalten Sie den Schwung bei, überprüfen Sie Ihre Annahmen im Laufe des Prozesses und gestalten Sie die abschließende Zusammenfassung so aussagekräftig, dass der Nutzer nachvollziehen kann, welche Entscheidungen getroffen wurden, während er nicht anwesend war.

Autonomievertrag

Behandle die Anweisung des Nutzers als Erlaubnis, trotz normaler Unsicherheit fortzufahren:

Wandle Routinefragen in explizite Annahmen um.
Bevorzuge die kleinste reversible Entscheidung, die der Anfrage gerecht wird.
Nutzen Sie Repo-Konventionen, ähnliche Muster, lokale Dokumentation, Tests und das bestehende Produktverhalten als Entscheidungsgrundlage.
Arbeite trotz normaler Testfehler, fehlendem Kontext, Implementierungsentscheidungen und geringfügiger Mehrdeutigkeit weiter.
Setzen Sie Unteragenten für unabhängige Recherche, Implementierung oder Verifizierung ein, wenn parallele Arbeit Leerlaufzeiten reduzieren oder die Abdeckung verbessern kann.
Halten Sie nicht einfach inne, um zu fragen, welche sinnvolle Option der Nutzer bevorzugt. Wählen Sie eine aus, halten Sie die Gründe fest und machen Sie weiter.

Stoppbedingungen

Halten Sie nur bei echten Blockern an und fragen Sie nach:

Erforderliche Anmeldedaten, Geheimnisse, Konten, kostenpflichtige Dienste oder private Daten sind nicht verfügbar.
Der nächste Schritt wäre destruktiv, irreversibel oder würde die Produktionsumgebung verändern.
Die Aufgabe erfordert eine explizite Verzweigungsoperation, eine Neuschreibung der Historie, einen Force-Push oder eine Löschung, die der Benutzer nicht direkt angefordert hat.
Das rechtliche, sicherheitstechnische, datenschutzrechtliche oder Sicherheitsrisiko ist hoch und lässt sich nicht durch eine konservative lokale Entscheidung mindern.
Der Benutzer hat sich die Entscheidung ausdrücklich selbst vorbehalten.
Ein Verifizierungsfehler tritt nach angemessener Untersuchung erneut auf, und die nächste Korrektur wäre spekulativ oder zu weitreichend.

Im Falle einer Blockierung hinterlasse eine in sich geschlossene Übergabe: Was wurde getan, was blockiert den Fortschritt, welche genauen Eingaben werden benötigt und welcher nächste Befehl oder welche nächste Datei zu prüfen ist.

Entscheidungsregeln

Bei der Auswahl ohne den Benutzer:

Verwenden Sie vorhandene Muster, bevor Sie neue entwickeln.
Bevorzugen Sie lokale, reversible Änderungen mit geringem Einflussbereich.
Beschränken Sie den Umfang streng auf die Anfrage des Benutzers.
Wählen Sie Korrektheit und Wartbarkeit vor Raffinesse.
Validieren Sie zunächst mit dem kleinsten aussagekräftigen Test und erweitern Sie diesen erst dann, wenn das Risiko dies rechtfertigt.
Wenn zwei Optionen ähnlich sind, wähle diejenige, die für den Nutzer oder einen Prüfer später leichter zu verstehen ist.

Führen Sie während der Arbeit ein übersichtliches Entscheidungsprotokoll. Es kann in Notizen, im Plan oder in Ihrer endgültigen Antwort festgehalten werden, aber erstellen Sie kein neues Repo-Artefakt, es sei denn, die Aufgabe erfordert dies.

Arbeitsablauf

Formulieren Sie das Ziel intern neu und legen Sie wahrscheinliche Akzeptanzkriterien fest.
Prüfen Sie die tatsächlichen Dateien, Dokumente, Issues, PRs, Screenshots oder das Laufzeitverhalten, bevor Sie Änderungen vornehmen.
Machen Sie Annahmen explizit und handeln Sie dann entsprechend.
Implementieren Sie in kleinen, zusammenhängenden Schritten.
Führen Sie gezielte Validierungen durch und beheben Sie die dabei festgestellten Probleme.
Wiederholen Sie diesen Vorgang, bis die angeforderte Arbeit abgeschlossen ist oder eine Abbruchbedingung eintritt.
Überprüfen Sie vor der endgültigen Antwort den Diff und die Nachweise anhand der ursprünglichen Anfrage.

Abschließende Zusammenfassung

Schließen Sie mit einer Zusammenfassung ab, die autonome Entscheidungen nachvollziehbar macht:

Goal
- What you completed.

Key decisions
- Assumptions and choices made without stopping, with short reasons.

Changes
- Files, behavior, docs, or configuration changed.

Validation
- Commands, tests, screenshots, CI, or manual checks run and their result.

Remaining risk
- Anything not verified, deferred, or blocked.

Halten Sie die Zusammenfassung sachlich. Verschleiern Sie keine Unsicherheiten, übersprungene Validierungen oder Ermessensentscheidungen .

Auf GitHub ansehen

---
name: plow-ahead
description: Proceed through ordinary ambiguity by making reasonable assumptions, keeping momentum, validating as you go, and ending with a clear recap of decisions, changes, verification, and residual risk.
---

# Plow Ahead

Proceed through ordinary ambiguity. Make reasonable assumptions, keep momentum,
validate as you go, and make the final recap strong enough that the user can see
what decisions were made while they were away.

## Autonomy Contract

Treat the user's instruction as permission to continue through normal
uncertainty:

- Turn routine questions into explicit assumptions.
- Prefer the smallest reversible choice that satisfies the request.
- Use repo conventions, nearby patterns, local docs, tests, and existing product
  behavior as the decision source.
- Keep working through normal test failures, missing context, implementation
  choices, and minor ambiguity.
- Use subagents for independent research, implementation, or verification when
  parallel work can reduce idle time or improve coverage.
- Do not pause merely to ask which reasonable option the user prefers. Pick one,
  record why, and keep going.

## Stop Conditions

Stop and ask only for true blockers:

- Required credentials, secrets, accounts, paid services, or private data are
  unavailable.
- The next step would be destructive, irreversible, or production-mutating.
- The task requires an explicit branch operation, history rewrite, force push, or
  deletion that the user did not directly request.
- Legal, safety, privacy, or security risk is high and cannot be reduced by a
  conservative local choice.
- The user explicitly reserved a decision for themselves.
- A verification failure repeats after reasonable investigation and the next fix
  would be speculative or broad.

If blocked, leave a self-contained handoff: what was done, what blocks progress,
what exact input is needed, and the next command or file to inspect.

## Decision Rules

When choosing without the user:

1. Reuse existing patterns before inventing new ones.
2. Prefer local, reversible, low-blast-radius changes.
3. Keep scope tight to the user's request.
4. Choose correctness and maintainability over cleverness.
5. Validate with the smallest meaningful test first, then broaden only when the
   risk justifies it.
6. If two options are close, choose the one that is easier for the user or a
   reviewer to understand later.

Maintain a lightweight decision log while working. It can live in notes, the
plan, or your final answer, but do not create a new repo artifact unless the task
needs one.

## Work Loop

1. Restate the goal internally and identify likely acceptance criteria.
2. Inspect the real files, docs, issue, PR, screenshots, or runtime behavior
   before editing.
3. Make assumptions explicit, then act on them.
4. Implement in small coherent steps.
5. Run targeted validation and fix issues found by validation.
6. Repeat until the requested work is complete or a stop condition applies.
7. Before final response, review the diff and verification evidence against the
   original request.

## Final Recap

End with a recap that makes autonomous decisions auditable:

```md
Goal
- What you completed.

Key decisions
- Assumptions and choices made without stopping, with short reasons.

Changes
- Files, behavior, docs, or configuration changed.

Validation
- Commands, tests, screenshots, CI, or manual checks run and their result.

Remaining risk
- Anything not verified, deferred, or blocked.
```

Keep the recap factual. Do not hide uncertainty, skipped validation, or judgment
calls.