Use these steps to deploy and diagnose app issues quickly.
Works with
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versioneve-deploy-debuggingExecute the skills CLI command in your project's root directory to begin installation:
Fetches eve-deploy-debugging from incept5/eve-skillpacks and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate eve-deploy-debugging. Access via /eve-deploy-debugging in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Create detailed user stories, acceptance criteria, and feature specs
Example
Generate user stories for 'password reset feature' with acceptance criteria, edge cases, and test scenarios
Reduce spec writing time by 50%, ensure comprehensive coverage
Research competitors, compare features, identify gaps
Example
Analyze 5 competitor products, create feature comparison matrix, suggest differentiation opportunities
Complete competitive research in 2 hours instead of 2 days
Evaluate features using frameworks (RICE, ICE, Kano) and create prioritized backlogs
Example
Score 20 feature ideas using RICE framework, generate prioritized roadmap with rationale
0
total installs
0
this week
0
upvotes
Run in your terminal
0
installs
0
this week
—
stars
Use these steps to deploy and diagnose app issues quickly.
eve profile create staging --api-url https://api.eh1.incept5.dev
eve profile use staging
Never run kubectl apply, helm install, or any direct Kubernetes resource creation against shared infrastructure. All infrastructure changes go through Terraform. Use the Eve CLI (eve env, eve env deploy) to manage application deployments — the platform handles the underlying k8s resources.
# Create env if needed
eve env create staging --project proj_xxx --type persistent
# Deploy (requires --ref with 40-char SHA or a ref resolved against --repo-dir)
eve env deploy staging --ref main --repo-dir .
# When environment has a pipeline configured, the above triggers the pipeline.
# Use --direct to bypass pipeline and deploy directly:
eve env deploy staging --ref main --repo-dir . --direct
# Pass inputs to pipeline:
eve env deploy staging --ref main --repo-dir . --inputs '{"key":"value"}'
When eve env deploy is called:
deployment_status directly. Poll health endpoint until ready === true.pipeline_run_id. Poll GET /pipelines/{name}/runs/{id} until all steps complete, then check health.Deploy is complete when: ready === true AND active_pipeline_run === null.
eve job list --phase active
eve job follow <job-id> # Real-time SSE streaming
eve job watch <job-id> # Poll-based status updates
eve job diagnose <job-id> # Full diagnostic
eve job result <job-id> # Final result
eve job runner-logs <job-id> # Raw worker logs
# Terminal 1: Pipeline/job progress
eve job follow <job-id>
# Terminal 2: Environment health
eve env diagnose <project> <env>
# Terminal 3: System-level logs
eve system logs
eve job dep list <job-id>eve job show <job-id> → look at blocked_byeve env show <project> <env>eve system orchestrator statuseve job diagnose <job-id>eve job follow <job-id> or eve job runner-logs <job-id>eve build diagnose <build-id>eve secrets list --project <project_id>eve job show <job-id> → effective_phaseeve thread messages <thread-id>eve system podseve system healtheve system orchestrator statuseve system events| Error | Cause | Fix |
|---|---|---|
401 Unauthorized |
Token expired | eve auth login |
git clone failed |
Missing credentials | Set github_token or ssh_key secret |
service not provisioned |
Environment not created | eve env create <env> |
image pull backoff |
Registry auth failed | If using BYO/custom registry, verify REGISTRY_USERNAME + REGISTRY_PASSWORD; for managed apps use registry: "eve" |
healthcheck timeout |
App not starting | Check app logs, verify ports in manifest |
If a deploy pipeline fails at the build step:
eve build list --project <project_id>
eve build diagnose <build_id>
eve build logs <build_id>
eve secrets list --project <project_id> # Required for BYO/custom registry: REGISTRY_USERNAME, REGISTRY_PASSWORD
Common build failures:
REGISTRY_USERNAME and REGISTRY_PASSWORD secretsbuild.context path in manifesteve build diagnoseEve publishes worker images to the configured private registry with these variants:
| Variant | Contents |
|---|---|
base |
Node.js, git, standard CLI tools |
python |
Base + Python runtime |
rust |
Base + Rust toolchain |
java |
Base + JDK |
kotlin |
Base + Kotlin compiler |
full |
All runtimes combined |
Version pinning: Use semver tags (e.g., v1.2.3) in production. Use SHA tags or :latest in development.
Eve automatically injects these into every deployed service container:
| Variable | Purpose |
|---|---|
EVE_API_URL |
Internal cluster URL for server-to-server calls |
EVE_PUBLIC_API_URL |
Public ingress URL for browser-facing apps (when configured) |
EVE_SSO_URL |
SSO broker URL for user authentication (when configured) |
EVE_PROJECT_ID |
Current project ID |
EVE_ORG_ID |
Current organization ID |
EVE_ENV_NAME |
Current environment name |
Use EVE_API_URL for backend calls. Use EVE_PUBLIC_API_URL for browser/client-side code. Services can override any of these by defining them explicitly in their manifest environment section.
{service}.{orgSlug}-{projectSlug}-{env}.{domain}lvh.me| Environment | How to Debug |
|---|---|
| Local (k3d) | Direct service access via ingress, eve system logs |
| Docker Compose | docker compose logs <service>, dev-only (no production use) |
| Kubernetes | Ingress-based access, kubectl -n eve logs as last resort |
Connect services on private networks (home lab GPUs, internal APIs, dev machines) to the Eve cluster. The platform creates K8s ExternalName services backed by Tailscale egress proxies.
# Register a private endpoint
eve endpoint add \
--name lmstudio \
--provider tailscale \
--tailscale-hostname mac-mini.tail12345.ts.net \
--port 1234 \
--org org_xxx
# List and inspect
eve endpoint list --org org_xxx
eve endpoint show lmstudio --org org_xxx
# Diagnose connectivity
eve endpoint diagnose lmstudio
# Remove
eve endpoint remove lmstudio --org org_xxx
Each endpoint gets a stable in-cluster DNS name: http://{orgSlug}-{name}.eve-tunnels.svc.cluster.local:{port}. Wire it into apps/agents via secrets:
eve secrets set LLM_BASE_URL \
"http://myorg-lmstudio.eve-tunnels.svc.cluster.local:1234/v1" \
--scope project
Diagnostics check: operator status, K8s service existence, DNS resolution, TCP connectivity, and HTTP health.
The default worker image is base (~800MB with Node.js, git, and all harnesses). Toolchains (Python, Rust, Java, Kotlin, media) are injected on-demand via init containers rather than bundled in a fat image.
Deployment impact: If an agent job needs toolchains, the runner pod starts init containers that copy toolchain binaries from small pre-built images. First pull adds ~5-10s; subsequent jobs on the same node use cached images.
Debugging toolchain issues:
# Check if toolchains are declared in agent config
# agents.yaml: toolchains: [python]
# If a toolchain binary is missing at runtime:
# 1. Verify agent config has the toolchain declared
# 2. Check init container logs on the runner pod
# 3. Verify toolchain images are available in the registry
To use the full image (all toolchains bundled): set EVE_WORKER_VARIANT=full or use --variant full locally.
Remove environments and clean up resources:
# Undeploy services from an environment (stops pods, keeps env record)
eve env undeploy <project> <env>
# Delete the environment entirely (removes env record, managed DB, secrets)
eve env delete <project> <env>
When a managed DB is attached, eve env delete deprovisions it. Secrets scoped to the environment are cleaned up. The environment's pipeline history remains in the audit log.
For app-level cleanup, remove the project:
eve project delete <project-id>
This cascades: environments, secrets, pipeline history, and build artifacts are removed.
Production disk management for agent workspaces:
EVE_WORKSPACE_MAX_GB — total workspace budgetEVE_WORKSPACE_MIN_FREE_GB — trigger cleanup thresholdEVE_SESSION_TTL_HOURS — auto-evict stale sessionseve-local-dev-loopeve-auth-and-secretseve-manifest-authoringMake data-driven prioritization decisions faster
Draft PRDs, status updates, and stakeholder presentations
Example
Create executive summary of Q3 roadmap, monthly progress report, feature launch announcement
Save 3-5 hours/week on communication overhead
Prerequisites
Time Estimate
30-60 minutes to see productivity improvements
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
mattpocock/skills
parcadei/continuous-claude-v3
cursor/plugins
ailabs-393/ai-labs-claude-skills
pproenca/dot-skills
mattpocock/skills
I recommend eve-deploy-debugging for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
eve-deploy-debugging has been reliable in day-to-day use. Documentation quality is above average for community skills.
Keeps context tight: eve-deploy-debugging is the kind of skill you can hand to a new teammate without a long onboarding doc.
Useful defaults in eve-deploy-debugging — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
eve-deploy-debugging fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
eve-deploy-debugging reduced setup friction for our internal harness; good balance of opinion and flexibility.
I recommend eve-deploy-debugging for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
eve-deploy-debugging is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
Registry listing for eve-deploy-debugging matched our evaluation — installs cleanly and behaves as described in the markdown.
I recommend eve-deploy-debugging for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
showing 1-10 of 47