write-status

Article status

Answer one question fast: which per-article writing skills have run on this article, and which haven't. Then offer the review if it's missing. This skill only reads; the only thing it starts is write-review, and only after the user says yes.

Usage

/write:status [article]

article is a path to an index.md or its bundle folder. Omit it to check the last article created or changed (the same lookup write-review uses).

Workflow

1. Resolve the article. If the user named one, use it. If you created or edited an article earlier in this conversation, use the last one. Otherwise run the check with no argument: the script calls write-review/scripts/last-article.sh, which picks the repo from $BLOG_ROOT, else the current directory's git repo if it has content/ or hugo/content/, else ~/Projects/websites/jeffbaileyblog; inside it, the newest uncommitted article wins, then the most-changed article of the last commit. The script prints that choice on its Picked by: line. Repeat it to the user, because from the wrong directory the default repo can silently pick a different article than the one they meant.

1. Run the check. Needs only python3 and git (command -v python3 git; if missing, say "tool missing" and stop).

   python3 "${CLAUDE_SKILL_DIR}/scripts/article_status.py" check [article]

${CLAUDE_SKILL_DIR} is this skill's directory; substitute it if your agent does not expand the variable. The script reads three places, so you don't search transcripts yourself:

• the run ledger (~/.local/state/jbb-writing/runs.jsonl, or $XDG_STATE_HOME/jbb-writing/), which the writing skills append to when they finish;
• Claude Code transcripts, for Skill calls and slash commands that named the article's folder (and, for calls with no arguments, the first article that session read afterwards);
• the article itself, for work that leaves a mark (see artifact below).

It takes a second or two. Use --json to parse it (summary holds the missing/stale/covered lists).

1. Report the Picked by: line, the table (one row per skill), and the script's last line (Missing: ... Stale: ... Covered by write-validate-article: ...) as the summary. Use the script's lists as they are; don't rebuild them by hand. Statuses:

When answering "what's left before I publish?", list only missing and stale rows; covered and artifact rows are done unless the user wants a deeper pass. Say once, briefly, that transcripts are kept only transcripts_kept_days days (30 by default), so missing on an older article can mean "ran before the ledger existed".

1. Offer the review. If write-review is missing, ask exactly:

Run write-review on <folder> now? [y/N]

Then stop and wait. Only y or yes (any case) runs it; anything else, including no answer, means no. Don't ask about the other missing skills; list them and let the user pick. If write-review is stale, mention it in the summary but don't prompt, since a review already exists.

1. On yes, invoke the write-review skill (jbb-writing-skills:write-review when installed as a plugin) with the absolute article path. write-review records its own run in the ledger as its last step, so don't record it again. Only if it ended without printing recorded write-review on ... (crashed, or an older copy without the record step), record it yourself with its overall score as the note. Then re-run check and show the write-review row.

Recording runs from other skills

record is how the ledger grows. The per-article writing skills call it as their last step; run it yourself only after a tracked skill finishes without recording:

python3 "<write-status dir>/scripts/article_status.py" record <skill> <article> [--note TEXT]

Skill names are accepted in any form (write-seo, /write:seo, jbb-writing-skills:write-seo). Only the eight skills above are tracked. A second record of the same skill on the same article within 10 minutes is skipped (the first one, from the skill itself, keeps its note); pass --force to add it anyway. Timestamps are stored to the microsecond, so a record made right after an edit doesn't read as stale.