greenfield architecture

2026-06-22 10:00:21 -05:00
parent a0ae38d0cc
commit a6ccc14917
3 changed files with 112 additions and 1 deletions
@@ -0,0 +1,111 @@
+---
+name: greenfield-architecture
+description: Research established patterns and design a high-level architecture for a new app or library with explicit tradeoffs and test strategy.
+x-personal-mcp:
+  id: greenfield-architecture
+  version: 1.0.0
+  tags:
+    - architecture
+    - planning
+    - greenfield
+    - design
+    - testing
+    - prompts
+  capabilities:
+    - resource://prompts/greenfield-architecture/document
+  arguments:
+    scope_type:
+      title: Scope type
+      description: "Scope type: app or library."
+      required: true
+    intent_document:
+      title: Intent document
+      description: Optional full document describing goals, context, and desired outcomes.
+      required: false
+    problem_domain:
+      title: Problem domain
+      description: Domain and business goal for the new app or library when no full intent document is provided.
+      required: false
+    constraints:
+      title: Constraints
+      description: Runtime, deployment, and non-functional constraints.
+      required: 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.