107 lines
3.2 KiB
Markdown
107 lines
3.2 KiB
Markdown
# Deployment Profile
|
|
|
|
Use this file to stage prefilled defaults before deploying the suite into other repositories.
|
|
|
|
This file is the canonical source of preloaded build, tool, environment, workflow, and quality preferences for the deployed bundle. Keep it concise enough to be read early in a session.
|
|
|
|
## Precedence
|
|
|
|
1. Destination repository instructions
|
|
2. This deployment profile
|
|
3. Generic `AGENTS.md`, hubs, and skill files
|
|
|
|
## How To Maintain This File
|
|
|
|
- Fill out [PROJECT-PROFILE-WORKBOOK.md](./PROJECT-PROFILE-WORKBOOK.md) first.
|
|
- Rewrite the answers here as agent-facing defaults, not as questions.
|
|
- Prefer short, durable defaults over long policy prose.
|
|
- Update this file when your preferred build, tool, or workflow defaults change materially.
|
|
|
|
## Global Defaults
|
|
|
|
Replace this section with concise deployment-wide defaults for:
|
|
- target repository types
|
|
- OS, shell, and environment assumptions
|
|
- preferred package managers, build tools, and task runners
|
|
- favored languages, runtimes, and frameworks
|
|
- testing philosophy by risk level
|
|
- assumption-versus-confirmation bias
|
|
- default documentation expectations
|
|
- UX and quality bar
|
|
- release and rollout expectations
|
|
- top risks to optimize against
|
|
|
|
## Software Development Defaults
|
|
|
|
Replace this section with concise defaults for:
|
|
- architecture bias
|
|
- frontend, backend, or full-stack emphasis
|
|
- preferred frameworks and implementation patterns
|
|
- database and persistence assumptions
|
|
- migration safety posture
|
|
- dependency upgrade strategy
|
|
- performance expectations
|
|
- security baseline
|
|
- observability expectations
|
|
- refactoring and technical-debt appetite
|
|
|
|
## Debugging Defaults
|
|
|
|
Replace this section with concise defaults for:
|
|
- repro-first versus inspect-first posture
|
|
- preferred diagnostic signals
|
|
- incident and stabilization behavior
|
|
- rollback and mitigation posture
|
|
- regression-test expectations for bug fixes
|
|
- root-cause explanation standard
|
|
- acceptable short-term stabilization tradeoffs
|
|
- threshold for bundling observability improvements with fixes
|
|
|
|
## Documentation Defaults
|
|
|
|
Replace this section with concise defaults for:
|
|
- docs-as-code posture
|
|
- onboarding depth
|
|
- ADR expectations
|
|
- release-note and change-summary style
|
|
- API and integration doc expectations
|
|
- examples and snippet preference
|
|
- required update thresholds after behavior changes
|
|
- concise versus comprehensive doc bias
|
|
|
|
## UI/UX Defaults
|
|
|
|
Replace this section with concise defaults for:
|
|
- design-system strictness
|
|
- accessibility baseline
|
|
- responsive expectations
|
|
- component reuse policy
|
|
- interface copy standards
|
|
- motion and visual flourish tolerance
|
|
- boldness versus continuity preference
|
|
- required state coverage for UI readiness
|
|
|
|
## Marketing Defaults
|
|
|
|
Replace this section with concise defaults for:
|
|
- primary audience priority
|
|
- baseline voice and tone
|
|
- claim-proof expectations
|
|
- launch-content defaults
|
|
- SEO versus launch emphasis
|
|
- product-copy style
|
|
- positioning posture
|
|
- preferred CTA style
|
|
|
|
## Brainstorming Defaults
|
|
|
|
Replace this section with concise defaults for:
|
|
- breadth versus speed bias
|
|
- default option count
|
|
- scoring criteria
|
|
- prioritization method
|
|
- innovation versus practicality balance
|
|
- roadmap framing
|
|
- trigger for converting ideas into plans
|
|
- common early rejection criteria
|