Improve common third-party enrichment quality
Give the company-profile agent (Agent A) the read-only browser toolset and build it per-run, so it can read footer, imprint, about, and legal pages and follow a product domain to the corporate one to resolve the legal name and headquarters address rather than failing cold. Make the website the hard precondition: when Agent A cannot resolve a canonical website, skip the compliance-docs agent and logo step instead of running them blind, which previously produced inconsistent cross-domain document URLs. Fall back to the catalog display name for the legal name when nothing better is found, recorded with a distinct provenance status so a later real find overwrites it. Rewrite both enrichment prompts in the project's role/task/instructions XML style, add a domain-consistency rule for document URLs and a tool-budget directive, and document the prompt style as a rule and guide. Fix the find_links_matching browser tool, which double-encoded its pattern and made JSON.parse fail on every keyword, starving any agent that used it until it hit the turn cap. Salvage output when an agent exhausts its turn budget while still exploring with a pending structured output by forcing one final synthesis turn instead of failing outright. Signed-off-by: Émile Ré <emile@probo.com>
This commit is contained in:
44
.cursor/rules/prompt-style.mdc
Normal file
44
.cursor/rules/prompt-style.mdc
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
description: Agent prompt template structure (role/task/instructions XML style)
|
||||
globs: "**/prompts/**/*.tmpl"
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# Agent prompt style
|
||||
|
||||
See full guide: `contrib/claude/prompt-style.md`
|
||||
|
||||
Agent prompt templates use an XML-tag structure with three top-level sections,
|
||||
in this order:
|
||||
|
||||
```
|
||||
<role>
|
||||
One short paragraph: who the agent is and its single objective.
|
||||
</role>
|
||||
|
||||
<task>
|
||||
What the agent is given and the fields it must return. Describe the structured
|
||||
output here as a bullet list (one bullet per field).
|
||||
</task>
|
||||
|
||||
<instructions>
|
||||
1. A numbered list of directives, most important first.
|
||||
2. ...
|
||||
</instructions>
|
||||
```
|
||||
|
||||
## Rules
|
||||
|
||||
- Always use the three sections `<role>`, `<task>`, `<instructions>` in that order.
|
||||
- `<instructions>` is an ordered (numbered) list; put the most decisive rule first.
|
||||
- Keep `<role>` to one short paragraph stating the objective.
|
||||
- Describe every output field in `<task>` as a bullet, mirroring the typed result struct.
|
||||
- Never hardcode enum values or source-of-truth lists; use a `{{.Placeholder}}`
|
||||
and substitute at runtime (see `template-files.mdc`).
|
||||
- No commentary outside the tags; the prompt body is the system instruction.
|
||||
|
||||
## Examples
|
||||
|
||||
- `pkg/thirdparty/prompts/disambiguation.txt.tmpl`
|
||||
- `pkg/cookiebanner/prompts/tracker_identification.txt.tmpl`
|
||||
- `pkg/thirdparty/prompts/common_third_party_company_profile.txt.tmpl`
|
||||
Reference in New Issue
Block a user