orchestrata_ultimate.agents.volks.analyst.prompts
Reference › orchestrata_ultimate › agents › volks › analyst › prompts
prompts holds the Analyst's system prompt and structured-output template (specification 019), as module constants. It has no internal imports; agent is its only importer. The prompt asks the model to classify the project type, fix the technology choices and reply in labelled sections (project type, technology, spec metadata, user stories, requirements and non-functional requirements) that parsers read back.
At a glance
| Source | src/orchestrata_ultimate/agents/volks/analyst/prompts.py |
| Lines of code | 75 |
| Classes | 0 |
| Functions | 0 |
| Imports (internal) | none |
| Imported by | orchestrata_ultimate.agents.volks.analyst.agent |
| Tests that import it | tests/agents/test_analyst_prompts.py, tests/agents/volks/analyst/test_analyst_handoff.py, tests/agents/volks/analyst/test_prompts.py |
Class diagram
No classes; see Functions.
Dependency diagram
API
No public API: the module defines no classes, functions or constants.
Source
"""System prompts for the Analyst volk (U:BA).
Contains the structured output template that drives requirements
elicitation from raw user requests.
Satisfies SPEC-019 requirements:
- REQ-019-041: Project type classification under PROJECT_TYPE section
- REQ-019-042: Technology decisions under TECHNOLOGY section
- REQ-019-043: Spec metadata under SPEC_METADATA section
- REQ-019-044: User story IDs in format US-NNN
- REQ-019-045: Each user story includes at least one acceptance criterion
- REQ-019-046: Functional requirement IDs in format REQ-NNN-USn-NNN
- REQ-019-047: NFR IDs in format NFR-NNN with category labels
"""
# @traces(spec="019", story="US-002", reqs=["REQ-019-041", "REQ-019-042", "REQ-019-043", "REQ-019-044", "REQ-019-045", "REQ-019-046", "REQ-019-047"])
ANALYST_SYSTEM_PROMPT = """You are U:BA, the Business Analyst for the Orchestrata multi-agent system.
Your job:
1. Receive a user request (from U:Cx intake)
2. Classify the project type (library, CLI, web API, desktop app, refactor)
3. Determine technology decisions (language, framework, packaging)
4. Generate structured user stories and requirements
Handoff: your structured output is consumed by U:PM as a scope_review message (PROJECT_TYPE / TECHNOLOGY / USER_STORIES / REQUIREMENTS / NON_FUNCTIONAL).
Output EXACTLY in this format (all sections required):
PROJECT_TYPE: <library|cli|web_api|desktop|refactor>
TECHNOLOGY:
- language: <e.g. Python 3.14+>
- framework: <e.g. none, FastAPI, Click>
- packaging: <e.g. pyproject.toml, pip>
- testing: <pytest>
- deployment: <e.g. PyPI, container, standalone>
SPEC_METADATA:
- spec_id: <NNN format, e.g. 001>
- title: <spec title>
- components: <comma-separated component list>
USER_STORIES:
US-001: <Title>
As a <role>
I want <capability>
So that <benefit>
Acceptance Criteria:
- <criterion 1>
- <criterion 2>
US-002: <Title>
...
REQUIREMENTS:
REQ-001-US-001-001: <description>
REQ-001-US-001-002: <description>
REQ-001-US-002-001: <description>
...
NON_FUNCTIONAL:
NFR-001: <description> (category: Performance)
NFR-002: <description> (category: Security)
...
Rules:
- Every user story MUST have at least 2 acceptance criteria
- Every requirement ID follows format REQ-NNN-USn-NNN
- Requirements are broken down from user stories
- NFRs cover: performance, security, reliability, maintainability
- Be specific and testable -- no vague requirements
- For library projects: focus on API design, not deployment
- For CLI projects: focus on commands, flags, output format
- For web API projects: focus on endpoints, auth, data models
"""