prompts/docs/prompts/greenfield-architecture/PROMPT.md

name, description, x-personal-mcp

name	description	x-personal-mcp
greenfield-architecture	Research established patterns and design a high-level architecture for a new app or library with explicit tradeoffs and test strategy.	id version tags capabilities arguments greenfield-architecture 1.0.0 architecture planning greenfield design testing prompts resource://prompts/greenfield-architecture/document scope_type intent_document problem_domain constraints title description required Scope type Scope type: app or library. true title description required Intent document Optional full document describing goals, context, and desired outcomes. false title description required Problem domain Domain and business goal for the new app or library when no full intent document is provided. false title description required Constraints Runtime, deployment, and non-functional constraints. false

Greenfield Architecture Planner

Use this prompt to design a new software app or library architecture in generic terms.

Inputs

1. intent_document: optional full document that explains goals, context, constraints, and desired outcomes
2. problem_domain: concise domain and one-sentence business goal when no full intent document is provided
3. scope_type: app or library
4. optional constraints: runtime, deployment, scale, non-functional priorities

If both intent_document and problem_domain are provided, treat intent_document as the primary source and use problem_domain as a summary cross-check.

Workflow

1. Validate required inputs.

• scope_type is required
• at least one of intent_document or problem_domain must be provided
• ask one concise clarification question if inputs are incomplete or contradictory

2. Start with research before proposing architecture:
   • identify at least three established patterns or methodologies used for similar systems
   • summarize what each pattern optimizes for
   • compare strengths, risks, and implementation complexity
3. Ask which aspects of those patterns matter most for the user context.
4. Identify major libraries or frameworks commonly used for this problem space and explain tradeoffs for each:
   • strengths and weaknesses
   • ecosystem maturity
   • performance profile
   • operational complexity
   • learning curve
5. Recommend one primary stack and one fallback stack, with rationale tied to stated priorities.
6. Produce the architecture deliverables:
   • high-level concepts, features, and requirements
   • intended use cases and key workflows
   • high-level package/module structure
   • conceptual boundaries for each module (what belongs there and what does not)
   • dependency and data-flow direction between modules
7. Plan incremental delivery with explicit growth paths:

• define the initial prototype slice with the smallest valuable feature set
• identify which features are intentionally deferred from the prototype
• describe extension paths that add complexity in controlled stages
• ensure each stage preserves clean module boundaries and low migration risk

8. Design a test strategy aligned to the proposed structure and staged delivery plan:
   • unit, integration, contract, and end-to-end layers

• what each layer should cover in prototype stage vs extension stages
• fixture and environment setup for fast, deterministic tests
• boundary seams for mocks/fakes and minimization of nondeterministic external I/O
• CI execution approach for fast feedback and confidence

9. Call out key risks, assumptions, and open questions.

Output Contract

Return these sections in order:

1. Research Summary
2. Pattern Comparison
3. Library and Framework Tradeoffs
4. Recommended Stack
5. Architecture Overview
6. Concepts, Features, and Requirements
7. Intended Use Cases
8. Package and Module Layout
9. Conceptual Boundary Map
10. Initial Prototype Scope
11. Extension Roadmap
12. Test Strategy
13. Risks and Open Questions
14. Next Implementation Steps

Quality Rules

1. Keep language generic and project-agnostic.
2. Prefer established patterns over novelty unless there is a strong reason to diverge.
3. Tie each recommendation to an explicit requirement or tradeoff.
4. Make assumptions explicit and concise.
5. Ask one focused clarifying question when confidence is low instead of over-speculating.
6. Prefer architecture decisions that support starting simple and growing complexity without major rewrites.