mcpField
C
cloudflare

cloudflare

github.com/heyvhuangCloud & DevOps33851 installsUpdated 30w ago
Repository

About cloudflare

cloudflare is an operations skill for managing Cloudflare services, intended for infrastructure operators. It combines read-only diagnosis with confirmation-gated resource changes and evidence-based verification.

Key features

  1. 01Query logs, metrics, and audit history
  2. 02Inspect Workers and build records
  3. 03Manage KV, R2, D1, and Hyperdrive
  4. 04Require confirmation for writes
  5. 05Use MCP, Wrangler CLI, or Dashboard

Use cases

  1. 01Investigating worker errors
  2. 02Reviewing builds and change history
  3. 03Planning and verifying resource changes

MCP support

MCP is an optional execution backend alongside Wrangler CLI and Dashboard. With MCP, the skill can operate Cloudflare services through connected MCP servers.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/heyvhuang/ship-faster --skill cloudflare

After installing, type/cloudflarein Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

BACKENDS.md
scenarios.md
SETUP.md

Details

From the project README

Cloudflare Infrastructure Operations

Manage Cloudflare services: Workers, KV, R2, D1, Hyperdrive, Observability, Builds, and Audit Logs.

MCP is optional. This skill works with MCP (auto), Wrangler CLI, or Dashboard. See BACKENDS.md for execution options.

Permission Tiers

TierPurposeScopeRisk Control
DiagnoseRead-only/query/troubleshootObservability, Builds, AuditDefault entry, no writes
ChangeCreate/modify/delete resourcesKV, R2, D1, HyperdriveRequires confirmation + verification
Super AdminHighest privilegesAll + Container SandboxOnly in isolated/test environments

Security Rules

Read Operations
  1. Define scope first — account / worker / resource ID
  2. No account set? — List accounts first, then set active
  3. Evidence required — Conclusions must have logs/screenshots/audit records
Write Operations (Three-step Flow)
1. Plan: Read current state first (list/get)
2. Confirm: Output precise change (name/ID/impact), await user confirmation
3. Execute: create/delete/update
4. Verify: audit logs + observability confirm no new errors
Prohibited Actions
  • ❌ Execute create/delete/update without confirmation
  • ❌ Delete production resources (unless user explicitly says "delete production xxx")
  • ❌ Use Super Admin privileges in non-isolated environments
  • ❌ Use container sandbox as persistent environment

Operation Categories

Diagnose Tier (Read-only)
CategoryWhat You Can Do
ObservabilityQuery worker logs/metrics, discover fields, explore values
BuildsList build history, get build details, view build logs
BrowserFetch page HTML, convert to markdown, take screenshots
AuditPull change history by time range
WorkersList workers, get details, view source code
Change Tier (Write Operations)
ResourceOperations
KVList, get, create ⚠️, update ⚠️, delete ⚠️
R2List, get, create ⚠️, delete ⚠️
D1List, get, query, create ⚠️, delete ⚠️
HyperdriveList, get, create ⚠️, edit ⚠️, delete ⚠️

⚠️ = Requires confirmation

Super Admin Tier (Container Sandbox)

Temporary container for isolated tasks (~10 min lifecycle):

  • Initialize, execute commands, read/write/delete files
  • Use for: running tests, reproducing issues, parsing data
  • NOT for: persistent state, production workloads

Common Workflows

Troubleshooting Flow
1. Clarify symptoms → worker name / time range / error type
2. Query observability to pull logs/metrics
3. If build-related → get build logs
4. If page-related → take screenshot to reproduce
5. Trace changes → pull audit logs
6. Summarize: root cause + evidence + fix recommendations
Resource Management Flow
1. List accounts → set active account
2. List resources (KV / R2 / D1)
3. Plan changes → present to user
4. Execute after confirmation
5. Verify: audit logs + observability shows no errors

Output Format

  • Language: English
  • Structure: Conclusion → Key data/evidence → Tool call summary → Next steps
  • Write operations: Must clearly list operations and impact scope

Example:

✅ Investigation complete: worker `api-gateway` experienced 5xx spike between 18:00-18:30

Root cause: New code deployed threw TypeError when processing /v2/users
Evidence:
- Logs: 18:02 first occurrence of "Cannot read property 'id' of undefined"
- Audit: 18:00 user [email protected] deployed new version
- Metrics: error_rate jumped from 0.1% to 12%

Recommendation: Roll back to previous version, or fix /v2/users handler

File-based Pipeline

When integrating into multi-step workflows:

runs/<workflow>/active/<run_id>/
├── proposal.md                # Symptoms/objectives
├── context.json               # Account/worker/resource/time_range
├── tasks.md                   # Checklist + approval gate
├── evidence/observability.md
├── evidence/audit.md
├── evidence/screenshots/
├── evidence/change-plan.md    # Write operations written here first
├── evidence/report.md         # Conclusion + evidence + next steps
└── logs/events.jsonl          # Optional tool call summary

Error Handling

SituationAction
Account not setRun accounts_list → set_active_account first
Resource doesn't existVerify ID/name, list available resources
Insufficient permissionsExplain required permissions, check API token scope
Observability query too broadSplit into smaller time ranges

Related Files

Comments

Markdown supported