Z User
136379c666
- 18 agent specs across Software, Support, Marketing, Cross-cutting (orchestrator + 7 software + 5 support + 3 cross-cutting + leads-finder) - 8 reusable skills (handoff, pr-review, dokploy-deploy, campaign-structure, content-calendar, ticket-triage, license-lifecycle, invoice-draft) - 3 JSON schemas: handoff, deliverable, approval - Policies: autonomy levels, tool risk classification, compliance (DSGVO/GoBD/UWG) - routing.toml: model tiers T1/T2/T3 + provider config (PII gating) - Rust workspace (5 crates, all compile + 16 tests pass): - aos-mcp: tool registry + risk tagging - aos-policy: autonomy levels, budget enforcement, approval requests - aos-license: ed25519 license issue/verify (real crypto + CLI binary) - aos-ledger: integer-cents money math, gapless numbering, VAT, audit chain - aos-sync: frontmatter validator (18/18 specs pass), CLI binary - CLAUDE.md entry point with architecture overview + roadmap
91 lines
4.5 KiB
Markdown
91 lines
4.5 KiB
Markdown
---
|
||
name: campaign-structure
|
||
version: 1.0.0
|
||
applies_to: [ads-lead, search-ads-agent]
|
||
risk: low
|
||
---
|
||
|
||
# Campaign Structure Draft
|
||
|
||
## When to use
|
||
When a task is to draft a new paid-search campaign (Google Ads / equivalent)
|
||
from a brief and a budget. Drafting the structure here is low-risk because
|
||
nothing is created in the ad platform — activation is a separate, gated step.
|
||
|
||
## Steps
|
||
1. Read the brief and the confirmed budget (EUR, from AOS). If the brief
|
||
is missing target audience, geo, language, or goal (leads / sales /
|
||
traffic), return `blocked` with the open questions.
|
||
2. Confirm **Consent Mode v2** is configured for the client's site. If not
|
||
on record in AOS, flag as a blocking precondition for activation.
|
||
Drafting can continue.
|
||
3. Structure the campaign as a tree:
|
||
- **Campaign** (one per budget / goal / geo split), `budget_eur` matching
|
||
the brief, `bidding_strategy` (max conversions w/ target CPA, or manual
|
||
CPC for launch).
|
||
- **Ad groups** (one per keyword intent cluster, usually 3–7 per
|
||
campaign); one tight theme each.
|
||
- **Keywords** (exact, phrase, broad) — minimum 3 match types per ad
|
||
group where relevant. No SKAGs unless the brief calls for it.
|
||
- **Negatives** (brand competitors, jobs, free, info, …) — minimum 15
|
||
per campaign, drawn from the shared negative list.
|
||
- **Ad copy** (3 RSA headlines + 2 descriptions per ad group), DE / EN /
|
||
TR per client language. Claims must be substantiable (UWG §3).
|
||
4. Validate every claim against the brief + product facts. Any misleading
|
||
claim (UWG §5, §7) is flagged with a `risk` entry and rewritten before
|
||
the draft is finalized.
|
||
5. Compute the spend plan: budget split across campaigns, daily caps,
|
||
expected run duration. Never exceed the confirmed budget. If the brief
|
||
asks for spend beyond the cap, return `blocked` and request a
|
||
`budget_change` approval instead.
|
||
6. Write the structured campaign draft to AOS as an `AgentDeliverable`
|
||
(`output_format: draft`). Include the full tree as a structured `payload`
|
||
(campaign → ad groups → keywords → ads → negatives).
|
||
7. Do **not** call `ads:spend` or `ads:activate_campaign`. Those are
|
||
`risk: high` and always produce an `ApprovalRequest`.
|
||
8. When the human signals the draft is ready, emit an `ApprovalRequest`
|
||
(`schemas/approval.json`): `action: campaign_activation`, `risk: high`,
|
||
`rationale` (why go live now), `diff_summary` (campaign name, platform,
|
||
total budget, expected daily spend, target audience, geo, language),
|
||
`payload` (the structured campaign tree), `estimated_cost_eur` (the
|
||
confirmed budget).
|
||
9. Pause. Activation only happens after human approval via the policy crate.
|
||
|
||
## Inputs
|
||
- A brief in AOS (target audience, geo, language, goal, KPIs).
|
||
- A confirmed budget (EUR) on the client record.
|
||
- The client's brand guidelines + substantiation sheet for claims.
|
||
- The client's Consent Mode v2 status (on/off, recorded in AOS).
|
||
- The shared negative-keyword list.
|
||
|
||
## Outputs
|
||
An `AgentDeliverable` (`schemas/deliverable.json`) with:
|
||
- `status`: `done` (draft ready) | `needs_approval` (activation requested) |
|
||
`blocked` (brief incomplete or consent missing)
|
||
- `deliverables[]`: the structured campaign tree (`inline` JSON or
|
||
`aos_record` ref to the draft campaign record).
|
||
- `risks[]`: any borderline claims (UWG), audience assumptions, spend-vs-budget
|
||
headroom, consent-mode status.
|
||
- `cost`: tokens only (no platform spend until activation).
|
||
|
||
## Guard rails / compliance
|
||
- **UWG §3, §5, §7**: no misleading claims, no unverifiable superlatives,
|
||
no comparative claims without substantiation. The reviewer double-checks.
|
||
- **Consent Mode v2 must be configured before activation.** Drafting can
|
||
proceed; activation cannot.
|
||
- **Spend is always approval-gated.** No `ads:spend` or
|
||
`ads:activate_campaign` without an approved `ApprovalRequest` of action
|
||
`campaign_activation`.
|
||
- No retargeting without a documented consent basis.
|
||
- No auto-activation, no auto-budget-increase. Spend beyond the confirmed
|
||
budget is a separate `budget_change` approval.
|
||
- Language: DE / EN / TR per the client's `language.deliverables` setting;
|
||
ad copy is not translated by guesswork — missing languages block.
|
||
|
||
## References
|
||
- `schemas/approval.json` — `campaign_activation` action
|
||
- `schemas/deliverable.json` — `draft` output format
|
||
- `policies/compliance.md` — UWG, ad & cookie rules, Consent Mode v2
|
||
- `policies/autonomy.md` — spending always human-approved
|
||
- `policies/tool-risk.md` — `ads:spend` and `ads:activate_campaign`
|