ideate-month git:20260811.9bf17e7F

Immutable. This exact content never changes and is served at /api/v1/blob/03dd6b9fc42cf219.

---
name: ideate-month
description: "Plan next month's content calendar from a theme, raw signals, and last month's results — before any calendar exists. Triggers on \"/ideate-month\", \"/plan-month\", \"what should we post next month\", \"plan the calendar\", \"ideas for next month\", \"month theme\", \"content ideas for [brand]\", \"build a calendar from scratch\", or any time a brand needs a month planned and no client calendar has arrived. Outputs a calendar-data.json-compatible draft — series arcs, one-off posts, tiers, platforms — that feeds straight into /socialforge:parse-calendar and the production pipeline. Reads the brand profile for pillars and voice; mines pasted news/trends/notes into on-pillar angles; compounds whatever performed last month instead of starting from zero."
argument-hint: "[--brand <name>] [--month <YYYY-MM>] [--theme <text>] [--signals <pasted material>]"
effort: high
user-invocable: true
---

# /socialforge:ideate-month — the month before the calendar exists

SocialForge's pipeline starts at `parse-calendar` — someone hands it a calendar.
This skill is for when nobody has: the client asks "what should this month be
about?", and that question is the actual work they are paying for.

The output is a **draft calendar in the exact shape `parse-calendar` ingests**,
so an approved plan flows into production with zero re-typing.

## Inputs — use whichever exist, say which were missing

1. **The brand profile** (required) — pillars, voice, platforms, compliance
   rules from `brand-config.json`. No profile → stop and run
   `/socialforge:brand-setup` first. Ideating without pillars produces generic
   content for nobody.
2. **A theme or business context** (optional) — a launch, a season, a campaign
   the client named.
3. **Raw signals** (optional) — pasted news, industry threads, competitor
   moves, sales-call notes, community questions. Mine them; never use them as
   filler. Every signal either maps to a pillar and a concrete angle, or it is
   dropped and listed as dropped, with the reason.
4. **Last month's results** (optional) — the review gallery, status tracker, or
   anything the client reports as having worked. A win is validated audience
   demand: plan its compounding follow-ups rather than starting from zero.

## Process

1. Read the brand profile. List pillars, platforms, posting cadence.
2. If last month's performance is available: identify the 1–3 clear wins and
   design **follow-ups that compound them** — the deeper dive, the objection it
   raised, the adjacent question it opened. Not a repost of the same idea.
3. Mine any signals into angles, each tagged with its pillar. Drop what does
   not map — and say so.
4. Design 1–2 **series** — connected multi-part sequences with an arc (setup →
   develop → payoff), each part standing alone but rewarding the follower. A
   month of disconnected posts is a feed; a series builds a habit.
5. Fill the remaining cadence with one-off posts across pillars.
6. Assign every post a tier honestly: HERO (heavy production, big swing), HUB
   (core pillar content), HYGIENE (light, frequent presence).
7. Balance platforms per the brand's platform config — not everything
   everywhere.

## Output structure

```
# Month plan — {brand}, {YYYY-MM}

## The month's spine
[2-3 sentences: the theme, the wins being compounded, what the month should
have achieved by its last post]

## Series ({n})
### Series A: [name] — [pillar]
Arc: [what part 1 sets up, how it develops, where it pays off]
Parts: [P03, P07, P11] — see calendar below

## What last month validated (if performance was provided)
- [win] → [the compounding follow-up now on the calendar, with post id]

## Signals used / dropped (if signals were provided)
- USED: [signal] → [P05: the angle]
- DROPPED: [signal] — [why it does not serve this brand's pillars]

## Draft calendar (calendar-data.json compatible)
​```json
{
  "month": "YYYY-MM",
  "brand": "{brand}",
  "status": "DRAFT — needs client approval",
  "posts": [
    {
      "post_id": "P01",
      "date": "YYYY-MM-DD",
      "platform": "linkedin",
      "content_type": "carousel",
      "tier": "HUB",
      "topic": "[specific enough that a stranger could brief a designer from it]",
      "pillar": "[brand pillar]",
      "series": "[series name or null]",
      "rationale": "[one line: why this post, why this day]"
    }
  ]
}
​```

## What I did not have
[Which optional inputs were missing and what they would have improved]
```

## Critical rules

- **Every post traces to a pillar, a win, or a signal.** A post that traces to
  none of them is filler; cut it and say the cadence target was not met rather
  than padding.
- **Topics must be briefable.** "5 mistakes agencies make with reporting
  (carousel, one mistake per slide)" is a topic. "Engagement post" is not.
- **At least one series per month.** Disconnected posts build reach at best; a
  series builds return visits.
- **Wins get follow-ups, not reposts.** The follow-up answers what the win
  opened, from the validated angle — never the same post again slightly
  reworded.
- **Tier honestly.** A month of all-HERO is a burnout plan; all-HYGIENE is
  invisible. Typical shape: 1–2 HERO, 40–50% HUB, the rest HYGIENE.
- **The draft is a draft.** Output carries `status: DRAFT` and this skill never
  writes calendar-data.json to the workspace itself — the client approves, then
  `/socialforge:parse-calendar` ingests it as the approved source of truth.
- **State what was missing.** A plan built without performance data or signals
  is a weaker plan; the client should know that, not discover it.

## Pairs with

- `/socialforge:parse-calendar` — ingests the approved draft verbatim
- `/socialforge:reactive-post` — mid-month trend response; this skill plans, that one reacts
- `/socialforge:price-check` — quote the month's video load before the client approves it