Deployment
Purpose
Safely prepare, deploy, verify, and troubleshoot Cee-Tailor releases.
Project Stack
Project-defined deployment platform, Next.js, FastAPI, PostgreSQL, Redis.
Operating Principles
- Inspect the actual deployment configuration before making assumptions.
- Never assume a provider, environment, or service exists.
- Keep production secrets outside source control.
- Verify build and runtime commands.
- Understand environment variables required by each service.
- Database migrations must be considered part of deployment.
- Use health checks where available.
- Verify the deployed application after changes.
- Keep rollback procedures clear.
- Do not make destructive production changes without explicit confirmation.
Required Workflow
- Inspect deployment configuration.
- Identify build, runtime, environment, and database requirements.
- Validate locally where possible.
- Deploy using the project's established mechanism.
- Verify service health.
- Verify critical user flows.
- Check logs.
- Confirm migration state.
- Record deployment result and remaining uncertainty.
Evidence Rules
Use the strongest available evidence in this order:
- Runtime behavior
- Automated test results
- Type checking, linting, and build results
- Installed package/source behavior
- Official framework or library documentation
- Repository configuration
- Static code inspection
- General model knowledge
Never report an assumption as a verified result.
Tool Selection
- Use Filesystem MCP for repository exploration and file inspection.
- Use Context7 for current, version-specific library/framework documentation.
- Use Fetch when official documentation or public web resources need to be retrieved.
- Use Playwright for browser behavior, frontend interaction, forms, authentication flows, and UI verification.
- Use GitHub CLI for repository, branch, pull request, issue, workflow, and CI operations.
- Prefer the smallest tool set that establishes reliable evidence.
Failure Handling
When something fails:
- Reproduce the failure.
- Capture the exact error.
- Identify the failing layer.
- Check whether the failure is environmental, dependency-related, configuration-related, or caused by application code.
- Research uncertain behavior using authoritative sources.
- Apply the smallest appropriate fix.
- Reproduce the original failure again.
- Run regression checks.
- Inspect the final diff.
Do not hide failures by weakening tests, suppressing errors, deleting evidence, or claiming success without verification.
Security
- Never expose secrets.
- Never commit credentials.
- Treat all external input as untrusted.
- Preserve authentication and authorization boundaries.
- Avoid leaking internal implementation details through errors.
- Review security implications whenever the skill touches users, data, credentials, networking, or deployment.
Completion Criteria
A task using this skill is complete only when:
- The requested behavior is implemented.
- Existing project conventions are preserved.
- Relevant static checks pass.
- Relevant tests pass or their absence is explicitly reported.
- Browser verification is performed when the task affects user-facing behavior.
- Security implications have been considered.
- The final diff has been inspected.
- Verified facts are clearly distinguished from assumptions or remaining uncertainty.
1---2name: deployment3description: Deployment4---5# Deployment67## Purpose89Safely prepare, deploy, verify, and troubleshoot Cee-Tailor releases.1011## Project Stack1213Project-defined deployment platform, Next.js, FastAPI, PostgreSQL, Redis.1415## Operating Principles16171. Inspect the actual deployment configuration before making assumptions.182. Never assume a provider, environment, or service exists.193. Keep production secrets outside source control.204. Verify build and runtime commands.215. Understand environment variables required by each service.226. Database migrations must be considered part of deployment.237. Use health checks where available.248. Verify the deployed application after changes.259. Keep rollback procedures clear.2610. Do not make destructive production changes without explicit confirmation.2728## Required Workflow29301. Inspect deployment configuration.312. Identify build, runtime, environment, and database requirements.323. Validate locally where possible.334. Deploy using the project's established mechanism.345. Verify service health.356. Verify critical user flows.367. Check logs.378. Confirm migration state.389. Record deployment result and remaining uncertainty.3940## Evidence Rules4142Use the strongest available evidence in this order:43441. Runtime behavior452. Automated test results463. Type checking, linting, and build results474. Installed package/source behavior485. Official framework or library documentation496. Repository configuration507. Static code inspection518. General model knowledge5253Never report an assumption as a verified result.5455## Tool Selection5657- Use Filesystem MCP for repository exploration and file inspection.58- Use Context7 for current, version-specific library/framework documentation.59- Use Fetch when official documentation or public web resources need to be retrieved.60- Use Playwright for browser behavior, frontend interaction, forms, authentication flows, and UI verification.61- Use GitHub CLI for repository, branch, pull request, issue, workflow, and CI operations.62- Prefer the smallest tool set that establishes reliable evidence.6364## Failure Handling6566When something fails:67681. Reproduce the failure.692. Capture the exact error.703. Identify the failing layer.714. Check whether the failure is environmental, dependency-related, configuration-related, or caused by application code.725. Research uncertain behavior using authoritative sources.736. Apply the smallest appropriate fix.747. Reproduce the original failure again.758. Run regression checks.769. Inspect the final diff.7778Do not hide failures by weakening tests, suppressing errors, deleting evidence, or claiming success without verification.7980## Security8182- Never expose secrets.83- Never commit credentials.84- Treat all external input as untrusted.85- Preserve authentication and authorization boundaries.86- Avoid leaking internal implementation details through errors.87- Review security implications whenever the skill touches users, data, credentials, networking, or deployment.8889## Completion Criteria9091A task using this skill is complete only when:9293- The requested behavior is implemented.94- Existing project conventions are preserved.95- Relevant static checks pass.96- Relevant tests pass or their absence is explicitly reported.97- Browser verification is performed when the task affects user-facing behavior.98- Security implications have been considered.99- The final diff has been inspected.100- Verified facts are clearly distinguished from assumptions or remaining uncertainty.