debug-and-fix-site

Diagnose and auto-fix failing Promaker sites using MCP logs and URL probes.

Updated Apr 19, 2026
One-click install
npx skills add https://github.com/PromakerDev/promaker-plugin --skill debug-and-fix-site
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: debug-and-fix-site
Source: https://github.com/PromakerDev/promaker-plugin/tree/main/plugins/promaker/skills/debug-and-fix-site
Command: npx skills add https://github.com/PromakerDev/promaker-plugin --skill debug-and-fix-site

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill diagnoses a Promaker managed site that is failing and attempts to fix it automatically in one cohesive flow, consolidating status checks, logs collection, and remediation attempts to reduce manual troubleshooting time.

Core Features & Use Cases

  • Diagnose site failures by querying the Promaker MCP for deployments, build logs, runtime logs, and a live public URL probe.
  • Execute the cheapest fixes first (start, redeploy) and escalate to code-level tweaks (e.g., patching the Dockerfile for lockfile drift) before handing off to report-site-down.
  • Supports bilingual operator UX by mirroring the user's language and translating responses accordingly.

Quick Start

Tell me which site to review and I’ll diagnose and auto-fix it in one flow.

Frequently Asked Questions about debug-and-fix-site

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I diagnose a failing Promaker site using build logs and runtime logs?

Diagnosing a failing Promaker site involves querying the Promaker MCP for deployments, build logs, runtime logs, and probing the live public URL to determine health and root causes automatically.

What is the best way to auto-fix a site that is failing during deployment?

Auto-fixing a failing site follows a decision-tree workflow applying the cheapest viable remediation first, such as starting or redeploying, before escalating to code-level tweaks like patching the Dockerfile.

Can I use site_name, appName, or primary domain to troubleshoot my deployment?

Yes, you can operate the diagnostic process using site_name, appName, or primary domain as inputs to consult MCP-provided deployments, logs, and live URL probes to determine site health.

How does the auto-fix process handle Dockerfile lockfile drift?

The auto-fix process escalates to code-level tweaks like patching the Dockerfile for lockfile drift only after cheaper remediation attempts fail, relying on safe, reversible changes to push fixes and recheck results.

When should I escalate a failing site to report-site-down instead of auto-fixing?

You should escalate to report-site-down after the decision-tree workflow exhausts the cheapest viable remediation steps and code-level tweaks without successfully resolving the Promaker site failure.