59 lines
3.6 KiB
Markdown
59 lines
3.6 KiB
Markdown
# Delivery profile
|
|
|
|
Use this portable default when the user has not supplied an installation-level
|
|
delivery preference. A user-supplied directory and filename convention always wins.
|
|
|
|
```yaml
|
|
output_format: docx
|
|
output_directory: ./output
|
|
filename_pattern: "{analysis_date}-campaign-triage.docx"
|
|
chat_behavior: completion_and_file_link_only
|
|
```
|
|
|
|
Rules:
|
|
|
|
- `analysis_date` is the delivery/report date analyzed in the brief. Do not substitute
|
|
the file-generation date when they differ.
|
|
- Create the output directory when absent. Do not overwrite a same-named report until
|
|
the new DOCX has passed structural and visual verification; build in a temporary
|
|
path and replace only at final delivery.
|
|
- Preserve the four-section format from `output-standard.md` inside the document.
|
|
- Use a compact professional business-brief design with readable Chinese fonts,
|
|
deliberate table widths, repeated headers for multi-page tables, and explicit
|
|
maturity dates.
|
|
- Do not place a `核心判断` summary between the title/date block and section 1.
|
|
- Keep the visual treatment close to a restrained business brief. Do not use
|
|
full-width section bands, large color blocks, forced section page breaks, or repeated
|
|
callout boxes; these create excessive pagination when text wraps.
|
|
- Use at most three visible design colors across the document. Prefer one dark blue
|
|
for headings, one light blue-gray for table headers or thin rules, and neutral gray
|
|
for secondary text. Do not assign a separate color to every status or section.
|
|
- Separate hierarchy mainly through typography and spacing: numbered section heading,
|
|
smaller subsection heading, evidence table, and concise labeled interpretation or
|
|
action. A thin rule beneath a major heading is acceptable; shaded paragraphs are not
|
|
the default.
|
|
- Keep the action-oriented expression from the accepted direct version. Use short,
|
|
plain labeled lines such as `待排查`, `趋势`, `结论`, `预算影响`,
|
|
`继续观察`, `去重原则`, `预算情景`, `3 / 5 / 7天`, `筛选结果`, and `次优参考`
|
|
where applicable. Bold only the label; do not turn each line into a colored card.
|
|
- Do not include `Campaign层级`, a Campaign ranking table, or `层级判断`. The daily
|
|
brief is Ad-focused; parent names appear only when needed to identify an Ad.
|
|
- Do not carry a previously discussed named-Ad专项判断 into later daily briefs. Use
|
|
named-Ad drilldowns only for an explicit follow-up request; retain the structure as
|
|
a template, never the old entity name or historical values.
|
|
- Do not mechanically insert a separate `结论` paragraph before every table. Let the
|
|
table present comparable data, then place the nearest decision immediately beside
|
|
it. In the action section, let the action table lead and follow it with quantified
|
|
budget impact and observation instructions.
|
|
- Use prose for short conclusions and tables only for genuinely comparable evidence.
|
|
Keep tables able to flow naturally across pages with repeated headers; do not force
|
|
a new page merely to keep an entire table or section together.
|
|
- Render every generated DOCX to page images and inspect all pages when a compatible
|
|
renderer is available. If the renderer is unavailable, perform structural OOXML
|
|
checks and disclose that visual QA could not run.
|
|
- Do not paste the complete brief into chat after successful file delivery unless the
|
|
user explicitly asks for an inline copy.
|
|
- Never commit user reports, generated briefs, absolute home-directory paths, account
|
|
names, or installation-specific KPI into the reusable Skill. Store local overrides
|
|
outside the repository or in an ignored `delivery-profile.local.md` file.
|