---
name: weekly-review
description: 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.
version: 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:

```markdown
# <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]
```

7. **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:

```bash
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.