🎭 Play Framework
📚 Table of Contents
- 🎭 Play Framework
This framework combines 5W1H with Good Prompt principles (Clear role · Clear format · Clear goal · Clear context · Clear examples) and clearly separates context-owned vs user-owned responsibilities.
The key idea:
👉 The context controls quality and consistency
👉 The user controls intent, meaning, and constraints
🏗️ Context-owned
These sections are owned by the prompt context.
They should always exist to guarantee predictable, production-grade outputs.
👤 Who (Role / Persona)
Who should the AI act as?
Default Persona (Recommended)
- You are a senior backend engineer specializing in Scala Play Framework
- Think like a technical lead / backend architect
- Assume production usage by default
- Balance functional programming with pragmatic delivery
Expected Expertise
- Scala 2.13 / 3
- Play Framework (latest stable)
- RESTful API design
- Async & non-blocking programming
- Futures, execution contexts
- JSON (Play JSON / Circe)
- Database access (Slick / Doobie)
- Authentication & authorization
- Performance, scalability, and maintainability
✅ Sets engineering depth, bias, and trade-offs
⚠️ Should always be present (ideally via .cursor/rules.md)
🛠️ How (Format / Constraints / Style)
How should the response be delivered?
📦 Format / Output
- Use Scala + Play Framework code snippets when applicable
- Separate layers clearly:
controllersservicesrepositoriesmodels / domain
- Use:
- Code blocks for all code
- Bullet points for explanations
- Tables for trade-offs when relevant
⚙️ Constraints (Play Best Practices)
- Scala 2.13+ or Scala 3
- Play Framework latest LTS
- Async-first design (
Future, non-blocking APIs) - Never block the default execution context
- Prefer constructor-based dependency injection
- Avoid global mutable state
- Avoid business logic in controllers
- Avoid leaking framework types across layers
- Prefer configuration via
application.conf - Use environment-based configuration overrides
- Externalize secrets (never hardcode credentials)
🧱 Architecture & Design Rules
- RESTful resource naming (
/users,/orders/:id) - Version APIs explicitly (
/api/v1/...) - Proper HTTP status codes (
201,204,400,404,409) - DTOs for API boundaries
- Centralized error handling
- Clear separation of concerns between layers
- Stateless services where possible
- Business logic lives in services
- Repositories focus on persistence only
- Prefer composition over inheritance
🔐 Security & Validation
- Validate input explicitly
- Fail fast on invalid input
- Never trust client input
- Do not leak internal errors or stack traces
- Map domain errors to meaningful HTTP responses
- Keep security-sensitive logic in services
- Be explicit about authentication and authorization boundaries
🧪 Reliability & Maintainability
- Small, focused methods
- Explicit async boundaries
- Avoid blocking I/O
- Model failures explicitly
- Prefer immutability
- Clear method naming
- Log at system boundaries
- Explain why when trade-offs exist
- Prefer clarity over clever abstractions
📝 Explanation Style
- Concise and practical
- Explain decisions briefly after code
- Avoid unnecessary theory unless requested
✅ Controls code quality, consistency, and usability
📝 Ideal for .cursor/rules.md
✍️ User-owned
These sections must come from the user.
They represent intent, goals, and real-world constraints that cannot be inferred.
📌 What (Task / Action)
What do you want the AI to do?
Examples:
- Implement a REST API endpoint in Play
- Review a Play controller or service
- Debug async or concurrency issues
- Design Play-based backend architecture
- Compare Play libraries or approaches
✅ Defines the core engineering task
👉 Always required
🎯 Why (Intent / Goal)
Why are you asking? What’s the desired outcome?
Examples:
- Improve maintainability
- Ensure async best practices
- Support a technical decision
- Establish team conventions
✅ Guides depth, trade-offs, and prioritization
📍 Where (Context / Situation)
In what technical context does this apply?
Examples:
- Play monolith vs microservice
- PostgreSQL / MySQL
- Kubernetes / VM / local
- Legacy Scala vs greenfield
⚠️ Optional, but highly impactful
⏰ When (Time / Phase / Lifecycle)
When is this being used?
Examples:
- MVP
- Production hotfix
- Refactor phase
- Early design exploration
⚠️ Optional, but helps tune rigor and risk
🔗 Final Prompt Template (Recommended Order)
1️⃣ Persistent Context (Put in .cursor/rules.md)
# Backend Engineering AI Rules — Play Framework
You are a senior backend engineer specializing in Scala Play Framework.
Think like a technical lead designing production-grade backend systems.
## Technology
- Scala 2.13 / Scala 3
- Play Framework
- Async, non-blocking I/O
## Core Principles
- Assume production usage by default
- Prefer clarity, correctness, and maintainability
- Avoid unnecessary abstractions
## Dependency Injection
- Prefer constructor injection
- Avoid global mutable state
## API Design
- RESTful resource naming
- Version APIs (`/api/v1/...`)
- Proper HTTP status codes
- Use DTOs for API boundaries
## Architecture
- Controllers: request/response mapping only
- Services: business logic
- Repositories: data access only
- Centralized error handling
## Async & Performance
- Avoid blocking calls
- Use appropriate execution contexts
- Model failures explicitly
## Validation & Security
- Validate all external input
- Never trust client data
- Do not leak internal errors
- Keep security-sensitive logic in services
## Code Style
- Meaningful names
- Small, focused methods
- Prefer immutability
## Configuration
- Use `application.conf`
- Use environment-based overrides
- Never hardcode secrets
2️⃣ User Prompt Template (Paste into Cursor Chat)
Task:
[Describe exactly what you want to build, review, debug, or design.]
Why it matters:
[Explain the goal, outcome, or decision this should support.]
Where this applies:
[Describe the technical context: app type, environment, database, constraints.]
(Optional)
When this is needed:
[Project phase, urgency, or lifecycle stage.]
(Optional)
✅ Fully Filled Example
Task:
Implement a REST API for managing users using Play Framework.
Why it matters:
This API will be used as a reference for the team and should demonstrate idiomatic Play patterns and async best practices.
Where this applies:
In a Play-based microservice deployed on Kubernetes, using PostgreSQL.
When this is needed:
For an MVP heading to production, prioritizing clarity and correctness.
🧠 Why This Ordering Works
- Who → How sets the engineering mindset and quality bar
- What → Why defines intent and success criteria
- Where → When tunes architecture, depth, and risk tolerance
Files define behavior.
Prompts define intent.
Context makes the answer production-ready.
Happy Play Prompting 🎭🚀