9.9 KiB
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.
This version has been completed and should act as the human-readable source behind DEPLOYMENT-PROFILE.md.
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: Full-stack web apps.
2. What operating systems, shells, and local environments should the agent assume first?
Answer: Windows and PowerShell for local development. Keep Linux, Docker, and Unraid deployment realities in mind.
3. What package managers, build tools, and task runners should the agent prefer when multiple options exist?
Answer: Compatibility-first defaults and standard stack tooling.
4. Which languages, runtimes, or frameworks should get first-class preference across deployments?
Answer: Node and TypeScript first for application work, with Python acceptable for tooling and automation.
5. What is your default testing philosophy before considering work complete?
Answer: Run the most relevant local tests for the changed area by default, and broaden verification for risky changes.
6. How cautious should the agent be about asking questions versus making reasonable assumptions?
Answer: Ask-first when product intent or change risk is unclear.
7. What documentation should usually be updated when behavior, setup, or workflows change?
Answer: Readmes, Unraid install docs, roadmaps, and shipped summaries are all important and should usually be updated when changes matter.
8. What UX and polish bar should the suite assume for user-facing changes?
Answer: High polish by default.
9. What release, rollout, and communication expectations should be standard?
Answer: Provide a concise change summary by default and note rollout or migration impact when relevant.
10. What kinds of risk should the suite optimize hardest against?
Answer: Regressions and broken behavior.
Software Development Defaults
1. What architecture style or system design bias should be the default?
Answer: Favor modular boundaries and cleaner separation early.
2. How should the suite balance frontend, backend, and full-stack execution by default?
Answer: Full-stack by default.
3. Which frameworks, libraries, or implementation patterns should be preferred first?
Answer: Prefer mainstream modern patterns for the stack.
4. What database and persistence assumptions should the agent make?
Answer: Relational database first.
5. How conservative should migration and schema-change work be?
Answer: Be careful, but do not overengineer small schema changes.
6. What dependency upgrade strategy should be assumed?
Answer: Prefer small, safe, frequent upgrades with focused validation.
7. What performance bar should the suite assume by default?
Answer: Be proactive about performance on critical paths.
8. What minimum security baseline should be applied to code changes?
Answer: Basic secure defaults only: validate input, handle secrets safely, and respect auth boundaries.
9. What observability and operability expectations should be normal?
Answer: Good operational hygiene with meaningful logs and diagnostics for important paths.
10. How aggressive should the agent be about refactoring and technical debt reduction while doing feature work?
Answer: Use feature work as an opportunity to improve surrounding structure meaningfully when it helps the change.
Debugging Defaults
1. Should debugging start with reproduction first, code inspection first, or whichever is fastest to verify?
Answer: Use whichever path gives the fastest trustworthy signal.
2. What logs, traces, or diagnostics should the agent expect to consult before guessing?
Answer: Lean on logs and traces first.
3. How should the agent behave during live or user-impacting incidents?
Answer: Stabilize first, then diagnose more deeply.
4. What is the preferred rollback, mitigation, or feature-flag strategy when risk is high?
Answer: Prefer reversible mitigations such as flags, rollbacks, or partial disablement.
5. How strongly should the agent try to add or update tests when fixing bugs?
Answer: Add tests for higher-risk or recurring bugs.
6. What level of root-cause explanation should be standard after a fix?
Answer: Clearly explain cause, symptom, and why the fix works.
7. What tradeoffs are acceptable when stabilizing an issue quickly?
Answer: Avoid temporary compromises unless there is no safer path.
8. When should observability improvements be bundled with a bug fix?
Answer: For most medium or high-risk bugs, add enough signal to help next time.
Documentation Defaults
1. How strongly should the suite treat documentation as part of normal implementation work?
Answer: Docs are part of most meaningful changes unless clearly unnecessary.
2. What onboarding depth should be the default for new repos or contributor workflows?
Answer: Practical onboarding with prerequisites, setup steps, validation, and common gotchas.
3. When should architecture decision records be created or updated?
Answer: For major decisions and meaningful pattern shifts.
4. What release-note or change-summary style should be standard?
Answer: Concise, audience-aware summaries with user impact called out when relevant.
5. What level of API or integration documentation is expected by default?
Answer: Strong API and integration documentation by default.
6. How much should examples, snippets, or command samples be favored in docs?
Answer: Prefer examples for setup, APIs, and workflows where ambiguity hurts adoption.
7. What documentation updates should be mandatory after behavior or workflow changes?
Answer: Update docs for any meaningful user-facing, setup, or team workflow change.
8. What types of documentation should be concise versus comprehensive?
Answer: Balanced. Keep reference content concise and onboarding or operational content more complete.
UI/UX Defaults
1. How strict should design-system adherence be by default?
Answer: Strong preference for reuse, but custom patterns are acceptable when they clearly improve the experience.
2. What accessibility baseline should every user-facing change meet?
Answer: Do not assume extra accessibility work by default unless requested.
3. What responsive behavior should be assumed for new or updated UI?
Answer: Responsive by default for desktop and mobile.
4. How strongly should the agent favor component reuse over local implementation?
Answer: Reuse when it fits well, and create new abstractions only when they are likely to matter again.
5. What clarity and copy standards should be assumed for interface text?
Answer: Highly polished product-copy quality by default.
6. How much motion, animation, or visual flourish is appropriate by default?
Answer: Use motion and flourish actively enough to make the interface feel premium.
7. Should the suite bias toward bold, distinctive UI or conservative continuity with existing patterns?
Answer: Bold and distinctive by default, within reason.
8. How detailed should UI work be before it is considered ready?
Answer: High completeness with strong state coverage, copy quality, polish, and edge-case handling.
Marketing Defaults
1. Which audience should marketing and messaging defaults prioritize first?
Answer: Mixed audience, leaning technical and product-savvy.
2. What voice and tone should be the baseline?
Answer: Premium, distinctive, and persuasive.
3. What level of proof, specificity, or technical grounding should marketing claims include?
Answer: Claims should be persuasive but grounded in real features and outcomes.
4. What launch-content formats should be standard by default?
Answer: Broader launch kit: release notes, launch copy, landing page sections, and social or email variants.
5. How important is SEO and evergreen discoverability relative to launch messaging?
Answer: Balance both, but do not let SEO weaken clarity.
6. What product-copy style should be the default?
Answer: Strong product-copy polish with sharper differentiation and CTA energy.
7. How should the suite frame differentiation and positioning?
Answer: Conservative positioning that focuses on real value rather than aggressive comparison.
8. What types of calls to action should be preferred?
Answer: Clear, action-oriented CTAs without heavy urgency.
Brainstorming Defaults
1. Should idea generation favor breadth, speed, novelty, practicality, or a specific balance?
Answer: Favor breadth first.
2. How many options should the agent generate by default before recommending one?
Answer: Three options by default.
3. What criteria should be used most often to score or compare ideas?
Answer: User value, differentiation, and implementation realism.
4. What prioritization method should be the default for roadmap or opportunity choices?
Answer: Strategic fit, user value, and implementation cost.
5. How should innovation be balanced against implementation realism?
Answer: Balanced, but require a believable path to execution.
6. What kind of roadmap framing should be standard?
Answer: Short-to-medium horizon with practical sequencing.
7. When should brainstorming output turn into a scoped implementation plan?
Answer: Usually after a preferred option is selected.
8. What types of ideas should usually be filtered out early?
Answer: Do not filter too early. Raise concerns and explore alternatives with more value before narrowing.