Agent Prompt Library¶
Use these prompts with agent-context.md, the relevant section files, and the exported project-state JSON when available.
Each prompt is a controlled work order. Keep local policy, data restrictions, and human approval gates in force.
Read-Only Current-State Discovery¶
You are working in read-only discovery mode. Do not modify files.
Project: [PROJECT NAME].
Goal: help me understand the current system deeply enough to correlate implementation with business workflows, identify architecture and productionization gaps, and prepare a target architecture decision.
Start broad before narrowing. Inspect repository instructions, README files, package/build files, entry points, UI routes, API routes/controllers, domain/business logic, database/schema/migrations, integrations, authentication/authorization, tests, deployment files, environment configuration, and CI/CD clues.
Create a current-state discovery report with these sections:
1. Executive summary
2. Repository structure and technology stack
3. Runtime architecture
4. User-facing workflows
5. Screens, routes, and navigation
6. APIs and backend use cases
7. Domain model and business rules
8. Data model, persistence, migrations, and seed/demo data
9. Roles, permissions, authentication, and trust boundaries
10. Integrations and external dependencies
11. Tests and validation coverage
12. Deployment and environment assumptions
13. Observability, logging, and supportability
14. Prototype elements to retain, refactor, replace, spike, or classify as unknown
15. Productionization gaps
16. Risks of premature implementation
17. Recommended lifecycle route
18. Next five owner decisions
For every finding, distinguish observed fact, reasonable inference, assumption, and open question. Include repository-relative file path evidence. Do not create an implementation plan yet.
Architecture Diagram Package¶
Using the current-state discovery report and repository evidence, create a visual architecture package for [PROJECT NAME].
Generate Mermaid diagrams for:
1. System context
2. Container/runtime view
3. Component/module view
4. Data model / ERD
5. Primary workflow state machine
6. Sequence diagram for the most important user workflow
7. Deployment view
8. Security and trust-boundary view
For each diagram:
- Include a short explanation.
- State what is observed from code versus inferred.
- Highlight unknowns.
- Identify productionization risks.
- Do not invent integrations, roles, or services that are not supported by evidence.
- If prototype code conflicts with documentation or workflow notes, call out the contradiction.
Product Shape Brief¶
Create a product shape brief for [PROJECT NAME].
Use the current-state discovery, stakeholder notes, prototype behavior, and workflow artifacts as evidence. Do not invent features. Separate observed facts, assumptions, and open questions.
Include:
1. Product thesis
2. Problem statement
3. Business outcomes
4. Primary users and secondary stakeholders
5. Jobs to be done
6. Current manual or prototype-supported process
7. Core workflows
8. Exception workflows
9. Business rules
10. Decision tables
11. Conceptual data model
12. Roles and permissions
13. MVP scope
14. Explicit non-goals
15. Deferred roadmap
16. Acceptance criteria
17. UAT scenarios
18. Risks and unresolved questions
19. Owner decisions needed before technical design
Keep the document practical enough to drive implementation and client review.
Architecture Options Comparison¶
Compare architecture options for [PROJECT NAME] using evidence from the current-state discovery and product shape brief.
Options to evaluate:
1. Productionize the prototype in place
2. Refactor the prototype into a modular architecture
3. Rebuild as a production modular monolith
4. Build service-oriented or microservice architecture
5. Use low-code/configuration platform
6. Defer implementation pending additional discovery
Score each option from 1 to 5 on maintainability, modularity, security, testability, delivery speed, long-term scalability, operational simplicity, team skill fit, agent compatibility, client fit, cost, and risk.
Provide the decision matrix, recommendation, rationale, risks, mitigations, revisit trigger, and first vertical slice that would prove the decision.
Technical Design From Approved Architecture¶
Create a practical technical design for [PROJECT NAME] based on the approved architecture decision.
Include:
1. Executive summary
2. System boundaries
3. Technology stack
4. Module boundaries
5. Data model and migrations
6. API/use-case design
7. Workflow state model
8. Roles and authorization model
9. Validation and error-handling strategy
10. Audit logging strategy
11. Testing strategy
12. Environment strategy
13. Deployment and rollback approach
14. Observability and supportability
15. Security checklist
16. Open questions
17. First three implementation slices
Keep the design implementation-ready but avoid speculative architecture.
Execution Plan For First Vertical Slice¶
Create an execution plan for the first vertical slice of [PROJECT NAME].
The slice must exercise UI, application/use-case logic, domain rule, database persistence, authorization, validation, and tests. Keep the slice small enough to review in one PR.
Include objective, business outcome, acceptance criteria, files and modules likely affected, data model changes, migration plan, API/use-case changes, UI changes, authorization impact, test plan, manual validation steps, risks, rollback considerations, commit/PR plan, and definition of done.
Do not implement yet. Wait for approval.
Test Strategy Generator¶
Create a practical test strategy for [PROJECT NAME].
Use the product shape brief, architecture decision, technical design, and current-state discovery. Focus on tests that protect business-critical behavior and avoid test bloat.
Include testing principles, domain unit tests, application/use-case tests, integration tests, API tests, workflow/E2E tests, UAT scripts, security tests, golden scenario suite, test data and fixtures, CI gating strategy, maintenance rules, and tests to avoid or defer.
For each proposed test, explain the business risk it protects.
Security Review¶
Perform a security review of [PROJECT NAME] using a pragmatic subset of NIST SSDF and OWASP ASVS concepts.
Focus on authentication, authorization and role enforcement, direct object access risks, input validation, secrets management, sensitive data handling, audit logging, dependency and supply-chain risk, error handling and information disclosure, configuration by environment, admin functions, data backup and restore, and agent-generated code governance.
Classify findings as blocker, high, medium, low, or observation. For each finding, provide evidence, impact, recommended fix, and validation method.
PR Review Checklist¶
Review this PR for [PROJECT NAME] as an architecture-aware reviewer.
Evaluate alignment with approved architecture and module boundaries, business behavior and acceptance criteria, data integrity and migrations, authorization and security impact, error handling, test quality and meaningful assertions, maintainability and readability, unnecessary abstraction or over-engineering, hidden coupling, documentation updates, and production operations risk.
Return summary, must-fix issues, should-fix issues, questions, suggested tests, approval recommendation, and follow-up technical debt items.
Production Readiness Review¶
Conduct a production readiness review for [PROJECT NAME].
Review evidence across product readiness, data readiness, security readiness, quality readiness, operational readiness, business readiness, support readiness, deployment readiness, and rollback readiness.
For each area, classify as ready, conditionally ready, not ready, or unknown. Identify launch blockers, accepted risks, missing evidence, owner decisions, and post-launch follow-ups. End with a readiness assessment, required local reviewers, and the local approval gate. Do not approve launch, compliance, security acceptance, or production release.
Client-Facing Progress Summary¶
Create a client-facing progress summary for [PROJECT NAME].
Tone: clear, practical, business-readable, not overly technical.
Include what has been clarified, what has been built or validated, workflow or product decisions made, current risks or known limitations, decisions needed from the client/product owner, next milestone, and what will be demonstrated next.
Do not expose raw agent activity, credentials, security-sensitive implementation details, or low-level engineering churn.