alexaiarchitect/agentcore-skills

Plant den Einsatz der Amazon Bedrock AgentCore-Infrastruktur und deren Rollback, und übergebe dem Benutzer die exakten Befehle – ohne sie selbst auszuführen.

Was ist agentcore-skills?

Dieses Skill plant das Deployment einer Amazon Bedrock AgentCore-Umgebung, inklusive der erforderlichen Terraform- oder Terragrunt-Ausführungsreihenfolge, Prüfung auf bekannte Fehler beim ersten Apply (z.B. IAM-Weitergabeverzögerungen, erstellungsbedingte Ressourcen, veraltete Provider-Sperren, fehlendes Remote-Backend), Überwachung veröffentlichter Kontingente (Targets pro Gateway, Tools pro Target) sowie die Ausgabe der kompletten Befehlskette: init, validate, plan-to-file, show -json, policy check, apply des gespeicherten Plans, Post-Apply-Verifikation und detaillierte Rollback-Anleitungen. Es unterstützt Amazon Bedrock AgentCore auf AWS und wird mit Claude Code, Cursor, Codex und ähnlichen KI-Agenten-Plattformen verwendet. Das Skill führt niemals selbst Befehle aus – es gibt nur Anweisungen aus, die der Benutzer manuell umsetzt. Es identifiziert das richtige Root-Modul oder den Terragrunt-Stack, ordnet die Ressourcen nach ihrer Abhängigkeit (zuerst Identitäten und Rollen, dann Gateway, Laufzeit und Speicher, dann Ziele und Strategien, zuletzt Loglieferung) und markiert potenzielle Fehlerquellen wie IAM-Propagierung oder die Notwendigkeit von Transaction Search vor TRACES-Zustellung. Die Erkenntnisse werden im `DPL0xx`-Band gemeldet; die Kostenstufe ist `aws`, da die Befehle kostenpflichtige Ressourcen erstellen.

Funktioniert mit✓Claude Code~Codex CLI~Cursor

npx skills add https://github.com/alexaiarchitect/agentcore-skills/tree/HEAD/skills/agentcore-deploy

Dokumentation

Bereitstellung von AgentCore: Reihenfolge, Kontingente, Befehle, Rollback

Die Bereitstellung ist der Punkt, an dem dieses Plugin aufhört zu handeln und zu beraten beginnt. Terraform ordnet Ressourcen bereits anhand ihrer Referenzen an; was es jedoch nicht mitteilen kann, ist: welches Root-Modul geplant werden soll, was bei einem ersten Apply aus Gründen außerhalb des Graphen fehlschlagen wird, welche Einstellungen später nicht mehr geändert werden können und wie man zurückkehrt. Dieses Skill schreibt nichts und führt nichts aus: es gibt die Befehle aus, und der Benutzer führt sie aus.

${CLAUDE_SKILL_DIR} wird von der Skill-Laufzeitumgebung auf das eigene Verzeichnis dieses Skills gesetzt. Verwenden Sie es wörtlich in jedem Befehl unten; die Skripte eines benachbarten Skills befinden sich unter ${CLAUDE_SKILL_DIR}/../<skill>/scripts/.

Ablauf

Zuerst prüfen. Ein Bereitstellungsplan, der auf einem Fehler aufbaut, ist ein Plan, den Fehler bereitzustellen:
```
python3 ${CLAUDE_SKILL_DIR}/../agentcore-review/scripts/review.py <projekt>
```
Die Bereitstellung planen.
```
python3 ${CLAUDE_SKILL_DIR}/scripts/deploy_plan.py <projekt>
```
--root VERZ wenn das gefundene Root nicht das zu verwendende ist (Provider-Einschränkung, Sperre, Region und Stages sind dann die des eigenen Roots); --plan-file DATEINAME; --json. Befehle benennen das Plugin als $AGENTCORE_PLUGIN, gesetzt durch die ausgegebene setup-Zeile.
Berichten Sie das Root-Modul, die Stages, die DPL-Erkenntnisse, die Befehle und den Rollback in dieser Reihenfolge. Geben Sie die Kostenstufe an: Diese Befehle erstellen kostenpflichtige Ressourcen im Konto des Benutzers.
Optionen: (1, empfohlen) Der Benutzer führt init → validate → plan to a file → show -json → die Richtlinienprüfung aus und fügt die Richtlinienausgabe ein; (2) nach dem Lesen wendet der Benutzer diese gespeicherte Plan-Datei an. Bestätigen Sie jeden Schritt mit AskUserQuestion; fassen Sie sie niemals in einem Schritt zusammen.
Überprüfen Sie nach der Meldung eines erfolgreichen Apply durch den Benutzer: Übergeben Sie an /agentcore:agentcore-verify.

Das `DPL0xx`-Band

Id	Schweregrad	Auslöser
`DPL001`	warn	kein Remote-Backend (und kein Terragrunt)
`DPL002`	error	ein veröffentlichtes Kontingent überschritten (Targets pro Gateway, Tools pro Target)
`DPL003`	info	Rolle und Gateway in einem Apply: IAM-Weitergabe könnte beim ersten Versuch fehlschlagen
`DPL004`	info	semantische Suche ist nur bei Erstellung möglich
`DPL005`	info	ein Terragrunt-Stack: Befehle verwenden `terragrunt`
`DPL006`	warn	hashicorp/aws unter 6.55.0 gesperrt
`DPL007`	info	TRACES-Zustellung erfordert, dass Transaction Search zuerst aktiviert ist
`DPL008`	info	das gewählte Root deklariert keine hashicorp/aws-Versionsbeschränkung

Entscheidungsregeln

Einen gespeicherten Plan anwenden, niemals -auto-approve. Der Plan, den der Benutzer gelesen hat, ist der Plan, der ausgeführt wird.
Prüfung vor Apply. policy_check.py verweigert das Löschen von Memories, Gateways, Credential Providern und User Pools ohne explizites --allow-replace.
-target ist für Rollback, nicht für die erste Bereitstellung. Wenn das erste Apply aufgrund der IAM-Weitergabe fehlschlägt, führen Sie dasselbe Apply erneut aus.
Rollback durch Rückgängigmachen, nicht durch Zerstören. Zustandsbehaftete Ressourcen (Benutzer, Unterhaltungen, Geheimnisse) sind niemals Teil eines Rollbacks.

Referenzen

Frage	Datei
Stage-Reihenfolge, was beim ersten Apply fehlschlägt, Terragrunt	apply-sequencing.md
Die für die Bereitstellung relevanten AgentCore-Kontingente	quotas.md
Rollback pro Änderungsart; was niemals zerstört werden darf	rollback.md

Skripte

Befehl	Aufgabe	Exit-Codes
`scripts/deploy_plan.py <projekt> [--root VERZ] [--plan-file D] [--json]`	Root, Stages, `DPL`-Erkenntnisse, Befehle, Rollback	0 keine Fehler, 1 Fehler, 2 kein Terraform

Abschluss-Checkliste

review.py wurde zuerst ausgeführt und seine Fehler wurden vom Benutzer behoben oder akzeptiert.
deploy_plan.py wurde ausgeführt; das Root-Modul wurde mit dem Benutzer bestätigt.
Die Kostenstufe (aws) wurde genannt, bevor Befehle übergeben wurden.
Der Benutzer hat vor jedem Apply die Reihenfolge plan → show -json → policy check ausgeführt.
Nur die gespeicherte Plan-Datei wurde vom Benutzer angewendet; kein Befehl wurde vom Assistenten ausgeführt.
Der Rollback für diese Änderung wurde vor dem Apply genannt.