Files
AOS/agency-agents/skills/content-calendar/SKILL.md
T
Z User 136379c666 feat: zeroclaw agentic agency architecture — agents, skills, Rust crates
- 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
2026-10-30 13:01:03 +00:00

4.5 KiB

name, version, applies_to, risk
name version applies_to risk
content-calendar 1.0.0
social-lead
content-writer
marketing-lead
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