progress-check

A preserved method from https://github.com/tjcages/skills at 687c395cba58, path progress-check/skills/progress-check, MIT. 129 of 266 source lines differ (48%), every difference claimed by an entry of the ledger with its reason. Entries: baseline-copies-2026-09-11, descriptions-practice-the-catalog-2026-09-11, fold-2026-09-11, vocabulary-owner-2026-09-12.

  • harness 10
  • lifecycle 4
  • location 4
  • scope 1

Files

Every difference, as it stands

EXAMPLES.md

# Progress Check examples
# Progress Check examples
 
 
## Useful milestone update
## Useful milestone update
29 unchanged lines
 
 
1. The schema migration passed its apply-twice test.
1. The schema migration passed its apply-twice test.
2. API integration is active.
2. API integration is active.
3. Next: verify the deployed read path.
3. Next: verify the deployed read path.
 
 
`API rollout [████████████░░░░░░░░] 60%`
`API rollout [████████████░░░░░░░░] 60%`
 
 
## Actionable blocker
## Actionable blocker
 
 
1. Packaging and validation are complete.
1. Packaging and validation are complete.
2. Publishing is blocked because the registry session is not authenticated.
2. Publishing is blocked because the registry session is not authenticated.
3. Next: authorize the registry, then rerun the publish command.
3. Next: authorize the registry, then rerun the publish command.
 
 
`Skill release [████████████████░░░░] 80%`
`Skill release [████████████████░░░░] 80%`
 
 
## Completion
## Completion
 
 
1. The package is published and installable from both catalog routes.
1. The package is published and installable from both catalog routes.
 
 
`Skill release [████████████████████] 100%`
`Skill release [████████████████████] 100%`
 
 
## Updates to suppress
## Updates to suppress
 
 
Do not send any of these when no material state changed:
Do not send any of these when no material state changed:
 
 
- “Still working.”
- “Still working.”
- “The tests are still running.”
- “The tests are still running.”
- The same percentage and bar as the prior update.
- The same percentage and bar as the prior update.
- Separate bars for every subagent or batch.
- Separate bars for every subagent or batch.
 
 
## Dogfood log
## Dogfood log
 
 
harnesschangedfold-2026-09-11

The greenline CLI installs this skill, so the Install globally mode, its npx skills add command and its native always-on instruction steps are not procedures here and Report progress is the only reporting mode; the mode bullet says so where the mode was introduced, EXAMPLES.md marks the Dogfood log as upstream's own install history rather than a command or a claim about this installation, and the last SKILL.md hunk carries the situational closing line (Durable output: none; applied on its own cadence in the worker moment and the moment the user asks to change the cadence, before any preference is saved).

This log is upstream's record of its own install runs, kept as written. It is
not a command to run here and makes no claim about this installation, which
the greenline CLI performs.
 
### 2026-08-25 — Codex and Claude Code install
### 2026-08-25 — Codex and Claude Code install
 
 
- Targets: clean temporary Codex and Claude Code projects.
- Targets: clean temporary Codex and Claude Code projects.
10 unchanged lines
- Command: local `npx skills add` with `--copy` and each agent identifier.
- Command: local `npx skills add` with `--copy` and each agent identifier.
- Friction: the first run skipped all shared references because their relative
- Friction: the first run skipped all shared references because their relative
symlinks pointed one directory too high.
symlinks pointed one directory too high.
- Fix: use `../../shared/*.md`, then require installed-reference read checks in
- Fix: use `../../shared/*.md`, then require installed-reference read checks in
both target directories before accepting a dogfood run.
both target directories before accepting a dogfood run.
- Behavior friction: Codex dropped the requested fence, while Claude added a
- Behavior friction: Codex dropped the requested fence, while Claude added a
disclaimer after the bar. Fenced blocks exposed renderer chrome, and the
disclaimer after the bar. Fenced blocks exposed renderer chrome, and the
first four-space-indented fix still produced a copyable code block.
first four-space-indented fix still produced a copyable code block.
- Fix: require one inline-code progress line as the final content, with one pair
- Fix: require one inline-code progress line as the final content, with one pair
of backticks, no indentation, no fence, and no text beneath it.
of backticks, no indentation, no fence, and no text beneath it.
- Result: Codex and Claude Code both loaded the copied skill and ended on the
- Result: Codex and Claude Code both loaded the copied skill and ended on the
correct 12/20, 60% inline-code bar. Cursor's project install also copied the
correct 12/20, 60% inline-code bar. Cursor's project install also copied the
complete skill and all three references through its universal `.agents` path.
complete skill and all three references through its universal `.agents` path.

METHODOLOGY.md

# Progress Check methodology
# Progress Check methodology
 
 
**Version:** 1.0.1 — 2026-08-25
**Version:** 1.0.1 — 2026-08-25
30 unchanged lines
 
 
## 0. Core thesis
## 0. Core thesis
 
 
Progress updates are decision signals, not proof that an agent is busy. A good
Progress updates are decision signals, not proof that an agent is busy. A good
update helps the user understand what became true, what remains uncertain, and
update helps the user understand what became true, what remains uncertain, and
whether intervention is needed. Reassurance without changed evidence is noise.
whether intervention is needed. Reassurance without changed evidence is noise.
 
 
## 1. When progress reporting applies
## 1. When progress reporting applies
 
 
Use this method when work is expected to exceed 15 minutes, spans multiple
Use this method when work is expected to exceed 15 minutes, spans multiple
milestones, coordinates multiple agents, or has meaningful blockers between
milestones, coordinates multiple agents, or has meaningful blockers between
start and completion. Skip it for short answers, one-command changes, or work
start and completion. Skip it for short answers, one-command changes, or work
whose only honest states are started and finished.
whose only honest states are started and finished.
 
 
## 2. Establish the denominator
## 2. Establish the denominator
 
 
Before showing a percentage, identify 3–7 observable milestones. A milestone
Before showing a percentage, identify 3–7 observable milestones. A milestone
is complete only when its evidence exists: a passing check, committed artifact,
is complete only when its evidence exists: a passing check, committed artifact,
accepted review, accessible deployment, or another task-specific gate.
accepted review, accessible deployment, or another task-specific gate.
 
 
Weight milestones by expected work and risk. Do not divide them equally when
Weight milestones by expected work and risk. Do not divide them equally when
one milestone clearly dominates the task. Never derive progress from elapsed
one milestone clearly dominates the task. Never derive progress from elapsed
time, tool-call count, token use, or confidence.
time, tool-call count, token use, or confidence.
 
 
Rebaseline only when scope materially changes. State the scope change in the
Rebaseline only when scope materially changes. State the scope change in the
same update; do not silently move the percentage backward or inflate it.
same update; do not silently move the percentage backward or inflate it.
 
 
## 3. Cadence
## 3. Cadence
 
 
Send one baseline update after the scope and denominator are understood.
Send one baseline update after the scope and denominator are understood.
 
 
Routine updates require both:
Routine updates require both:
 
 
harnesschangedfold-2026-09-11

The agent has no wall clock and its unit of reply is the turn, so the 30-minute half of the routine-update gate is re-anchored in SKILL.md step 3 and METHODOLOGY.md section 3 to turns of work since the previous routine update or a status transition of the owning ticket, the change half (a milestone, ten verified points, a different next action) unchanged and an estimated elapsed time never used to open the gate; section 8's open gap names the turn-and-status cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode.

1. At least 30 minutes since the previous routine update.
1. Turns of work since the previous routine update, or a status transition of
the owning ticket; never an estimate of elapsed time.
2. A completed milestone, at least 10 percentage points of verified progress,
2. A completed milestone, at least 10 percentage points of verified progress,
or a materially different next action.
or a materially different next action.
 
 
harnesschangedfold-2026-09-11

The agent has no wall clock and its unit of reply is the turn, so the 30-minute half of the routine-update gate is re-anchored in SKILL.md step 3 and METHODOLOGY.md section 3 to turns of work since the previous routine update or a status transition of the owning ticket, the change half (a milestone, ten verified points, a different next action) unchanged and an estimated elapsed time never used to open the gate; section 8's open gap names the turn-and-status cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode.

New actionable blockers and final completion bypass the time gate. Waiting,
New actionable blockers and final completion bypass the turn gate. Waiting,
unchanged checks, agent polling, and repeated test runs do not.
unchanged checks, agent polling, and repeated test runs do not.
 
 
## 4. Format
## 4. Format
23 unchanged lines
 
 
Each update contains no more than three concise items:
Each update contains no more than three concise items:
 
 
1. What completed, with concrete evidence.
1. What completed, with concrete evidence.
2. What is active now.
2. What is active now.
3. The next step or blocker.
3. The next step or blocker.
 
 
End with one 20-cell overall bar styled as inline code on its own line:
End with one 20-cell overall bar styled as inline code on its own line:
 
 
`Performance rollout [██████████████████░░] 90%`
`Performance rollout [██████████████████░░] 90%`
 
 
Use one pair of backticks for inline-code styling. Do not indent the line by
Use one pair of backticks for inline-code styling. Do not indent the line by
four spaces and do not use a fenced code block. Those forms create a separate
four spaces and do not use a fenced code block. Those forms create a separate
code block that interfaces may label or make copyable.
code block that interfaces may label or make copyable.
 
 
Use `█` for completed cells and `░` for remaining cells. Each cell represents
Use `█` for completed cells and `░` for remaining cells. Each cell represents
5%. Round down to avoid overstating progress. Use 100% only when every required
5%. Round down to avoid overstating progress. Use 100% only when every required
gate is complete.
gate is complete.
 
 
Replace the label with a short task-specific label. Keep one overall bar even
Replace the label with a short task-specific label. Keep one overall bar even
when the work has batches or subagents. Subtask bars appear only when the user
when the work has batches or subagents. Subtask bars appear only when the user
asks for them. In coordinated work, the root agent owns the bar.
asks for them. In coordinated work, the root agent owns the bar.
 
 
The progress line is the final content. End immediately after it; do not add a
The progress line is the final content. End immediately after it; do not add a
note, recap, disclaimer, or closer beneath it.
note, recap, disclaimer, or closer beneath it.
 
 
locationchangedfold-2026-09-11

A reporting preference is followed within the current task and saved nowhere; a lasting rule is recorded only on the operator's request as a house ruling in the repository's user-owned instruction home in the format .greenline/WORK.md defines, never in a machine-global instruction file, and the next context reads it without a second confirmation; the section that described the global install (SKILL.md and METHODOLOGY.md section 5) now carries this rule under a heading that names it.

## 5. Global installation
## 5. Installation and persistence
 
 
scopechangedvocabulary-owner-2026-09-12

The opening paragraph says the skill governs speaking unasked during long owned work (a ticket held at implementing, a multi-milestone build, delegated agents), never on a short answer or two-state work, on a cadence that is judgment; that it also fires the moment the user asks to change how or how often progress is reported, the preference followed within the task and saved nowhere unless the operator asks for a lasting rule; and that progress stays in the conversation with an estimated clock never claimed. (carried from fold-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))

The portable default is a global Agent Skills installation:
The greenline CLI installs this skill; there is no global installation step
here and no machine-global instruction write. A reporting preference the user
states is followed within the current task and saved nowhere. When the
owner asks for a lasting repository rule, record it as a house ruling in
the repository's user-owned instruction home, in the format
`.greenline/WORK.md` defines; the next context reads it without a second
confirmation.
 
 
harnesschangedfold-2026-09-11

The greenline CLI installs this skill, so the Install globally mode, its npx skills add command and its native always-on instruction steps are not procedures here and Report progress is the only reporting mode; the mode bullet says so where the mode was introduced, EXAMPLES.md marks the Dogfood log as upstream's own install history rather than a command or a claim about this installation, and the last SKILL.md hunk carries the situational closing line (Durable output: none; applied on its own cadence in the worker moment and the moment the user asks to change the cadence, before any preference is saved).

```bash
npx skills add tjcages/skills --skill progress-check -g --agent '*'
```
 
This lets compatible agents discover the same skill without maintaining copies
of the rules in several products.
 
If the user explicitly wants native always-on rules, detect each product's
documented user-level mechanism at execution time. Preserve existing content,
add one identifiable section, make repeated runs idempotent, and avoid project
files when a user-global mechanism exists. For UI-only products, report the
exact settings location and provide the block; do not invent a filesystem path.
 
## 6. Anti-patterns
## 6. Anti-patterns
 
 
| Pattern | Failure | Correction |
| Pattern | Failure | Correction |
8 unchanged lines
|---|---|---|
|---|---|---|
| Activity percentage | Measures motion, not completion | Tie each increase to evidence |
| Activity percentage | Measures motion, not completion | Tie each increase to evidence |
| Update spam | Hides meaningful changes | Apply both cadence gates |
| Update spam | Hides meaningful changes | Apply both cadence gates |
| Frozen repeated bar | Pretends to inform | Stay silent until state changes |
| Frozen repeated bar | Pretends to inform | Stay silent until state changes |
| Batch bar collection | Makes the user aggregate status | Show one overall bar |
| Batch bar collection | Makes the user aggregate status | Show one overall bar |
| Optimistic rounding | Overstates readiness | Round down to 5% |
| Optimistic rounding | Overstates readiness | Round down to 5% |
| Instant 90% | Leaves the risky tail invisible | Weight validation and delivery gates |
| Instant 90% | Leaves the risky tail invisible | Weight validation and delivery gates |
| Silent rebaseline | Breaks trust in the denominator | Name the scope change |
| Silent rebaseline | Breaks trust in the denominator | Name the scope change |
 
 
## 7. Readiness rubric
## 7. Readiness rubric
 
 
lifecyclechangedfold-2026-09-11

Milestone evidence belongs to the owning ticket's acceptance items and its execution account, so every update quotes that evidence, the update is conversation with no parallel progress file or tracker, and METHODOLOGY.md section 7 keeps no 0/1/2 readiness score (its sixth item scored a global persistence greenline does not perform); the execution contract is the readiness measure.

Score each item 0, 1, or 2. A usable implementation scores at least 10/12 with
No readiness score is kept here. Report observable milestone evidence and its
no zero.
limits under the execution contract: the owning ticket's acceptance items and
the witnesses recorded in its account. Global persistence is not a criterion,
since the greenline CLI installs this skill.
 
 
lifecyclechangedfold-2026-09-11

Milestone evidence belongs to the owning ticket's acceptance items and its execution account, so every update quotes that evidence, the update is conversation with no parallel progress file or tracker, and METHODOLOGY.md section 7 keeps no 0/1/2 readiness score (its sixth item scored a global persistence greenline does not perform); the execution contract is the readiness measure.

1. Eligibility: the method activates only for qualifying work.
2. Denominator: milestones are observable and evidence-based.
3. Honesty: percentages follow completed work and round down.
4. Cadence: routine updates satisfy both gates.
5. Clarity: one bar and at most three concise items.
6. Persistence: global installation preserves unrelated configuration.
 
## 8. Open gaps
## 8. Open gaps
 
 
harnesschangedfold-2026-09-11

The agent has no wall clock and its unit of reply is the turn, so the 30-minute half of the routine-update gate is re-anchored in SKILL.md step 3 and METHODOLOGY.md section 3 to turns of work since the previous routine update or a status transition of the owning ticket, the change half (a milestone, ten verified points, a different next action) unchanged and an estimated elapsed time never used to open the gate; section 8's open gap names the turn-and-status cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode.

- Validate native always-on installation against new agent products as their
- Revisit the turn-and-status cadence and the 10-point default only after real
documented global configuration mechanisms change.
usage shows that they are too sparse or still noisy.
- Revisit the 30-minute and 10-point defaults only after real usage shows that
they are too sparse or still noisy.

SKILL.md

---
---
harnesschangeddescriptions-practice-the-catalog-2026-09-11

greenline renders its own frontmatter: quoted name and description; the description rewritten without em dashes under the widened rule

name: progress-check
name: "progress-check"
license: MIT
description: "Give sparse, evidence-based progress updates during long-running work: observable milestones weighted by work and risk, an update only when something material changed, one rounded-down bar. Fires in the worker moment, a claimed ticket or a multi-milestone build, never for short answers or work with no intermediate state. Also fires the moment the user asks to change how or how often you report progress, whether more updates, total silence or estimated clocks, BEFORE any such preference is saved anywhere."
metadata:
version: "1.0.1"
description: >-
Give sparse, evidence-based progress updates for long-running agent tasks and
projects. Use when work will take more than 15 minutes, spans multiple
milestones, involves delegated agents, or when the user asks for progress
bars, status cadence, fewer updates, or a global cross-agent progress rule.
Not for short answers or tasks with no meaningful intermediate state.
---
---
 
 
# Progress Check
# Progress Check
 
 
harnesschangedvocabulary-owner-2026-09-12

The greenline CLI installs this skill, so the Install globally mode, its npx skills add command and its native always-on instruction steps are not procedures here and Report progress is the only reporting mode; the mode bullet says so where the mode was introduced, EXAMPLES.md marks the Dogfood log as upstream's own install history rather than a command or a claim about this installation, and the last SKILL.md hunk carries the situational closing line (Durable output: none; applied on its own cadence in the worker moment and the moment the user asks to change the cadence, before any preference is saved). (carried from fold-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))

This skill governs speaking unasked during long owned work: a ticket you hold
at implementing, a multi-milestone build, delegated agents running. It never
fires on a short answer or on work whose only honest states are started and
finished, and its cadence is judgment, never spam. It also fires the moment the
user asks to change how or how often you report, whether more updates, silence
or an estimated clock: follow the preference within the current task, keep
reporting actionable blockers, and save nothing anywhere unless the owner
asks for a lasting rule (Persist a preference, below). Progress stays in the
conversation; the evidence behind it belongs to the owning ticket and its
execution account, and an estimated clock is an unmeasured claim this skill
never makes.
 
Full method: [METHODOLOGY.md](./METHODOLOGY.md). Chat shape:
Full method: [METHODOLOGY.md](./METHODOLOGY.md). Chat shape:
[RESPONSE.md](./RESPONSE.md). Examples: [EXAMPLES.md](./EXAMPLES.md).
[RESPONSE.md](./RESPONSE.md). Examples: [EXAMPLES.md](./EXAMPLES.md).
 
 
## Choose the mode
## Choose the mode
 
 
- **Report progress:** default for qualifying long-running work.
- **Report progress:** default for qualifying long-running work.
locationchangedvocabulary-owner-2026-09-12

A reporting preference is followed within the current task and saved nowhere; a lasting rule is recorded only on the operator's request as a house ruling in the repository's user-owned instruction home in the format .greenline/WORK.md defines, never in a machine-global instruction file, and the next context reads it without a second confirmation; the section that described the global install (SKILL.md and METHODOLOGY.md section 5) now carries this rule under a heading that names it. (carried from fold-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))

- **Install globally:** only when the user asks to persist this behavior across
- **Persist a preference:** only when the owner asks for a lasting rule. The
agents or projects.
greenline CLI installs this skill, so there is no install-globally mode here.
 
 
## Report progress
## Report progress
 
 
1. Define a small set of observable milestones before estimating a percentage.
1. Define a small set of observable milestones before estimating a percentage.
lifecyclechangedfold-2026-09-11

Milestone evidence belongs to the owning ticket's acceptance items and its execution account, so every update quotes that evidence, the update is conversation with no parallel progress file or tracker, and METHODOLOGY.md section 7 keeps no 0/1/2 readiness score (its sixth item scored a global persistence greenline does not perform); the execution contract is the readiness measure.

Weight by work and risk, not elapsed time.
Weight by work and risk, not elapsed time. Where a ticket owns the work, the
milestones are its acceptance items and every update quotes their evidence.
2. Send one baseline update after scope is understood.
2. Send one baseline update after scope is understood.
harnesschangedfold-2026-09-11

The agent has no wall clock and its unit of reply is the turn, so the 30-minute half of the routine-update gate is re-anchored in SKILL.md step 3 and METHODOLOGY.md section 3 to turns of work since the previous routine update or a status transition of the owning ticket, the change half (a milestone, ten verified points, a different next action) unchanged and an estimated elapsed time never used to open the gate; section 8's open gap names the turn-and-status cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode.

3. Send a routine update only when at least 30 minutes have passed **and** one
3. Send a routine update only when turns of work have passed since the previous
of these is true: a milestone completed, verified progress rose by at least
routine update or the owning ticket changed status, **and** one of these is
10 percentage points, or the next action materially changed.
true: a milestone completed, verified progress rose by at least 10 percentage
points, or the next action materially changed. Never estimate elapsed time to
open the gate; an estimated clock is an unmeasured claim.
4. Report a new blocker immediately when the user can act on it. Report
4. Report a new blocker immediately when the user can act on it. Report
completion immediately.
completion immediately.
5. Never repeat an unchanged bar or send a routine “still working” message.
5. Never repeat an unchanged bar or send a routine “still working” message.
 
 
lifecyclechangedfold-2026-09-11

Milestone evidence belongs to the owning ticket's acceptance items and its execution account, so every update quotes that evidence, the update is conversation with no parallel progress file or tracker, and METHODOLOGY.md section 7 keeps no 0/1/2 readiness score (its sixth item scored a global persistence greenline does not perform); the execution contract is the readiness measure.

Keep each update to at most three short items: completed evidence, current
The update is conversation and nothing else: milestone evidence belongs to the
work, and next step or blocker. End with exactly one overall bar styled as
owning ticket and its execution account, and no parallel progress file or
inline code on its own line:
tracker is created. Keep each update to at most three short items: completed
evidence, current work, and next step or blocker. End with exactly one overall
bar styled as inline code on its own line:
 
 
`Performance rollout [██████████████████░░] 90%`
`Performance rollout [██████████████████░░] 90%`
 
 
9 unchanged lines
Use one pair of backticks for inline-code styling. Do not indent the line by
Use one pair of backticks for inline-code styling. Do not indent the line by
four spaces and do not use a fenced code block; both create a separate block
four spaces and do not use a fenced code block; both create a separate block
that interfaces may label or make copyable.
that interfaces may label or make copyable.
 
 
- Replace the label with a short task-specific label.
- Replace the label with a short task-specific label.
- Use 20 cells: `█` completed and `░` remaining.
- Use 20 cells: `█` completed and `░` remaining.
- Round down to the nearest 5% unless completion evidence supports 100%.
- Round down to the nearest 5% unless completion evidence supports 100%.
- Show only the overall bar unless the user requests subtask bars.
- Show only the overall bar unless the user requests subtask bars.
- In multi-agent work, only the coordinator shows the overall bar.
- In multi-agent work, only the coordinator shows the overall bar.
- The progress line is the final content in the update. End immediately after
- The progress line is the final content in the update. End immediately after
it with no note, recap, or closer.
it with no note, recap, or closer.
 
 
locationchangedfold-2026-09-11

A reporting preference is followed within the current task and saved nowhere; a lasting rule is recorded only on the operator's request as a house ruling in the repository's user-owned instruction home in the format .greenline/WORK.md defines, never in a machine-global instruction file, and the next context reads it without a second confirmation; the section that described the global install (SKILL.md and METHODOLOGY.md section 5) now carries this rule under a heading that names it.

## Install globally
## Persist a preference
 
 
locationchangedvocabulary-owner-2026-09-12

A reporting preference is followed within the current task and saved nowhere; a lasting rule is recorded only on the operator's request as a house ruling in the repository's user-owned instruction home in the format .greenline/WORK.md defines, never in a machine-global instruction file, and the next context reads it without a second confirmation; the section that described the global install (SKILL.md and METHODOLOGY.md section 5) now carries this rule under a heading that names it. (carried from fold-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))

Prefer installing this skill globally through the available Agent Skills CLI
The greenline CLI installs this skill; there is no global installation step
so one source works across supported agents:
here and no machine-global instruction write. A request to change how or how
often you report is followed within the current task and saved nowhere.
Persist a preference only when the owner asks for a lasting repository
rule, as a house ruling in the repository's user-owned instruction home, in the
format `.greenline/WORK.md` defines. The next context reads that rule without
demanding a second confirmation.
 
 
harnesschangedfold-2026-09-11

The greenline CLI installs this skill, so the Install globally mode, its npx skills add command and its native always-on instruction steps are not procedures here and Report progress is the only reporting mode; the mode bullet says so where the mode was introduced, EXAMPLES.md marks the Dogfood log as upstream's own install history rather than a command or a claim about this installation, and the last SKILL.md hunk carries the situational closing line (Durable output: none; applied on its own cadence in the worker moment and the moment the user asks to change the cadence, before any preference is saved).

```bash
Durable output: none. Applied on its own cadence in the worker moment, and the moment the user asks to change how or how often you report, before any preference is saved anywhere.
npx skills add tjcages/skills --skill progress-check -g --agent '*'
```
 
If the user explicitly requests native always-on instructions instead:
 
1. Detect each installed agent's documented user-level instruction mechanism.
2. Merge the progress rules without overwriting existing instructions.
3. Make the change idempotent and avoid repository-level instruction files.
4. If an agent supports only UI-managed rules, give the exact settings location
and a copy-ready block instead of inventing a file path.
5. Verify each changed target and state whether a new session is required.
 
Do not claim an unsupported agent was configured. Do not modify unrelated
preferences.

agents/openai.yaml

harnessremoved filebaseline-copies-2026-09-11

the renderer generates agents/openai.yaml from the manifest; the vendored copy is not projected

interface:
display_name: "Progress Check"
short_description: "Install sparse progress updates across agents"
default_prompt: "Use $progress-check to install sparse milestone-based progress updates globally across my supported coding agents."

The timeline

Each entry that touched this method, with the differences it claimed as they stood at its commit, read from the repository's history.

2026-09-11 baseline-copies-2026-09-11

the cutover to an edited copy (ADR 0039): the composed output written as the copy, every difference from upstream claimed with the reason of the overlay that produced it

SKILL.md

harnesschangedbaseline-copies-2026-09-11

greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag

name: progress-check
name: "progress-check"
license: MIT
description: "Give sparse, evidence-based progress updates during long-running work: observable milestones weighted by work and risk, an update only when something material changed, one rounded-down bar. Fires in the worker moment, a claimed ticket or a multi-milestone build, never for short answers or work with no intermediate state. Also fires the moment the user asks to change how or how often you report progress — more updates, total silence, estimated clocks — BEFORE any such preference is saved anywhere."
metadata:
version: "1.0.1"
description: >-
Give sparse, evidence-based progress updates for long-running agent tasks and
projects. Use when work will take more than 15 minutes, spans multiple
milestones, involves delegated agents, or when the user asks for progress
bars, status cadence, fewer updates, or a global cross-agent progress rule.
Not for short answers or tasks with no meaningful intermediate state.
lifecyclechangedbaseline-copies-2026-09-11

greenline prelude, to fold: the worker moment only; the wall-clock gate re-anchored to turns and ticket transitions; the global-install mode is out of scope

**greenline prelude: the worker moment only.** This skill governs speaking unasked during long owned work: a claimed ticket mid-`implementing`, a multi-milestone build, delegated agents running. It never fires on short answers, and its cadence is judgment, never spam. The body's 30-minute wall-clock gate does not transfer: your unit of reply is the turn, so re-anchor that half of the gate to turns and to ticket-status transitions, and keep the change half exactly as the body states it (a milestone completed, verified progress rose materially, or the next action changed). Never estimate elapsed time; an estimated clock is an unmeasured claim. The body's Install globally mode does not apply here: the greenline CLI installs this skill, machine-global instruction writes are out of scope, and Report progress is the only mode. Where a ticket owns the work, milestones map to its acceptance items and every update quotes their evidence.
 
**The same integration applies to the linked support files.** METHODOLOGY.md
§3 uses the turn/status cadence above. Its §5 global-install procedure and §8
global-install follow-up are out of scope; EXAMPLES.md's Dogfood log is preserved
upstream history, not a command to execute or a claim about this installation.
Use the skill already installed by greenline. METHODOLOGY.md §7's 0/1/2 readiness
rubric, including its global-persistence score, is not used: report observable
milestone evidence and limits under the execution contract, without a readiness
score. These replacements apply when a support file is read or delegated.
 
lifecyclechangedbaseline-copies-2026-09-11

greenline completion, to fold: progress stays in conversation; no parallel progress file; a preference persists only on the operator's request

 
 
## greenline completion: progress stays in conversation
 
The bar and updates remain conversation. Actual milestone evidence belongs to the owning work and execution account; create no parallel progress file or tracker. Follow the operator's communication preference within the current task and report actionable blockers. Persist a preference only when the operator asks for a lasting repository rule, in its user-owned instruction home. The next context reads that rule without demanding a second confirmation.

agents/openai.yaml

harnessremoved filebaseline-copies-2026-09-11

the renderer generates agents/openai.yaml from the manifest; the vendored copy is not projected

interface:
display_name: "Progress Check"
short_description: "Install sparse progress updates across agents"
default_prompt: "Use $progress-check to install sparse milestone-based progress updates globally across my supported coding agents."

2026-09-11 descriptions-practice-the-catalog-2026-09-11

the em-dash rule now reaches the descriptions (they were manifest overrides, outside the old rule); rewritten without the dashes, meaning kept

SKILL.md

harnesschangeddescriptions-practice-the-catalog-2026-09-11

greenline renders its own frontmatter: quoted name and description; the description rewritten without em dashes under the widened rule

name: progress-check
name: "progress-check"
license: MIT
description: "Give sparse, evidence-based progress updates during long-running work: observable milestones weighted by work and risk, an update only when something material changed, one rounded-down bar. Fires in the worker moment, a claimed ticket or a multi-milestone build, never for short answers or work with no intermediate state. Also fires the moment the user asks to change how or how often you report progress, whether more updates, total silence or estimated clocks, BEFORE any such preference is saved anywhere."
metadata:
version: "1.0.1"
description: >-
Give sparse, evidence-based progress updates for long-running agent tasks and
projects. Use when work will take more than 15 minutes, spans multiple
milestones, involves delegated agents, or when the user asks for progress
bars, status cadence, fewer updates, or a global cross-agent progress rule.
Not for short answers or tasks with no meaningful intermediate state.

2026-09-11 fold-2026-09-11

The prelude and completion are folded into the body and its support files: the scope paragraph, the cadence gate re-anchored in place, the install-globally mode replaced where it is introduced by the rule for a lasting preference, milestone evidence tied to the owning ticket, and a situational closing line; the milestone, format and bar rules are untouched.

EXAMPLES.md

harnesschangedfold-2026-09-11

The greenline CLI installs this skill, so the Install globally mode, its npx skills add command and its native always-on instruction steps are not procedures here and Report progress is the only reporting mode; the mode bullet says so where the mode was introduced, EXAMPLES.md marks the Dogfood log as upstream's own install history rather than a command or a claim about this installation, and the last SKILL.md hunk carries the situational closing line (Durable output: none; applied on its own cadence in the worker moment and the moment the user asks to change the cadence, before any preference is saved).

This log is upstream's record of its own install runs, kept as written. It is
not a command to run here and makes no claim about this installation, which
the greenline CLI performs.
 

METHODOLOGY.md

harnesschangedfold-2026-09-11

The agent has no wall clock and its unit of reply is the turn, so the 30-minute half of the routine-update gate is re-anchored in SKILL.md step 3 and METHODOLOGY.md section 3 to turns of work since the previous routine update or a status transition of the owning ticket, the change half (a milestone, ten verified points, a different next action) unchanged and an estimated elapsed time never used to open the gate; section 8's open gap names the turn-and-status cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode.

1. At least 30 minutes since the previous routine update.
1. Turns of work since the previous routine update, or a status transition of
the owning ticket; never an estimate of elapsed time.
harnesschangedfold-2026-09-11

The agent has no wall clock and its unit of reply is the turn, so the 30-minute half of the routine-update gate is re-anchored in SKILL.md step 3 and METHODOLOGY.md section 3 to turns of work since the previous routine update or a status transition of the owning ticket, the change half (a milestone, ten verified points, a different next action) unchanged and an estimated elapsed time never used to open the gate; section 8's open gap names the turn-and-status cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode.

New actionable blockers and final completion bypass the time gate. Waiting,
New actionable blockers and final completion bypass the turn gate. Waiting,
locationchangedfold-2026-09-11

A reporting preference is followed within the current task and saved nowhere; a lasting rule is recorded only on the operator's request as a house ruling in the repository's user-owned instruction home in the format .greenline/WORK.md defines, never in a machine-global instruction file, and the next context reads it without a second confirmation; the section that described the global install (SKILL.md and METHODOLOGY.md section 5) now carries this rule under a heading that names it.

## 5. Global installation
## 5. Installation and persistence
locationchangedfold-2026-09-11

A reporting preference is followed within the current task and saved nowhere; a lasting rule is recorded only on the operator's request as a house ruling in the repository's user-owned instruction home in the format .greenline/WORK.md defines, never in a machine-global instruction file, and the next context reads it without a second confirmation; the section that described the global install (SKILL.md and METHODOLOGY.md section 5) now carries this rule under a heading that names it.

The portable default is a global Agent Skills installation:
The greenline CLI installs this skill; there is no global installation step
here and no machine-global instruction write. A reporting preference the user
states is followed within the current task and saved nowhere. When the
operator asks for a lasting repository rule, record it as a house ruling in
the repository's user-owned instruction home, in the format
`.greenline/WORK.md` defines; the next context reads it without a second
confirmation.
harnesschangedfold-2026-09-11

The greenline CLI installs this skill, so the Install globally mode, its npx skills add command and its native always-on instruction steps are not procedures here and Report progress is the only reporting mode; the mode bullet says so where the mode was introduced, EXAMPLES.md marks the Dogfood log as upstream's own install history rather than a command or a claim about this installation, and the last SKILL.md hunk carries the situational closing line (Durable output: none; applied on its own cadence in the worker moment and the moment the user asks to change the cadence, before any preference is saved).

```bash
npx skills add tjcages/skills --skill progress-check -g --agent '*'
```
 
This lets compatible agents discover the same skill without maintaining copies
of the rules in several products.
 
If the user explicitly wants native always-on rules, detect each product's
documented user-level mechanism at execution time. Preserve existing content,
add one identifiable section, make repeated runs idempotent, and avoid project
files when a user-global mechanism exists. For UI-only products, report the
exact settings location and provide the block; do not invent a filesystem path.
 
lifecyclechangedfold-2026-09-11

Milestone evidence belongs to the owning ticket's acceptance items and its execution account, so every update quotes that evidence, the update is conversation with no parallel progress file or tracker, and METHODOLOGY.md section 7 keeps no 0/1/2 readiness score (its sixth item scored a global persistence greenline does not perform); the execution contract is the readiness measure.

Score each item 0, 1, or 2. A usable implementation scores at least 10/12 with
No readiness score is kept here. Report observable milestone evidence and its
no zero.
limits under the execution contract: the owning ticket's acceptance items and
the witnesses recorded in its account. Global persistence is not a criterion,
since the greenline CLI installs this skill.
lifecyclechangedfold-2026-09-11

Milestone evidence belongs to the owning ticket's acceptance items and its execution account, so every update quotes that evidence, the update is conversation with no parallel progress file or tracker, and METHODOLOGY.md section 7 keeps no 0/1/2 readiness score (its sixth item scored a global persistence greenline does not perform); the execution contract is the readiness measure.

1. Eligibility: the method activates only for qualifying work.
2. Denominator: milestones are observable and evidence-based.
3. Honesty: percentages follow completed work and round down.
4. Cadence: routine updates satisfy both gates.
5. Clarity: one bar and at most three concise items.
6. Persistence: global installation preserves unrelated configuration.
 
harnesschangedfold-2026-09-11

The agent has no wall clock and its unit of reply is the turn, so the 30-minute half of the routine-update gate is re-anchored in SKILL.md step 3 and METHODOLOGY.md section 3 to turns of work since the previous routine update or a status transition of the owning ticket, the change half (a milestone, ten verified points, a different next action) unchanged and an estimated elapsed time never used to open the gate; section 8's open gap names the turn-and-status cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode.

- Validate native always-on installation against new agent products as their
- Revisit the turn-and-status cadence and the 10-point default only after real
documented global configuration mechanisms change.
usage shows that they are too sparse or still noisy.
- Revisit the 30-minute and 10-point defaults only after real usage shows that
they are too sparse or still noisy.

SKILL.md

scopechangedfold-2026-09-11

The opening paragraph says the skill governs speaking unasked during long owned work (a ticket held at implementing, a multi-milestone build, delegated agents), never on a short answer or two-state work, on a cadence that is judgment; that it also fires the moment the user asks to change how or how often progress is reported, the preference followed within the task and saved nowhere unless the operator asks for a lasting rule; and that progress stays in the conversation with an estimated clock never claimed.

This skill governs speaking unasked during long owned work: a ticket you hold
at implementing, a multi-milestone build, delegated agents running. It never
fires on a short answer or on work whose only honest states are started and
finished, and its cadence is judgment, never spam. It also fires the moment the
user asks to change how or how often you report, whether more updates, silence
or an estimated clock: follow the preference within the current task, keep
reporting actionable blockers, and save nothing anywhere unless the operator
asks for a lasting rule (Persist a preference, below). Progress stays in the
conversation; the evidence behind it belongs to the owning ticket and its
execution account, and an estimated clock is an unmeasured claim this skill
never makes.
 
harnesschangedfold-2026-09-11

The greenline CLI installs this skill, so the Install globally mode, its npx skills add command and its native always-on instruction steps are not procedures here and Report progress is the only reporting mode; the mode bullet says so where the mode was introduced, EXAMPLES.md marks the Dogfood log as upstream's own install history rather than a command or a claim about this installation, and the last SKILL.md hunk carries the situational closing line (Durable output: none; applied on its own cadence in the worker moment and the moment the user asks to change the cadence, before any preference is saved).

- **Install globally:** only when the user asks to persist this behavior across
- **Persist a preference:** only when the operator asks for a lasting rule. The
agents or projects.
greenline CLI installs this skill, so there is no install-globally mode here.
lifecyclechangedfold-2026-09-11

Milestone evidence belongs to the owning ticket's acceptance items and its execution account, so every update quotes that evidence, the update is conversation with no parallel progress file or tracker, and METHODOLOGY.md section 7 keeps no 0/1/2 readiness score (its sixth item scored a global persistence greenline does not perform); the execution contract is the readiness measure.

Weight by work and risk, not elapsed time.
Weight by work and risk, not elapsed time. Where a ticket owns the work, the
milestones are its acceptance items and every update quotes their evidence.
harnesschangedfold-2026-09-11

The agent has no wall clock and its unit of reply is the turn, so the 30-minute half of the routine-update gate is re-anchored in SKILL.md step 3 and METHODOLOGY.md section 3 to turns of work since the previous routine update or a status transition of the owning ticket, the change half (a milestone, ten verified points, a different next action) unchanged and an estimated elapsed time never used to open the gate; section 8's open gap names the turn-and-status cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode.

3. Send a routine update only when at least 30 minutes have passed **and** one
3. Send a routine update only when turns of work have passed since the previous
of these is true: a milestone completed, verified progress rose by at least
routine update or the owning ticket changed status, **and** one of these is
10 percentage points, or the next action materially changed.
true: a milestone completed, verified progress rose by at least 10 percentage
points, or the next action materially changed. Never estimate elapsed time to
open the gate; an estimated clock is an unmeasured claim.
lifecyclechangedfold-2026-09-11

Milestone evidence belongs to the owning ticket's acceptance items and its execution account, so every update quotes that evidence, the update is conversation with no parallel progress file or tracker, and METHODOLOGY.md section 7 keeps no 0/1/2 readiness score (its sixth item scored a global persistence greenline does not perform); the execution contract is the readiness measure.

Keep each update to at most three short items: completed evidence, current
The update is conversation and nothing else: milestone evidence belongs to the
work, and next step or blocker. End with exactly one overall bar styled as
owning ticket and its execution account, and no parallel progress file or
inline code on its own line:
tracker is created. Keep each update to at most three short items: completed
evidence, current work, and next step or blocker. End with exactly one overall
bar styled as inline code on its own line:
locationchangedfold-2026-09-11

A reporting preference is followed within the current task and saved nowhere; a lasting rule is recorded only on the operator's request as a house ruling in the repository's user-owned instruction home in the format .greenline/WORK.md defines, never in a machine-global instruction file, and the next context reads it without a second confirmation; the section that described the global install (SKILL.md and METHODOLOGY.md section 5) now carries this rule under a heading that names it.

## Install globally
## Persist a preference
locationchangedfold-2026-09-11

A reporting preference is followed within the current task and saved nowhere; a lasting rule is recorded only on the operator's request as a house ruling in the repository's user-owned instruction home in the format .greenline/WORK.md defines, never in a machine-global instruction file, and the next context reads it without a second confirmation; the section that described the global install (SKILL.md and METHODOLOGY.md section 5) now carries this rule under a heading that names it.

Prefer installing this skill globally through the available Agent Skills CLI
The greenline CLI installs this skill; there is no global installation step
so one source works across supported agents:
here and no machine-global instruction write. A request to change how or how
often you report is followed within the current task and saved nowhere.
Persist a preference only when the operator asks for a lasting repository
rule, as a house ruling in the repository's user-owned instruction home, in the
format `.greenline/WORK.md` defines. The next context reads that rule without
demanding a second confirmation.
harnesschangedfold-2026-09-11

The greenline CLI installs this skill, so the Install globally mode, its npx skills add command and its native always-on instruction steps are not procedures here and Report progress is the only reporting mode; the mode bullet says so where the mode was introduced, EXAMPLES.md marks the Dogfood log as upstream's own install history rather than a command or a claim about this installation, and the last SKILL.md hunk carries the situational closing line (Durable output: none; applied on its own cadence in the worker moment and the moment the user asks to change the cadence, before any preference is saved).

```bash
Durable output: none. Applied on its own cadence in the worker moment, and the moment the user asks to change how or how often you report, before any preference is saved anywhere.
npx skills add tjcages/skills --skill progress-check -g --agent '*'
```
 
If the user explicitly requests native always-on instructions instead:
 
1. Detect each installed agent's documented user-level instruction mechanism.
2. Merge the progress rules without overwriting existing instructions.
3. Make the change idempotent and avoid repository-level instruction files.
4. If an agent supports only UI-managed rules, give the exact settings location
and a copy-ready block instead of inventing a file path.
5. Verify each changed target and state whether a new session is required.
 
Do not claim an unsupported agent was configured. Do not modify unrelated
preferences.

2026-09-12 vocabulary-owner-2026-09-12

The workspace's person is the owner: the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12); every earlier claim on a re-measured hunk is carried forward under its own kind, with its authority where it had one.

METHODOLOGY.md

scopechangedvocabulary-owner-2026-09-12

The opening paragraph says the skill governs speaking unasked during long owned work (a ticket held at implementing, a multi-milestone build, delegated agents), never on a short answer or two-state work, on a cadence that is judgment; that it also fires the moment the user asks to change how or how often progress is reported, the preference followed within the task and saved nowhere unless the operator asks for a lasting rule; and that progress stays in the conversation with an estimated clock never claimed. (carried from fold-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))

The portable default is a global Agent Skills installation:
The greenline CLI installs this skill; there is no global installation step
here and no machine-global instruction write. A reporting preference the user
states is followed within the current task and saved nowhere. When the
owner asks for a lasting repository rule, record it as a house ruling in
the repository's user-owned instruction home, in the format
`.greenline/WORK.md` defines; the next context reads it without a second
confirmation.

SKILL.md

harnesschangedvocabulary-owner-2026-09-12

The greenline CLI installs this skill, so the Install globally mode, its npx skills add command and its native always-on instruction steps are not procedures here and Report progress is the only reporting mode; the mode bullet says so where the mode was introduced, EXAMPLES.md marks the Dogfood log as upstream's own install history rather than a command or a claim about this installation, and the last SKILL.md hunk carries the situational closing line (Durable output: none; applied on its own cadence in the worker moment and the moment the user asks to change the cadence, before any preference is saved). (carried from fold-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))

This skill governs speaking unasked during long owned work: a ticket you hold
at implementing, a multi-milestone build, delegated agents running. It never
fires on a short answer or on work whose only honest states are started and
finished, and its cadence is judgment, never spam. It also fires the moment the
user asks to change how or how often you report, whether more updates, silence
or an estimated clock: follow the preference within the current task, keep
reporting actionable blockers, and save nothing anywhere unless the owner
asks for a lasting rule (Persist a preference, below). Progress stays in the
conversation; the evidence behind it belongs to the owning ticket and its
execution account, and an estimated clock is an unmeasured claim this skill
never makes.
 
locationchangedvocabulary-owner-2026-09-12

A reporting preference is followed within the current task and saved nowhere; a lasting rule is recorded only on the operator's request as a house ruling in the repository's user-owned instruction home in the format .greenline/WORK.md defines, never in a machine-global instruction file, and the next context reads it without a second confirmation; the section that described the global install (SKILL.md and METHODOLOGY.md section 5) now carries this rule under a heading that names it. (carried from fold-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))

- **Install globally:** only when the user asks to persist this behavior across
- **Persist a preference:** only when the owner asks for a lasting rule. The
agents or projects.
greenline CLI installs this skill, so there is no install-globally mode here.
locationchangedvocabulary-owner-2026-09-12

A reporting preference is followed within the current task and saved nowhere; a lasting rule is recorded only on the operator's request as a house ruling in the repository's user-owned instruction home in the format .greenline/WORK.md defines, never in a machine-global instruction file, and the next context reads it without a second confirmation; the section that described the global install (SKILL.md and METHODOLOGY.md section 5) now carries this rule under a heading that names it. (carried from fold-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))

Prefer installing this skill globally through the available Agent Skills CLI
The greenline CLI installs this skill; there is no global installation step
so one source works across supported agents:
here and no machine-global instruction write. A request to change how or how
often you report is followed within the current task and saved nowhere.
Persist a preference only when the owner asks for a lasting repository
rule, as a house ruling in the repository's user-owned instruction home, in the
format `.greenline/WORK.md` defines. The next context reads that rule without
demanding a second confirmation.