200 lines
9.4 KiB
Markdown
200 lines
9.4 KiB
Markdown
---
|
|
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]
|
|
|
|
|
|
|
|
[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.
|