/plea

LLM Instruction Prompt Generation

Purpose: Templates and authoring rules for the paste-ready LLM instruction prompts Plea pairs with every demand and every report.

Plea emits two granularities. Both are mandatory output — not optional.

Action Verbs

One verb per prompt, declared at the top of # Your task.

Default verb by receiving agent

Authoring Rules

• Always quote the user voice verbatim inside the prompt — never paraphrase out the emotion.
• Tag synthetic origin explicitly (synthetic: true) so the receiving agent calibrates confidence.
• State the action verb at the top of # Your task. One verb per prompt.
• Include acceptance criteria so the receiving agent has a definition of done.
• End with constraints on hypothesis-handling, traceability, and contradiction-preservation.
• In multi Recipe output: embed each demand's engine_concurrence and calibration tags so downstream agents know whether they are acting on a 3/3-validated demand or a 1/3-divergent hypothesis.

Per-Request Prompt Template

Embedded inside each ## Request block as ### LLM Instruction Prompt:

### LLM Instruction Prompt
```text
You are receiving a synthetic user demand generated by Plea (user advocate).

# Persona
- Name / Archetype: [persona name] ([archetype])
- Daily context: [one-line context]
- Current emotion: [emotion]

# Demand
- Title: [title]
- Scene: [when/where/what]

# User voice (verbatim — do not paraphrase)
> [first-person voice]

# Why this matters
- [reason 1]
- [reason 2]

# Acceptance criteria (user perspective)
- [ ] [criterion 1]
- [ ] [criterion 2]

# Your task
[ANALYZE | PROPOSE | DESIGN | DRAFT-SPEC | PROTOTYPE | REFINE]
Produce: [expected deliverable for the next agent]

# Constraints
- Treat this as a synthetic hypothesis (`synthetic: true`), not validated user voice.
- Preserve user-voice intent; do not silently drop on feasibility grounds.
- Flag assumptions explicitly and list clarifying questions before proposing solutions if ACs are ambiguous.
```

Per-Report Orchestration Prompt Template

Appended at the end of the Demand Report as ## LLM Orchestration Prompt (paste-ready):

## LLM Orchestration Prompt (paste-ready)
```text
You are receiving a User Demand Report from Plea covering [scope].

# Source
- Personas used: [N personas with archetypes]
- Total demands: [M]
- Top user-felt urgency: [demand title]
- Biggest blind spot: [blind spot]

# Demands
[Embed structured request list above, each with its persona attribution]

# Cross-persona analysis
[Shared demands / persona-specific demands]

# Assumption challenges
[3+ team assumptions with user-reality counterarguments]

# Your task
Choose the action that matches your role:
- Spark: structure these demands into feature proposals with hypothesis and KPIs.
- Scribe[unified]: integrate user-voice requirements into spec packages (L0-L3).
- Scribe: convert user voices into PRD user stories with INVEST criteria.
- Builder / Forge: select highest-urgency demand and prototype.
- Rank: score demands by urgency × frequency × persona breadth.
- Field: design a study to validate or refute these synthetic hypotheses.

# Constraints
- Treat synthetic demands as hypotheses (`synthetic: true`), not validated user voice.
- Pair every output with the originating persona and demand ID for traceability.
- Surface contradictions across personas instead of smoothing them.
- If acceptance criteria are ambiguous, list clarifying questions before producing solutions.
```

Request Template (SKILL.md excerpt)

Speaker: [Persona name] ([Archetype]) Scene: [When, where, and what they were doing when this need arose]

User Voice (First Person)

[Request in the persona's own words — emotion, specificity, daily context]

Why This Is Needed

• [User-context reason 1]
• [User-context reason 2]

Acceptance Criteria (User Perspective)

• [Condition that makes the user feel "it works"]

Emotional Impact

• Current emotion: [Frustration / Resignation / Tolerance / Unaware]
• Post-fulfillment emotion: [Relief / Joy / Surprise / Obvious]
• User-felt urgency: [Daily pain / Weekly inconvenience / Occasional thought]

Confidence & Calibration

• synthetic: true
• calibration: [validated] / [supported] / [hypothesis] / [synthetic-only] — default [hypothesis] (plausible, no real data); [synthetic-only] if it may be an AI artifact; promote only with a cited real-data match per reference/calibration.md. Every request carries a tag — not just multi.
• Don't-build check: [Is this need already met elsewhere, better solved without a feature, or a YAGNI risk? The honest user voice sometimes says "don't build this."]