208 lines
9.6 KiB
Markdown
208 lines
9.6 KiB
Markdown
|
|
# Project Profile Workbook
|
||
|
|
|
||
|
|
Fill out this workbook once before deployment when you want the suite to ship with pre-staged defaults for build, tools, environment, workflow, and quality preferences.
|
||
|
|
|
||
|
|
The answers here are for humans to provide. After filling this out, translate the answers into [DEPLOYMENT-PROFILE.md](./DEPLOYMENT-PROFILE.md) so agents can use the results directly.
|
||
|
|
|
||
|
|
## How To Use This Workbook
|
||
|
|
|
||
|
|
- Keep answers concise and specific.
|
||
|
|
- Prefer durable defaults over task-specific preferences.
|
||
|
|
- If a question does not matter for your projects, write `No strong preference`.
|
||
|
|
- If your answer depends on project type, note the default and the main exception.
|
||
|
|
- Treat this workbook as the source for pre-deployment staging, not a runtime questionnaire.
|
||
|
|
|
||
|
|
## Global Defaults
|
||
|
|
|
||
|
|
### 1. What repository types should this suite optimize for by default?
|
||
|
|
Answer shape: short list of repo types and their priority.
|
||
|
|
|
||
|
|
### 2. What operating systems, shells, and local environments should the agent assume first?
|
||
|
|
Answer shape: primary OS, shell, and any fallback assumptions.
|
||
|
|
|
||
|
|
### 3. What package managers, build tools, and task runners should the agent prefer when multiple options exist?
|
||
|
|
Answer shape: ranked tool preferences plus any tools to avoid.
|
||
|
|
|
||
|
|
### 4. Which languages, runtimes, or frameworks should get first-class preference across deployments?
|
||
|
|
Answer shape: priority-ordered stack preferences.
|
||
|
|
|
||
|
|
### 5. What is your default testing philosophy before considering work complete?
|
||
|
|
Answer shape: what level of testing is expected for low, medium, and high-risk changes.
|
||
|
|
|
||
|
|
### 6. How cautious should the agent be about asking questions versus making reasonable assumptions?
|
||
|
|
Answer shape: preferred bias plus examples of when to stop and confirm.
|
||
|
|
|
||
|
|
### 7. What documentation should usually be updated when behavior, setup, or workflows change?
|
||
|
|
Answer shape: required doc types and the threshold for updating them.
|
||
|
|
|
||
|
|
### 8. What UX and polish bar should the suite assume for user-facing changes?
|
||
|
|
Answer shape: default quality bar and what cannot be skipped.
|
||
|
|
|
||
|
|
### 9. What release, rollout, and communication expectations should be standard?
|
||
|
|
Answer shape: release-note, migration-note, and rollout-summary expectations.
|
||
|
|
|
||
|
|
### 10. What kinds of risk should the suite optimize hardest against?
|
||
|
|
Answer shape: ranked risks such as regressions, slow delivery, incidents, weak UX, docs drift, or security gaps.
|
||
|
|
|
||
|
|
## Software Development Defaults
|
||
|
|
|
||
|
|
### 1. What architecture style or system design bias should be the default?
|
||
|
|
Answer shape: preferred architecture patterns and anti-patterns.
|
||
|
|
|
||
|
|
### 2. How should the suite balance frontend, backend, and full-stack execution by default?
|
||
|
|
Answer shape: preferred split and what usually takes priority.
|
||
|
|
|
||
|
|
### 3. Which frameworks, libraries, or implementation patterns should be preferred first?
|
||
|
|
Answer shape: preferred stack choices and any banned or discouraged patterns.
|
||
|
|
|
||
|
|
### 4. What database and persistence assumptions should the agent make?
|
||
|
|
Answer shape: default datastore types, ORM/query preferences, and data-model expectations.
|
||
|
|
|
||
|
|
### 5. How conservative should migration and schema-change work be?
|
||
|
|
Answer shape: rollout posture, compatibility expectations, and rollback requirements.
|
||
|
|
|
||
|
|
### 6. What dependency upgrade strategy should be assumed?
|
||
|
|
Answer shape: preferred upgrade cadence, batch size, and tolerance for deprecations.
|
||
|
|
|
||
|
|
### 7. What performance bar should the suite assume by default?
|
||
|
|
Answer shape: key performance concerns and when optimization should be proactive.
|
||
|
|
|
||
|
|
### 8. What minimum security baseline should be applied to code changes?
|
||
|
|
Answer shape: required checks around auth, validation, secrets, or exposure.
|
||
|
|
|
||
|
|
### 9. What observability and operability expectations should be normal?
|
||
|
|
Answer shape: logging, metrics, traces, dashboards, and alerting expectations.
|
||
|
|
|
||
|
|
### 10. How aggressive should the agent be about refactoring and technical debt reduction while doing feature work?
|
||
|
|
Answer shape: cleanup appetite and what counts as acceptable adjacent improvement.
|
||
|
|
|
||
|
|
## Debugging Defaults
|
||
|
|
|
||
|
|
### 1. Should debugging start with reproduction first, code inspection first, or whichever is fastest to verify?
|
||
|
|
Answer shape: preferred starting posture and exceptions.
|
||
|
|
|
||
|
|
### 2. What logs, traces, or diagnostics should the agent expect to consult before guessing?
|
||
|
|
Answer shape: preferred debugging signals in priority order.
|
||
|
|
|
||
|
|
### 3. How should the agent behave during live or user-impacting incidents?
|
||
|
|
Answer shape: stabilize-first versus diagnose-first posture and escalation expectations.
|
||
|
|
|
||
|
|
### 4. What is the preferred rollback, mitigation, or feature-flag strategy when risk is high?
|
||
|
|
Answer shape: favored containment methods and what to avoid under pressure.
|
||
|
|
|
||
|
|
### 5. How strongly should the agent try to add or update tests when fixing bugs?
|
||
|
|
Answer shape: regression-test expectations by bug type or risk.
|
||
|
|
|
||
|
|
### 6. What level of root-cause explanation should be standard after a fix?
|
||
|
|
Answer shape: expected detail and preferred format.
|
||
|
|
|
||
|
|
### 7. What tradeoffs are acceptable when stabilizing an issue quickly?
|
||
|
|
Answer shape: acceptable temporary fixes, degraded modes, or short-term compromises.
|
||
|
|
|
||
|
|
### 8. When should observability improvements be bundled with a bug fix?
|
||
|
|
Answer shape: default threshold for adding logs, metrics, traces, or alerts.
|
||
|
|
|
||
|
|
## Documentation Defaults
|
||
|
|
|
||
|
|
### 1. How strongly should the suite treat documentation as part of normal implementation work?
|
||
|
|
Answer shape: docs-as-code posture and exceptions.
|
||
|
|
|
||
|
|
### 2. What onboarding depth should be the default for new repos or contributor workflows?
|
||
|
|
Answer shape: expected setup detail and verification guidance.
|
||
|
|
|
||
|
|
### 3. When should architecture decision records be created or updated?
|
||
|
|
Answer shape: qualifying decision types and expected depth.
|
||
|
|
|
||
|
|
### 4. What release-note or change-summary style should be standard?
|
||
|
|
Answer shape: preferred audience, tone, and detail level.
|
||
|
|
|
||
|
|
### 5. What level of API or integration documentation is expected by default?
|
||
|
|
Answer shape: minimum doc standard for interfaces and integrations.
|
||
|
|
|
||
|
|
### 6. How much should examples, snippets, or command samples be favored in docs?
|
||
|
|
Answer shape: preferred density and where examples are most important.
|
||
|
|
|
||
|
|
### 7. What documentation updates should be mandatory after behavior or workflow changes?
|
||
|
|
Answer shape: triggers that require doc updates.
|
||
|
|
|
||
|
|
### 8. What types of documentation should be concise versus comprehensive?
|
||
|
|
Answer shape: guidance by doc type.
|
||
|
|
|
||
|
|
## UI/UX Defaults
|
||
|
|
|
||
|
|
### 1. How strict should design-system adherence be by default?
|
||
|
|
Answer shape: reuse posture and when custom patterns are acceptable.
|
||
|
|
|
||
|
|
### 2. What accessibility baseline should every user-facing change meet?
|
||
|
|
Answer shape: required accessibility checks and must-have standards.
|
||
|
|
|
||
|
|
### 3. What responsive behavior should be assumed for new or updated UI?
|
||
|
|
Answer shape: required device classes and layout expectations.
|
||
|
|
|
||
|
|
### 4. How strongly should the agent favor component reuse over local implementation?
|
||
|
|
Answer shape: reuse threshold and when new abstractions are warranted.
|
||
|
|
|
||
|
|
### 5. What clarity and copy standards should be assumed for interface text?
|
||
|
|
Answer shape: tone, verbosity, and UX-writing preferences.
|
||
|
|
|
||
|
|
### 6. How much motion, animation, or visual flourish is appropriate by default?
|
||
|
|
Answer shape: motion tolerance and preferred feel.
|
||
|
|
|
||
|
|
### 7. Should the suite bias toward bold, distinctive UI or conservative continuity with existing patterns?
|
||
|
|
Answer shape: preferred visual stance and exceptions.
|
||
|
|
|
||
|
|
### 8. How detailed should UI work be before it is considered ready?
|
||
|
|
Answer shape: expected treatment of empty, loading, error, success, and edge states.
|
||
|
|
|
||
|
|
## Marketing Defaults
|
||
|
|
|
||
|
|
### 1. Which audience should marketing and messaging defaults prioritize first?
|
||
|
|
Answer shape: primary audience, secondary audience, and who to deprioritize.
|
||
|
|
|
||
|
|
### 2. What voice and tone should be the baseline?
|
||
|
|
Answer shape: 3-5 tone traits and anything to avoid.
|
||
|
|
|
||
|
|
### 3. What level of proof, specificity, or technical grounding should marketing claims include?
|
||
|
|
Answer shape: proof standard and claim tolerance.
|
||
|
|
|
||
|
|
### 4. What launch-content formats should be standard by default?
|
||
|
|
Answer shape: favored deliverables such as release notes, emails, landing pages, blog posts, or social posts.
|
||
|
|
|
||
|
|
### 5. How important is SEO and evergreen discoverability relative to launch messaging?
|
||
|
|
Answer shape: priority order and content bias.
|
||
|
|
|
||
|
|
### 6. What product-copy style should be the default?
|
||
|
|
Answer shape: clarity, persuasion, length, and CTA preferences.
|
||
|
|
|
||
|
|
### 7. How should the suite frame differentiation and positioning?
|
||
|
|
Answer shape: preferred competitive posture and value framing.
|
||
|
|
|
||
|
|
### 8. What types of calls to action should be preferred?
|
||
|
|
Answer shape: action style, urgency, and conversion posture.
|
||
|
|
|
||
|
|
## Brainstorming Defaults
|
||
|
|
|
||
|
|
### 1. Should idea generation favor breadth, speed, novelty, practicality, or a specific balance?
|
||
|
|
Answer shape: default ideation bias and what to avoid.
|
||
|
|
|
||
|
|
### 2. How many options should the agent generate by default before recommending one?
|
||
|
|
Answer shape: preferred option count for small, medium, and strategic decisions.
|
||
|
|
|
||
|
|
### 3. What criteria should be used most often to score or compare ideas?
|
||
|
|
Answer shape: ranked decision criteria.
|
||
|
|
|
||
|
|
### 4. What prioritization method should be the default for roadmap or opportunity choices?
|
||
|
|
Answer shape: preferred comparison framework or decision lens.
|
||
|
|
|
||
|
|
### 5. How should innovation be balanced against implementation realism?
|
||
|
|
Answer shape: preferred balance and when to lean harder one way.
|
||
|
|
|
||
|
|
### 6. What kind of roadmap framing should be standard?
|
||
|
|
Answer shape: preferred time horizon and planning granularity.
|
||
|
|
|
||
|
|
### 7. When should brainstorming output turn into a scoped implementation plan?
|
||
|
|
Answer shape: trigger conditions and expected planning depth.
|
||
|
|
|
||
|
|
### 8. What types of ideas should usually be filtered out early?
|
||
|
|
Answer shape: common rejection criteria.
|