Zum Inhalt springen

Doku

Produktdokumentation

Die Doku eines Produkts neben seinen Tickets schreiben, in Markdown, und sie in Business mit Vorschlägen aus gemergten Pull Requests aktuell halten.

Jedes Produkt hat einen Tab Docs, in jedem Plan, auch in Free: einen Baum von Seiten in Markdown, neben den Tickets, die sie beschreiben.

Seiten schreiben

Öffnen Sie ein Produkt und wählen Sie Docs. Legen Sie eine Seite oben oder unter einer anderen Seite an und schreiben Sie in Markdown, mit einer Vorschau daneben. Wer eine Seite löscht, löscht auch die Seiten darunter.

  • Mitglieder, die das Produkt sehen, schreiben Seiten. Seine Gäste lesen sie.
  • Die Doku folgt der Sichtbarkeit des Produkts: Wer ein Nur-Team-Produkt nicht sieht, sieht auch seine Seiten nicht, weder in der Suche noch über MCP.
  • Änderungen an Seiten stehen in Business im Audit-Log, und die Seiten sind Teil des Workspace-Exports.

Suche

Die Suche durchsucht Titel und Text der Seiten eines Produkts. Jedes Wort trifft den Anfang eines Wortes, check findet also „Checkout“, und die Ergebnisse zeigen die Stelle mit markierten Wörtern.

Verifizierte Seiten

In Business kann die Doku dem Code folgen. Schalten Sie im Produkt Einstellungen → Code → Propose documentation updates after merge ein; bis dahin ist es aus.

  1. Wird der letzte offene Pull Request eines Tickets gemergt, liest NEWWORK Projects die Diffs, das Ticket und die Seiten des Produkts und schlägt Änderungen an bestehenden Seiten oder eine neue Seite vor.
  2. Jede Änderung muss den Diff oder das Ticket zitieren. Der Server prüft jedes Zitat Zeichen für Zeichen gegen die verknüpften Pull Requests, und jede Änderung muss genau eine Stelle der Seite treffen. Was durchfällt, wird ausgelassen und mit dem Grund unter Not proposed, needs a person aufgeführt. Hat sich für Nutzer nichts Sichtbares geändert, sagt der Vorschlag das.
  3. Documentation update am Ticket zeigt jede Änderung als Diff mit ihrem Nachweis. Ein Projektmanager oder die zuständige Person wählt die Änderungen aus und übernimmt sie. Vorher wird nichts geschrieben, und wurde eine Seite nach dem Vorschlag bearbeitet, lehnt die Übernahme ab und verlangt einen neuen Vorschlag.

Die Übernahme markiert jede geschriebene Seite mit dem Pull Request, gegen den sie geprüft wurde, etwa Verified · acme/payments #42. Ändert danach jemand den Text von Hand, zeigt die Seite Edited since verified, bis der nächste übernommene Vorschlag sie wieder prüft.

Ein Vorschlag ändert nur Seiten des Produkts, zu dem sein Ticket gehört. Pull Requests verknüpft die Verbindung zu GitHub, GitLab oder Bitbucket (siehe Erste Schritte) oder ein Agent mit pm-pr-link. Einen Vorschlag zu schreiben zählt als eine KI-Aktion, außer der Workspace nutzt seinen eigenen OpenAI-Schlüssel.

Agenten und die Doku

  • pm-docs-search listet die Seiten eines Produkts oder durchsucht sie; pm-doc-get liest eine Seite als Markdown, mit dem Pull Request, gegen den sie zuletzt verifiziert wurde, und ob sie seitdem bearbeitet wurde. Beide funktionieren in jedem Plan.
  • In Business kann ein Agent, der ein Ticket umgesetzt hat, die Änderung mit pm-doc-proposal-submit selbst vorschlagen. Es gelten dieselben Prüfungen, und ein Mensch übernimmt sie. pm-doc-proposal-get, pm-doc-proposal-request und pm-doc-proposal-apply lesen, beauftragen und übernehmen Vorschläge.

Nach einem Downgrade

Die Seiten bleiben und bleiben bearbeitbar. Vorschläge lassen sich nicht mehr anfordern oder übernehmen, und die Einstellung lässt sich nur noch ausschalten.