Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/swingerman/engineer/progress-lognpx skills add swingerman/engineer --skill progress-loggit clone --depth 1 https://github.com/swingerman/engineerWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00047 | $0.01418 |
| Opus 5 | $0.00023 | $0.00709 |
| Sonnet 5 | $0.00009 | $0.00284 |
| Haiku 4.5 | $0.00005 | $0.00142 |
Grade A, and why
progress-log scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 60 lines — stays where its author put it; the contents beside it link to each section on GitHub.
progress-log
The propagation engine of DAE visibility. Skills emit handoff summaries; progress-log turns them into the two visible state layers — progress.md (the per-feature glanceable file) and the external tracker.
When the foundations say "the agentic summary contract handles propagation," this skill is that propagation. checkpoint: null.
When to use
- Auto — invoked after a handoff-emitting skill changes a DAE-managed field (status change, checkpoint completion). Scope = the triggering feature.
- Manual —
/engineer.progress-log <slug>re-syncs one feature;--projectreconciles all.
Not for: changing artifacts (feature-edit); validating consistency (consistency-check); a session wrap-up (session-summary).
Workflow
- Resolve + scope — resolve the methodology root + manifest via
${CLAUDE_PLUGIN_ROOT}/scripts/dae_resolve.py(seereferences/resolving.md); the manifest carries the tracker config. Scope = one feature (auto /<slug>) or all (--project). - Read new handoffs —
handoffs/*.mdnot yet reflected inprogress.md(compare timestamps against the last-synced marker). - Update
progress.md— per handoff: update the Checkpoints table row (ifcheckpoint:set), append to Verification reports (if a verification skill), append to the Handoff log, recompute the CURRENT header — the fixed, parseable first line ofprogress.md:> ▶ CP<N> <Stage> — <m>/<n> criteria met | NEXT: <action> | BLOCKED: <none|reason>. Derive<m>/<n>from the latest handoff'sexit_criteriablock for the current checkpoint,NEXTfrom itsrecommended_next, andBLOCKEDfrom any unmet criterion that needs a human (elsenone). If the handoff carries acloud_session_urland its PR isn't merged yet, setNEXT: review cloud PR <url>and record the session/PR link in the Handoff log — this is the signalnextreads to surface the feature as DISPATCHED. - Recompute tracked state — derive the
TrackedFeaturerecord from local truth (feature.md+progress.md). - Sync the tracker — driver
upsert(TrackedFeature)perreferences/tracker.md: local-wins on DAE-managed fields, tracker-managed fields (comments, labels) preserved.local= no-op (the feature files are the tracker). Write the result toprogress.md's "Tracker sync" line. 5b. Sync the roadmap (if the feature came from one) — iffeature.mdcarries aroadmap_ref, keep the strategic item's lifecycle in step with the feature: onstatus: in-progressensure the item isin-progresswith the feature's slug back-linked; onstatus: done(CP8 complete / PR merged) mark itshipped. Driver perreferences/roadmap.md(local=${CLAUDE_PLUGIN_ROOT}/scripts/dae_roadmap.py mark <roadmap_ref> <status> <slug>; MCP/CLI/API-backed = the connected channel). Ifmanifest.roadmap.typeisnoneor the host is unreachable, skip with a one-line note — never block the tracker sync. Note the result onprogress.md's "Tracker sync" line. - (
--projectonly) Merged-PR reconcile + drift report — first, for each in-flight feature run${CLAUDE_PLUGIN_ROOT}/scripts/dae_reconcile.py <feature-dir> --apply: it flipsfeature.md status: donefor any feature whose PR is merged (detected viagh, so squash-merge andgit.manualare covered) so the tracker sync below reflects git reality instead of stalein-progress. A returnedflag: merged-unverified(shipped with no CP7 verify handoff) is a discipline gap — surface it, don't bury it. Then run driverreconcile()perreferences/tracker.md; surface anything unexpected (orphan tracker entry, untracked local feature).
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 60 lines · 47 tokens per session scan A 6b899eb187bb
progress-log is a skill published in the GitHub repository swingerman/engineer (146 stars, last pushed 6d ago), licensed MIT. It adds 47 tokens to every session and 1,418 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
execute-task
Execute the next TaskMaster task using the implementation plan with CDD verification. Picks the next ready task, matches it to the plan step, implements via a dispatched subagent, verifies subtasks with evidence, marks the task done, and loops until every task is complete. Wraps the TaskMaster next -> in-progress ->…
customise-workflow
Customise the prd-taskmaster plugin workflow via curated brainstorm questions. The AI asks, the user answers in plain English, and the skill writes their preferences to .atlas-ai/config/atlas.json. Future runs of prd-taskmaster read that file and apply user preferences to phase gates, validation strictness, default…
expand-tasks
Expand all TaskMaster tasks with deep research before coding begins. Reads tasks.json, launches parallel research agents per task in waves using the research-expander agent. Writes findings back to tasks.json. Part of the prd-taskmaster toolkit. Use after PRD is parsed and before implementation. Invoke with…
implement
End-to-end workflow for taking MCP work items from backlog to merged PR. Handles git branching, schema-driven planning, implementation, independent review, and PR creation. Composes spec-quality, review-quality, and schema-workflow skills into a single pipeline. Use when a user says "implement this", "work on this…
review-proposals
Triages pending improvement-proposal MCP items — presents each with its scope and evidence, collects an accept/reject/defer decision per proposal, and carries out the disposition: project-scoped acceptances get their exact YAML applied to .taskorchestrator/config.yaml and pushed per-root; global acceptances get a…
work-summary
Generates a project dashboard from MCP work items. Default is a lean, attention-first view: what's in flight, what's blocked, what to do next, what's queued. Use when the user says: project status, what's active, show me the dashboard, work summary, what should I work on, project health, what's blocked, where did I…