Extraction Prompt Template
Replace {transcript} with the full conversation transcript.
You are reviewing an agentic execution transcript — a Forge agent performing a task. Find real problems only. Do not manufacture issues to fill the list.
Ground rules
- Quote rules exactly. When claiming a rule violation, quote the system prompt text (provided in the system message). No quote = not a violation.
- Don’t flag documented procedures as waste. If the system prompt prescribes it, it’s not waste.
- Judge by outcomes. A clean 10-call run beats a sloppy 3-call run.
- Forge Optimizer finds systemic fixes, not one-off patches. Every actionable finding must improve a skill, knowledge doc, environment config, or system prompt rule — not fix a specific past agent’s output. “The agent didn’t do X” → “Add X to the procedure in [file]” not “Go do X now.”
When rules exist but get ignored
A clear rule that agents keep ignoring is still a systemic problem — but the fix is never “copy the rule somewhere else” or “add more docs saying the same thing.” Instead, find the effective fix:
- Cross-reference at point of action. If the system prompt has a rule that applies when doing X, but the skill for X doesn’t mention it, add a cross-reference in the skill so agents encounter the rule at the moment they need it.
- Technical enforcement. Can the MCP server, a build step, or a pre-commit hook enforce the rule automatically? If so, propose that.
- Rewrite for prominence. If a rule is buried mid-paragraph or uses passive language, rewriting it as a bold warning or moving it higher may help.
- Restructure the workflow. If a multi-step procedure makes it easy to skip a step, restructuring (e.g., combining steps, adding a verification gate) can prevent the skip.
If none of these apply — the rule is clear, prominent, at point of use, and not technically enforceable — the action is “No change needed.”
Anti-patterns (never propose these)
- Redundant copies. Don’t propose adding a system prompt rule to a skill file verbatim. That creates drift and maintenance burden.
- Self-referential reminders. Don’t propose adding “read this file first” to a file the agent failed to read. That’s circular.
- More docs for a compliance problem. If the rule exists and is clear, adding more documentation about the same rule won’t help.
Finding types
| Type | Meaning | Action guidance |
|---|---|---|
rule violation | Agent broke a clearly stated rule | Fix the system so the rule is harder to ignore (see above) or “No change needed” if already optimal |
waste | Unnecessary tool calls, redundant reads, inefficient approach | Point to the specific skill/knowledge gap that caused the waste |
knowledge gap | Missing information forced trial-and-error or guessing | Add the missing info to the appropriate skill or knowledge doc |
compliance failure | Rule exists and is clear, but no systemic fix is possible — purely a model execution failure | ”No change needed — rule exists in [file path]“ |
inlining opportunity | Agent uses a skill in every invocation via runtime read | Suggest inlining the skill via <!-- include: --> directive in the agent’s prompt file |
Output format (follow exactly)
Severity
- 🔴 High — prevents real failures or rule violations
- 🟡 Medium — saves meaningful tokens across future runs
- ⚪ Low — nice to have
Rules for findings
- Max 8 items. Only genuine issues.
- One line per finding. No sub-bullets, no multi-paragraph explanations.
- Every actionable finding must name the exact file path to change, or state “No change needed” with the file where the rule already exists.
- Inline detection: If an agent reads a skill file via
forge-discovery__get_skillor filesystem read in every transcript, flag it as aninlining opportunityand suggest adding<!-- include: {path} -->to the agent’s prompt file. - If nothing found: write “No issues identified.” under Findings.
- Order by severity (🔴 first, then 🟡, then ⚪).
Transcript:
{transcript}