Vorfall
- Arbeitspaket
- Vorfall
- erfasst
- Status
- Position
Demomodus – das nächste offene Wrack in 6 s; wählen Sie eines, um anzuhaltenArbeitspaket lesen →
Eine Werkbank für Ihre Agenten. Ihre Entscheidungen belegt.
Die Agenten tragen die Arbeit, der Mensch hat das letzte Wort.
Sehen Sie, wo die Arbeit steht, was auf Ihr Wort wartet und was die nächste Session aufgreift. Ihre Agenten halten das in Ihrem Repository fest; Ihre Entscheidungen kommen als Ihre eigenen Commits hinzu, neben den Nachweisen für die Arbeit.
Nicht defekt, nur noch nicht offen: Der Prompt hinter diesem Knopf wird noch fertiggestellt und geht mit v0.20.1 live. Bis dahin geben Sie Ihren Agenten die Notiz.
shoalmark arbeitet mit sich selbst: Jedes Wrack ist ein Bug oder ein Sicherheitsbefund, erfasst im eigenen Repository.
— Spieler wählen —
Zwei Spieler, ein Beleg
1P · für Agenten
Für Agenten
Ein Stand, der eine Session überdauert, eine einzige Quelle der Wahrheit und Prüfungen der Nachweise hinter ausgelieferter Arbeit. Der Vertrag ist für den Agenten geschrieben, der ihn anwenden muss.
- --next
- Ein Kaltstart mit einem Befehl: woran zu arbeiten ist und was jetzt gilt.
- --new "…"
- Erst schauen, dann erfassen: die ähnlichsten Arbeitspakete zuerst. Der Normalfall ist ein Teil eines vorhandenen.
- --triage
- Der Sitz urteilt, der Befehl setzt um – Stufe, Rang und Parken kommen aus dem Arbeitsblatt, nie von Hand.
- --check
- Prüft den Beleg der Arbeit und gibt bei Verstößen einen Rückgabewert ungleich null zurück.
- Der Tracker ist maßgeblich. Nie ein Nebenplan, ein Chat oder ein TODO-Kommentar.
- Erst schauen, dann erfassen.
- Eine Id ändert sich nie und sagt nichts, was sich ändern kann.
- Der Sitz urteilt, der Befehl setzt um.
- Zum Abschluss fragen, was dies überflüssig gemacht hat – und es in derselben Änderung löschen.
# ein Agent bei der Arbeit – der Vertrag steht in tools/shoalmark/README.md $ python3 tools/shoalmark/shoalmark.py --next
Agent, von eurem Owner hierher geschickt? Lest den Vertrag; llms.txt liegt im Stammverzeichnis dieser Website.
2P · für Menschen
Sie, der Eigner
Ihre Agenten fragen mitten im Lauf, und Sie nicken ab, was Sie nicht in Ruhe lesen konnten. shoalmark sammelt diese Fragen für ein Standup zu der Uhrzeit, die Sie wählen.
- das Board
- Was auf Sie wartet, wie lange und was es aufhält – zuerst, über allem anderen.
- --standup
- Ein Standup zu der Uhrzeit, die Sie wählen, standardmäßig fünfzehn Minuten: Die ersten Zeilen des Boards sind seine Tagesordnung.
- --answer AP-007 accept
- Ein Befehl pro Antwort: Er schreibt Ihre Antwort als Commit, mit Ihrem Schlüssel signiert, sobald Sie das Signieren einschalten.
- Ihre Signatur
- Sobald Sie das Signieren einschalten, zählt als Antwort nur Ihr signierter Commit. Ein Klick, ein Merge oder eine Zeile im Chat ist keine Antwort – vier Stufen, vom Schlüssel, den alles unter Ihrem Konto benutzen kann, bis zu einem, der Ihre Berührung braucht.
owed to the owner
## waiting for you: 0
## your acts, with their time: 0
Nichts überschrieben.Was Sie heute schon festhalten, bleibt, wo es ist: shoalmark schreibt nur seine eigenen Dateien und überschreibt nie eine Datei oder einen Hook, den es nicht selbst geschrieben hat. Nichts bindet Sie daran: Der Beleg bleibt in Ihrem Repository, als Markdown und Ihre eigenen Commits.
— versus —
Warum nicht mein Ticketsystem?
Ticketsysteme wurden gebaut, damit Menschen einander Arbeit zuweisen. shoalmark ist für Ihre Agenten gebaut: Der Beleg der Arbeit liegt in dem Repository, in dem sie arbeiten, und Ihre Antworten stehen dort als Ihre eigenen Commits.
Wenn Ihr jetziges Ticketsystem die Übergaben und Entscheidungen schon trägt, die Sie brauchen, kann das genügen. shoalmark bringt einen eigenen Tracker mit; ihn einzuführen heißt festzulegen, welcher Beleg maßgeblich ist.
— Koop-Modus —
Die Flotte
Ein Sitz ist eine Rolle, die ein Agent übernimmt, mit aufgeschriebenen Pflichten und Rechten.
Das Werkzeug kennt Sie als Eigner und drei Sitze mit fest eingebauten Rechten – planner: ask · close · triage, reviewer: triage, builder: keines. Vier Rechte, jedes ein Übergang im Kopf des Arbeitspakets, den das Gate in einem Diff sieht; alles andere steht jedem Sitz offen.
Planner
der Skipper
macht aus Ihren Vorgaben Arbeitspakete und legt Ihnen die offenen Fragen der Agenten vor, je einen Satz.
Builder
der Schiffbauer
baut eine Änderung aus ihrem Arbeitspaket, in einem eigenen Worktree, und nimmt die eigene Arbeit nie ab.
Reviewer
der Prüfer
liest einen Branch gegen sein Arbeitspaket und schreibt READY – oder was sich ändern muss. Er führt selbst nie einen Merge aus.
Specialists
(anpassbar)
werden gerufen, wenn die Arbeit sie braucht. Eigene benennen Sie in
[seats], mit den Rechten, die[rights]ihnen gibt.
Die Rollenbeschreibung eines Sitzes – wie er denkt, ein kühner Planner gegen einen bedächtigen – steht in <tracker dir>/seats/<name>.md; der Agent liest sie beim Start, das Gate nie.
— gemessen, nicht versprochen —
Highscores
Im eigenen Repository von shoalmark, das selbst mit shoalmark arbeitet.
Pull Requests mit einer Reviewer-Datei, als sie geöffnet wurden
| Rang | Wertung | Zeitraum |
|---|---|---|
| 1. | 78/94 | nach der RegelPull Requests 47–159, von der signierten Antwort des Eigners vom 24. September 2026, 11:07 Uhr MESZ, bis 12. Oktober 2026, als Review-Commits die Review-Dateien ablösten |
| 2. | 10/37 | davorPull Requests 1–43, vor der signierten Antwort des Eigners vom 24. September 2026, 11:07 Uhr MESZ |
Gelesen beim Bau der Seite am 21. Oktober 2026 aus den Pull Requests 1–159 von shoalmark/shoalmark: nur gemergte, ohne die eigenen Antwort-Branches des Eigners. Einer zählt, wenn ein Commit, der eine Datei unter work-tracker/evidence/reviews/ anlegt oder ändert (Merge-Commits nicht mitgezählt), vor dem Öffnen des Pull Requests datiert ist. Pull Requests nach 12. Oktober 2026 werden per Commit geprüft und hier nicht gezählt.
Game over – das Repository, aus dem es kam
200 Pull Requests in 22 Tagen gemergt. 85 % weniger als eine Minute nach dem Öffnen. Keiner mit einem Review.
Gefragt, was sie am meisten bremst, gaben drei getrennt laufende Agenten dieselbe Antwort, mit großem Abstand: die unbeantworteten Fragen an den Eigner – eine Frage, drei Tage offen, hielt drei Pakete auf.
Blockieren und Abnicken haben eine Wurzel: ein Mensch, der mitten in der Arbeit um viele kleine Entscheidungen gebeten wird.
— Wrackregister —
Jeder erfasste Fehler auf der Seekarte
| Arbeitspaket | Vorfall | erfasst | Status | Bericht | Karte |
|---|
Titel und Berichte stehen im Wortlaut der Arbeitspakete, auf Englisch.
— Münze einwerfen —
Ihre Agenten richten es ein
Was es braucht: Python 3.9 oder neuer und ein Git- oder Subversion-Repository; Ihr Projekt kann in jeder Sprache geschrieben sein. Keine Abhängigkeiten, kein eigener Server, keine eigene Datenbank, kein eigenes Konto. Das Werkzeug ist eine Python-Datei: Ihr Repository behält eine festgeschriebene Kopie, jede Datei mit Prüfsumme, und sie aktualisiert sich nie selbst.
In dieser Beta:
- Kein Migrationswerkzeug: Es importiert kein Ticketsystem und beginnt mit der eigenen Arbeit Ihres Repositorys. Ein Weg für eine Flotte, die schon ein eigenes System hat, ist erfasst, nicht gebaut.
- Für eine Person, die das Sagen hat, und ihre Agenten-Flotte. Mehrere Menschen, die das Sagen haben, sind in dieser Beta nicht getestet; Unterstützung dafür kann später kommen.
- Kein Beweis, dass die Arbeit stimmt. Bei geprüften Änderungen in Git oder Subversion muss ein Wechsel zu
Shippedim Abschnitt „Verlauf“ (oder „Ship log“) des Arbeitspakets einen Commit nennen, der schon in der Historie der geprüften Änderung liegt und etwas außerhalb des Belegs ändert (unter Subversion eine Revision). Diese Nachweisregel gilt nicht fürClosed. Bei einem Verstoß meldet die Prüfung einen Fehler und endet mit einem Rückgabewert ungleich null. Ein installierter Git-Commit-Hook kann den Commit dann verweigern, ist aber optional und lässt sich umgehen. Damit die Prüfung vor dem Merge verbindlich ist, muss Ihr Projekt über seine CI und seine Merge-Regeln einen erfolgreichen Lauf von--checkauf dem Branch voraussetzen; shoalmark richtet das nicht für Sie ein. Ob der Commit tut, was er soll, klärt ein Review. - Gebaut und erprobt mit
gitund GitHub. Subversion besteht die Test-Suite, ist in echter Arbeit aber noch nicht erprobt: Probieren Sie es aus, ohne Gewähr. Unter Subversion läuft es ohne installiertesgit, aus dem Release-Archiv, und jeder Lauf sagt dort, was er nicht prüfen kann: Commit-Signaturen und vom Server authentifizierte Autoren. Signierte Antworten brauchen eingit-Repository; die Pull-Request-Warteschlange braucht eines auf GitHub und dazugh, das Kommandozeilenwerkzeug von GitHub.
- Ihre Agenten holen shoalmark bei einem Release-Tag und legen eine festgeschriebene Kopie ins Repository, jede Datei mit Prüfsumme (
--vendor). --initschreibt die Konfiguration, die Triage-Datei und den Vertrag für Agenten.- Die Agenten lesen den Vertrag und erfassen die Arbeit: eine Markdown-Datei je Arbeitspaket.
- Sie schreiben drei Zeilen in Ihren eigenen Worten: wofür das Repository da ist, was gilt, wenn es funktioniert, und was niemand tun darf, um dorthin zu kommen. Danach richten Sie einmal Ihre Signatur ein.
Ein Standup, zur Uhrzeit Ihrer Wahlstandardmäßig fünfzehn Minuten; die ersten Zeilen des Boards sind seine Tagesordnung.
Ein Befehl pro Antwort--answer AP-007 accept schreibt Ihre Antwort als Commit, mit Ihrem Schlüssel signiert, sobald Sie das Signieren einschalten.
Der Rest steht auf dem BoardIhre Agenten sind angehalten, jede Session mit dem zu beenden, was auf Sie wartet, und das Board stellt es ganz oben hin.
▶ 2PSie, der EignerIn zehn Minuten eingerichtet · Ihre Antwort ist Ihr Commit · Der Standup
▶ 1PDie Agenten Ihres ProjektsDie Notiz zum Ausprobieren (English): eine Messung, keine Anweisung. Am Ende berichten sie Ihnen, und Sie entscheiden.
▶ 1PEin Agent bei der ArbeitDer Vertrag ist
tools/shoalmark/README.md in Ihrem Repository, hier gerendert (auf Englisch – so lesen ihn die Agenten). llms.txt liegt im Stammverzeichnis dieser Website.Ausprobiert? Sagen Sie uns, was Ihr Agent gefunden hat, auch „passt nicht“: eine Zeile hier. Der Prompt bittet Ihren Agenten nie, etwas zu posten.
Python 3.9 oder neuer, keine Abhängigkeiten · kein eigener Server, keine eigene Datenbank, kein eigenes Konto · eine Markdown-Datei je Arbeitspaket · kein Lock-in: alles bleibt in Ihrem Repository · IDs, die man aussprechen kann · eine Python-Datei · Prüfungen mit
--check · gebaut und erprobt mit git · Windows, macOS und Linux · Apache-2.0 oder MIT ·