Turn a running work log into a one-page update that a manager, a CEO, an advisor, a funder or any other stakeholder can absorb in a few minutes — without dropping the blockers, softening the negative results, or losing the long record.
Status updates often fail the same way: everything is written at the same weight, so the reader has to do the ranking. Progress Sync is built for the standing check-in — weekly team update, board or investor note, advisor meeting, client report:
- Forces a scan path. The title states the finding, not the date. Each item leads with a claim the reader can act on — "being unable to fix is itself a signal" — and the supporting detail sits underneath in small print. Reading only the headline lines gives the whole update; the detail is there when someone wants it.
- One page, one closing item. A page limit is what forces the ranking. The page ends with the single most important thing for the reader — and its type follows what that thing actually is: a decision needed, a point for discussion, something to watch, help needed, a risk flagged, or plainly nothing needed this period. Remaining open questions are carried forward in the log, not deleted.
- Written for someone outside the work. Every piece of jargon is explained the first time it appears, in the sentence itself, not in a glossary the reader will not scroll to. Numbers are stated in plain terms — "finds 70% of them, up from 45%", not "V1 0.70 vs V0 0.45".
- No AI flavor. The output is scrubbed of the tells that make a document read as machine-written — inflated significance, "-ing" tails that fake depth, rule-of-three padding, vague attribution, promotional adjectives. The pass is adapted from academic-humanizer; see Acknowledgments.
- Keeps the record honest. Blockers, failed attempts, negative results and unresolved disagreements are never dropped to make a page look better. The one-pager is a view of the running log, not a replacement for it.
Every page carries a date and a stated purpose. Reporter, recipient and reporting period are asked for up front and printed when given — and omitted entirely when not, rather than filled with a placeholder. A role is always accepted in place of a name, which keeps a document safe to forward.
Output is a self-contained HTML file plus a print-ready PDF. English by default, in whatever language the notes were written; ask for another language and it produces that instead, labels and all, with the line length adjusted for the script.
The skill is plain Markdown plus one HTML template and one shell script, with no runtime of its own.
It is developed and tested in Claude Code; other tools that load a SKILL.md should be able to use
it unchanged, but we have not tested them. Clone it wherever your tool looks for skills:
# Claude Code
git clone https://github.com/AIScientists-Dev/progress-sync ~/.claude/skills/progress-sync
# any other tool — clone it anywhere and point the tool at SKILL.md
git clone https://github.com/AIScientists-Dev/progress-syncRendering needs Google Chrome, Chromium or Microsoft Edge, and pdfinfo or pdftoppm from Poppler
for the page-count check.
/progress-sync
[point at notes.md, a running log, or paste this period's entry]
# optionally: "audience: CEO", "language: zh", "period: Sep 19-26", "close with a discussion point"
The skill asks five things before rendering — purpose, reporter, recipient, period, language — and leaves out whatever you skip. Purpose sets what the claims are about; there are twelve named ones, from research progress and product progress to decision request, investor update, incident postmortem and client status.
Recipient sets the register, not the facts. A board update leads with movement against plan, an advisor note with the technical finding, a client report with what is delivered and whether the date holds. Depth of method detail and how hard the jargon rule bites both follow from it. Blockers and negative results appear in every variant — if two versions of the same update would disagree about whether something is going wrong, that is spin, and the skill will not produce it.
Five steps — read the log and the previous sync → rank items by what changed and what is blocked →
compress each into a claim plus its evidence → strip AI tells and gloss every term the reader may
not know → render to one page and verify the page count. The compression rules, the de-AI-ifying
pass and the "never drop" list are in SKILL.md.
- It will not omit a blocker, a failed experiment, or a negative result to fit the page. If the page overflows, it cuts detail, never bad news.
- It will not invent a finding, a number, or a next step that is not in the source log.
- It will not write persuasion. The goal is a reader who understands the state of the work, not a reader who is impressed by it.
- It will not manufacture a decision to fill the closing block. If nothing is needed this period, it says so.
- It is not project management. It does not track tasks, take minutes, or run standups.
- academic-humanizer (MIT) — focus: removing AI-writing patterns from academic manuscripts and matching every claim to its evidence. Progress Sync reuses two things from it: the AI-tell catalog behind step 4, and the discipline that no verb may be stronger than its evidence. The registers differ — that skill edits scholarly prose, this one ranks and compresses a work log for a reader outside the work.
- blader/humanizer (MIT) — the general AI-tell catalog that academic-humanizer built on, and so indirectly the basis of the pass here.
This skill is deliberately narrow: a single compression and layout pass over notes you have already written.
Two synthetic one-pagers, with the messy source log for the first:
examples/product-progress-to-ceo.pdf— English, product progress to a CEO, closing with a decision. Built fromthe raw log, which buries the blocker six paragraphs down.examples/experiment-report-zh.pdf— Chinese, experiment results to an advisor, closing with a "worth watching" flag rather than a decision.
MIT.