ainova-systems/intelligence-dev-packs

Initialisierung des spezifikationsgesteuerten Dokumentations-Substrats

Richten Sie die gemeinsame Wissensbasis des Repositorys ein – die Schicht, die sowohl Menschen als auch Agenten lesen –, damit der Rest des Spezifikationspakets (spec-create, spec-execute) einen Ort zum Schreiben hat. Sicher und additiv: Es wird nichts gelöscht, Entwürfe werden als inferiert bis bestätigt geführt, der Besitzer genehmigt, bevor etwas als autoritativ gilt.

Zielstruktur ermitteln (erst lernen, dann profilieren, dann Standard) – niemals aufzwingen

1. Zuerst vom Projekt lernen. Wenn das Repository bereits eine Dokumentationsstruktur hat (docs/, Documentation/, eine docs-Regel, begleitende Feature-Dokumente), diese übernehmen – zuerst suchen, zwei verwandte Dokumente lesen, nachahmen, nicht erfinden. Eine ausgereifte bestehende Struktur hat Vorrang vor dem Standard; nicht umstrukturieren, was bereits funktioniert.
2. Profilieren legt Pfade bei Mehrdeutigkeit fest: specs_dir, features_dir, rules_dir, decisions_dir, spec_grouping.
3. Greenfield-Standard = der KI-erste-Dokumentationsbaum (siehe references/docs-tree.md): docs/ mit model.md, glossary.md, rules/R-NNN-*.md, features/<feature>.md, specs/NNN-<feature>/{requirements,plan,tasks}.md, decisions/NNNN-*.md, architecture/, guides/, _inbox/.

Das geschichtete Modell (was dieser Skill verwaltet)

Geordnet danach, wie stark jede Schicht einen Agenten einschränkt: Ein Agent folgt einer ausführbaren Prüfung zuverlässiger als Prosa.

• Schicht A – ausführbare Einschränkungen (Lint-/Grenz-/Vertragstest-Konfigurationen, tests/): die stärkste. Außerhalb des Geltungsbereichs hier – separat einrichten.
• Schicht B – maschinenlesbare Regeln & Architekturwissen (Regeln-als-Verträge rules/R-NNN, Abhängigkeitskarte, Entscheidungsprotokoll). spec-init richtet diese Dokumente ein; der Agenten-Einstiegsrouter (AGENTS.md) bleibt Eigentum der Synchronisations-Engine – dieser Skill stellt nur sicher, dass er auf den Dokumentationsbaum verweist, und überschreibt ihn niemals.
• Schicht C – gemeinsame Wissensbasis (Modell, Glossar, Feature-Dokumente, Spezifikationen, Architektur, Anleitungen). spec-init richtet diese ein und befüllt sie.

Schritte

1. Bestandsaufnahme der vorhandenen Dokumentation: jede *.md, Wiki-Export, Diagramm, verstreute Notiz. Klassifizieren Sie jede als Modell / Glossar / Feature-Verhalten / Ablauf / Entscheidung / Architektur / Anleitung / nicht klassifiziert.
2. Einrüsten des ermittelten Baums – nur das erstellen, was fehlt (Ordner + ein docs/README.md-Index). Niemals ein vorhandenes Dokument überschreiben.
3. Sicher migrieren – zuerst unter Quarantäne stellen. Verschieben Sie alle vorhandenen, nicht klassifizierten oder veralteten Inhalte in _inbox/ (die Quarantäne), sodass nur die neue Struktur als autoritativ gilt, und klassifizieren Sie dann ein Element nach dem anderen mit Überprüfung durch den Besitzer: „Wie X funktioniert“-Notizen -> features/, Ablaufdiagramme -> architecture/diagrams/, Entscheidungen -> decisions/. Es wird nichts gelöscht; die Neuklassifizierung erfolgt einzeln, nie automatisiert in großen Mengen.
4. Kerndokumente aus dem Code entwerfen, gekennzeichnet als confirmed / inferred: das Domänenmodell (model.md) und Glossar (glossary.md) aus Typen und Feldnamen; Feature-Verhaltensbaselines (features/) aus dem tatsächlichen Code-Verhalten heute + EARS-Akzeptanzkriterien; die Abhängigkeitskarte aus echten Importen; Kandidaten für nummerierte Geschäftsregeln (rules/R-NNN), die der Code bereits durchsetzt.
5. Namensprinzip anwenden. Alles unter dem Dokumentationsstamm ist in Kleinbuchstaben im kebab-case; geordnete Serien verwenden null-aufgefüllte Präfixe (NNNN- ADRs, NNN- Specs); ein Konzept, ein Name, keine Synonyme. Die einzigen Dateien in Großbuchstaben sind AGENTS.md und README.md auf der Wurzelebene (externe Standards erfordern diese Namen).
6. Besitzer-Gate. Präsentieren Sie den eingerüsteten Baum, die _inbox/-Inhalte, die auf Neuklassifizierung warten, und die entworfenen Dokumente. Nichts ist autoritativ, bis der Besitzer jeden Entwurf bestätigt; alles bleibt bis dahin als inferred gekennzeichnet.

Überprüfung

• Der ermittelte Baum existiert; der Index listet ihn auf; jede vorhandene Datei ist entweder neuklassifiziert oder befindet sich in _inbox/ (keine verloren); jeder entworfene Entwurf ist als confirmed/inferred gekennzeichnet; AGENTS.md wurde nicht überschrieben.

Geltungsbereich / Übergabe

• Erstellen einer Änderungsspezifikation innerhalb des eingerüsteten specs/ - spec-create.
• Schicht-A ausführbare Einschränkungen (Lint, Grenzen, Vertragstests) - außerhalb des Geltungsbereichs; separate Einrichtung.
• Dokumente danach mit dem Code synchron halten - spec-audit-docs.

KRITISCH

• Niemals vorhandene Dokumentation löschen oder überschreiben – in _inbox/ unter Quarantäne stellen, eins nach dem anderen neuklassifizieren, vom Besitzer überprüft.
• Niemals den Standardbaum über eine funktionierende Projektstruktur stülpen – zuerst lernen und übernehmen.
• Ehrlicher Vorbehalt, der in der Ausgabe anzugeben ist: Dies legt nur das fest, was bereits im Code strukturiert ist. Geschäftsregeln, die in Konfigurations-, Datenbankzeilen oder laufzeitregistrierten Erweiterungen leben, sind für die statische Erstellung unsichtbar – kennzeichnen Sie diese für funktionale Tests oder schrittweise Überführung in den Code; erfinden Sie niemals eine Regel, die der Code nicht zeigt.