Fetches eve-manifest-authoring from incept5/eve-skillpacks and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/eve-manifest-authoring
Restart Cursor to activate eve-manifest-authoring. Access via /eve-manifest-authoring in your agent's command palette.
⚠
Security Notice
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.
Keep the manifest as the single source of truth for build and deploy behavior.
Minimal skeleton (v2)
schema: eve/compose/v2
project: my-project
registry:"eve"# Use managed registry by default for Eve appsservices:api:build:context: ./apps/api # Build context directorydockerfile: Dockerfile # Optional, defaults to context/Dockerfile# image omitted by default; when build is present, Eve derives image name from service keyports:[3000]environment:NODE_ENV: production
x-eve:ingress:public:trueport:3000environments:staging:pipeline: deploy
pipeline_inputs:some_key: default_value
pipelines:deploy:steps:-name: build
action:type: build # Builds all services with build: config-name: release
depends_on:[build]action:type: release
-name: deploy
depends_on:[release]action:type: deploy
Registry Image Labels
Some registries require package metadata for permission and ownership inheritance.
Add these labels to your Dockerfiles when supported by your registry:
Why this matters: Metadata helps preserve repository ownership and improves traceability. The Eve builder injects these labels automatically, but including them in your Dockerfile is still recommended.
For multi-stage Dockerfiles, add the labels to the final stage (the production image).
Not deployed to K8s — provisioned by the orchestrator on first deploy.
Reference managed values elsewhere: ${managed.db.url}.
Eve-Migrate for Database Migrations
Use the platform's migration runner instead of Flyway, TypeORM, or Knex. It uses plain SQL files with timestamp prefixes, tracked in schema_migrations:
If the repo still uses components: from older manifests, migrate to services:
and add schema: eve/compose/v2. Keep ports and env keys the same.
Services
Provide image and optionally build (context and dockerfile).
Use ports, environment, healthcheck, depends_on as needed.
Use x-eve.external: true and x-eve.connection_url for externally hosted services.
Use x-eve.role: job for one-off services (migrations, seeds). For database migrations, prefer Eve's eve-migrate image (see below).
Build configuration
Services with Docker images should define their build configuration:
services:api:build:context: ./apps/api # Build context directorydockerfile: Dockerfile # Optional, defaults to context/Dockerfile# image: api # optional if using build; managed registry derives thisports:[3000]
Note: Every deploy pipeline should include a build step before release. The build step creates tracked BuildSpec/BuildRun records and produces image digests that releases use for deterministic deployments.
Local dev alignment
Keep service names and ports aligned with Docker Compose.
Prefer ${secret.KEY} and use .eve/dev-secrets.yaml for local values.
Environments, pipelines, workflows
Link each environment to a pipeline via environments.<env>.pipeline.
When pipeline is set, eve env deploy <env> triggers that pipeline instead of direct deploy.
Use environments.<env>.pipeline_inputs to provide default inputs for pipeline runs.
Override inputs at runtime with eve env deploy <env> --ref <sha> --inputs '{"key":"value"}' --repo-dir ./my-app.
Use --direct flag to bypass pipeline and do direct deploy: eve env deploy <env> --ref <sha> --direct --repo-dir ./my-app.
Pipeline steps can be action, script, or agent.
Use action.type: create-pr for PR automation when configured.
Workflows live under workflows and are invoked via CLI; db_access is honored.
Platform-Injected Environment Variables
Eve automatically injects these into all deployed service containers:
Variable
Description
EVE_API_URL
Internal cluster URL for server-to-server calls
EVE_PUBLIC_API_URL
Public ingress URL for browser-facing apps
EVE_PROJECT_ID
The project ID
EVE_ORG_ID
The organization ID
EVE_ENV_NAME
The environment name
Use EVE_API_URL for backend calls from your container. Use EVE_PUBLIC_API_URL for
browser/client-side code. Services can override these in their environment section.
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ 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.
Learning Path
1Basic: user stories, feature specs, status updates
