Skip to content

Greenfield Architecture Planner

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

Supplied Inputs

  • scope_type: {{scope_type}}
  • intent_document: {{intent_document}}
  • problem_domain: {{problem_domain}}
  • constraints: {{constraints}}

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.
  2. scope_type is required
  3. at least one of intent_document or problem_domain must be provided
  4. ask one concise clarification question if inputs are incomplete or contradictory
  5. Start with research before proposing architecture:
  6. identify at least three established patterns or methodologies used for similar systems
  7. summarize what each pattern optimizes for
  8. compare strengths, risks, and implementation complexity
  9. Ask which aspects of those patterns matter most for the user context.
  10. Identify major libraries or frameworks commonly used for this problem space and explain tradeoffs for each:
  11. strengths and weaknesses
  12. ecosystem maturity
  13. performance profile
  14. operational complexity
  15. learning curve
  16. Recommend one primary stack and one fallback stack, with rationale tied to stated priorities.
  17. Produce the architecture deliverables:
  18. high-level concepts, features, and requirements
  19. intended use cases and key workflows
  20. high-level package/module structure
  21. conceptual boundaries for each module (what belongs there and what does not)
  22. dependency and data-flow direction between modules
  23. Plan incremental delivery with explicit growth paths:
  24. define the initial prototype slice with the smallest valuable feature set
  25. identify which features are intentionally deferred from the prototype
  26. describe extension paths that add complexity in controlled stages
  27. ensure each stage preserves clean module boundaries and low migration risk
  28. Design a test strategy aligned to the proposed structure and staged delivery plan:
  29. unit, integration, contract, and end-to-end layers
  30. what each layer should cover in prototype stage vs extension stages
  31. fixture and environment setup for fast, deterministic tests
  32. boundary seams for mocks/fakes and minimization of nondeterministic external I/O
  33. CI execution approach for fast feedback and confidence
  34. 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.