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: content-calendar
|
|
version: 1.0.0
|
|
applies_to: [social-lead, content-writer, marketing-lead]
|
|
risk: low
|
|
---
|
|
|
|
# Content Calendar Draft
|
|
|
|
## When to use
|
|
When a task is to plan a batch of social posts across platforms over a date
|
|
range. This skill produces a scheduled-but-unpublished calendar; publishing
|
|
is a separate, approval-gated step.
|
|
|
|
## Steps
|
|
1. Read the client's brand guidelines from AOS: voice, tone, forbidden
|
|
topics, color palette, hashtag list, mention policy.
|
|
2. Read the platform style rules per target platform (Instagram, LinkedIn,
|
|
Facebook, TikTok, X): max length, media requirements, hashtag limits,
|
|
link policy.
|
|
3. Read the client's `language.deliverables` setting (typically DE / EN /
|
|
TR, possibly all three). One post per language per slot — never
|
|
machine-translate; missing-language slots are blocked, not auto-filled.
|
|
4. Read the brief: campaign goal, period, post count N, content pillars,
|
|
asset references, key dates (product launches, holidays, events).
|
|
5. Plan N posts distributed across platforms and dates with explicit
|
|
publish times in the client's timezone. Use a balanced pillar mix
|
|
(educational / promotional / engagement) per the brief.
|
|
6. For each post, draft: `platform`, `slot` (ISO-8601 datetime in client
|
|
TZ), `copy` (in the slot's language, within platform limits),
|
|
`media_ref` (asset in AOS or TBD — no stock photos without license
|
|
clearance recorded), `hashtags[]` (from the client's list; no off-list
|
|
hashtags without a noted reason), `mentions[]` (each requires a
|
|
recorded relationship or consent; otherwise block), `link` (UTM-tagged
|
|
per the client's convention), `pillar` (content pillar label),
|
|
`compliance_notes` (claims needing substantiation, audience assumptions).
|
|
7. Validate every claim against the brief and the client's product facts.
|
|
Any misleading claim (UWG §5, §7) is flagged and rewritten before the
|
|
draft is finalized.
|
|
8. Validate **no PII** in any post copy. Names, emails, phone numbers,
|
|
customer photos, screenshots of DMs — all require recorded consent per
|
|
data subject (DSGVO Art. 6/7). No consent → no PII, no exceptions.
|
|
9. Write the calendar to AOS as an `AgentDeliverable` (`output_format:
|
|
draft`). The full calendar is a structured `payload`; each post is a
|
|
draft `aos_record` linked to the client.
|
|
10. Schedule for human approval. Publishing is `publish_public` and always
|
|
produces an `ApprovalRequest` per post (or per batch if the policy crate
|
|
supports it). Do **not** call any platform publish tool — they are
|
|
`risk: high` and forbidden in this skill.
|
|
11. If the client's brand guidelines are missing or out of date, return
|
|
`blocked` — do not improvise voice.
|
|
|
|
## Inputs
|
|
- A brief in AOS (goal, period, post count, pillars, key dates, assets).
|
|
- The client's brand guidelines record.
|
|
- The client's `language.deliverables` setting (DE / EN / TR).
|
|
- The client's UTM convention and hashtag list.
|
|
- Consent records for any person depicted or named.
|
|
|
|
## Outputs
|
|
An `AgentDeliverable` (`schemas/deliverable.json`) with:
|
|
- `status`: `done` (draft ready) | `needs_approval` (publish requested) |
|
|
`blocked` (missing brand guidelines / language / consent)
|
|
- `deliverables[]`: the calendar (`inline` JSON or `aos_record` ref to
|
|
the draft posts).
|
|
- `risks[]`: any borderline claims (UWG), any post using a TBD asset,
|
|
any post scheduled near a sensitive date, language coverage gaps.
|
|
- `cost`: tokens only (no platform spend until publish).
|
|
|
|
## Guard rails / compliance
|
|
- **No auto-publish.** Every post pauses at a `publish_public` approval
|
|
gate. The policy crate enforces it.
|
|
- **Language: DE / EN / TR per client setting.** Missing-language slots
|
|
are blocked, never auto-translated by guesswork.
|
|
- **DSGVO: no PII in posts without recorded consent.** Names, photos,
|
|
screenshots, DMs, identifiable locations — all require a consent basis
|
|
(Art. 6/7) tied to the data subject.
|
|
- **UWG §5, §7**: no misleading claims, no unverifiable superlatives,
|
|
no disguised advertising (kennzeichnungspflichtig) — paid partnerships
|
|
must be labeled.
|
|
- **Impressum / Datenschutz**: posts do not link to a page lacking either;
|
|
this is checked at publish time but flagged here if known.
|
|
- No retargeting pixels referenced in post copy without consent basis.
|
|
|
|
## References
|
|
- `schemas/approval.json` — `publish_public` action
|
|
- `schemas/deliverable.json` — `draft` output format
|
|
- `policies/compliance.md` — DSGVO, UWG, DDG/Impressum
|
|
- `policies/autonomy.md` — publishing always human-approved
|
|
- `policies/tool-risk.md` — platform publish tools are `risk: high`
|