articles-repo-maintenance

name	articles-repo-maintenance
description	Maintain Peter's articles repo with the correct date-folder layout, bilingual article pairing, and MOC updates.
version	1.0.0
author	Hermes Agent
license	MIT
metadata	{"hermes":{"tags":["articles","markdown","bilingual","repo-maintenance","moc","indexing"]}}

Articles Repo Maintenance

Use this skill when working in Peter's articles repository at /Users/peter/Desktop/code/articles/ (Quriosity-agent/articles).

Repo conventions

• Main content repo path: /Users/peter/Desktop/code/articles/
• Do not use a nested articles/ content subdirectory such as /Users/peter/Desktop/code/articles/articles/.
• The correct layout is one level only: date folders directly under the repo root, for example:
  • 2026-04-30/2026-04-30-some-article.md
  • 2026-04-30/2026-04-30-some-article-en.md
• Each article should have Chinese and English versions.
• MOC.md must be updated when adding or moving articles.
• README.md is the chronological index; MOC.md is the topic map.
• User preference: after writing/updating articles in this repo, commit + push by default without asking.
• User preference: after the article is finished and pushed, send Peter the final GitHub links for the Chinese and English versions in the completion reply.

When adding a new article

1. Infer the article date from the filename.
2. Before drafting, search README.md, MOC.md, and recent date folders for the source URL, project name, or topic keywords. If prior coverage exists, do not silently duplicate the same article. Write a distinct follow-up angle (for example: feature reference vs patterns guide, implementation deep dive vs operating playbook) and link/position it accordingly.
3. Ensure the date folder exists at repo root.
4. Create both files:
   • YYYY-MM-DD/YYYY-MM-DD-slug.md
   • YYYY-MM-DD/YYYY-MM-DD-slug-en.md
5. If the source material includes images/screenshots/diagrams, download them into a local article asset folder (recommended: YYYY-MM-DD/imgs/<slug>/) and embed them in both Chinese and English articles using relative Markdown image links. Do not omit source images unless Peter explicitly asks for text-only.
   • For rendered Next.js image URLs such as /_next/image?url=<encoded-source>&w=... or https://www.anthropic.com/_next/image?url=..., decode the url query parameter and download the original CDN asset, not the resized proxy URL. Verify every relative image link exists before committing.
   • Some product/blog pages (for example MiniMax-style CDN pages) mix Next.js image proxies with direct filecdn... URLs and extensionless CDN paths. Download all meaningful body media, run file <asset> after download, and rename extensionless assets to the detected type (.jpg, .png, .gif, etc.) before embedding so GitHub/Markdown renderers handle them reliably.
   • If Python urllib times out or stalls while downloading CDN-hosted assets, retry with curl -L --retry 3 --connect-timeout 20 --max-time 180 -A 'Mozilla/5.0' -o <file> <url> rather than dropping the asset. Verify the downloaded file type with file and confirm Markdown references point to existing local files.
   • For pages where baoyu-url-to-markdown captures content but misses metadata (for example Anthropic research pages may show the publish date in rendered HTML while not exposing article:published_time), inspect the raw HTML or rendered page snippets for the date and use that date folder.
6. Add matching links in MOC.md.
7. Verify the new files and any asset folders are in the correct top-level date folder, not under any nested directory.

Source-doc and official-doc article angle control

When the source is an official documentation page rather than a GitHub repo or social post, keep the article analytical and operational instead of mirroring the docs. If there is already an article on a related doc page, explicitly choose a non-overlapping angle, such as:

• feature mechanics/reference (delegate_task parameters, lifecycle, constraints);
• workflow patterns (parallel research, code review, compare alternatives, gather-then-analyze);
• operational playbook (prompt templates, verification, least-privilege toolsets);
• troubleshooting/configuration notes.

Use the official doc URL in the metadata block and verify the article does not merely restate the prior article's outline.

When fixing structure

If files are misplaced under a nested articles/ directory or sitting in the repo root instead of a date folder:

1. Parse the leading YYYY-MM-DD from each filename.
2. Move each file into the corresponding top-level date folder.
3. Update all MOC.md links from old forms such as:
   • [[articles/YYYY-MM-DD/YYYY-MM-DD-slug|...]]
   • [[articles/YYYY-MM-DD-slug|...]] to
   • [[YYYY-MM-DD/YYYY-MM-DD-slug|...]]
4. Re-scan for remaining files under any nested articles/ directory.
5. Re-scan for missing bilingual pairs.
6. Commit and push.

Cleanup of stale temporary/source files

When the user asks whether tmp, _tmp, Python scripts, or other non-article files are needed in the articles repo, inspect before deleting:

1. Check tracked/untracked state and gitlinks/submodules:

   git status --short
   git ls-files -s | grep -E '(^160000 .*tmp|[[:space:]]tmp/|/_tmp/|\.py$)' || true
   git config --file .gitmodules --get-regexp '.*' || true
   

2. For top-level tmp/ or _tmp/ entries, treat empty 160000 gitlinks with no .gitmodules mapping as stale unless a Markdown file or index directly references them. Remove with git rm -r <path>, remove the now-empty parent directory, add tmp/ and _tmp/ to .gitignore, then commit/push.
3. For Python files:
   • Root-level one-off maintenance scripts (encoding fixes, local migration helpers, hard-coded local paths) usually do not belong in the article repo; remove them after confirming no Markdown/index references.
   • Article-local asset generator scripts may belong if they reproduce committed images/diagrams referenced by articles. Prefer keeping them, but replace absolute machine-specific paths with relative paths such as os.path.dirname(os.path.abspath(__file__)) and run the script to verify outputs still regenerate.
4. After cleanup, verify git status --short is clean after commit/push and re-scan for remaining tracked tmp/, _tmp/, or unintended root scripts.

Pair verification check

Use a quick scan to ensure every base article has both languages:

• Chinese file: base.md
• English file: base-en.md

A valid pair means both exist for the same base path.

Running article jobs via cron/background agents

When Peter asks to "cronjob" or otherwise schedule an article writeup from a URL, create a one-shot job rather than writing it inline. Use deliver="origin" so the completed job posts back to the same Discord thread. Include this skill in the job, enable at least web, browser, terminal, file, and skills; add vision for X/Twitter or visual/media-heavy sources. Schedule it for about one minute in the future using a tool-derived current time, and prompt the child agent to follow this repo's bilingual layout, image preservation, README/MOC updates, selective staging, commit/push, and GitHub link verification. Reply immediately with the cron job_id, source URL, and that the job will return links when complete.

When Peter wants multiple article jobs to run now and concurrently, prefer independent background Hermes processes over cron jobs or delegate_task. Use terminal(background=true, notify_on_complete=true) with one hermes chat -q <prompt> --source <article-job-tag> per article so each job survives Discord turn interrupts and can be polled by process session id. Do not wrap the command with shell backgrounding such as nohup, &, disown, or setsid; let the terminal tool manage lifecycle. For concurrent jobs in the same articles repo, instruct each child to use selective staging and git pull --rebase before push; for maximum safety, use a separate git worktree or temp clone per article and merge/index updates afterward. Avoid delegate_task for full article write/commit/push workflows because delegated children are synchronous to the parent turn and are not durable background workers.

Completion reply checklist

After writing, verifying, committing, and pushing an article task, send a concise final reply that includes:

• Chinese article GitHub link and English article GitHub link.
• Commit hash/message when available.
• A brief note that README.md/MOC.md and local assets were updated if applicable.
• A brief note that GitHub/raw links were verified. Do not re-run completed work after context compaction; if the handoff says the repo is clean and links are verified, only report the result.

Suggested verification steps

• List repo-root date folders and confirm article files live there.
• Search MOC.md for old broken articles/... paths.
• When verifying index links, remember README.md uses literal .md links while MOC.md uses Obsidian wikilinks without .md; verify MOC by searching for the slug/base path (e.g. YYYY-MM-DD/slug and YYYY-MM-DD/slug-en), not only slug.md.
• Scan all target article files for missing -en.md or missing Chinese counterpart.
• Review git status before commit.
• If an existing single-language article already exists, prefer migrating + pairing it instead of rewriting the original from scratch.
• For data/table-driven articles, verify the article contains concrete evidence, not just high-level analysis: name the specific companies/items, group them by category, and add an appendix/table with the underlying records when useful. If the user asks for “每家公司一段” / one paragraph per item from an image/table, preserve the original screenshot as a local asset, create a clearly numbered section for every source row, count the generated headings against the source count (for example 63 rows → 63 ### headings in each language), and include a short caveat when some companies are stealth or only partially public.
• For X/Twitter article writeups, inspect the source page for images (document.querySelectorAll('img') or the X-to-Markdown media workflow), save meaningful media locally, and verify every image referenced in Markdown exists and is pushed.
• When an X/Twitter post is mainly a pointer to an external article, launch page, GitHub repo, model card, demo, or docs page, resolve the outbound link first (record both the X post and canonical external URL in the article metadata), then ground the writeup in that canonical source and any official docs it links to. This avoids unnecessary reverse-engineered X API usage while preserving the social source context.
• For X/Twitter posts that summarize a GitHub/model release, treat the post as social framing and verify concrete claims against authoritative sources before writing: README/docs/model cards, GitHub API metadata, release notes, and benchmark tables. If the post conflicts with the canonical source (for example parameter counts, license, star count, model size, supported languages, dates), explicitly note the correction and cite the canonical value rather than repeating the post's claim.
• For X/Twitter posts announcing an open-weight model or model leaderboard result, ground the article in the social post plus the official model/product page, GitHub README, Hugging Face collection/model cards, and benchmark images/tables. Preserve the tweet image and any official benchmark charts as local assets, and explicitly separate “open weights / open code” from commercial licensing rights when licenses are non-commercial or gated.

Pitfalls

• Do not put new article files under articles/articles/... or articles/YYYY-MM-DD/....
• The correct path style is repo-root/YYYY-MM-DD/file.md.
• Do not add only one language version unless the user explicitly asks for a one-language draft.
• Do not forget source images: Peter expects article tasks based on visual/social posts to include the relevant original images, not just text analysis.
• When moving files, update MOC.md paths in the same task.
• Repo-level scans may show many legacy patterns outside the requested scope; only normalize the scope requested unless asked to refactor the entire repository.