Nexlem Cookbook

Real-world recipes for common content-pipeline scenarios. Each recipe assumes you have completed the setup steps in docs/GETTING_STARTED.md (tarball installed, project initialized, /nexlem setup run in Claude Code).

All commands run inside Claude Code — the /nexlem skill commands delegate to Claude Code subagents for text generation. The nexlem-sdk binary commands can run in any terminal.

Recipe: Blog-Only Article Run

When to use: You need a fully polished blog article without social media assets — for a content audit, a republish of a revised piece, or when your social calendar is handled separately. Running blog-only saves time by skipping the social fan-out.

Prerequisites: Initialized project, at least one site configured.

Step 1: Start a blog-only campaign

/nexlem run "Your article topic" --site <slug> --type blog-only

The blog-only type runs stages 1–10: research → writer → fact-check → eeat → humanizer → seo → disclaimer → image-planner → quality-gate → atomizer.

Step 2: Monitor progress

/nexlem status

Step 3: Review the quality gate result

Check .nexlem/campaigns/<id>/steps/09-quality-gate.json for the verdict. A "REJECTED" result halts the pipeline. Review the improvements array in the output and either:

Adjust your site's config/sites/<slug>.jsonc gate thresholds (lower minimums), or
Re-run with a refined topic framing.

Step 4: Retrieve the output

/nexlem campaign show <campaign-id>

The finalized article is at .nexlem/campaigns/<id>/steps/06-seo.md (SEO-optimized body) and the image plan at 08-image-planner.json.

Expected outcome: A fact-checked, E-E-A-T-polished, SEO-optimized article with an image-production plan. No social assets. Pipeline completes in roughly the time required for 10 sequential agent invocations.

When to use: You have already published a blog article and want to regenerate fresh social assets from its atoms — for example, after updating the article's content or targeting a seasonal campaign.

Prerequisites: A completed full or blog-only campaign whose atomizer step succeeded.

Step 1: Confirm the campaign has atomizer output

/nexlem campaign show <campaign-id>

Look for step 10 (atomizer) with status: "done". The atoms file is at .nexlem/campaigns/<id>/steps/10-atomizer.json.

/nexlem run --from-campaign <campaign-id> --type social-only --site <slug>

This picks up the atomizer output from the existing campaign and fans out to carousel, caption, reel-script, and youtube-short in parallel.

/nexlem campaign show <campaign-id>

Look for steps 11–14. Outputs land at:

11-carousel.json — Instagram/LinkedIn carousel script
12-caption.json — post captions (multiple variants per platform)
13-reel-script.json — short-form video script
14-youtube-short.json — YouTube Shorts script

Expected outcome: Four fresh social-channel assets derived from the original article's atoms. Useful for repurposing archived content or A/B testing caption variants.

Recipe: Multi-Site Silo Campaign

When to use: You operate multiple sites from the same Nexlem project and want a pillar article plus supporting silo pages that interlink — a common strategy for topical authority building.

Prerequisites: Two or more sites configured (e.g. achecar and moto-blog). Sites added via /nexlem site add.

Step 1: Add a second site if needed

/nexlem site add --slug second-site --url https://second-site.com

Step 2: Create the pillar campaign

/nexlem campaign create \
  --site achecar \
  --topic "Complete guide to compact hatchbacks" \
  --keyword "compact hatchback guide" \
  --type full \
  --run

The --run flag creates and immediately starts the campaign.

Step 3: Create silo supporting articles

After the pillar completes, create the supporting articles that link to it:

/nexlem campaign create \
  --site achecar \
  --topic "Chevrolet Onix vs VW Polo comparison" \
  --keyword "onix vs polo" \
  --type full

/nexlem campaign create \
  --site achecar \
  --topic "How to choose the right compact hatchback for city driving" \
  --keyword "choose compact hatchback"

Step 4: Run the batch

/nexlem run --batch --site achecar

All queued campaigns for the site run sequentially (one at a time to avoid rate pressure on the Claude Code agent pool).

Step 5: Check inter-article link opportunities

The seo agent in each campaign includes internal-link suggestions in 06-seo-meta.json. Review the internal_links_suggested array — each entry has anchor_text, suggested_topic, and context — and manually wire the anchors before publishing.

Expected outcome: A pillar article plus two or more supporting silo pages, each with SEO meta and internal-link anchors. The batch flow queues all campaigns; you review outputs after they complete.

Recipe: Refreshing an Existing Article

When to use: You notice that a planned campaign topic overlaps with a previously published article. Rather than producing duplicate content, you refresh the existing article so it incorporates updated research and angles — producing a delta-focused revision instead of a full redraft.

Prerequisites: At least one completed previous campaign.

Step 1: Configure your cannibalization policy (one-time setup)

Nexlem supports a per-site cannibalization_policy setting in config/sites/<slug>.jsonc. This is set once during the wizard main-site section and can be changed by hand or via /nexlem reconfigure:

"warn" (default) — at publish time, emits a stderr warning when the article's target keyword is already owned by a different site; the publish still proceeds.
"block" — at publish time, aborts the publish (exit 2) when the target keyword is already owned by a different site, unless --force-publish is passed. A campaign with an overlapping topic still runs its full pipeline regardless of this setting — the guard is publish-time only, not pre-run.

To change the policy after initialization:

# Edit config/sites/<slug>.jsonc and set:
# "cannibalization_policy": "block"

Or re-run the wizard for the main-site section:

/nexlem reconfigure

Step 2: Assess topic overlap yourself

There is no runtime JSON flag for cannibalization — the cannibalization_policy is a configuration-level guard, not a per-step output key. Use your knowledge of the content already published and the existing campaign list:

/nexlem campaign list --site achecar --status completed

If a prior campaign covers the same topic angle, proceed to Step 3.

Step 3: Run a targeted refresh

Delete any queued duplicate campaign for the overlapping topic, then run a refresh using the prior campaign as source context:

/nexlem campaign delete <duplicate-campaign-id>
/nexlem run "Compact hatchbacks for families" \
  --site achecar \
  --type refresh \
  --from-campaign <existing-campaign-id>

The topic is a positional argument to /nexlem run; the --topic flag is accepted only by /nexlem campaign create.

The --type refresh + --from-campaign combination tells the pipeline to use the prior campaign as inherited source context, producing a delta-focused refresh. Note that the refresh type excludes the image-planner agent from the pipeline, so no image plan is produced for the refreshed article.

Step 4: Publish the refreshed content

A refresh campaign runs a trimmed blog pipeline that ends at quality-gate (research → writer → fact-check → eeat → humanizer → seo → disclaimer → quality-gate). It excludes both the image-planner and the atomizer agents, so a refresh produces no 10-atomizer.json and therefore no atoms.

Because a refresh emits no atoms, its output cannot feed a social-only run (which consumes atomizer output). To produce updated social assets for the refreshed topic, run a separate full or blog-only campaign on that topic — those types run the atomizer and the resulting atoms can then feed a social-only run.

Expected outcome: A delta-focused refresh of the existing article that avoids duplicate content. The cannibalization_policy config setting is a publish-time, cross-site guard: "warn" emits a stderr warning at publish time when the target keyword is owned by a different site; "block" aborts the publish with exit 2 (unless --force-publish is passed). Campaigns with overlapping topics always run their full pipeline — the policy only takes effect when publishing.

Edit this page on GitHub