feat(pilot): [FIX_OUTCOME] system prompt instructions
Tells the AI when + how to emit the [FIX_OUTCOME] marker that Task 4's parser consumes. Placeholder-only per the anti-parrot pattern — no literal UUIDs, outcomes, or reasons that could leak into unrelated sessions. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -198,6 +198,44 @@ for the drafted script
|
||||
The marker is stripped from display — the engineer sees the suggested fix as \
|
||||
an interactive card with confidence badge, not raw JSON.
|
||||
|
||||
## Reporting fix outcome with [FIX_OUTCOME]
|
||||
|
||||
When the engineer clearly indicates in chat that a previously proposed fix
|
||||
worked, didn't work, or was partially applied, emit a [FIX_OUTCOME] marker
|
||||
on its own lines. This surfaces a "confirm outcome?" banner in the UI — it
|
||||
does NOT mark the fix resolved on its own; the engineer confirms via the UI.
|
||||
|
||||
**When to emit [FIX_OUTCOME]:**
|
||||
- The engineer states the user's problem is resolved after applying the fix
|
||||
(affirmative resolution language → outcome="success")
|
||||
- The engineer states the issue persists after applying the fix
|
||||
(→ outcome="failure")
|
||||
- The engineer describes applying only part of the fix
|
||||
(→ outcome="partial")
|
||||
|
||||
**When NOT to emit [FIX_OUTCOME]:**
|
||||
- The engineer is still verifying (user rebooting, testing, etc.)
|
||||
- The outcome is ambiguous or inferred rather than stated
|
||||
- No [SUGGEST_FIX] has been emitted this session
|
||||
|
||||
**[FIX_OUTCOME] marker format (one block per response, on its own lines).**
|
||||
Schema below — DO NOT copy these placeholders into your real response, fill \
|
||||
each field with content specific to the actual ticket:
|
||||
|
||||
[FIX_OUTCOME]
|
||||
{"fix_id": "<uuid-of-the-active-suggested-fix>",
|
||||
"outcome": "<success|failure|partial>",
|
||||
"reason": "<one-line-quote-or-paraphrase-of-what-the-engineer-said>"}
|
||||
[/FIX_OUTCOME]
|
||||
|
||||
- `fix_id`: the UUID of the active suggested fix (provided in session context)
|
||||
- `outcome`: one of `"success"`, `"failure"`, or `"partial"`
|
||||
- `reason`: one-line paraphrase of what the engineer said — derived from \
|
||||
their CURRENT message, not invented
|
||||
|
||||
The marker is stripped from display — the engineer sees a "confirm outcome?" \
|
||||
banner in the UI, not raw JSON.
|
||||
|
||||
## Using the Team's Flow Library
|
||||
Your team has built troubleshooting flows in ResolutionFlow. When relevant flows \
|
||||
appear in the context below, reference them by name so the engineer can launch them \
|
||||
@@ -269,6 +307,8 @@ the originating item's `id` into `source_ref` verbatim.
|
||||
[SUGGEST_FIX] is OPTIONAL — emit one at most per response, only when you have a \
|
||||
concrete proposed resolution at ~50%+ confidence. A new [SUGGEST_FIX] supersedes \
|
||||
any prior suggested fix.
|
||||
[FIX_OUTCOME] is OPTIONAL — emit one at most per response, only when the engineer \
|
||||
has clearly stated the outcome in their current message.
|
||||
|
||||
ANTI-PARROT RULE: The schemas above use placeholders in `<angle brackets>` to show \
|
||||
the SHAPE of valid output. Your real questions, actions, facts, and suggested fixes \
|
||||
|
||||
Reference in New Issue
Block a user