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

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.

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

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)

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)

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:

# 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.