skill
wiki-activity-review
UnreviewedDigest-style summary of an author's recent wiki contributions across Wiki v1 and Wiki v2 — handy for status updates, retros, and weekly all-engineers prep.
{
"schema_version": 1,
"type": "skill",
"slug": "wiki-activity-review",
"title": "wiki-activity-review",
"brief": "Digest-style summary of an author's recent wiki contributions across Wiki v1 and Wiki v2 — handy for status updates, retros, and weekly all-engineers prep.",
"version": "1.0.0",
"tags": [],
"license": "MIT",
"discovery_triggers": [
"wiki activity review",
"wiki review",
"weekly wiki digest",
"wiki digest",
"weekly update",
"weekly recap",
"weekly summary",
"what did I post on the wiki",
"what did I publish",
"what did I ship",
"what did I do last week",
"my wiki activity",
"my wiki contributions",
"recap my week",
"summarize my week",
"what shipped this week"
],
"discovery_pitch": "Wraps both Adom wikis to produce a digest-style summary of an author's recent publishes, edits, asset uploads, and commits — handy for status updates, retros, and weekly all-engineers prep.",
"sample_prompts": [
{
"label": "Recap",
"prompt": "what did I post on the wiki last week?"
},
{
"label": "Window",
"prompt": "give me a wiki activity review for the last 2 weeks"
},
{
"label": "Author",
"prompt": "what has Drew shipped on the wikis this month?"
}
],
"source_path": "SKILL.md",
"readme": "# wiki-activity-review\n\nProduce 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:\n\n- run on **Sat** → window = Mon-Sat of the current week (6 days)\n- run on **Wed** → window = Mon-Wed of the current week (3 days)\n- run on **Mon** → window = just today (1 day; falls back to previous Mon-Sun if the user asked for a retrospective)\n\nThe 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).\n\nThis skill covers **both wikis**. Skip neither — contributors typically have pages on both, and a digest that only covers one is incomplete.\n\n| Wiki | URL | CLI | Auth |\n|---|---|---|---|\n| v1 | `https://wiki-ufypy5dpx93o.adom.cloud` | `adom-wiki` | resolved by the CLI; for raw HTTP use `$ADOM_WIKI_TOKEN` |\n| v2 | `https://git-wiki-ktqxite5iglh.adom.cloud` | `adompkg` (or raw REST) | `adompkg login` once, or `$ADOM_WIKI_TOKEN` as a bearer for raw HTTP |\n\n## Workflow\n\n### Step 1 — Resolve identity\n\n```bash\nadom-wiki whoami | python3 -c \"import sys,json; u=json.load(sys.stdin)['user']; print(u['display_name'], u['id'], u.get('email',''))\"\n```\n\nThat 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.\n\nIf `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.\n\n### Step 2 — Enumerate pages on Wiki v1\n\nThe 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`.\n\n```bash\npython3 - <<'PY'\nimport subprocess, json\ntypes = ['skill','molecule','library','footprint','symbol','3dcomp','app','datasheet','agent','scaffold']\nall_pages = []\nfor t in types:\n r = subprocess.run(['adom-wiki','page','list','--type',t,'--limit','500'],\n capture_output=True, text=True)\n d = json.loads(r.stdout)\n all_pages.extend(d.get('pages', []))\n if d.get('total', 0) > len(d.get('pages', [])):\n print(f\"WARN: {t} truncated ({len(d['pages'])} of {d['total']})\", flush=True)\njson.dump({'pages': all_pages}, open('/tmp/v1_pages.json','w'))\nprint(f\"v1: {len(all_pages)} pages\")\nPY\n```\n\nIf any type warns \"truncated\", paginate via raw HTTP: `GET https://wiki-ufypy5dpx93o.adom.cloud/api/v1/pages?type=<t>&limit=200&offset=200`.\n\n### Step 3 — Enumerate pages on Wiki v2\n\n```bash\ncurl -fsS \"https://git-wiki-ktqxite5iglh.adom.cloud/api/v1/pages?limit=500\" \\\n -H \"Authorization: Bearer $ADOM_WIKI_TOKEN\" > /tmp/v2_pages.json\n```\n\nIf `total > returned`, paginate with `&offset=500`.\n\n### Step 4 — Narrow to candidate pages\n\nA 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.\n\n**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.\n\n### Step 5 — Pull the activity log for each candidate (Wiki v1)\n\n```bash\nadom-wiki page log <type>/<slug> --limit 100\n```\n\nReturns `{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:\n- `author_id` or `author_name` matches the resolved identity\n- `created_at` is inside the window\n\nGroup consecutive entries by date for a cleaner digest.\n\n### Step 6 — Pull the git log for each candidate (Wiki v2)\n\n```bash\ncurl -fsS \"https://git-wiki-ktqxite5iglh.adom.cloud/api/v1/pages/<slug>/log?limit=100\" \\\n -H \"Authorization: Bearer $ADOM_WIKI_TOKEN\"\n```\n\nFilter 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.\n\n### Step 7 — Compose the digest\n\nOutput structure:\n\n```markdown\n# Weekly Wiki Digest — week of <YYYY-MM-DD>\n\n## Wiki v1 — <N> active pages\n\n### 1. [<title>](https://wiki-ufypy5dpx93o.adom.cloud/<type>s/<slug>) — `<type>` · v<version>\n**<DayOfWeek MM/DD>** — <one-line summary of what changed>\n- <changelog 1>\n- <changelog 2>\n\n(repeat per page, newest first)\n\n## Wiki v2 — <N> active pages\n\n### 1. [<title>](https://git-wiki-ktqxite5iglh.adom.cloud/<type>/<slug>) — `<type>` · v<version>\n(same shape; commit messages instead of typed activities)\n\n## Quiet touches (no logged content changes)\n- [<title>](url) — `updated_at` advanced into the window but `page log` shows no activity from you. Backend touch.\n\n---\n**Theme of the week:** <1-2 sentences capturing the throughline you noticed across the week's work>\n```\n\nURL 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.\n\n## Rules\n\n1. **Always check both wikis.** If you only ran one, say so explicitly and rerun.\n2. **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.\n3. **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.\n4. **Never invent activity.** If `page log` returns 0 entries in the window, the page goes under \"Quiet touches\", not the main digest.\n5. **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).\n6. **No emoji.** Plain markdown headings, tables, and links only.\n\n## Output length\n\nA 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.\n",
"author": {
"id": "695820315b5f1e4db2fcf602",
"name": "Kyle Bergstedt",
"email": "[email protected]"
},
"visibility": {
"public": true
},
"hero": null,
"metadata": {},
"created_at": "2026-05-28T05:29:26.600Z",
"updated_at": "2026-05-28T05:29:26.600Z",
"sub_skills": [],
"parent_app": null
}