docs-structure
Skill1 starsChanged 7 months agoMITView on GitHub
Projekt-Dokumentation nach Hub-Pattern erstellen und pflegen: docs/{bereich}/general.md mit Code-Pfaden, Status, Trigger-Wörtern. Nutze bei: 'Doku anlegen', 'Docs strukturieren', 'wo finde ich was', 'Code-Map', 'Projekt-Doku', 'Modul dokumentieren'.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- Seekers2001/docs-governancetheir own version, first seen Oct 13, 2026
- qshanx/docs-governancetheir own version, first seen Oct 13, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- Seekers2001/docs-governance★ 320same name
- qshanx/docs-governance★ 253same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository18 other files it gives its agents.
- architectureSkill
- audit-projectSkill
- backendSkill
- deploySkill
- frontendSkill
- geoSkill
- git-commitSkill
- helpSkill
- init-projectSkill
- laravel-a11ySkill
- laravel-docsSkill
- laravel-performanceSkill
- laravel-security-auditSkill
- laravel-testsSkill
- portfolio-texteSkill
- qaSkill
- requirementsSkill
- seoSkill
The file
Files
/docs-structure – Projekt-Dokumentation nach Hub-Pattern
Du erstellst und pflegst eine strukturierte Projektdokumentation die Claude (und Menschen) sofort zeigt, wo welche Dateien zu finden sind.
Das Prinzip
Jedes Modul/Feature bekommt eine Hub-Datei (docs/{bereich}/general.md) die als Einstiegspunkt dient:
- Code-Pfade: Controller, Services, Models, Views, Routes, Tests – alles auf einen Blick
- Status: Was ist fertig, was in Arbeit, was offen
- Trigger-Wörter: Wann soll Claude diese Datei lesen
- Abhängigkeiten: Was nutzt dieses Modul, wer nutzt es
Plus: Eine zentrale Lookup-Tabelle in CLAUDE.md die alle Hub-Dateien mit Trigger-Wörtern listet.
Workflow
Modus 1: Initiale Struktur anlegen
Trigger: Projekt hat keine docs/ Struktur oder /docs-structure init.
- Codebase scannen: Welche Module existieren?
- Bereiche identifizieren: Logische Gruppierung der Module
- Hub-Dateien erstellen: Pro Bereich eine
general.md - Lookup-Tabelle: In
CLAUDE.mddie zentrale Tabelle ergänzen - Patterns:
docs/patterns/mit Templates und Regeln
# Module erkennen
ls app/Http/Controllers/*/ 2>/dev/null
ls app/Services/*/ 2>/dev/null
ls app/Models/ 2>/dev/null
find resources/views -maxdepth 1 -type d 2>/dev/null
ls app/Jobs/*/ 2>/dev/nullModus 2: Einzelnes Modul dokumentieren
Trigger: Neues Feature/Modul erstellt oder /docs-structure {bereich}.
- Modul analysieren: Controllers, Services, Models, Views, Routes, Jobs, Tests finden
- Hub-Datei erstellen:
docs/{bereich}/general.mdnach Template - Lookup-Tabelle updaten: Neuen Eintrag in
CLAUDE.md
Modus 3: Docs aktualisieren
Trigger: Nach Code-Änderungen oder /docs-structure update.
- Änderungen erkennen:
git diff --name-only HEAD~5 - Betroffene Hub-Dateien identifizieren: Welche Bereiche wurden geändert?
- Code-Pfade prüfen: Stimmen die Pfade noch? Neue Dateien ergänzen?
- Status aktualisieren: Features die fertig sind → ✅
Hub-Datei Template
Erstelle als docs/{bereich}/general.md:
# {Titel}
> **Bereich:** {bereich-slug}
> **Letzte Aktualisierung:** {YYYY-MM-DD}
> **Status:** {aktiv | geplant | archiviert}
## Überblick
{1-3 Sätze: Was ist das, was tut es, warum existiert es}
## Status
- ✅ {Was fertig ist}
- 🔄 {Was in Arbeit ist}
- ⬚ {Was geplant/offen ist}
## Code-Pfade
| Typ | Pfad |
|---|---|
| Controller | `app/Http/Controllers/{...}` |
| Service | `app/Services/{...}` |
| Model | `app/Models/{...}` |
| Enums | `app/Enums/{...}` |
| Views | `resources/views/{...}` |
| Routes | `routes/web.php:L{x}-{y}` |
| Tests | `tests/{...}` |
| Config | `config/{...}` |
| Lang | `lang/{de,en}/{...}.php` |
| Jobs | `app/Jobs/{...}` |
| Migrations | `database/migrations/{...}` |
## Relevante Enums
| Enum | Werte | Zweck |
|---|---|---|
| `{EnumName}` | {wert1, wert2} | {Beschreibung} |
## Scheduled Tasks & Commands
| Command / Schedule | Wann | Zweck |
|---|---|---|
| `{command}` | {Zeitplan} | {Beschreibung} |
## Externe APIs / Services
| Service | Config | Zweck |
|---|---|---|
| {Name} | `config/{...}` | {Beschreibung} |
## Abhängigkeiten
- → **nutzt:** {andere Module/Services}
- ← **genutzt von:** {wer ruft dieses Modul auf}
## Ablauf
{Hauptflow als nummerierte Schritte}
## Erweiterung
### {Typische Aufgabe: z.B. "Neuen Check hinzufügen"}
1. {Schritt 1}
2. {Schritt 2}Lookup-Tabelle (in CLAUDE.md)
Erstelle/ergänze diesen Abschnitt in der Projekt-CLAUDE.md:
## Dokumentation
**Regel:** Lies `docs/{bereich}/general.md` wenn du an einem Bereich arbeitest.
| Bereich | Hub-Datei | Trigger-Wörter |
|---|---|---|
| {Bereich} | `docs/{slug}/general.md` | {Wort1, Wort2, Wort3} |Trigger-Wörter: Die Begriffe die ein User oder Claude verwenden würde wenn es um diesen Bereich geht. Beispiele:
- SEO → "SEO, PageSpeed, Crawler, Sitemap, Schema"
- Auth → "Login, Register, Passwort, 2FA, Invite"
- Billing → "Zahlung, Abo, Subscription, Mollie, Credits"
Patterns-Ordner
Erstelle docs/patterns/ mit:
docs/patterns/development.md – Globale Entwicklungsregeln:
# Entwicklungsregeln
## 1. Test-Pflicht
Kein Feature ohne Tests. Gibt es keine Tests für den berührten Bereich, neue erstellen.
## 2. Doc Auto-Update
Bei Änderungen an einem Modul → zugehörige `general.md` prüfen und aktualisieren:
- Controller/Service/Model verschoben/erstellt → Code-Pfade-Tabelle prüfen
- Enum hinzugefügt/entfernt → Enum-Tabelle prüfen
- Scheduled Task geändert → Tasks-Tabelle prüfen
- Feature fertig → Status-Sektion updaten (⬚ → 🔄 → ✅)
## 3. Neue Features → Doc anlegen
Neues Feature? → prüfen ob Doc existiert, sonst nach Template anlegen.
## 4. Boy Scout Rule
Docs besser hinterlassen als vorgefunden.docs/patterns/doc-template.md – Das Hub-Datei Template (wie oben).
Regeln
- Code-Pfade müssen stimmen: Jeder Pfad in der Tabelle muss eine echte Datei referenzieren. Vor dem Schreiben prüfen:
ls {pfad} - Nicht raten: Wenn du nicht sicher bist ob ein Controller existiert → nachschauen, nicht erfinden
- Granularität: Ein Bereich = ein logisches Modul. Nicht zu fein (jeder Controller einzeln) und nicht zu grob (alles in einer Datei)
- Aktuell halten: Die Doku ist nur wertvoll wenn sie stimmt. Lieber weniger aber korrekt als viel aber veraltet
- Trigger-Wörter großzügig: Lieber ein Trigger-Wort zu viel als dass Claude die richtige Doku nicht findet
Typische Bereichs-Aufteilung
Laravel-Projekte
docs/
├── patterns/ # Globale Regeln + Templates
│ ├── development.md
│ └── doc-template.md
├── auth/ # Login, Register, 2FA, Rollen
├── billing/ # Payment, Subscriptions, Credits
├── {feature}/ # Pro Feature-Modul
│ ├── general.md # Hub-Datei
│ └── {detail}.md # Detail-Docs bei Bedarf
└── infrastruktur/ # Hosting, Deploy, Queue, RedisWordPress-Projekte
docs/
├── patterns/
├── theme/ # Child-Theme, Templates, Bricks
├── plugins/ # Custom Plugins, ACF, Polylang
├── content/ # CPTs, Taxonomies, Menus
└── hosting/ # Server, Caching, UpdatesHandoff
Nach Abschluss:
Dokumentation erstellt/aktualisiert. {X} Hub-Dateien, {Y} Code-Pfade dokumentiert. Claude findet jetzt automatisch die richtige Datei anhand der Trigger-Wörter in CLAUDE.md.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

