Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Read changed files to understand the full context around each change (not just the diff hunks).
Analyze the changes against these criteria:
Area
What to check
Error wrapping
Use fmt.Errorf("...: %w", err), not %v — ensure errors are properly wrapped for errors.Is/errors.As
Context propagation
Pass context.Context through call chains, respect cancellation
Goroutine leaks
Ensure goroutines have exit conditions, use errgroup where appropriate
Template correctness
Go text templates in templates/ must produce valid JSON, YAML, shell scripts, or config files
Config defaults
Changes to EnvironmentConfig or defaults must not break existing environments
Docker Compose validity
Changes to docker-compose.yaml template must produce valid Compose v2 syntax
Embed consistency
New or renamed template files must be covered by the embed.go directives
Port conflicts
New services or port changes must not conflict with existing host-network ports
Feature flag gating
Optional components must be gated behind the correct Docker Compose profile
Security
No credentials or secrets in templates, no command injection in shell script templates
Breaking changes
Changes to CLI flags, values.yaml schema, or environment structure that break existing usage
Deliver your review:
If CI mode: post to GitHub
Part A: Inline file comments
For each issue, post a comment on the exact file and line. Keep comments short (1-3 sentences), end with — Claude Code. Use line numbers from the new version of the file.
Without suggestion block — single-line command, <br> for line breaks:
gh api -X POST -H "Accept: application/vnd.github+json""repos/<owner/repo>/pulls/<number>/comments" -f body="Issue description.<br><br>— Claude Code" -f path="file" -F line=42 -f side="RIGHT" -f commit_id="<headRefOid>"
With suggestion block — use a heredoc (-F body=@-) so code renders correctly:
gh api -X POST -H "Accept: application/vnd.github+json""repos/<owner/repo>/pulls/<number>/comments" -F body=@- -f path="file" -F line=42 -f side="RIGHT" -f commit_id="<headRefOid>" <<'COMMENT_BODY'
Issue description.
```suggestion
first line of suggested code
second line of suggested code
— Claude Code
COMMENT_BODY
Only suggest when you can show the exact replacement. For architectural or design issues, just describe the problem.
#### Part B: Summary comment
Single-line command, `<br>` for line breaks. No markdown headings — they render as giant bold text. Flat bullet list only:
```bash
gh pr comment <number> --repo <owner/repo> --body "- file:line — issue<br>- file:line — issue<br><br>Review by Claude Code"
If no issues: just say "LGTM". End with: Review by Claude Code
If local mode: output the review as text
Do NOT post anything to GitHub. Instead, output the review directly as text.
For each issue found, output:
**<file_path>:<line_number>** — <what's wrong and how to fix it>
When the fix is a concrete line change, include a fenced code block showing the suggested replacement.
At the end, output a summary section listing all issues. If no issues: just say "LGTM".
End with: Review by Claude Code
What NOT to do
Do not comment on markdown formatting preferences
Do not suggest refactors unrelated to the PR's purpose
Do not praise code — only flag problems or stay silent
If no issues are found, post only a summary saying "LGTM"
Do not flag style issues already covered by the project's linter (eslint, biome, pylint, golangci-lint)
