---
name: wiki-activity-review
user-invocable: true
description: Produce a digest-style summary of an author's recent contributions to the Adom wikis. Default window is week-to-date (most recent Monday through today). Checks both Wiki v1 (via `adom-wiki` CLI) and Wiki v2 (via REST API). Groups output by wiki, then by page, with publish/edit/asset/commit changelogs from the activity log. Trigger words — wiki activity review, wiki review, week review, weekly update, wiki digest, wiki weekly, what did I post, what did I publish, what did I ship, what did I do last week, weekly recap, weekly summary, my wiki activity, my wiki contributions, my commits, my changes, recap my week.
---

# wiki-activity-review

Produce a digest of an author's wiki contributions over a recent window. Default window is **week-to-date** — from the most recent Monday (00:00 local) through end of today, inclusive. Examples:

- run on **Sat** → window = Mon-Sat of the current week (6 days)
- run on **Wed** → window = Mon-Wed of the current week (3 days)
- run on **Mon** → window = just today (1 day; falls back to previous Mon-Sun if the user asked for a retrospective)

The caller can override with phrases like "last week" (preceding Mon-Sun), "last 2 weeks" (preceding 14 days), "since May 10" (anchored), or "this month" (from the 1st).

This skill covers **both wikis**. Skip neither — contributors typically have pages on both, and a digest that only covers one is incomplete.

| Wiki | URL | CLI | Auth |
|---|---|---|---|
| v1 | `https://wiki-ufypy5dpx93o.adom.cloud` | `adom-wiki` | resolved by the CLI; for raw HTTP use `$ADOM_WIKI_TOKEN` |
| v2 | `https://git-wiki-ktqxite5iglh.adom.cloud` | `adompkg` (or raw REST) | `adompkg login` once, or `$ADOM_WIKI_TOKEN` as a bearer for raw HTTP |

## Workflow

### Step 1 — Resolve identity

```bash
adom-wiki whoami | python3 -c "import sys,json; u=json.load(sys.stdin)['user']; print(u['display_name'], u['id'], u.get('email',''))"
```

That gives you the v1 `pub_author_id` / `pub_author_name` and the v2 `author_id` / `author_name` (same Carbon user id across both wikis). Match against author fields case-insensitively on display name AND exact match on id — author records sometimes carry only one or the other.

If `whoami` returns the shared `Developer` identity, fall back to `adom-cli carbon user get` to surface the caller's platform profile and warn that v1 attribution may be missing.

### Step 2 — Enumerate pages on Wiki v1

The CLI caps each `page list` call at 200 results. Pull each type separately and concatenate. Types: `skill, molecule, library, footprint, symbol, 3dcomp, app, datasheet, agent, scaffold`.

```bash
python3 - <<'PY'
import subprocess, json
types = ['skill','molecule','library','footprint','symbol','3dcomp','app','datasheet','agent','scaffold']
all_pages = []
for t in types:
    r = subprocess.run(['adom-wiki','page','list','--type',t,'--limit','500'],
                       capture_output=True, text=True)
    d = json.loads(r.stdout)
    all_pages.extend(d.get('pages', []))
    if d.get('total', 0) > len(d.get('pages', [])):
        print(f"WARN: {t} truncated ({len(d['pages'])} of {d['total']})", flush=True)
json.dump({'pages': all_pages}, open('/tmp/v1_pages.json','w'))
print(f"v1: {len(all_pages)} pages")
PY
```

If any type warns "truncated", paginate via raw HTTP: `GET https://wiki-ufypy5dpx93o.adom.cloud/api/v1/pages?type=<t>&limit=200&offset=200`.

### Step 3 — Enumerate pages on Wiki v2

```bash
curl -fsS "https://git-wiki-ktqxite5iglh.adom.cloud/api/v1/pages?limit=500" \
  -H "Authorization: Bearer $ADOM_WIKI_TOKEN" > /tmp/v2_pages.json
```

If `total > returned`, paginate with `&offset=500`.

### Step 4 — Narrow to candidate pages

A page is a **candidate** for the window if (a) the author matches AND (b) its `updated_at` (v1) or `last_commit_at`/`updated_at` (v2) falls inside the window.

**Critical gotcha** — `updated_at` is a poor proxy for "the user did something". A page may have its `updated_at` bumped by backend re-stamps with no logged activity. After narrowing by `updated_at`, **always confirm with the activity log** in step 5. Pages with no in-window log entries get demoted to a "Quiet touches" footnote in the output — don't drop them silently, the user may want to investigate.

### Step 5 — Pull the activity log for each candidate (Wiki v1)

```bash
adom-wiki page log <type>/<slug> --limit 100
```

Returns `{activity: [{created_at, kind, author_name, author_id, changelog, metadata, ...}]}`. `kind` is one of: `publish, edit, asset_upload, asset_delete, video_add, video_delete, skill_add, skill_remove`. Filter to entries where:
- `author_id` or `author_name` matches the resolved identity
- `created_at` is inside the window

Group consecutive entries by date for a cleaner digest.

### Step 6 — Pull the git log for each candidate (Wiki v2)

```bash
curl -fsS "https://git-wiki-ktqxite5iglh.adom.cloud/api/v1/pages/<slug>/log?limit=100" \
  -H "Authorization: Bearer $ADOM_WIKI_TOKEN"
```

Filter to commits by the user inside the window. Note v2 commits don't have `kind` — they're just git commits with messages. Surface the commit message as the changelog.

### Step 7 — Compose the digest

Output structure:

```markdown
# Weekly Wiki Digest — week of <YYYY-MM-DD>

## Wiki v1 — <N> active pages

### 1. [<title>](https://wiki-ufypy5dpx93o.adom.cloud/<type>s/<slug>) — `<type>` · v<version>
**<DayOfWeek MM/DD>** — <one-line summary of what changed>
- <changelog 1>
- <changelog 2>

(repeat per page, newest first)

## Wiki v2 — <N> active pages

### 1. [<title>](https://git-wiki-ktqxite5iglh.adom.cloud/<type>/<slug>) — `<type>` · v<version>
(same shape; commit messages instead of typed activities)

## Quiet touches (no logged content changes)
- [<title>](url) — `updated_at` advanced into the window but `page log` shows no activity from you. Backend touch.

---
**Theme of the week:** <1-2 sentences capturing the throughline you noticed across the week's work>
```

URL pluralization on Wiki v1 takes the type plural (`apps`, `skills`, `molecules`). Wiki v2 uses singular (`/app/...`, `/skill/...`). Get this right — broken links in a digest are the most common bug.

## Rules

1. **Always check both wikis.** If you only ran one, say so explicitly and rerun.
2. **Match the window to the user's ask.** Default is **week-to-date** (most recent Monday through today). "Last week" → preceding Mon-Sun; "last 2 weeks" → preceding 14 days; "this month" → from the 1st of the current month; "since Tuesday" → from that Tuesday. Convert relative phrases to absolute dates in the digest header.
3. **Cite changelogs verbatim** when they exist — they're the truest source of "what shipped". Don't paraphrase what the user wrote in the publish message.
4. **Never invent activity.** If `page log` returns 0 entries in the window, the page goes under "Quiet touches", not the main digest.
5. **End with a theme sentence**, not a bare list. The point of a digest is connective tissue, not a changelog dump. Read the week's pages and surface what they have in common (a focus area, a customer, an internal tool, a recurring fix).
6. **No emoji.** Plain markdown headings, tables, and links only.

## Output length

A typical week has 3-6 active pages. Aim for ~30-60 lines of markdown. If the window spans several weeks with 20+ pages, suggest the user narrow the window rather than producing a 300-line wall.