article_feed/.claude/skills/weekly-review/SKILL.md
2026-04-24 02:02:16 -04:00

9.4 KiB

name description version
weekly-review Use this skill when the user asks to generate a "weekly review", create a "review article", run the "weekly review" process, or mentions generating content for AI, Intelligence Augmentation, Longevity, Resource Abundance, Energy, or Space subjects on their scheduled days. 1.3.1

Weekly Review Article Generator

Generate weekly review articles covering the best 10 items from the past week in each subject area.

Schedule

Day Subject Directory
Monday AI ai/
Tuesday Intelligence Augmentation intelligence-augmentation/
Wednesday Longevity longevity/
Thursday Resource Abundance resource-abundance/
Friday Energy energy/
Saturday Space space/
Sunday Robotics robotics/

Process

  1. Determine the subject

    • Use the current day of week to select from the schedule
    • If Sunday, ask the user which subject to generate
    • User may override by specifying a subject
  2. Read subject-specific guidance

    • Read <subject-directory>/SUBJECT.md for search terms, priority sources, and emphasis areas
  3. Research the past week (be efficient)

    • Run 3-4 WebSearches in parallel using search terms from SUBJECT.md
    • Cover the 7 days ending yesterday
    • WebSearch summaries contain substantial detail—use them directly
    • Do NOT run additional broad search rounds; 3-4 searches is sufficient
    • EXCEPTION: targeted source-upgrade searches in step 4 are allowed and expected
  4. Select the best 10 items

    Selection criteria:

    • Future and technology positive framing
    • College graduate sophistication (substantive, not dumbed down)
    • Lay interest appropriate (accessible to educated non-specialists)
    • Importance OR novelty to the field

    Source quality rubric — apply to each candidate before writing:

    Tier Examples Use?
    A Peer-reviewed journals, university press releases, government/IGO bodies, primary company announcements Use freely
    B Established trade press (Nature News, Reuters, IEEE Spectrum, Ars Technica, sector-specific tier-1) Use freely
    C Investment newsletters, aggregators, Wikipedia-style summaries, WordPress/Medium blogs, SEO content farms Upgrade or drop — never the sole source
    D Press-release reprint sites, unattributed "news" domains, content matching the pattern /blogs/<slug> Do not use

    For any candidate item whose best available source is Tier C or D:

    • Run ONE targeted search for a primary or trade-press version of the same story (e.g., the university's press office, the company's newsroom, the government portal, the journal's DOI page)
    • If a Tier A or B source is found, use it
    • If not, drop the item and select the next-best candidate from the search pool

    URL sanity check — reject any URL that is:

    • A journal or publisher homepage rather than a specific article — e.g. pubs.acs.org/journal/<slug> with no article ID
    • A tag, category, or archive page rather than the specific item
    • A domain that does not match the "Publication Name" in the citation
  5. Write from search summaries

    • Search result summaries contain enough detail for 3-5 paragraph synopses
    • Only use WebFetch for 2-3 items max where critical detail is missing
    • Skip any WebFetch that fails (403, paywall, etc.)—do not retry
    • Omit images rather than searching for them; include only if URL is in search results
    • Every specific statistic, dollar figure, or named claim must be traceable to the item's cited source — do not import figures from search snippets that aren't among the 10 selected items
  6. Write the article

    Subject display names — use these exact capitalizations in filenames, H1, and the published title:

    Directory Display Name
    ai/ AI
    intelligence-augmentation/ Intelligence Augmentation
    longevity/ Longevity
    resource-abundance/ Resource Abundance
    energy/ Energy
    space/ Space
    'robotics/' Robotics

    Filename: <subject-directory>/<Display Name> Weekly Review <End Date>.md

    • <End Date> is ISO format YYYY-MM-DD
    • Spaces in filenames are intentional — do not substitute hyphens or underscores
    • Example: ai/AI Weekly Review 2026-03-09.md
    • Example: resource-abundance/Resource Abundance Weekly Review 2026-04-23.md

    The H1 at the top of the article must match the filename (minus the .md extension). When publishing via the Ghost Admin API, pass this same string as the title field in the POST body — Ghost requires title explicitly and does not derive it from the filename or first H1, so keeping all three identical means one source of truth.

    Week In Review discipline: the synthesis paragraphs may ONLY reference the 10 selected items. If a theme needs an 11th example to hold together, reconsider item selection rather than citing an unselected source in the synthesis.

    Format:

# <Display Name> Weekly Review <End Date>

## Week In Review

[2-4 paragraphs synthesizing the week's themes and interconnections]

References to articles use format: [Article Title](url), linking ONLY to items in the "Items" section below.

Explain how the items relate to each other and their collective significance to the field.

## Items

### [Item Title]

![Description](image-url)

[3-5 paragraphs - accessible but substantive synopsis]

Source: [Publication Name](url)

---

[Repeat for all 10 items]
  1. Save the article
    • Write to the appropriate subject directory
    • Confirm completion with the filename

Writing Style

  • Substantive and informative
  • Accessible to educated generalists
  • No hype or clickbait framing
  • Optimistic but grounded tone
  • Connect items to broader trends and implications
  • When a claim depends on a specific number or date, attribute it to a source rather than presenting it as established fact

Future: Publishing via Ghost Admin API

This skill's scope ends at "file saved to disk." A separate publisher script handles the Ghost API integration. Documenting the contract here so the invariant doesn't drift.

The invariant

The filename-to-title chain established above extends naturally into publishing:

  • Filename stem (minus .md) → Ghost title field in the API body
  • First H1 of the markdown → same string, duplicated for local readability
  • Everything after the first H1 → Ghost post body (HTML-converted, first H1 stripped)

The Ghost newsletter slug is a separate piece of configuration — a single value identifying which newsletter in Ghost Admin the post should be emailed through. Pipeline-level config, not per-file. Each newsletter must be created once in Ghost Admin (Settings → Email newsletter → Newsletters) before the first automated publish; the API cannot create newsletters.

Two-step publish pattern

Ghost's Admin API requires a draft-then-publish flow to trigger newsletter email send. Single POST with status: published and a newsletter query parameter silently publishes without emailing. Confirmed pattern:

Step 1 — create draft:

POST /admin/posts/?source=html
Body: {
  "posts": [{
    "title": "<filename stem>",
    "html": "<body HTML, first H1 stripped>",
    "status": "draft",
    "newsletter": "<newsletter-slug>"
  }]
}

Response contains id and updated_at — capture both.

Step 2 — publish and send:

PUT /admin/posts/<id>/?newsletter=<newsletter-slug>&email_segment=all
Body: {
  "posts": [{
    "updated_at": "<from step 1 response>",
    "status": "published"
  }]
}

The newsletter query parameter must be on both requests. email_segment=all sends to all subscribers; status:free or status:-free target free-only or paid-only.

Do NOT set email_only: true — that suppresses the public blog post and sends email only. Weekly reviews should appear on both the blog and in email.

Body transformation

The markdown on disk starts with an H1 that duplicates the Ghost title. Strip it before converting to HTML and sending, otherwise Ghost renders the title twice:

title=$(basename "$file" .md)
body=$(tail -n +2 "$file" | sed '/./,$!d')   # drop first line, then leading blanks
html=$(echo "$body" | pandoc -f markdown -t html)

Validation

Before publishing, the publisher should verify that the first H1 of the file matches basename "$file" .md. This catches rename/edit drift — cases where the filename was changed but the H1 wasn't, or vice versa. If the check fails, refuse to publish and surface the mismatch.