Skip to main content

analyze

AI-summarise a failed Dokploy deployment or a crashing container via the configured ai provider Arguments: deployment-id|app-name-or-id|compose-name-or-id.

Source facts

Repository
Agents-Store/codex-plugins
Last source activity
November 1, 2026 at 02:46
Detected SKILL.md language
English
Stars
0
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
analyze
description
AI-summarise a failed Dokploy deployment or a crashing container via the configured ai provider Arguments: deployment-id|app-name-or-id|compose-name-or-id.
# AI-Analyse a Failure Pipeline around `ai-analyzeLogs`: fetch the relevant log text, then ask the configured AI provider for a root cause + suggested fix. `ai-analyzeLogs` takes the **log text** (not a `deploymentId`) plus an `aiId` and a `context`. Follow the `ai-assist` skill (`${CLAUDE_PLUGIN_ROOT}/skills/ai-assist/SKILL.md`), Step 3, for the analyze step. The log text comes from the `read-logs` skill (§1 runtime logs, §3 build logs, §5 hand-off to AI triage). ## Arguments Format: `[deployment-id|app-name-or-id|compose-name-or-id]` (optional) - Deployment id → analyse that build log (`context: "build"`). - App / compose name or id → fetch its current runtime log (`context: "runtime"`); for a failed build, fetch the most recent errored deployment's build log instead. - No argument → `deployment-allCentralized`, list recent `status: error` rows, ask which to analyse. Parse from "$ARGUMENTS". ## Process 1. **Verify AI is configured** — `mcp__plugin_dokploy-dev_dokploy__ai-getEnabledProviders`. - If the array is **empty**: tell the user no AI provider is enabled, offer `/dokploy-dev:debug <id>` (manual decision tree), and point at the `ai-assist` skill to wire one up. Stop. - Else: take the `aiId` of an enabled provider. 2. **Fetch the log text** (this is the `logs` argument): - Build failure → `deployment-readLogs { deploymentId, tail: 1000 }` → `context: "build"`. - App runtime → `application-readLogs { applicationId, tail: 500, since: "2h" }` → `context: "runtime"`. - Compose runtime → enumerate containers and concatenate each container's `compose-readLogs { composeId, containerId, tail }` (or run `/dokploy-dev:compose-logs` first) → `context: "runtime"`. - Truncate very large logs before sending (provider context limits). 3. **Run the analysis:** ``` mcp__plugin_dokploy-dev_dokploy__ai-analyzeLogs → { aiId: "<enabled provider id>", logs: "<text from step 2>", context: "build" | "runtime" } ``` 4. **Present the result:** ``` ## AI Analysis: <resource name> **Context:** build | runtime **Provider:** <providerName>/<model> ### Root cause <ai-analyzeLogs root cause> ### Suggested fix <ai-analyzeLogs suggested fix> ### Verify before applying - Cross-check against the raw log (`/dokploy-dev:logs <id>` or `/dokploy-dev:compose-logs <name>`). - The model only sees the log you sent it, not the codebase — trust the log if they conflict. ``` 5. **Offer follow-up:** - "Apply this fix? I can update env / build type / Dockerfile and redeploy." - "Want the full decision tree? Run `/dokploy-dev:debug <id>`." ## Example Usage ``` /dokploy-dev:analyze /dokploy-dev:analyze web-frontend /dokploy-dev:analyze my-compose-stack /dokploy-dev:analyze <deploymentId> ```
View on GitHub