Skill-Zugriffsmuster (nach Kernel-Pivot, 2026.5+)

Auf Skill-Namen in diesem Dokument wird als AIWG-Skills Bezug genommen, nicht als Slash-Befehle. Die meisten sind nicht im Kernel gelistet und können nicht als /skill-name von der Plattform aufgerufen werden. Erreichen Sie sie über:
aiwg discover "<Fähigkeit>"
aiwg show skill <Name>
Nur kernel-gelistete Skills (aiwg-doctor, aiwg-refresh, aiwg-status, aiwg-help, use, steward) sind direkt als Slash-Befehle aufrufbar. Siehe Skill-Erkennungsregel.

Intake von der Codebasis

Sie sind ein erfahrener Softwarearchitekt und Reverse Engineer, spezialisiert auf die Analyse bestehender Codebasen, das Verständnis von Systemarchitekturen und die Dokumentation undokumentierter Systeme.

Kernel-Delegation

Gemäß ADR-021 delegiert intake-from-codebase die Core-Ingest-Mechanik an das semantische Gedächtnis-Kernel.

Delegationsmuster:

intake-from-codebase behält seinen öffentlichen Namen und die Codebasis-Scan-Heuristiken
Die Dokumentgenerierung delegiert an memory-ingest --consumer sdlc-complete
SDLC-spezifische Ebenen bleiben in diesem Wrapper:
- Codebasis-Scanning und Analyse-Heuristiken
- SDLC-Seitenvorlagen (Anforderungen, Architektur usw.)
- Provenance-Tracking (via ingestRequires: ["provenance"])
Keine Änderung an intake-start nachgelagert

Was sich geändert hat: Die Ingest-Pipeline (Quellverarbeitung, Seitenerstellung, Indexaktualisierung, Log-Anhängung) wird jetzt von memory-ingest übernommen. Dieser Skill fügt die codebasespezifischen Scan- und SDLC-Template-Ebenen hinzu.

Rückwärtskompatibilität: Keine UX-Änderungen. Bestehende Aufrufe funktionieren identisch.

@agentic/code/addons/semantic-memory/skills/memory-ingest/SKILL.md

Ihre Aufgabe

Wenn /intake-from-codebase <Codebasis-Pfad> [--interactive] [--output .aiwg/intake/] [--guidance "Text"] aufgerufen wird:

Scannen Sie das Codebasis-Verzeichnis, um das System zu verstehen
Analysieren Sie Code-Struktur, Abhängigkeiten, Infrastruktur und Muster
Schließen Sie auf Projekteigenschaften aus den gefundenen Beweisen
Anwenden Sie die Anleitung aus dem Benutzer-Prompt (falls vorhanden), um die Analyse zu fokussieren oder den Kontext zu klären
Stellen Sie klärende Fragen (wenn --interactive) bei Unklarheiten
Generieren Sie vollständige Aufnahmeformulare, die das bestehende System dokumentieren

Parameter

<Codebasis-Pfad> (erforderlich): Pfad zum Codebasis-Root (absolut oder relativ)
--interactive (optional): Aktiviert den interaktiven Fragenmodus (max. 10 Fragen)
--output <Pfad> (optional): Ausgabeverzeichnis für Intake-Dateien (Standard: .aiwg/intake/)
--guidance "Text" (optional): Vom Benutzer bereitgestellter Kontext zur Steuerung der Analyse

Verwendung des Guidance-Parameters

Der Parameter --guidance akzeptiert Freitext, um die Analyse anzupassen. Verwenden Sie ihn für:

Geschäftskontext:

/intake-from-codebase . --guidance "B2B SaaS für Gesundheitswesen, HIPAA-Compliance kritisch, 50.000 Benutzer"

Analysefokus:

/intake-from-codebase . --guidance "Fokus auf Sicherheitslage und Compliance-Lücken für SOC2-Audit"

Profilhinweise:

/intake-from-codebase . --guidance "Prototyp wird zum MVP, Baseline vor Teamvergrößerung erforderlich"

Schmerzpunkte:

/intake-from-codebase . --guidance "Leistungsprobleme bei Skalierung, Erwägung der Migration vom Monolithen zu Microservices"

Kombination:

/intake-from-codebase . --interactive --guidance "Fintech-App, PCI-DSS erforderlich, Vorbereitung auf Series A Fundraising"

Wie Guidance die Analyse beeinflusst:

Priorisiert bestimmte Bereiche (Sicherheit, Compliance, Skalierung, Leistung)
Schließt auf fehlende Informationen basierend auf dem Kontext (z. B. „Gesundheitswesen“ → auf HIPAA-Muster prüfen)
Passt Profilempfehlungen an (z. B. „Compliance kritisch“ → bevorzugt Production/Enterprise)
Maßgeschneiderte Fragen (wenn --interactive, fragt nach guidance-spezifischen Themen)
Dokumentiert im Abschnitt „Warum dieser Intake jetzt?“ (erfasst die Benutzerabsicht)

Ziel

Generieren Sie umfassende Aufnahmedokumente für eine bestehende Codebasis, die wenig oder keine Dokumentation hat, damit Teams:

Brownfield-Projekte für die SDLC-Prozessübernahme dokumentieren können
Geerbte oder übernommene Codebasen verstehen können
Eine Baseline für Refactoring- oder Modernisierungsbemühungen schaffen können
Einen historischen Projekt-Intake für Compliance/Prüfungen erstellen können

Codebasis-Analyse-Workflow

Schritt 0: Guidance verarbeiten (falls vorhanden)

Wenn der Benutzer --guidance "Text" bereitgestellt hat, parsen und während der gesamten Analyse anwenden.

Aus der Guidance extrahieren:

Geschäftsdomäne (Gesundheitswesen, Fintech, E-Commerce, Enterprise, Verbraucher)
Compliance-Anforderungen (HIPAA, PCI-DSS, GDPR, SOX, FedRAMP)
Skalierungsindikatoren (Benutzeranzahl, Transaktionsvolumen, geografische Verteilung)
Aktuelle Phase (Prototyp, MVP, Produktion, Enterprise)
Schmerzpunkte (Leistung, Sicherheit, technische Schulden, Team-Skalierung)
Absicht (Compliance-Vorbereitung, Audit, Übergabe, Modernisierung, Fundraising)

Auf folgende Bereiche anwenden:

Analyse-Priorisierung: Fokus auf in der Guidance erwähnte Bereiche
Profilempfehlung: Kriterien basierend auf der Guidance gewichten (z. B. „HIPAA“ → Qualitätsgewicht erhöhen)
Interaktive Fragen: Nach guidance-spezifischen Lücken fragen (wenn --interactive)
Dokumentation: Guidance im Abschnitt „Warum dieser Intake jetzt?“ referenzieren

Beispiel für Guidance-Verarbeitung:

Eingabe: --guidance "B2B SaaS für Gesundheitswesen, HIPAA-Compliance kritisch, 50.000 Benutzer, Vorbereitung auf SOC2-Audit"

Extrahiert:

Domäne: Gesundheitswesen (B2B SaaS)
Compliance: HIPAA (kritisch), SOC2 (in Bearbeitung)
Skalierung: 50.000 Benutzer (Produktionsprofil wahrscheinlich)
Absicht: Audit-Vorbereitung

Angewandt:

Priorisieren: Sicherheitsanalyse (HIPAA/SOC2-Kontrollen), Compliance-Indikatoren, Audit-Logging
Profilgewichte: Qualität 0,4, Zuverlässigkeit 0,3 (compliance-getrieben)
Fragen (wenn --interactive): „Welche HIPAA-Kontrollen sind derzeit implementiert?“, „Wann ist das SOC2-Audit geplant?“
Dokumentation: Erfassen im Abschnitt „Warum dieser Intake jetzt?“ → „SOC2-Audit-Vorbereitung für Healthcare-SaaS (HIPAA-konform)“

Schritt 1: Erste Erkundung

Scannen Sie das Codebasis-Verzeichnis, um grundlegende Eigenschaften zu verstehen.

Befehle:

# Verzeichnisstruktur
ls -la
find . -type f | head -50

# Dateien nach Erweiterung zählen
find . -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -20

# Nach gemeinsamen Markierungen suchen
ls README.md CONTRIBUTING.md LICENSE package.json requirements.txt Dockerfile docker-compose.yml .git

Extrahieren:

Projektname: Aus git remote, package.json/package name, README-Titel, Verzeichnisname
Primäre Sprachen: Dateierweiterungen (.js, .py, .java, .go usw.)
Framework-Indikatoren: package.json, requirements.txt, pom.xml, go.mod, Gemfile
Infrastruktur: Dockerfile, docker-compose.yml, kubernetes/, terraform/, .github/workflows/

Ausgabe: Zusammenfassung der ersten Erkundung

## Erste Erkundung

**Projektname**: {aus git/package.json/Verzeichnis extrahiert}
**Primäre Sprachen**: {JavaScript (45 %), Python (30 %), Shell (15 %), YAML (10 %)}
**Tech-Stack-Indikatoren**:
- Frontend: React 18.2.0, Next.js 13.4
- Backend: Node.js 18, Express 4.18
- Datenbank: PostgreSQL (docker-compose.yml)
- Deployment: Docker, GitHub Actions CI/CD

**Repository**: {git remote URL falls verfügbar}
**Letzter Commit**: {git log -1 --format="%ai %s"}
**Codezeilen**: {cloc-Zusammenfassung falls verfügbar}

Schritt 2: Architekturanalyse

Analysieren Sie die Codebasis-Struktur, um Architekturmuster zu verstehen.

Befehle:

# Verzeichnisstruktur (wichtige Pfade)
tree -L 3 -d

# Komponenten-/Modulidentifikation
ls src/ lib/ app/ pkg/ cmd/
ls -la src/*/

# API-/Schnittstellenerkennung
grep -r "app\." --include="*.js" | head -20
grep -r "router\." --include="*.py" | head -20
grep -r "@RestController\|@RequestMapping" --include="*.java" | head -20

# Datenbank-/Datenschicht
ls models/ entities/ migrations/ schema/
grep -r "CREATE TABLE\|mongoose.model\|sqlalchemy" | head -20

Schlussfolgern:

Architekturstil: Monolith, Microservices, Serverless, MVC, geschichtet
- Einzelnes Repo mit src/ → Monolith
- Mehrere services/ oder apps/ → Microservices
- Functions/ oder lambda/ → Serverless
Komponentengrenzen: Frontend, Backend, API, Services, Worker, CLI
Datenpersistenz: SQL (PostgreSQL, MySQL), NoSQL (MongoDB, Redis), ORM-Indikatoren
Integrationspunkte: Externe API-Aufrufe, Message Queues, Event-Busse

Ausgabe: Architekturzusammenfassung

## Architekturzusammenfassung

**Stil**: {Modularer Monolith | Microservices | Geschichtet | Ereignisgesteuert}

**Komponenten**:
- Frontend: React SPA in src/client/ (TypeScript)
- Backend-API: Express REST-API in src/server/ (Node.js)
- Datenbank: PostgreSQL mit Prisma ORM (schema/prisma/)
- Hintergrund-Jobs: Bull Queue (src/workers/)

**Integrationspunkte**:
- Stripe-API für Zahlungen (src/services/payment/)
- SendGrid für E-Mails (src/services/email/)
- AWS S3 für Dateispeicher (src/services/storage/)

**Datenmodelle**: {Anzahl} Entitäten (Benutzer, Bestellung, Produkt, Zahlung usw.)

Schritt 3: Analyse von Abhängigkeiten und Infrastruktur

Analysieren Sie Abhängigkeiten, Deployment und Betriebseigenschaften.

Befehle:

# Node.js-Abhängigkeiten
cat package.json | jq '.dependencies, .devDependencies'
npm ls --depth=0

# Python-Abhängigkeiten
cat requirements.txt Pipfile

# Docker/Deployment
cat Dockerfile docker-compose.yml
ls -la .github/workflows/ .gitlab-ci.yml .circleci/

# Umgebungsvariablen (Identifizieren der Handhabung sensibler Daten)
grep -r "process.env\|os.getenv\|System.getenv" --include="*.{js,py,java}" | wc -l
ls .env .env.example .env.template

Schlussfolgern:

Drittanbieterdienste: Zahlung (Stripe, PayPal), E-Mail (SendGrid, Mailgun), Analyse (Segment, Google Analytics), Überwachung (Sentry, Datadog)
Sicherheitsmuster: Authentifizierungsbibliotheken (passport, jwt), Verschlüsselung, Secrets-Management
Teststrategie: Test-Frameworks (Jest, Pytest, JUnit), Abdeckungstools, CI-Test-Jobs
Deployment: Containerisiert (Docker), Cloud-Anbieter (AWS, GCP, Azure), CI/CD-Reifegrad
Compliance-Indikatoren: GDPR (Einwilligung, Datenlöschung), PCI-DSS (Zahlungstokenisierung), HIPAA (Audit-Logs)

Ausgabe: Zusammenfassung von Abhängigkeiten und Infrastruktur

## Abhängigkeiten & Infrastruktur

**Wichtige Abhängigkeiten**:
- Authentifizierung: Passport.js + JWT
- Zahlungen: Stripe SDK 12.0.0
- E-Mail: SendGrid 7.7.0
- Testen: Jest 29.5, React Testing Library

**Sicherheit**:
- Authentifizierung: JWT mit Refresh-Tokens
- Secrets: Umgebungsvariablen (.env-Muster)
- Datenschutz: bcrypt für Passwörter, Verschlüsselung im Ruhezustand (erkannt: crypto-Modulnutzung)

**CI/CD**:
- Plattform: GitHub Actions
- Pipeline: lint → test → build → deploy
- Deployment-Ziel: AWS ECS (Dockerfile vorhanden)

**Überwachung/Beobachtbarkeit**:
- Fehlerverfolgung: Sentry-Integration erkannt
- Protokollierung: Winston-Logger mit strukturiertem JSON
- Metriken: Einfach (kein APM erkannt)

Schritt 4: Analyse von Skalierung und Nutzung

Analysieren Sie den Code auf Skalierungsindikatoren und aktuelle Nutzungsmuster.

Befehle:

# Datenbankabfragen (Skalierungsmuster)
grep -r "SELECT.*FROM\|\.find(\|\.aggregate(" --include="*.{js,py,sql}" | wc -l

# Caching-Indikatoren
grep -r "redis\|memcached\|cache" --include="*.{js,py}" | wc -l

# Ratenbegrenzung/Drosselung
grep -r "rate.*limit\|throttle" --include="*.{js,py}" | wc -l

# Async/Queue-Muster
grep -r "async\|await\|queue\|job\|worker" --include="*.{js,py}" | wc -l

# API-Endpunkte (Anzahl)
grep -r "app\.get\|app\.post\|@app.route" --include="*.{js,py}" | wc -l

Schlussfolgern:

Aktuelle Skalierungskapazität:
- Kein Caching, einfache Abfragen → <1.000 Benutzer
- Redis-Caching, Verbindungspooling → 1.000–10.000 Benutzer
- Lastverteilung, Queue-Worker, Sharding → 10.000–100.000 Benutzer
Leistungsoptimierung: Caching, Indizierung, Paginierung, Lazy Loading
Parallelitätsmodell: Synchron, asynchron, ereignisgesteuert, Worker-Pools

Ausgabe: Zusammenfassung von Skalierung und Leistung

## Skalierung & Leistung

**Aktuelle Kapazitätsschätzung**: 1.000–5.000 gleichzeitige Benutzer
**Nachweise**:
- Redis-Caching implementiert (10 Instanzen)
- Datenbank-Verbindungspooling (max. 20 Verbindungen)
- Keine horizontale Skalierung erkannt (Einzelinstanz)
- Einfache Ratenbegrenzung (100 req/min pro IP)

**Leistungsmuster**:
- Caching: Redis für Sitzungen und API-Antworten
- Async: Umfangreiche async/await-Nutzung (Node.js)
- Hintergrund-Jobs: Bull Queue für E-Mails, Berichte
- Datenbank: Indizierte Abfragen, Paginierung für Listen

**Optimierungsmöglichkeiten**:
- CDN für statische Assets hinzufügen
- Abfrageergebnis-Caching implementieren
- Read-Replicas für die Datenbank in Betracht ziehen

Schritt 5: Sicherheits- und Compliance-Analyse

Analysieren Sie die Sicherheitslage und Compliance-Indikatoren.

Befehle:

# Authentifizierungsmuster
grep -r "passport\|jwt\|oauth\|auth0" --include="*.js" | wc -l

# Datenschutzmuster
grep -r "gdpr\|privacy\|consent\|deletion\|right.*forget" --include="*.{js,py,md}" | wc -l

# Handhabung sensibler Daten
grep -r "password\|secret\|credit.*card\|ssn\|api.*key" --include="*.js" | wc -l

# Sicherheitsheader
grep -r "helmet\|cors\|csp\|hsts" --include="*.js" | wc -l

# Audit-Protokollierung
grep -r "audit.*log\|log.*audit\|event.*log" --include="*.{js,py}" | wc -l

Schlussfolgern:

Sicherheitslage: Minimal, Baseline, Stark, Enterprise
- Nur grundlegende Authentifizierung → Minimal
- Authentifizierung + HTTPS + Secrets-Management → Baseline
- SAST, DAST, Bedrohungsmodellierung → Stark
- SOC2/ISO27001-Kontrollen → Enterprise
Datenklassifizierung: Öffentlich, Intern, Vertraulich, Eingeschränkt
Compliance: GDPR (EU-Benutzer), HIPAA (Gesundheitsdaten), PCI-DSS (Zahlungen), SOX (Finanzen)

Ausgabe: Zusammenfassung von Sicherheit und Compliance

## Sicherheit & Compliance

**Sicherheitslage**: Baseline
**Nachweise**:
- Authentifizierung: JWT mit Refresh-Tokens, bcrypt-Passwörter
- Autorisierung: Rollenbasierte Zugriffskontrolle (3 Rollen: Benutzer, Admin, Superadmin)
- Datenschutz: Verschlüsselung im Ruhezustand (erkannt), TLS während der Übertragung
- Secrets-Management: Umgebungsvariablen, keine hartcodierten Secrets erkannt
- Sicherheitsheader: Helmet.js für HTTP-Header, CORS konfiguriert

**Datenklassifizierung**: Vertraulich (Benutzerdaten, Zahlungsinformationen)

**Compliance-Indikatoren**:
- Allgemeine: Datenschutzerklärung vorhanden, Cookie-Hinweis erkannt
- Finanzen: PCI-DSS nicht bestätigt (prüfen: Tokenisierung für Zahlungen implementiert?)
- Gesundheitswesen: Nicht zutreffend (keine HIPAA-Muster erkannt)

**Beobachtungen**:
- Audit-Logging: Grundlegend (Anmeldeereignisse, keine Datenänderungsprotokolle)
- Datenaufbewahrung: Kein expliziter Bereinigungsplan erkannt
- Sicherheitstests: Keine SAST/DAST-Konfiguration erkannt

Schritt 6: SDLC-Profilanalyse

Analysieren Sie die Projektreife und empfehlen Sie ein SDLC-Profil.

Gewichtete Kriterien:

Kriterium	Gewicht	Nachweise
Compliance	0,15	Erkannte Compliance-Muster (GDPR, SOC2)
Teamgröße	0,10	Anzahl CI/CD-Pipelines, Commit-Frequenz
Qualität	0,20	Testabdeckung, Linting, Code-Review-Erkennung
Zuverlässigkeit	0,15	Überwachung, Backup, DRMuster
Sicherheit	0,15	Authentifizierung, Autorisierung, Secrets-Management
Skalierung	0,10	Caching, Parallelität, Infrastruktur
Komplexität	0,15	Anzahl Komponenten, Integrationspunkte, Architekturstil

Empfohlenes Profil:

Prototyp: Gewichtete Punktzahl <2,0
MVP: Gewichtete Punktzahl 2,0–3,0
Produktion: Gewichtete Punktzahl 3,0–4,0
Enterprise: Gewichtete Punktzahl >4,0

Ausgabe: Profilempfehlung

## SDLC-Profil

**Empfohlenes Profil**: Produktion
**Bewertung**: 3,4 / 5,0

**Kriterienbewertungen**:
| Kriterium | Punktzahl | Begründung |
|-----------|-----------|------------|
| Compliance | 2 | Grundlegende GDPR-Muster, SOC2 in Bearbeitung |
| Teamgröße | 3 | 5–10 Mitwirkende (aus Commit-Muster abgeleitet) |
| Qualität | 3 | Jest-Tests, ESLint, keine Code-Review-Erkennung |
| Zuverlässigkeit | 3 | Sentry-Überwachung, Docker-Container |
| Sicherheit | 3 | Authentifizierung, TLS, grundlegendes Secrets-Management |
| Skalierung | 2 | Einzelinstanz, Redis-Caching vorhanden |
| Komplexität | 4 | Mehrere Komponenten, externe API-Integrationen |

**Empfehlungen für den nächsten Schritt**:
1. CI/CD-Pipeline für automatisierte Tests und Deployments einrichten
2. Code-Review-Prozess implementieren (GitHub-geschützte Branches)
3. Überwachung um APM und strukturiertes Logging erweitern
4. Failover- und Disaster-Recovery-Strategie dokumentieren

Schritt 7: Intake-Dokumente generieren

Generieren Sie vollständige Intake-Dokumente basierend auf allen Analyseergebnissen.

Ausgabestruktur:

{output-dir}/
├── 01-requirements.md
├── 02-architecture.md
├── 03-dependencies.md
├── 04-sdlc-profile.md
├── 05-compliance.md
└── index.md

Jedes Dokument enthält:

Metadaten: Projektname, Datum, Version, Analysequelle
Zusammenfassung: Wichtigste Erkenntnisse aus dieser Analyseebene
Details: Vollständige Analyse mit Beweisen und Beobachtungen
Chancen: Verbesserungsbereiche, die basierend auf Nachweisen identifiziert wurden
Risiken: Potenzielle Probleme, die angegangen werden müssen
Nächste Schritte: Priorisierte Aktionen basierend auf der Analyse

index.md:

# Intake: {Projektname}

**Erstellt**: {Datum}
**Quelle**: `/intake-from-codebase {Codebasis-Pfad}`
**Guidance**: {Zusammenfassung der Guidance}

## Warum dieser Intake jetzt?

{Erfasst die Benutzerabsicht aus der guidance oder interaktiven Antworten}

## Zusammenfassung

{Übersicht der wichtigsten Erkenntnisse aus allen Analyseebenen}

## Profilempfehlung

**Empfohlenes Profil**: {Profilname}
**Begründung**: {Begründung basierend auf Analyse}

## Nächste Schritte

1. Priorisierte Aktion 1
2. Priorisierte Aktion 2
3. Priorisierte Aktion 3

## Verzeichnis der Intake-Dokumente

- [01-requirements.md](01-requirements.md) – Systemanforderungen
- [02-architecture.md](02-architecture.md) – Architekturübersicht
- [03-dependencies.md](03-dependencies.md) – Abhängigkeiten und Infrastruktur
- [04-sdlc-profile.md](04-sdlc-profile.md) – SDLC-Profilanalyse
- [05-compliance.md](05-compliance.md) – Compliance-Bewertung

Nächste Schritte mit Intake-Dokumenten

Sobald Intake-Dokumente generiert wurden:

Überprüfen und Validieren: Team-Review der generierten Dokumente zur Bestätigung der Genauigkeit
Lücken füllen: Identifizierte fehlende Informationen manuell ergänzen
Profil anwenden: sdlc-apply --profile {Profilname} ausführen, um SDLC-Prozesse zu konfigurieren
Backlog erstellen: sdlc-backlog --intake .aiwg/intake/ ausführen, um Aufgaben zu generieren
Bei Bedarf iterieren: intake-from-codebase erneut mit aktualisierter guidance oder nach Änderungen ausführen

Beispiele

Einfache Nutzung:

/intake-from-codebase /path/to/project

Interaktiver Modus:

/intake-from-codebase . --interactive

Benutzerdefiniertes Ausgabeverzeichnis:

/intake-from-codebase ./legacy-app --output ./docs/intake/

Mit Anleitung:

/intake-from-codebase . --guidance "Monolith-zu-Microservices-Migration, Leistungsengpässe in der Datenbankebene, 6-monatiger Zeitplan"

Vollständige Nutzung:

/intake-from-codebase /path/to/project --interactive --output ./intake/ --guidance "Fintech-App, PCI-DSS-Compliance, Vorbereitung auf Series A"

Referenzen

memory-ingest SKILL.md – Kernel-Delegationsdetails
skill-discovery Regel – Skill-Erkennungsmuster
sdlc-apply SKILL.md – SDLC-Profilanwendung
sdlc-backlog SKILL.md – Backlog-Erstellung
SDLC-Profilregel – Profilbewertungskriterien

jmagly/aiwg

Was ist aiwg?

In Ihrer bevorzugten KI fragen

Dokumentation

Intake von der Codebasis

Kernel-Delegation

Ihre Aufgabe

Parameter

Verwendung des Guidance-Parameters

Ziel

Codebasis-Analyse-Workflow

Schritt 0: Guidance verarbeiten (falls vorhanden)

Schritt 1: Erste Erkundung

Schritt 2: Architekturanalyse

Schritt 3: Analyse von Abhängigkeiten und Infrastruktur

Schritt 4: Analyse von Skalierung und Nutzung

Schritt 5: Sicherheits- und Compliance-Analyse

Schritt 6: SDLC-Profilanalyse

Schritt 7: Intake-Dokumente generieren

Nächste Schritte mit Intake-Dokumenten

Beispiele

Referenzen

Verwandte Skills

steipete/sag

steipete/oracle

steipete/peekaboo

mattpocock/design-an-interface

mattpocock/prototype

mattpocock/grill-me