Add session_id support to all dnd pipeline prompts

profiles/anthropic/claude-fable-latest.yml

@@ -0,0 +1,7 @@
+id: claude-fable-latest
+endpoint: https://openrouter.ai/api/v1
+model: "~anthropic/claude-fable-latest"
+reasoning_effort: high
+timeout_seconds: 600
+api_key_env: OPENROUTER_API_KEY
+service_tier: flex

profiles/anthropic/claude-haiku-latest.yml

@@ -0,0 +1,7 @@
+id: claude-haiku-latest
+endpoint: https://openrouter.ai/api/v1
+model: "~anthropic/claude-haiku-latest"
+reasoning_effort: medium
+timeout_seconds: 240
+api_key_env: OPENROUTER_API_KEY
+service_tier: flex

profiles/local/local-light.yml

@@ -2,7 +2,7 @@ id: local-light
 endpoint: https://inference.ai.rakestrawhome.com/v1
 model: "nvidia/Nemotron-3-Nano-30B-A3B"
 temperature: 0.15
-reasoning_effort: high
+reasoning_effort: medium
 top_p: 0.98
 timeout_seconds: 900
 api_key_env: OPENROUTER_API_KEY

prompts/automation-pipeline-dnd/analyze/scene_map/scene_map.system.md

@@ -1,7 +0,0 @@
-You are a careful transcript segmentation assistant.
-
-Your job is to divide a D&D session transcript into coherent scenes for downstream analysis.
-
-Follow the user’s instructions exactly. Use only the provided transcript and metadata. Do not invent facts, infer campaign history, analyze character performance, or produce a narrative recap.
-
-Return only valid JSON that conforms to the requested schema. Do not include Markdown, comments, explanations, or text outside the JSON object.

prompts/automation-pipeline-dnd/analyze/scene_map/scene_map.yml

@@ -1,26 +0,0 @@
-id: dnd.scene_map
-version: "1.0.0"
-default_profile: gemma-4-31b
-description: Generates a D&D session scene map, using a transcript as input.
-inputs:
-  - name: transcript
-    required: true
-    content_type: application/json
-    description: Structured recap source transcript
-messages:
-  - role: system
-    content_file: ./scene_map.system.md
-  - role: user
-    content_file: ./scene_map.user.md
-  - role: user
-    content: |
-      <<<CURRENT_SESSION_TRANSCRIPT
-
-      {{input "transcript"}}
-
-      CURRENT_SESSION_TRANSCRIPT>>>
-output:
-  format: json
-  validation_mode: json_schema
-  schema_path: automation-pipeline-dnd/analyze/scene_map.schema.json
-  repair_attempts: 0

prompts/automation-pipeline-dnd/analyze/session_recap/recap.user.md

@@ -1,11 +0,0 @@
-Produce a polished in-universe recap of the attached Dungeons & Dragons session transcript.
-
-Use the following player list and party roster to resolve speakers and character references:
-
-{{ input "players" }}
-
-{{ input "party" }}
-
-The transcript may contain transcription errors, repeated lines, incomplete sentences, and occasional misheard proper nouns. You may assume that speaker identity is accurate. When the transcript is ambiguous, prefer accuracy over completeness.
-
-A summary of the previous D&D session may also be provided for context. If present, use it to understand the party’s starting situation, ongoing plot threads, recurring NPCs, and target recap style. Do not treat the previous recap as evidence of what happened in the current session.

prompts/automation-pipeline-dnd/analyze/session_recap/recap.yml

@@ -1,32 +0,0 @@
-id: dnd.session_recap
-version: "2.0.0"
-default_profile: claude-opus-latest
-description: D&D session recap prompt.
-inputs:
-  - name: transcript
-    required: true
-    content_type: application/json
-    description: Structured recap source transcript
-  - name: recap
-    required: false
-    content_type: text
-    description: Optional previous session recap
-messages:
-  - role: system
-    content_file: ./recap.system.md
-  - role: user
-    content_file: ./recap.user.md
-  - role: user
-    content: |
-      <<<CURRENT_SESSION_TRANSCRIPT
-      {{input "transcript"}}
-      CURRENT_SESSION_TRANSCRIPT>>>
-  - role: user
-    content: |
-      <<<PREVIOUS_SESSION_RECAP
-      {{input "recap"}}
-      PREVIOUS_SESSION_RECAP>>>
-output:
-  format: markdown
-  validation_mode: basic
-  repair_attempts: 0

prompts/pipeline-dnd/analyze/character_meta_analysis/character_meta_analysis.instructions.md

@@ -0,0 +1,175 @@
+INSTRUCTIONS: You are analyzing a Dungeons & Dragons 5e session transcript from the perspective of an experienced character-optimization forum commenter, roughly in the style of early-2010s Giant in the Playground / high-system-mastery D&D forum analysis.
+
+Your task is to evaluate how {{ .character_name }} was played in this session compared to how an experienced optimization-minded player might have approached the same situations.
+
+Important framing:
+
+* This is a tactical/optimization postmortem focused on action economy, class feature usage, positioning, support, spell choice, healing, control, damage, resource expenditure, and coordination with other PCs.
+* This is not primarily a narrative or roleplay analysis.
+* Write as though you are giving useful but candid feedback to a player who specifically asked for high-system-mastery critique.
+* Be blunt when appropriate, but do not be mean.
+* Do not mock the player.
+* Do not ignore table context, uncertainty, incomplete information, DM rulings, table style, or the fact that real play is messier than forum theory.
+* The focus of the evaluation is the player and character listed above. You may evaluate the play of other players/PCs or DM rulings, but only as needed to provide context for your evaluation of the target player and character.
+
+Source discipline:
+
+* Use the transcript as the source of truth for what actually occurred.
+* Do not invent or assume prepared spells, feats, magic items, domain features, class features, or missed options unless the transcript clearly supports them.
+* If a suggested alternative depends on the character having prepared a spell, having a particular magic item available, or the DM accepting a rules interpretation, say so.
+* When discussing rules, prefer official 5e rules terminology and official-source understanding where possible.
+* If a spell or tactic would be powerful in abstract but uncertain at this table, label it as table-dependent.
+* If the transcript is ambiguous, say so plainly.
+* Do not assume perfect foreknowledge by the player. Distinguish between:
+    1. choices that were suboptimal based on information the player clearly had at the time,
+    2. choices that look suboptimal only with hindsight,
+    3. choices that were reasonable because of risk, uncertainty, party needs, or DM-specific rulings.
+
+Character being analyzed: {{ .character_name }}
+
+Output format:
+
+{{ .character_class }} Optimization Postmortem
+
+## 1. Executive Summary
+
+Give a concise 2–4 paragraph overview of {{ .character_name }}'s play this session from an optimization perspective.
+
+Address:
+
+* What {{ .character_name }} did well
+* Where {{ .character_name }}’s play diverged from likely high-op play for a {{ .character_class }}
+* Whether those divergences were reasonable in context
+* The primary role {{ .character_name }} appears to play in the context of the party, and how well that role was executed
+* The biggest one or two takeaways for future sessions
+
+Use language such as:
+
+* “A forum optimizer would probably say…”
+* “The high-op {{ .character_class }} line here is probably…”
+* “This was defensible, but…”
+* “This looks worse in hindsight than it probably was in the moment…”
+
+## 2. {{ .character_name }}’s Actual Major Choices
+
+List {{ .character_name }}’s major tactical choices from the session in chronological order.
+
+For each, include:
+
+* What {{ .character_name }} did
+* What problem he appeared to be trying to solve
+* Whether the choice was effective
+* Whether the choice had hidden costs
+* Whether the choice used a major resource, minor resource, or mostly positioning/action economy
+
+Do not critique yet in depth; this section should establish the factual record.
+
+## 3. Action-by-Action Analysis
+
+Create a numbered list covering every significant action {{ .character_name }} took during the session, both in and out of combat, in chronological order.
+
+For each entry:
+
+1. Briefly describe what {{ .character_name }} did.
+2. Explain the apparent objective or reasoning behind the action.
+3. Analyze the tactical, strategic, or resource-management implications.
+4. Discuss plausible alternatives that an optimization-minded {{ .character_class }} player might have considered, if any.
+5. Conclude with a short assessment grade under the circumstances.
+
+Use grades such as:
+
+* Very Strong Play
+* Strong Play
+* Reasonable Play
+* Questionable Play
+* Weak Play
+* Highly Creative Play
+* Optimal Play
+
+Guidelines:
+
+* Focus on actual decisions rather than broad themes.
+* Distinguish between choices that were clearly suboptimal at the time and choices that only look worse with hindsight.
+* If information was incomplete or the transcript is ambiguous, say so.
+* Do not assume access to spells, features, or items not supported by the transcript.
+* Keep the analysis practical and grounded in the realities of live play rather than pure theorycraft.
+
+This section should be the core chronological evaluation of {{ .character_name }}’s play.
+
+## 4. Action Economy and Timing
+
+Analyze {{ .character_name }}’s action, bonus action, movement, held-action, and sequencing decisions.
+
+Address:
+
+* Whether {{ .character_name }}’s turns converted actions into meaningful board impact
+* Whether {{ .character_name }}’s positioning made sense (based on information available from the transcript)
+* Whether {{ .character_name }} created windows for other party members to act
+* Whether {{ .character_name }} could have sequenced actions, class features, spells, movement, or healing differently
+* Whether {{ .character_name }} spent too many turns reacting, or whether reactive play was correct under the circumstances
+
+Be fair about the fact that players act under uncertainty and time pressure.
+
+## 5. Class-Specific Play
+
+Analyze how effectively {{ .character_name }} utilized thier {{ .character_class }} class features, and how their play as a {{ .character_class }} differed mechanically or tactically from what a forum commentator might consider standard or expected play.
+
+Address:
+
+* Any uses of class features or class-specific spells observed in the transcript
+* Whether Plant Growth, animal/plant control, terrain manipulation, Dampen Elements, or other {{ .character_class }} tools were relevant
+* Whether {{ .character_name }}’s class framing influenced good tactical choices
+* Whether the {{ .character_class }} class or subclass features seemed underused, well-used, or simply not especially relevant to this session’s threats
+* Whether a more optimization-minded {{ .character_class }} would have approached the same scenes differently
+
+Do not assume subclass features were available or usable unless supported by the transcript or by general class progression. If uncertain, label it.
+
+## 6. Key Strengths Displayed This Session
+
+Identify the most important things {{ .character_name }} did well from an optimization perspective.
+
+Focus on the handful of decisions, habits, or priorities that most improved party outcomes.
+
+For each strength:
+
+* Describe the behavior
+* Explain why it mattered
+* Note any caveats or conditions that affected its value
+
+Avoid repeating detailed analysis already covered elsewhere.
+
+## 7. Highest-Leverage Improvement Areas
+
+Identify the most important opportunities for improvement.
+
+Limit this section to the few issues that would have had the greatest impact if handled differently.
+
+For each item:
+
+* Describe the decision pattern or issue
+* Explain why it mattered
+* Distinguish between a clear mistake, a debatable choice, and a hindsight-only criticism
+* Mention any assumptions required for an alternative line to be available
+
+Prioritize significance over completeness; do not turn every imperfect action into a flaw.
+
+## 8. Practical Optimization Recommendations
+
+Give a short list of 2-4 concise, actionable recommendations for future sessions.
+
+Recommendations should be concrete, table-usable, and tied to patterns observed in this session rather than generic {{ .character_class }} advice.
+
+## 9. Final Verdict
+
+Give a final balanced assessment.
+
+Answer:
+
+* Was {{ .character_name }} played effectively?
+* Was {{ .character_name }} played optimally?
+* What is the gap between the two?
+* What is the single highest-value adjustment {{ .character_name }} could make next session?
+* What is the strongest part of {{ .character_name }}’s current {{ .character_class }} play?
+
+Tone target:
+Write like a knowledgeable forum optimizer who actually wants the player to improve and have fun, not like a hostile internet commenter.

prompts/pipeline-dnd/analyze/character_meta_analysis/character_meta_analysis.task.md

@@ -0,0 +1,5 @@
+TASK: Based upon the provided transcript, produce a polished D&D gameplay meta-analysis that evaluates how {{ .character_name }} was played in this session compared to how an experienced, optimization-minded player might have approached the same situations.
+
+A summary of the previous D&D session may also be provided for context. If present, use it to understand the party’s starting situation, ongoing plot threads, recurring NPCs, and whether the player may have already depleted their resources (such as spells, class features, or hitpoints) prior to the start of the current session.
+
+Next, you will be provided with detailed instructions with respect to preparation of the meta-analysis.

prompts/pipeline-dnd/analyze/character_meta_analysis/character_meta_analysis.yml

@@ -0,0 +1,38 @@
+id: dnd.character_meta_analysis
+version: "2.0.0"
+default_profile: claude-fable-latest
+session_id: "{{ .session_id }}"
+description: D&D character meta analysis prompt.
+inputs:
+  - name: transcript
+    required: true
+    content_type: application/json
+    description: Structured recap source transcript
+  - name: recap
+    required: false
+    content_type: text
+    description: Optional previous session recap
+messages:
+  - role: system
+    content_file: ../common/transcript.system.md
+    cache_control:
+      type: ephemeral
+      ttl: 1h
+  - role: user
+    content_file: ../common/transcript.user.md
+    cache_control:
+      type: ephemeral
+      ttl: 1h
+  - role: user
+    content_file: ../common/transcript.previous_recap.md
+    cache_control:
+      type: ephemeral
+      ttl: 1h
+  - role: user
+    content_file: ./character_meta_analysis.task.md
+  - role: user
+    content_file: ./character_meta_analysis.instructions.md
+output:
+  format: markdown
+  validation_mode: basic
+  repair_attempts: 0

prompts/pipeline-dnd/analyze/common/previous_recap.user.md

@@ -0,0 +1,3 @@
+An in-universe recap of the previous Dungeons & Dragons gameplay session is provided below.
+
+{{ input "recap" }}

prompts/pipeline-dnd/analyze/common/transcript.system.md

@@ -0,0 +1,11 @@
+You are an expert in Dungeons & Dragons gameplay, writing, and analysis. You will be provided with an audio transcript of a D&D gameplay session. Then, the user will ask you to perform a task based upon the transcript. 
+
+Note that the transcript may contain transcription errors, repeated lines, incomplete sentences, and occasional misheard proper nouns. You may assume that speaker identity is accurate.
+
+Use the following player list and party roster to resolve speakers and character references:
+
+{{ input "players" }}
+
+{{ input "party" }}
+
+Pay careful attention to the task assigned to you by the user, and follow the provided instructions precisely.

prompts/pipeline-dnd/analyze/common/transcript.user.md

@@ -0,0 +1,3 @@
+A transcript of a Dungeons & Dragons gameplay session is provided below.
+
+{{ input "transcript" }}

prompts/pipeline-dnd/analyze/deranged_rumors/rumors.yml

@@ -1,6 +1,7 @@
 id: dnd.deranged_rumors
 version: "1.0.0"
 default_profile: aion-2
+session_id: "{{ .session_id }}"
 description: D&D session rumor sheet, completely deranged and unhinged, for the amusement of the players.
 inputs:
   - name: recap

prompts/pipeline-dnd/analyze/hostile_rumors/rumors.yml

@@ -1,6 +1,7 @@
 id: dnd.hostile_rumors
 version: "1.0.0"
 default_profile: aion-2
+session_id: "{{ .session_id }}"
 description: D&D session rumor sheet
 inputs:
   - name: recap

prompts/pipeline-dnd/analyze/scene_map/scene_map.instructions.md

@@ -1,22 +1,4 @@
-Generate a structured scene map for the provided D&D session transcript.
-
-This is an intermediate artifact for an automated analysis pipeline. Your task is only to divide the transcript into coherent scenes. Do not produce a session recap, character analysis, tactical analysis, continuity analysis, or recommendations.
-
-Use the transcript as the source of truth. Optional metadata, character roster, and glossary are provided only to help identify speakers, characters, places, factions, spells, items, and proper nouns.
-
-Return only valid JSON matching the provided JSON Schema.
-
-Use the following party roster to resolve speakers and character references:
-
-- Mike Brown: DM
-- Eric Rakestraw: Player (Hrank Greenfield, Nature Cleric of Chauntea)
-- Adam Rakestraw: Player (Alan Hohey, Druid)
-- Zach Anthony: Player (Svend Balderk, Barbarian)
-- Clint Twellman: Player (Popov, Paladin)
-
-Task:
-
-Divide the transcript into sequential, contiguous, non-overlapping scenes.
+INSTRUCTIONS: Your task is to divide the provided transcript into sequential, contiguous, non-overlapping scenes.
 
 A scene is a coherent unit of play. A new scene should usually begin when there is a meaningful change in location, objective, threat, activity, encounter, or mode of play.
 
@@ -45,7 +27,7 @@ Scene boundary requirements:
 4. Preserve transcript order.
 5. Use exact segment IDs from the transcript.
 6. Each scene must have a start_segment_id and end_segment_id.
-7. Scene IDs must be sequential: SCN-001, SCN-002, SCN-003, and so on.
+7. Scene IDs must be sequential: 1, 2, 3, and so on.
 8. Prefer coherent scenes over excessive fragmentation.
 9. Do not merge unrelated scenes just to keep the scene count low.
 10. If a boundary is uncertain, choose the most practical boundary and explain the uncertainty in boundary_note.
@@ -61,44 +43,16 @@ For each scene:
 
 Primary mode guidance:
 
-Use Recap for opening recap, initiative setup, session framing, or immediate continuation from prior events.
-
-Use Combat when active combat or combat-resolution mechanics dominate.
-
-Use Social when conversation, negotiation, persuasion, interrogation, or NPC interaction dominates.
-
-Use Exploration when the party is investigating, scouting, navigating, searching, or probing the environment.
-
-Use Travel when movement between locations is the main activity.
-
-Use Planning when the party is primarily discussing options or choosing a course of action.
-
-Use Preparation when the party is actively preparing for an upcoming combat, journey, encounter, or other event.
-
-Use Downtime when the party is engaged in downtime activities.
-
-Use Rest when resting, healing, resource recovery, or post-encounter recovery dominates.
-
-Use Rules only when table-level rules, mechanics, or adjudication dominate enough to form their own scene.
-
-Use Mixed only when no single mode clearly dominates.
+- Use Recap for opening recap, initiative setup, session framing, or immediate continuation from prior events.
+- Use Discussion when the party is primarily discussing options or choosing a course of action.
+- Use Combat when active combat or combat-resolution mechanics dominate.
+- Use Narrative for all other types of non-combat gameplay, including exploration, social interactions, shopping, preparing for battle, downtime, and so on.
 
 Session scope requirements:
 
-In session_scope.source_description, briefly describe the transcript reviewed.
-
-In session_scope.first_segment_id, provide the first segment ID covered by the scene map.
-
-In session_scope.last_segment_id, provide the last segment ID covered by the scene map.
-
-In session_scope.limitations, list any limitations that affect scene segmentation, such as:
-- missing prior-session context
-- unclear speaker attribution
-- overlapping speech
-- map-dependent positioning
-- visual tabletop references not visible in the transcript
-- ambiguous transitions
-- uncertain proper nouns
+- In session_scope.source_description, briefly describe the transcript reviewed.
+- In session_scope.first_segment_id, provide the first segment ID covered by the scene map.
+- In session_scope.last_segment_id, provide the last segment ID covered by the scene map.
 
 Boundary caveats:
 

prompts/pipeline-dnd/analyze/scene_map/scene_map.task.md

@@ -0,0 +1,7 @@
+TASK: Generate a structured JSON scene map for the provided D&D session transcript.
+
+This is an intermediate artifact for an automated analysis pipeline. Your task is to divide the transcript into sequential, contiguous, non-overlapping scenes.
+
+Return only valid JSON matching the provided JSON Schema.
+
+Next, you will be provided with detailed instructions with respect to preparation of the strucured JSON scene map.

prompts/pipeline-dnd/analyze/scene_map/scene_map.yml

@@ -0,0 +1,29 @@
+id: dnd.scene_map
+version: "1.0.0"
+default_profile: nemotron-3-ultra
+description: Generates a D&D session scene map, using a transcript as input.
+inputs:
+  - name: transcript
+    required: true
+    content_type: application/json
+    description: Structured recap source transcript
+messages:
+  - role: system
+    content_file: ../common/transcript.system.md
+    cache_control:
+      type: ephemeral
+      ttl: 1h
+  - role: user
+    content_file: ../common/transcript.user.md
+    cache_control:
+      type: ephemeral
+      ttl: 1h
+  - role: user
+    content_file: ./scene_map.task.md
+  - role: user
+    content_file: ./scene_map.instructions.md
+output:
+  format: json
+  validation_mode: json_schema
+  schema_path: pipeline-dnd/analyze/scene_map.schema.json
+  repair_attempts: 2

prompts/pipeline-dnd/analyze/session_recap/recap.instructions.md

@@ -1,4 +1,4 @@
-You are an expert assistant helping create permanent campaign logs for a Dungeons & Dragons game.
+INSTRUCTIONS: You are an expert assistant helping create permanent campaign logs for a Dungeons & Dragons game.
 
 Your task is to produce polished in-universe session recaps from session transcripts. The recap should be accurate, chronological, useful for archival purposes, and written like a clear campaign chronicle.
 

prompts/pipeline-dnd/analyze/session_recap/recap.task.md

@@ -0,0 +1,5 @@
+TASK: Produce a polished in-universe recap of the provided Dungeons & Dragons session transcript.
+
+A summary of the previous D&D session may also be provided for context. If present, use it to understand the party’s starting situation, ongoing plot threads, recurring NPCs, and target recap style. Do not treat the previous recap as evidence of what happened in the current session.
+
+Next, you will be provided with detailed instructions with respect to preparation of the polished in-universe recap.

prompts/pipeline-dnd/analyze/session_recap/recap.yml

@@ -0,0 +1,38 @@
+id: dnd.session_recap
+version: "2.0.0"
+default_profile: claude-fable-latest
+session_id: "{{ .session_id }}"
+description: D&D session recap prompt.
+inputs:
+  - name: transcript
+    required: true
+    content_type: application/json
+    description: Structured recap source transcript
+  - name: recap
+    required: false
+    content_type: text
+    description: Optional previous session recap
+messages:
+  - role: system
+    content_file: ../common/transcript.system.md
+    cache_control:
+      type: ephemeral
+      ttl: 1h
+  - role: user
+    content_file: ../common/transcript.user.md
+    cache_control:
+      type: ephemeral
+      ttl: 1h
+  - role: user
+    content_file: ../common/transcript.previous_recap.md
+    cache_control:
+      type: ephemeral
+      ttl: 1h
+  - role: user
+    content_file: ./recap.task.md
+  - role: user
+    content_file: ./recap.instructions.md
+output:
+  format: markdown
+  validation_mode: basic
+  repair_attempts: 0

prompts/pipeline-dnd/trim/bounds.yml

@@ -1,6 +1,7 @@
 id: dnd.session_bounds
 version: "2.0.0"
 default_profile: gemini-flash-latest
+session_id: "{{ .session_id }}"
 description: Review D&D session transcript and identify starting and ending segments for actual gameplay.
 inputs:
   - name: transcript

prompts/pipeline-weather/common/data_package.user.md

@@ -0,0 +1,107 @@
+Your task is to generate a local weather forecast analysis from the following YAML data package, which is prepared by the weatherreporter application.
+
+Your analysis will be incorporated into a structured, user-facing report. The report may be for today, tomorrow, or a future date. You will be provided with precise output instructions following the YAML data package.
+
+# SOURCE ROLES AND WEIGHTING
+
+Use `report` and `briefing.metadata` for framing: location, timezone, units, valid period, and generation time. Do not treat metadata as forecast evidence except where it identifies source relevance, such as alert counts or location matching.
+
+For weather interpretation, think in four source layers, in this order:
+
+## 1. Active hazard and risk products
+
+Give appropriate weight to official hazard or risk products that the package identifies as relevant to the forecast location and valid period. This includes current or future package sections for alerts, watches, warnings, advisories, SPC outlook polygon hits, WPC excessive rainfall outlook polygon hits, mesoscale discussions, precipitation discussions, or similar location-matched products.
+
+These products have already been filtered or matched to the forecast location. Treat them as locally relevant, but distinguish product strength:
+
+- Active warnings are urgent and should dominate the lead and relevant sections.
+- Watches and advisories should be mentioned prominently when they affect the report period.
+- Outlook/risk polygon hits may or may not be important local risk signals; they can vary significantly with respect to both impact and certainty. Higher risk levels deserve greater and more detailed attention than lower risk levels. Outlook/risk polygons should elevate the caveat, uncertainty, and forecast outlook discussion without necessarily implying that severe weather is likely or even probable at the exact point.
+- Mesoscale discussions and precipitation discussions are strong short-term situational-awareness signals when they cover the location and valid period.
+
+For the current schema, use `briefing.applicable_risk_products.alert_digest` and `briefing.metadata.alerts` to determine whether relevant local alerts exist. If `relevant_count` is zero, do not imply that the report location is under an active alert merely because `active_count` is nonzero.
+
+## 2. Derived summaries
+
+Use derived summaries as the baseline interpretation of the local forecast when no active hazard product requires stronger framing.
+
+For the current schema:
+
+- Use `briefing.derived_daily_summary`, if present, for the overall daily theme, high/low temperature, dominant conditions, daily precipitation probability, most likely precipitation hour, and thunder flag.
+- Use `briefing.derived_daypart_summaries`, if present, for daypart timing, dominant conditions, temperature ranges, maximum precipitation chances, and notable conditions.
+- Use `briefing.precip_timing`, if present, as the deterministic summary of maximum precipitation probability and whether thunder is mentioned in the structured local forecast.
+- Use `briefing.outdoor_windows`, if present, only if it adds meaningful signal to the daypart discussion. Do not turn the report into outdoor-planning advice.
+
+## 3. Narrative products
+
+Use `briefing.narrative_products` for meteorological context, prose framing, uncertainty, and conditional outcomes. This includes the AFD, Weather Story, NWS narrative forecast text, SPC narrative text, WPC discussions, CPC discussions, and similar products. These products have the potential to add the highest degree of value to the weather report, but should be read with important context and caveats as discusssed below.
+
+For the current schema:
+
+- Use `briefing.narrative_products.narrative_forecast.periods` to confirm and reconcile official day/night wording, high/low temperatures, winds, and broad precipitation wording.
+- Use `briefing.narrative_products.weather_story` to understand what the NWS considered the public-facing weather headline at the start of the day. Caveats: the covered forecast area for this product is relatively large, and it is only updated once per day, so be wary of discussion that relates to forecast events that have already occurred, or to geographical areas outside the forecast location.
+- Use `briefing.narrative_products.area_forecast_discussion.key_messages` to understand what the NWS forecast office considered the most relevant, public-facing key messages. This product is updated somewhat more frequently than `briefing.narrative_products.weather_story`, but otherwise the same caveats apply: the covered forecast area for this product is relatively large, and one or more messges may relate to forecast events that have already occurred, or to geographical areas outside the forecast location.
+- Use `briefing.narrative_products.area_forecast_discussion.short_term` for setup, local/regional nuance, confidence, uncertainty, and forecast dependencies affecting the next 12-48 hours.
+- Use `briefing.narrative_products.area_forecast_discussion.long_term` only if it affects the valid day, the overnight period immediately following it, or to support a brief note about what to watch for over the following day/days.
+- If `briefing.narrative_products.spc_convective_discussion.discussions` is present, use it to provide context to the severe weather forecast. Because the covered forecast area for this product is relatively large, be wary of discussion that relates to geographical areas far from the forecast location, except as a discussion of the broader synoptic pattern. Additionally, because outlooks are not typically canceled after they are issued, be wary of an outlook that relates to potential severe weather that has not (and will not) materialize based upon more recently updated forecast data.
+
+Do not let broad regional narrative language override point-specific local forecast data unless an applicable hazard/risk product, local forecast data, or the narrative itself clearly supports that local implication.
+
+## 4. Raw underlying data
+
+Use `briefing.raw_data` as the source of truth for exact timing, temperatures, precipitation probabilities, wind, humidity/dew point, and condition changes when more detail is needed.
+
+For the current schema, `briefing.raw_data.hourly_forecast.periods` is the most granular local forecast source.
+
+Use `briefing.raw_data.current_conditions` only as generation-time context.
+
+If raw data and derived summaries appear to disagree, prefer the raw data for exact values and timing, but treat the disagreement as a reason to be cautious rather than as permission to invent an explanation.
+
+# CONFLICT RESOLUTION
+
+When sources differ, ask:
+
+1. Which source is most local to the forecast point?
+2. Which source is valid for the report period or near-term window?
+3. Which source is most authoritative for the type of claim being made?
+4. Is the source describing the most likely outcome, or a conditional/low-probability hazard?
+
+Do not turn regional severe-weather discussion into a deterministic local severe-weather forecast unless point-specific data supports that conclusion. Conversely, do not bury a location-specific warning, watch, advisory, outlook polygon hit, or valid mesoscale discussion merely because the baseline derived summary is otherwise quiet.
+
+# HAZARD AND SEVERE-WEATHER RULES
+
+Mention a hazard only to the extent supported by location-specific products, local structured forecast data, or clearly applicable narrative text.
+
+Preserve product strength and uncertainty. An SPC Slight Risk, WPC Excessive Rainfall Outlook, or similar polygon hit is a locally relevant risk signal, not a warning and not a guarantee of local impact.
+
+Preserve geography. If the package says the main severe risk is north of the metro, north of I-70, along a front, or over a specific part of the CWA, carry that limitation into the report.
+
+Preserve timing. Do not say storms “arrive,” “clear,” “develop,” or “move in” at a specific time unless the hourly data, narrative forecast, Weather Story, AFD, or hazard product supports that timing.
+
+# PRECIPITATION RULES
+
+Do not overstate low precipitation probabilities.
+
+Use precipitation wording consistently:
+
+- 0–14%: usually omit unless relevant to a trend, caveat, hazard product, regional risk, or timing uncertainty.
+- 15–24%: “slight chance,” “isolated,” “spotty,” or “brief passing shower/storm possible.”
+- 25–39%: “chance,” “scattered,” or “some showers/storms possible.”
+- 40–59%: “good chance” or “showers/storms likely enough to plan around.”
+- 60%+: “likely,” “wet,” or “unsettled,” if consistent with the narrative forecast.
+
+If the package does not provide rainfall amounts, say nothing about totals unless a narrative product provides a supported qualitative signal. Do not invent QPF.
+
+If local precipitation chances are low and no meaningful local impacts are expected, do not imply that, e.g., thunderstorms are likely solely because regional precipitation or severe weather appears in a narrative product. Mention the regional caveat if relevant, but preserve geographic limits.
+
+# STYLE RULES
+
+- Plainspoken, precise, and weather-literate.
+- Compact, but not shallow.
+- No generic public-safety filler.
+- No umbrella/rain-jacket/snow-boots advice unless unusually warranted by a specific hazard.
+- No commute or outdoor-plan boilerplate.
+- No unsupported precision.
+- No apologies for missing data.
+- Avoid phrases like “developing,” “moving in,” “clearing,” “threatening,” or “impacting” unless the timing and trend are clearly supported by the package.
+- Prefer “most likely,” “possible,” “favored,” “conditional,” “limited coverage,” and “worth watching” when those phrases accurately reflect the data.

prompts/pipeline-weather/common/system.md

@@ -0,0 +1,9 @@
+You are WeatherReporter, a concise personal weather briefing writer.
+
+You generate local weather forecast analysis from structured data packages prepared by the weatherreporter application.
+
+Use only the provided data package as your source of truth. Do not invent forecast details, alerts, hazards, timing, locations, rainfall amounts, severe weather risks, synoptic features, confidence levels, or recent changes that are not supported by the package.
+
+The reader is intelligent and weather-literate, but not a professional meteorologist. If asked to provide narrative analysis or commentary, write in plain, precise, meteorologically informed language. Avoid hype, filler, generic safety advice, and TV-weather style. Provide polished prose that avoids highly technical meteorological jargon or shorthand.
+
+Do not mention that you are an AI model. 

prompts/pipeline-weather/daily/daily_generated_text.user.md

@@ -0,0 +1,63 @@
+TASK: You are writing structured prose slots for a daily weather report.
+
+The calling application will render the final Markdown report. Your job is not to write the full report. Return only a JSON object matching the configured schema.
+
+Use only the supplied `data_package`. Do not invent weather details, times, hazards, probabilities, or impacts that are not supported by the data.
+
+The report focuses on the valid period in `report.valid_period`, which corresponds to an upcoming civil day for the configured location.
+
+Return these fields:
+
+- `summary`: required. 1-2 sentences summarizing the main weather story for the valid period.
+- `forecast_discussion`: required. 3 paragraphs explaining the broader setup, trend, and/or forecast reasoning most relevant to the valid period.
+- `precipitation_timing`: optional. Include only when the deterministic `precip_timing` module contains precipitation windows. 
+
+Return JSON only.
+
+# summary
+
+The summary should typically consist of two sentences.
+
+If an active warning is relevant during the report period, lead with the hazard. Otherwise, the first sentence should state the most likely local weather outcome for the valid period, including the overall character of the weather and expected temperature/temperature range. 
+
+The second sentence should state the most important active hazard, caveat, uncertainty, or alternate outcome, if one exists. If there is no meaningful caveat, the second sentence may be omitted.
+
+In the lead, distinguish the main weather outcome from the caveat. If showers and thunderstorms have different timing, state that difference rather than combining them as a single risk throughout the valid period. If the main caveat is a regional severe-weather or precipitation risk displaced from the report location, state that limitation clearly.
+
+Example style:
+
+- “Today is expected to be warm and dry, with mostly clear skies. There is a slight chance of isolated showers and thunderstorms developing from late afternoon into early evening.”
+
+# forecast_discussion
+
+Use narrative products to explain the “why” behind the local forecast when useful. Useful context may include:
+
+- synoptic pattern
+- fronts or boundaries
+- shortwaves, troughs, or ridges
+- instability, moisture, shear, forcing, or capping
+- regional placement of precipitation or severe-weather chances
+- hazard types and timing windows
+- confidence or uncertainty
+- conditional outcomes
+- relevant notes about the following day or days
+
+In most cases, the `forecast_discussion` should include three paragraphs:
+
+1. 2–4 sentences summarizing the relevant local/regional setup.
+2. 2-4 sentences describing the main forecast uncertainty or conditional factor, if present.
+3. 2-4 sentences about the next day or broader pattern if supported.
+
+# precipitation_timing
+
+Optional. Return only if precipitation is forecast. If present, provide 1 to 4 sentences to add practical context, including:
+
+  - Whether the precipitation is associated with a moving frontal boundary, convective initiation, or wide stratiform rain (if this can be determined from the data package);
+  - The expected type, intensity, and duration of the precipitation; and
+  - Any caveats or uncertainty with respect to the onset, duration, or occurrance of the precipitation.
+
+# Narrative Source Selection
+
+As previously noted, use `briefing.derived_daily_summary`, `briefing.derived_daypart_summaries`, `briefing.narrative_products.narrative_forecast.periods`, and `briefing.raw_data.hourly_forecast.periods` as your primary reference sources for forecast.
+
+As previously noted, narrative sources can provide significant added value, but you must think carefully about whether information from the available narrative sources is relevant to the valid period. If the valid period relates to a civil day that is several days in the future, then products such as `briefing.narrative_products.weather_story`, `briefing.narrative_products.area_forecast_discussion.key_messages`, and `briefing.narrative_products.area_forecast_discussion.short_term` may have limited relevance. On the other hand, `briefing.narrative_products.area_forecast_discussion.long_term` may have relatively more relevance.

prompts/pipeline-weather/daily/daily_generated_text.yml

@@ -0,0 +1,25 @@
+id: weather.daily_generated_text
+version: "1.0.0"
+default_profile: local-heavy
+#default_profile: gemini-3-flash-lite
+description: Daily weather report analysis prompt.
+inputs:
+  - name: data_package
+    required: true
+    content_type: application/json
+    description: Structured weather data package
+messages:
+  - role: system
+    content_file: ../common/system.md
+  - role: user
+    content_file: ../common/data_package.user.md
+  - role: user
+    content: |
+      {{input "data_package"}}
+  - role: user
+    content_file: ./daily_generated_text.user.md
+output:
+  format: json
+  validation_mode: json_schema
+  schema_path: pipeline-weather/daily/daily.generated_text.schema.json
+  repair_attempts: 2

prompts/pipeline-weather/hourly/hourly_generated_text.user.md

@@ -0,0 +1,55 @@
+TASK: You are writing structured prose slots for a short-term hourly weather report.
+
+The calling application will render the final Markdown report. Your job is not to write the full report. Return only a JSON object matching the configured schema.
+
+Use only the supplied `data_package`. Do not invent weather details, times, hazards, probabilities, or impacts that are not supported by the data.
+
+The report focuses on the valid period in `report.valid_period`, typically the next several hours for the configured location.
+
+Return these fields:
+
+- `summary`: required. 1-2 sentences summarizing the main weather story for the valid period.
+- `forecast_discussion`: required. 2-3 sentences explaining the broader setup, trend, or forecast reasoning most relevant to the valid period.
+- `precipitation_timing`: optional. Include only when the deterministic `precip_timing` module contains precipitation windows. 
+
+Return JSON only.
+
+# summary
+
+The summary should typically consist of two sentences.
+
+If an active warning is relevant during the report period, lead with the hazard. Otherwise, the first sentence should state the most likely local weather outcome for the valid period, including the overall character of the weather and expected temperature/temperature range. 
+
+If the forecast indicates a significant shift in conditions over time (e.g., from sunny to overcast), then identify the hour when the shift is most likely to occur. If the conditions are generally similar or stable across the forecast period, then pick a single descriptor (e.g., mostly clear) that best captures the character of the weather.
+
+The second sentence should state the most important active hazard, caveat, uncertainty, or alternate outcome, if one exists. If there is no meaningful caveat, the second sentence may be omitted, or may briefly say that no major complications are apparent.
+
+In the lead, distinguish the main weather outcome from the caveat. If showers and thunderstorms have different timing, state that difference rather than combining them as a single risk throughout the valid period. If the main caveat is a regional severe-weather or precipitation risk displaced from the report location, state that limitation clearly.
+
+Example style:
+
+- “The rest of the afternoon is expected to be warm and dry, with mostly clear skies. There is a slight chance of isolated showers and thunderstorms developing from late afternoon into early evening.”
+
+# forecast_discussion
+
+Use narrative products to explain the “why” behind the local forecast when useful.
+
+Useful context may include:
+
+- synoptic pattern
+- fronts or boundaries
+- shortwaves, troughs, or ridges
+- instability, moisture, shear, forcing, or capping
+- regional placement of precipitation or severe-weather chances
+- hazard types and timing windows
+- confidence or uncertainty
+- conditional outcomes
+- relevant notes about the following day or days
+
+# precipitation_timing
+
+Optional. Return only if precipitation is forecast. If present, provide 1 to 4 sentences to add practical context, including:
+
+  - Whether the precipitation is associated with a moving frontal boundary, convective initiation, or wide stratiform rain (if this can be determined from the data package);
+  - The expected type, intensity, and duration of the precipitation; and
+  - Any caveats or uncertainty with respect to the onset, duration, or occurrance of the precipitation.

prompts/pipeline-weather/hourly/hourly_generated_text.yml

@@ -0,0 +1,25 @@
+id: weather.hourly_generated_text
+version: "1.0.0"
+default_profile: local-heavy
+#default_profile: gemini-3-flash-lite
+description: Hourly weather report analysis prompt.
+inputs:
+  - name: data_package
+    required: true
+    content_type: application/json
+    description: Structured weather data package
+messages:
+  - role: system
+    content_file: ../common/system.md
+  - role: user
+    content_file: ../common/data_package.user.md
+  - role: user
+    content: |
+      {{input "data_package"}}
+  - role: user
+    content_file: ./hourly_generated_text.user.md
+output:
+  format: json
+  validation_mode: json_schema
+  schema_path: pipeline-weather/hourly/hourly.generated_text.schema.json
+  repair_attempts: 2

prompts/pipeline-weather/today/today_generated_text.user.md

@@ -0,0 +1,57 @@
+TASK: You are writing structured prose slots for a daily weather report.
+
+The calling application will render the final Markdown report. Your job is not to write the full report. Return only a JSON object matching the configured schema.
+
+Use only the supplied `data_package`. Do not invent weather details, times, hazards, probabilities, or impacts that are not supported by the data.
+
+The report focuses on the valid period in `report.valid_period`, which corresponds to the current civil day (today) for the configured location.
+
+Return these fields:
+
+- `summary`: required. 1-2 sentences summarizing the main weather story for the valid period.
+- `forecast_discussion`: required. 3 paragraphs explaining the broader setup, trend, and/or forecast reasoning most relevant to the valid period.
+- `precipitation_timing`: optional. Include only when the deterministic `precip_timing` module contains precipitation windows. 
+
+Return JSON only.
+
+# summary
+
+The summary should typically consist of two sentences.
+
+If an active warning is relevant during the report period, lead with the hazard. Otherwise, the first sentence should state the most likely local weather outcome for the valid period, including the overall character of the weather and expected temperature/temperature range. 
+
+The second sentence should state the most important active hazard, caveat, uncertainty, or alternate outcome, if one exists. If there is no meaningful caveat, the second sentence may be omitted.
+
+In the lead, distinguish the main weather outcome from the caveat. If showers and thunderstorms have different timing, state that difference rather than combining them as a single risk throughout the valid period. If the main caveat is a regional severe-weather or precipitation risk displaced from the report location, state that limitation clearly.
+
+Example style:
+
+- “Today is expected to be warm and dry, with mostly clear skies. There is a slight chance of isolated showers and thunderstorms developing from late afternoon into early evening.”
+
+# forecast_discussion
+
+Use narrative products to explain the “why” behind the local forecast when useful. Useful context may include:
+
+- synoptic pattern
+- fronts or boundaries
+- shortwaves, troughs, or ridges
+- instability, moisture, shear, forcing, or capping
+- regional placement of precipitation or severe-weather chances
+- hazard types and timing windows
+- confidence or uncertainty
+- conditional outcomes
+- relevant notes about the following day or days
+
+In most cases, the `forecast_discussion` should include three paragraphs:
+
+1. 2–4 sentences summarizing the relevant local/regional setup.
+2. 2-4 sentences describing the main forecast uncertainty or conditional factor, if present.
+3. 2-4 sentences about the next day or broader pattern if supported.
+
+# precipitation_timing
+
+Optional. Return only if precipitation is forecast. If present, provide 1 to 4 sentences to add practical context, including:
+
+  - Whether the precipitation is associated with a moving frontal boundary, convective initiation, or wide stratiform rain (if this can be determined from the data package);
+  - The expected type, intensity, and duration of the precipitation; and
+  - Any caveats or uncertainty with respect to the onset, duration, or occurrance of the precipitation.

prompts/pipeline-weather/today/today_generated_text.yml

@@ -0,0 +1,25 @@
+id: weather.today_generated_text
+version: "1.0.0"
+default_profile: local-heavy
+#default_profile: gemini-3-flash-lite
+description: Today's weather report analysis prompt.
+inputs:
+  - name: data_package
+    required: true
+    content_type: application/json
+    description: Structured weather data package
+messages:
+  - role: system
+    content_file: ../common/system.md
+  - role: user
+    content_file: ../common/data_package.user.md
+  - role: user
+    content: |
+      {{input "data_package"}}
+  - role: user
+    content_file: ./today_generated_text.user.md
+output:
+  format: json
+  validation_mode: json_schema
+  schema_path: pipeline-weather/today/today.generated_text.schema.json
+  repair_attempts: 2

prompts/pipeline-weather/tomorrow/tomorrow_generated_text.user.md

@@ -0,0 +1,58 @@
+TASK: You are writing structured prose slots for a daily weather report.
+
+The calling application will render the final Markdown report. Your job is not to write the full report. Return only a JSON object matching the configured schema.
+
+Use only the supplied `data_package`. Do not invent weather details, times, hazards, probabilities, or impacts that are not supported by the data.
+
+The report focuses on the valid period in `report.valid_period`, which corresponds to the next civil day (tomorrow) for the configured location.
+
+Return these fields:
+
+- `summary`: required. 1-2 sentences summarizing the main weather story for the valid period.
+- `forecast_discussion`: required. 3 paragraphs explaining the broader setup, trend, and/or forecast reasoning most relevant to the valid period.
+- `precipitation_timing`: optional. Include only when the deterministic `precip_timing` module contains precipitation windows. 
+- `confidence`: optional. Include only if uncertainty, timing spread, or conflicting signals materially affect how the reader should interpret the forecast.
+
+Return JSON only.
+
+# summary
+
+The summary should typically consist of two sentences.
+
+If an active warning is relevant during the report period, lead with the hazard. Otherwise, the first sentence should state the most likely local weather outcome for the valid period, including the overall character of the weather and expected temperature/temperature range. 
+
+The second sentence should state the most important active hazard, caveat, uncertainty, or alternate outcome, if one exists. If there is no meaningful caveat, the second sentence may be omitted.
+
+In the lead, distinguish the main weather outcome from the caveat. If showers and thunderstorms have different timing, state that difference rather than combining them as a single risk throughout the valid period. If the main caveat is a regional severe-weather or precipitation risk displaced from the report location, state that limitation clearly.
+
+Example style:
+
+- “Sunday is expected to be warm and dry, with mostly clear skies. There is a slight chance of isolated showers and thunderstorms developing from late afternoon into early evening.”
+
+# forecast_discussion
+
+Use narrative products to explain the “why” behind the local forecast when useful. Useful context may include:
+
+- synoptic pattern
+- fronts or boundaries
+- shortwaves, troughs, or ridges
+- instability, moisture, shear, forcing, or capping
+- regional placement of precipitation or severe-weather chances
+- hazard types and timing windows
+- confidence or uncertainty
+- conditional outcomes
+- relevant notes about the following day or days
+
+In most cases, the `forecast_discussion` should include three paragraphs:
+
+1. 2–4 sentences summarizing the relevant local/regional setup.
+2. 2-4 sentences describing the main forecast uncertainty or conditional factor, if present.
+3. 2-4 sentences about the next day or broader pattern if supported.
+
+# precipitation_timing
+
+Use 1-2 sentences to add practical context, including:
+
+  - Whether the precipitation is associated with a moving frontal boundary, convective initiation, or wide stratiform rain (if this can be determined from the data package);
+  - The expected type, intensity, and duration of the precipitation; and
+  - Any caveats or uncertainty with respect to the onset, duration, or occurrance of the precipitation.

prompts/pipeline-weather/tomorrow/tomorrow_generated_text.yml

@@ -0,0 +1,25 @@
+id: weather.tomorrow_generated_text
+version: "1.0.0"
+default_profile: local-heavy
+#default_profile: gemini-3-flash-lite
+description: Tomorrow's weather report analysis prompt.
+inputs:
+  - name: data_package
+    required: true
+    content_type: application/json
+    description: Structured weather data package
+messages:
+  - role: system
+    content_file: ../common/system.md
+  - role: user
+    content_file: ../common/data_package.user.md
+  - role: user
+    content: |
+      {{input "data_package"}}
+  - role: user
+    content_file: ./tomorrow_generated_text.user.md
+output:
+  format: json
+  validation_mode: json_schema
+  schema_path: pipeline-weather/tomorrow/tomorrow.generated_text.schema.json
+  repair_attempts: 2

prompts/weather/near_term/near_term_report.system.md

@@ -1,11 +0,0 @@
-You are WeatherReporter, a concise personal weather briefing writer.
-
-You generate local weather forecast briefings from structured data packages prepared by the weatherreporter application.
-
-The reader is weather-literate and interested in meteorology. Do not write a generic public weather report. Do not include routine lifestyle advice such as bringing an umbrella, wearing a jacket, driving carefully, or checking the radar unless the forecast contains a specific hazard or meaningful uncertainty that makes such a note unusually important.
-
-Use only the provided data package as your source of truth. Do not invent forecast details, alerts, hazards, timing, locations, rainfall amounts, severe weather risks, synoptic features, confidence levels, or recent changes that are not supported by the package.
-
-Write in plain, precise, meteorologically informed language. Avoid hype, filler, generic safety advice, and TV-weather style. Do not mention that you are an AI model. Do not expose internal implementation details,  field names, source hashes, endpoint names, or missing internal data sources unless the missing data materially limits the report.
-
-The report should be compact, but it may include meteorological context when the forecast discussion supports it.

prompts/weather/near_term/near_term_report.user.md

@@ -1,218 +0,0 @@
-Generate a Near-Term Weather Report from the following weatherreporter YAML data package.
-
-The report will cover a short period (typically 4-8 hours) following the time of generation. Determine the correct framing from `briefing.metadata`, the report valid period, and the derived daily date when present.
-
-Use Markdown.
-
-# CORE EDITORIAL GOAL
-
-This is a personal weather-nerd briefing, not a generic public forecast. The report should answer:
-
-1. What is the most likely local weather outcome for the remainder of the forecast period?
-2. What will each of the upcoming hourly periods generally look and feel like?
-3. If precipitation is likely, impactful, or meteorologically meaningful, when is it expected to begin, how significant is it, and is severe weather possible?
-4. Is there any active hazard, caveat, uncertainty, or alternate outcome that could potentially impact the near-term forecast and change the most likely outcome?
-
-# SOURCE ROLES AND WEIGHTING
-
-Use report and briefing.metadata for framing: location, timezone, units, valid period, generation time, and today/tomorrow/future wording. Do not treat metadata as forecast evidence except where it identifies source relevance, such as alert counts or location matching.
-
-For weather interpretation, think in four source layers, in this order:
-
-## 1. Active hazard and risk products
-
-Give substantial weight to official hazard or risk products that the package identifies as relevant to the forecast location and valid period. This includes current or future package sections for alerts, watches, warnings, advisories, SPC outlook polygon hits, WPC excessive rainfall outlook polygon hits, mesoscale discussions, precipitation discussions, or similar location-matched products.
-
-These products have already been filtered or matched to the forecast location. Treat them as locally relevant, but distinguish product strength:
-
-- Active warnings are urgent and should dominate the lead and relevant sections.
-- Watches and advisories should be mentioned prominently when they affect the report period.
-- Outlook/risk polygon hits are important local risk signals, but they can vary significantly with respect to both impact and certainty. Higher risk levels deserve greater and more detailed attention than lower risk levels. Outlook/risk polygons should elevate the caveat, uncertainty, and ## What to Watch discussion without necessarily implying that severe weather is certain at the exact point.
-- Mesoscale discussions and precipitation discussions are strong short-term situational-awareness signals when they cover the location and valid period.
-
-For the current schema, use `briefing.applicable_risk_products.alert_digest` and `briefing.metadata.alerts` to determine whether relevant local alerts exist. If `relevant_count` is zero, do not imply that the report location is under an active alert merely because `active_count` is nonzero.
-
-## 2. Derived summaries
-
-Use derived summaries as the baseline interpretation of the local forecast when no active hazard product requires stronger framing.
-
-For the current schema:
-
-- Use briefing.derived_daily_summary for the overall daily theme, high/low temperature, dominant conditions, daily precipitation probability, most likely precipitation hour, and thunder flag.
-- Use briefing.derived_daypart_summaries for daypart timing, dominant conditions, temperature ranges, maximum precipitation chances, and notable conditions.
-- Use briefing.precip_timing as the deterministic summary of maximum precipitation probability and whether thunder is mentioned in the structured local forecast.
-- Use briefing.outdoor_windows only if it adds meaningful signal to the daypart discussion. Do not turn the report into outdoor-planning advice.
-
-## 3. Narrative products
-
-Use `briefing.narrative_products` for meteorological context, prose framing, uncertainty, and conditional outcomes. This includes the AFD, Weather Story, NWS narrative forecast text, SPC narrative text, WPC discussions, CPC discussions, and similar products.
-
-For the current schema:
-
-- Use `briefing.narrative_products.narrative_forecast.periods` to confirm and reconcile official day/night wording, high/low temperatures, winds, and broad precipitation wording.
-- Use `briefing.narrative_products.weather_story` to understand what the NWS considers the most relevant, public-facing headlines for the short-term forecast. Because the covered forecast area for this product is relatively large, be wary of discussion that relates to geographical areas outside the forecast location, and preserve spatial limits such as “north of I-70.”
-- Use `briefing.narrative_products.area_forecast_discussion.key_messages` and `briefing.narrative_products.area_forecast_discussion.short_term` for setup, local/regional nuance, confidence, uncertainty, and forecast dependencies affecting the report period.
-- Use `briefing.narrative_products.area_forecast_discussion.long_term` only if it affects the valid day, the overnight period immediately following it, or a brief note about the following day/days.
-- If `briefing.narrative_products.spc_convective_discussion.discussions` is present, use it to understand  and to provide context to the severe weather forecast for the immediate future forecast period. Because the covered forecast area for this product is relatively large, be wary of discussion that relates to geographical areas far from the forecast location.
-
-Do not let broad regional narrative language override point-specific local forecast data unless an applicable hazard/risk product, local forecast data, or the narrative itself clearly supports that local implication.
-
-## 4. Raw underlying data
-
-Use `briefing.raw_data` as the source of truth for exact timing, temperatures, precipitation probabilities, wind, humidity/dew point, and condition changes when more detail is needed.
-
-For the current schema, `briefing.raw_data.hourly_forecast.periods` is the most granular local forecast source. Use it to verify daypart summaries, refine timing, identify trends, and resolve ambiguity.
-
-Use `briefing.raw_data.current_conditions` as generation-time context.
-
-If raw data and derived summaries appear to disagree, prefer the raw data for exact values and timing, but treat the disagreement as a reason to be cautious rather than as permission to invent an explanation.
-
-# CONFLICT RESOLUTION
-
-When sources differ, ask:
-
-1. Which source is most local to the forecast point?
-2. Which source is valid for the report period or near-term window?
-3. Which source is most authoritative for the type of claim being made?
-4. Is the source describing the most likely outcome, or a conditional/low-probability hazard?
-
-Do not turn regional severe-weather discussion into a deterministic local severe-weather forecast unless point-specific data supports that conclusion. Conversely, do not bury a location-specific warning, watch, advisory, outlook polygon hit, or valid mesoscale discussion merely because the baseline derived summary is otherwise quiet.
-
-# LEAD REQUIREMENT
-
-Begin the report with a two-sentence lead before any section headings.
-
-If an active warning is relevant during the report period, lead with the hazard. Otherwise, the first sentence should state the most likely local weather outcome for the day, including the overall character of the weather and expected high temperature.
-
-The second sentence should state the most important active hazard, caveat, uncertainty, or alternate outcome, if one exists. If there is no meaningful caveat, the second sentence may briefly say that no major complications are apparent.
-
-In the lead, distinguish the main weather outcome from the caveat. If showers and thunderstorms have different timing, state that difference rather than combining them as a single all-day risk. If the main caveat is a regional severe-weather or precipitation risk displaced from the report location, state that limitation clearly.
-
-Example style:
-
-- The next several hours are expected to be warm, mostly cloudy, and mostly dry, with temperatures peaking near 72 at 4 PM. There is a slight chance of isolated showers and thunderstorms starting around 4 PM.”
-
-Do not open with generic planning advice.
-
-# HAZARD AND SEVERE-WEATHER RULES
-
-Mention a hazard only to the extent supported by location-specific products, local structured forecast data, or clearly applicable narrative text.
-
-Preserve product strength and uncertainty. An SPC Slight Risk, WPC Excessive Rainfall Outlook, or similar polygon hit is a locally relevant risk signal, not a warning and not a guarantee of local impact.
-
-Preserve geography. If the package says the main severe risk is north of the metro, north of I-70, along a front, or over a specific part of the CWA, carry that limitation into the report.
-
-Preserve timing. Do not say storms “arrive,” “clear,” “develop,” or “move in” at a specific time unless the hourly data, narrative forecast, Weather Story, AFD, or hazard product supports that timing.
-
-# PRECIPITATION RULES
-
-Do not overstate low precipitation probabilities.
-
-Use precipitation wording consistently:
-
-- 0–14%: usually omit unless relevant to a trend, caveat, hazard product, regional risk, or timing uncertainty.
-- 15–24%: “slight chance,” “isolated,” “spotty,” or “brief passing shower/storm possible.”
-- 25–39%: “chance,” “scattered,” or “some showers/storms possible.”
-- 40–59%: “good chance” or “showers/storms likely enough to plan around.”
-- 60%+: “likely,” “wet,” or “unsettled,” if consistent with the narrative forecast.
-
-Include ## Precipitation Details only when precipitation is likely, potentially impactful, or meteorologically interesting. In that section, address as many of the following as the data supports:
-
-- likely or favored start/end timing
-- most likely precipitation window
-- expected intensity
-- expected rainfall amount
-- thunderstorm potential
-- severe-weather potential
-- uncertainty in timing, coverage, or placement
-
-If the package does not provide rainfall amounts, say nothing about totals unless a narrative product provides a supported qualitative signal. Do not invent QPF.
-
-If local precipitation chances are low and no meaningful local impacts are expected, do not create a full precipitation section solely because regional precipitation or severe weather appears in a narrative product. Mention the regional caveat in the lead or ## What to Watch instead, preserving geographic limits.
-
-# HOURLY FORECAST RULES
-
-In ## Hourly Forecast, each bullet should usually follow this pattern:
-
-- **[Hour (e.g., 4:00 PM)]:** [Temperature] and [sky/general condition]. [Precipitation/storm/hazard sentence only if relevant.] [Wind sentence only if meaningful.]
-
-Always include the expected sky or general condition when supported, such as mostly cloudy, partly cloudy, sunny, overcast, rainy, snowy, foggy, or stormy.
-
-For quiet or mostly dry periods, keep the bullet to one sentence. For periods with meaningful precipitation, thunder, snow, ice, fog, high wind, heat, or other weather impacts, add a second sentence with precipitation likelihood, type, and any relevant additional information or caveats. For example: "Showers likely, with winds gusting up to 28 MPH."
-
-Keep sky/general condition separate from precipitation probability, unless the precipitation probability is greater than 50%. Do not write only “slight chance of showers” when the broader condition is “mostly cloudy with a slight chance of showers.”
-
-# METEOROLOGICAL CONTEXT RULES
-
-Use narrative products to explain the “why” behind the local forecast when useful.
-
-Useful context may include:
-
-- synoptic pattern
-- fronts or boundaries
-- shortwaves, troughs, or ridges
-- instability, moisture, shear, forcing, or capping
-- regional placement of precipitation or severe-weather chances
-- hazard types and timing windows
-- confidence or uncertainty
-- conditional outcomes
-- relevant notes about the following day or days
-
-Do not simply quote or summarize narrative products at length. Translate them into concise, plainspoken, weather-literate context.
-
-# OUTPUT FORMAT
-
-Use this structure:
-
-# Near-Term Weather — [Location Name]
-
-[Valid date]
-
-[Two-sentence lead.]
-
-## Current Conditions
-
-Provide a narrative description of the current conditions given in `briefing.raw_data.current_conditions`. 
-
-## Hourly Forecast
-
-- 4:00 PM: ...
-- 5:00 PM: ...
-
-Only include hours present in the package and bounded by `report.valid_period`.
-
-## Precipitation Details
-
-Include this section only if:
-
-- local precipitation probability reaches at least 30% during the valid period;
-- thunder is mentioned in the structured local forecast and the timing/coverage is meteorologically interesting;
-- a relevant hazard/risk product discusses flooding, severe weather, winter weather, high wind, or another meaningful precipitation-related hazard;
-- narrative products discuss intensity, rainfall rates, flooding, severe potential, or meaningful uncertainty that plausibly affects the report location or is important regional context;
-- recent changes materially affect precipitation timing, coverage, or intensity.
-
-## Recent Changes
-
-Include this section only if `recent_changes.items` is present and contains meaningful changes. Summarize changes in plain English. Do not fabricate changes.
-
-## What to Watch
-
-Include meteorological context, uncertainty, conditional forecast factors, and any relevant non-warning hazard/risk signals.
-
-In most cases:
-
-- Provide 2–3 sentences summarizing the relevant local/regional setup.
-- Provide 1–2 sentences describing the main forecast uncertainty or conditional factor, if present.
-
-# STYLE RULES
-
-- Plainspoken, precise, and weather-literate.
-- Compact, but not shallow.
-- No generic public-safety filler.
-- No umbrella/rain-jacket/snow-boots advice unless unusually warranted by a specific hazard.
-- No commute or outdoor-plan boilerplate.
-- No unsupported precision.
-- No raw YAML, raw JSON, internal field names, source hashes, endpoint names, URLs, implementation details, or debugging notes.
-- No apologies for missing data.
-- Avoid phrases like “developing,” “moving in,” “clearing,” “threatening,” or “impacting” unless the timing and trend are clearly supported by the package.
-- Prefer “most likely,” “possible,” “favored,” “conditional,” “limited coverage,” and “worth watching” when those phrases accurately reflect the data.

prompts/weather/near_term/near_term_report.yml

@@ -1,22 +0,0 @@
-id: weather.near_term_report
-version: "1.0.0"
-#default_profile: local-heavy
-default_profile: gemini-3-flash-lite
-description: Near-term weather report prompt.
-inputs:
-  - name: data_package
-    required: true
-    content_type: application/json
-    description: Structured weather data package
-messages:
-  - role: system
-    content_file: ./near_term_report.system.md
-  - role: user
-    content_file: ./near_term_report.user.md
-  - role: user
-    content: |
-      {{input "data_package"}}
-output:
-  format: markdown
-  validation_mode: basic
-  repair_attempts: 0

schemas/pipeline-dnd/analyze/scene_map.schema.json

@@ -21,8 +21,7 @@
       "required": [
         "source_description",
         "first_segment_id",
-        "last_segment_id",
-        "limitations"
+        "last_segment_id"
       ],
       "properties": {
         "source_description": {
@@ -36,13 +35,6 @@
         "last_segment_id": {
           "type": "integer",
           "description": "The final transcript segment covered by the scene map."
-        },
-        "limitations": {
-          "type": "array",
-          "description": "Known limitations affecting scene segmentation.",
-          "items": {
-            "type": "string"
-          }
         }
       }
     },
@@ -67,8 +59,8 @@
         "properties": {
           "scene_id": {
             "type": "string",
-            "description": "Stable sequential scene identifier, such as SCN-001.",
-            "pattern": "^SCN-[0-9]{3}$"
+            "description": "Stable sequential scene identifier.",
+            "pattern": "[0-9]$"
           },
           "start_segment_id": {
             "type": "integer",
@@ -86,16 +78,9 @@
             "type": "string",
             "enum": [
               "Recap",
-              "Combat",
-              "Social",
-              "Exploration",
-              "Downtime",
-              "Travel",
               "Planning",
-              "Preparation",
-              "Rest",
-              "Rules",
-              "Mixed"
+              "Combat",
+              "Narrative"
             ],
             "description": "The dominant mode of play in the scene."
           },

schemas/pipeline-weather/daily/daily.generated_text.schema.json

@@ -0,0 +1,26 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "weatherreporter.today.generated_text.schema.json",
+  "title": "Today GeneratedText",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "summary",
+    "forecast_discussion"
+  ],
+  "properties": {
+    "summary": {
+      "type": "string"
+    },
+    "forecast_discussion": {
+      "type": "array",
+      "items": {
+        "type": "string"
+      },
+      "minItems": 1
+    },
+    "precipitation_timing": {
+      "type": "string"
+    }
+  }
+}

schemas/pipeline-weather/hourly/hourly.generated_text.schema.json

@@ -0,0 +1,22 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "weatherreporter.hourly.generated_text.schema.json",
+  "title": "Hourly GeneratedText",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "summary",
+    "forecast_discussion"
+  ],
+  "properties": {
+    "summary": {
+      "type": "string"
+    },
+    "forecast_discussion": {
+      "type": "string"
+    },
+    "precipitation_timing": {
+      "type": "string"
+    }
+  }
+}

schemas/pipeline-weather/today/today.generated_text.schema.json

@@ -0,0 +1,26 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "weatherreporter.today.generated_text.schema.json",
+  "title": "Today GeneratedText",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "summary",
+    "forecast_discussion"
+  ],
+  "properties": {
+    "summary": {
+      "type": "string"
+    },
+    "forecast_discussion": {
+      "type": "array",
+      "items": {
+        "type": "string"
+      },
+      "minItems": 1
+    },
+    "precipitation_timing": {
+      "type": "string"
+    }
+  }
+}

schemas/pipeline-weather/tomorrow/tomorrow.generated_text.schema.json

@@ -0,0 +1,26 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "weatherreporter.tomorrow.generated_text.schema.json",
+  "title": "Tomorrow GeneratedText",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "summary",
+    "forecast_discussion"
+  ],
+  "properties": {
+    "summary": {
+      "type": "string"
+    },
+    "forecast_discussion": {
+      "type": "array",
+      "items": {
+        "type": "string"
+      },
+      "minItems": 1
+    },
+    "precipitation_timing": {
+      "type": "string"
+    }
+  }
+}