progress-log

A process for turning feature handoff notes into visible project status in a progress file and an external tracker.

In plain words
What is it for?
Updating one feature's progress, synchronizing changes after a handoff, or reconciling the status of all project features.
Why use it?
It keeps project tracking aligned with work that has been completed or whose status has changed, reducing manual reconciliation.

Skill for Claude CodeCodex

Install

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.

agentmods
npx agentmods add skills/swingerman/engineer/progress-log
Any agent
npx skills add swingerman/engineer --skill progress-log
Clone the repo
git clone --depth 1 https://github.com/swingerman/engineer

Made for: Claude Code, Codex.

Per session 47 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,418 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What 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.

ModelPer sessionOnce 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

Measured 2d ago against content hash 6b899eb187bb, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

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.

engineer/skills/progress-log/SKILL.md · 60 lines

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; --project reconciles all.

Not for: changing artifacts (feature-edit); validating consistency (consistency-check); a session wrap-up (session-summary).

Workflow

  1. Resolve + scope — resolve the methodology root + manifest via ${CLAUDE_PLUGIN_ROOT}/scripts/dae_resolve.py (see references/resolving.md); the manifest carries the tracker config. Scope = one feature (auto / <slug>) or all (--project).
  2. Read new handoffshandoffs/*.md not yet reflected in progress.md (compare timestamps against the last-synced marker).
  3. Update progress.md — per handoff: update the Checkpoints table row (if checkpoint: set), append to Verification reports (if a verification skill), append to the Handoff log, recompute the CURRENT header — the fixed, parseable first line of progress.md: > ▶ CP<N> <Stage> — <m>/<n> criteria met | NEXT: <action> | BLOCKED: <none|reason>. Derive <m>/<n> from the latest handoff's exit_criteria block for the current checkpoint, NEXT from its recommended_next, and BLOCKED from any unmet criterion that needs a human (else none). If the handoff carries a cloud_session_url and its PR isn't merged yet, set NEXT: review cloud PR <url> and record the session/PR link in the Handoff log — this is the signal next reads to surface the feature as DISPATCHED.
  4. Recompute tracked state — derive the TrackedFeature record from local truth (feature.md + progress.md).
  5. Sync the tracker — driver upsert(TrackedFeature) per references/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 to progress.md's "Tracker sync" line. 5b. Sync the roadmap (if the feature came from one) — if feature.md carries a roadmap_ref, keep the strategic item's lifecycle in step with the feature: on status: in-progress ensure the item is in-progress with the feature's slug back-linked; on status: done (CP8 complete / PR merged) mark it shipped. Driver per references/roadmap.md (local = ${CLAUDE_PLUGIN_ROOT}/scripts/dae_roadmap.py mark <roadmap_ref> <status> <slug>; MCP/CLI/API-backed = the connected channel). If manifest.roadmap.type is none or the host is unreachable, skip with a one-line note — never block the tracker sync. Note the result on progress.md's "Tracker sync" line.
  6. (--project only) Merged-PR reconcile + drift report — first, for each in-flight feature run ${CLAUDE_PLUGIN_ROOT}/scripts/dae_reconcile.py <feature-dir> --apply: it flips feature.md status: done for any feature whose PR is merged (detected via gh, so squash-merge and git.manual are covered) so the tracker sync below reflects git reality instead of stale in-progress. A returned flag: merged-unverified (shipped with no CP7 verify handoff) is a discipline gap — surface it, don't bury it. Then run driver reconcile() per references/tracker.md; surface anything unexpected (orphan tracker entry, untracked local feature).

Read the full file on GitHub · 60 lines

Changes

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.

  1. 2d ago First seen · 60 lines · 47 tokens per session scan A 6b899eb187bb

Subscribe to this mod's changes

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.

Related

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 ->…

anombyte93/prd-taskmaster · 98 tokens

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…

anombyte93/prd-taskmaster · 137 tokens

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…

anombyte93/prd-taskmaster · 68 tokens

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…

jpicklyk/task-orchestrator · 101 tokens

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…

jpicklyk/task-orchestrator · 129 tokens

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…

jpicklyk/task-orchestrator · 110 tokens