Habit · loads whenever its situation comes up, at any step

progress-check

about 2,900 tokens

progress-check as it installs, each line coloured by where its words came from.

  • 5 files
  • 3 edits
  • 31 sentences left out
  • 1 source
  • last changed 2026-10-19

The text

SKILL.md

about 1,000 tokens
  • tjcages
  • greenline

---

name: "progress-check"

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. Use while long work with several milestones runs between replies, never for a short answer or work with no intermediate state; and the moment the owner asks to change how or how often you report progress, whether more updates, total silence or an estimated clock, BEFORE any such preference is saved anywhere."

---

tjcagesprogress-check/SKILL.md

# Progress Check

greenlineOpens the habit: long work between replies, never a short answer

progress-check is the habit for the moment long work runs between replies: a change with several milestones, a build of many slices, delegated agents running one after another. 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 owner 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). It writes no record of its own: progress stays in the conversation, the evidence behind it belongs to the change record's sections and the checks the change recorded, and an estimated clock is an unmeasured claim this habit never makes.

greenlinePoints at the skill's references page for paths and commands

Greenline's paths and commands for this skill stand on its references page, [references/greenline.md](references/greenline.md): read it when the work lands in the workspace.

tjcagesprogress-check/SKILL.md

Full method: [METHODOLOGY.md](./METHODOLOGY.md). Chat shape: [RESPONSE.md](./RESPONSE.md). Examples: [EXAMPLES.md](./EXAMPLES.md).

## Choose the mode

- **Report progress:** default for qualifying long-running work.

greenlinePreferences last the task; a lasting rule needs the owner's request

- **Persist a preference:** only when the owner asks for a lasting rule. The greenline CLI installs this skill, so there is no install-globally mode here.

tjcagesprogress-check/SKILL.md

## Report progress

greenlineMilestones are the change's acceptance items, each update quoting their evidence

1. Define a small set of observable milestones before estimating a percentage. Weight by work and risk, not elapsed time. Where a change owns the work, the milestones are its acceptance items and every update quotes their evidence.

tjcagesprogress-check/SKILL.md

2. Send one baseline update after scope is understood.

greenlineRoutine updates follow turns of work or a step's end, not minutes

3. Send a routine update only when turns of work have passed since the previous routine update or a step of the change has ended, **and** one of these is 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.

tjcagesprogress-check/SKILL.md

4. Report a new blocker immediately when the user can act on it. Report completion immediately.

5. Never repeat an unchanged bar or send a routine “still working” message.

greenlineUpdates stay in conversation; no progress file or tracker is created

The update is conversation and nothing else: milestone evidence belongs to the change record and its checks, and no parallel progress file or 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:

tjcagesprogress-check/SKILL.md

`Performance rollout [██████████████████░░] 90%`

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 that interfaces may label or make copyable.

- Replace the label with a short task-specific label.

- Use 20 cells: `█` completed and `░` remaining.

- Round down to the nearest 5% unless completion evidence supports 100%.

- Show only the overall bar unless the user requests subtask bars.

- In multi-agent work, only the coordinator shows the overall bar.

- The progress line is the final content in the update. End immediately after it with no note, recap, or closer.

greenlineA lasting reporting rule goes in the repository, never a machine-global file

## Persist a preference

greenlinePreferences last the task; a lasting rule needs the owner's request

The greenline CLI installs this skill; there is no global installation step 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 the work guide defines. The next context reads that rule without demanding a second confirmation.

greenlineCloses on nothing durable, applied during long work or a cadence request

Durable output: none. Applied on its own cadence while long work runs, and the moment the owner asks to change how or how often you report, before any preference is saved anywhere.

SKILL.md as installed, byte for byte SHA-256 24f5dcff453c66ac19440c75592dc8943ded60eb09b4e65f662e96a4e052a4d5

EXAMPLES.md

about 520 tokens
  • tjcages
  • greenline
tjcagesprogress-check/EXAMPLES.md

# Progress Check examples

## Useful milestone update

1. The schema migration passed its apply-twice test.

2. API integration is active.

3. Next: verify the deployed read path.

`API rollout [████████████░░░░░░░░] 60%`

## Actionable blocker

1. Packaging and validation are complete.

2. Publishing is blocked because the registry session is not authenticated.

3. Next: authorize the registry, then rerun the publish command.

`Skill release [████████████████░░░░] 80%`

## Completion

1. The package is published and installable from both catalog routes.

`Skill release [████████████████████] 100%`

## Updates to suppress

Do not send any of these when no material state changed:

- “Still working.”

- “The tests are still running.”

- The same percentage and bar as the prior update.

- Separate bars for every subagent or batch.

## Dogfood log

greenlinegreenline installs this skill, so the global install mode goes

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.

tjcagesprogress-check/EXAMPLES.md

### 2026-08-25 — Codex and Claude Code install

- Targets: clean temporary Codex and Claude Code projects.

- Command: local `npx skills add` with `--copy` and each agent identifier.

- Friction: the first run skipped all shared references because their relative symlinks pointed one directory too high.

- Fix: use `../../shared/*.md`, then require installed-reference read checks in both target directories before accepting a dogfood run.

- Behavior friction: Codex dropped the requested fence, while Claude added a disclaimer after the bar. Fenced blocks exposed renderer chrome, and the 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 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 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.

METHODOLOGY.md

about 1,100 tokens
  • tjcages
  • greenline
tjcagesprogress-check/METHODOLOGY.md

# Progress Check methodology

**Version:** 1.0.1 — 2026-08-25

## 0. Core thesis

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 whether intervention is needed. Reassurance without changed evidence is noise.

## 1. When progress reporting applies

Use this method when work is expected to exceed 15 minutes, spans multiple milestones, coordinates multiple agents, or has meaningful blockers between start and completion. Skip it for short answers, one-command changes, or work whose only honest states are started and finished.

## 2. Establish the denominator

Before showing a percentage, identify 3–7 observable milestones. A milestone is complete only when its evidence exists: a passing check, committed artifact, accepted review, accessible deployment, or another task-specific gate.

Weight milestones by expected work and risk. Do not divide them equally when one milestone clearly dominates the task. Never derive progress from elapsed time, tool-call count, token use, or confidence.

Rebaseline only when scope materially changes. State the scope change in the same update; do not silently move the percentage backward or inflate it.

## 3. Cadence

Send one baseline update after the scope and denominator are understood.

Routine updates require both:

greenlineCounts turns since the last update, never estimated elapsed time

1. Turns of work since the previous routine update, or the end of a step of the change; never an estimate of elapsed time.

tjcagesprogress-check/METHODOLOGY.md

2. A completed milestone, at least 10 percentage points of verified progress, or a materially different next action.

New actionable blockers and final completion bypass the turn gate. Waiting, unchanged checks, agent polling, and repeated test runs do not.

## 4. Format

Each update contains no more than three concise items:

1. What completed, with concrete evidence.

2. What is active now.

3. The next step or blocker.

End with one 20-cell overall bar styled as inline code on its own line:

`Performance rollout [██████████████████░░] 90%`

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 code block that interfaces may label or make copyable.

Use `█` for completed cells and `░` for remaining cells. Each cell represents 5%. Round down to avoid overstating progress. Use 100% only when every required gate is complete.

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 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 note, recap, disclaimer, or closer beneath it.

greenlineA lasting reporting rule goes in the repository, never a machine-global file

## 5. Installation and persistence

greenlineNo global install step here; lasting rules go in the repository

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 the work guide defines; the next context reads it without a second confirmation.

tjcagesprogress-check/METHODOLOGY.md

## 6. Anti-patterns

| Pattern | Failure | Correction |

|---|---|---|

| Activity percentage | Measures motion, not completion | Tie each increase to evidence |

| Update spam | Hides meaningful changes | Apply both cadence gates |

| Frozen repeated bar | Pretends to inform | Stay silent until state changes |

| Batch bar collection | Makes the user aggregate status | Show one overall bar |

| Optimistic rounding | Overstates readiness | Round down to 5% |

| Instant 90% | Leaves the risky tail invisible | Weight validation and delivery gates |

| Silent rebaseline | Breaks trust in the denominator | Name the scope change |

## 7. Readiness rubric

greenlineKeeps no readiness score; reports acceptance items and recorded checks

No readiness score is kept here. Report observable milestone evidence and its limits: the change's acceptance items and the checks the change recorded for it. Global persistence is not a criterion, since the greenline CLI installs this skill.

tjcagesprogress-check/METHODOLOGY.md

## 8. Open gaps

greenlineRe-anchors the update gate from thirty minutes to turns of work

- Revisit the turn-and-step cadence and the 10-point default only after real usage shows that they are too sparse or still noisy.

RESPONSE.md

about 200 tokens
  • tjcages
tjcagesprogress-check/RESPONSE.md

# Progress Check responses

## Rules

1. Lead with changed state, not an announcement that work continues.

2. Use at most three numbered items: completed, current, and next or blocked.

3. Include concrete evidence for completed work.

4. Keep one overall progress bar at the end.

5. Do not post when the percentage and material state are unchanged.

6. Report blockers matter-of-factly with the action needed to clear them.

7. Report completion immediately and use 100% only after every gate passes.

8. Do not add a closing pleasantry or ask a generic follow-up question.

## Example

1. The API contract and migration now pass their focused checks.

2. Deployment verification is active.

3. Next: confirm the preview route returns the new response shape.

`Performance rollout [██████████████████░░] 90%`

references/greenline.md

about 100 tokens
  • greenline
greenlineOpens the skill's mechanics page, read with SKILL.md

# Progress check: the practice's mechanics

This page holds where progress-check's work lands in the workspace and the commands it runs, which `SKILL.md` names by their nouns. Read it with `SKILL.md` when the work lands in the workspace.

greenlineThe recorder and the work guide's ruling format

## Where its work lands

The checks a change recorded are those `greenline check` wrote. A house ruling follows the format the work guide, `.greenline/WORK.md`, defines.

The edits

Red is upstream's text; green is what greenline shipped in its place.

What the edit kinds mean
method
changes what the method does, under a recorded ruling
correction
fixes an error
scope
fits the text to this skill
pointer
re-points a reference
smaller edits
rename, relocate or adjust tool details

  1. Edit 1 pointer SKILL.md:49

    Upstream: Keep each update to at most three short items: completed evidence, current work, and next step or blocker.

    Shipped: Keep each update to at most three short items: completed evidence, current work, and next step or blocker.

    No readiness score: acceptance items and recorded checks measure readiness

    Full reason

    Milestone evidence belongs to the change's acceptance items and the checks greenline check recorded for it, 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 change's acceptance and checks are the readiness measure.

  2. Edit 2 pointer SKILL.md:50

    Upstream: End with exactly one overall bar styled as inline code on its own line:

    Shipped: End with exactly one overall bar styled as inline code on its own line:

    No readiness score: acceptance items and recorded checks measure readiness

    Full reason

    Milestone evidence belongs to the change's acceptance items and the checks greenline check recorded for it, 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 change's acceptance and checks are the readiness measure.

1 smaller edit

Renames, locations and tool details, each with its reason.

  1. Edit 3 tool details METHODOLOGY.md:42

    Upstream: New actionable blockers and final completion bypass the time gate.

    Shipped: New actionable blockers and final completion bypass the turn gate.

    Re-anchors the update gate from thirty minutes to turns of work

    Full reason

    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 the end of a step of the change, 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-step cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode.

What greenline wrote

The full reason for every passage greenline wrote, in the order of the text.

  1. SKILL.md:8 scope

    The opening paragraph in the habit's own voice: the situations its block rows key it by, long work running between replies (a change with several milestones, a build of many slices, delegated agents one after another) and the owner asking to change how or how often progress is reported; never a short answer or two-state work, on a cadence that is judgment; that it writes no record of its own, the evidence being the change record's and its checks'; and that an estimated clock is never claimed. Re-cut at S18b onto the change record, in place of a ticket held at implementing and its execution account. Since J-93 S2 the front names greenline's homes and commands by their nouns, their paths and commands on the skill's references page.

  2. SKILL.md:21 pointer

    The front points at the skill's references page, where greenline's paths and commands for it stand since J-93 S2, so the front holds the method alone.

  3. SKILL.md:29 relocate

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

  4. SKILL.md:35 pointer

    Milestone evidence belongs to the change's acceptance items and the checks greenline check recorded for it, 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). Re-cut at S18b onto the change record, in place of the owning ticket and its execution account.

  5. SKILL.md:38 tool details

    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 the end of a step of the change, 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-step cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode. Re-cut at S18b: the end of a step replaces a ticket's status transition.

    Credits: tjcages

  6. SKILL.md:47 pointer

    Milestone evidence belongs to the change record and its checks, so the update is conversation with no parallel progress file or tracker. Re-cut at S18b onto the change record, in place of the owning ticket and its execution account.

  7. SKILL.md:67 relocate

    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.

  8. SKILL.md:69 relocate

    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)) Since J-93 S2 the front names greenline's homes and commands by their nouns, their paths and commands on the skill's references page.

  9. SKILL.md:77 tool details

    The habit's closing line: Durable output none, applied on its own cadence while long work runs and the moment the owner asks to change the cadence, before any preference is saved. Re-cut at S18b in the habit's words, in place of the worker moment.

  10. EXAMPLES.md:36 tool details

    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 while long work runs and the moment the user asks to change the cadence, before any preference is saved).

  11. METHODOLOGY.md:37 tool details

    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 to turns of work since the previous routine update or the end of a step of the change, an estimated elapsed time never used to open the gate. Re-cut at S18b: the end of a step replaces a ticket's status transition.

  12. METHODOLOGY.md:72 relocate

    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.

  13. METHODOLOGY.md:74 tool details

    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 while long work runs 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)) Since J-93 S2 the front names greenline's homes and commands by their nouns, their paths and commands on the skill's references page.

  14. METHODOLOGY.md:96 pointer

    Milestone evidence is the change's acceptance items and the checks greenline check recorded for it, so section 7 keeps no 0/1/2 readiness score (its sixth item scored a global persistence greenline does not perform). Re-cut at S18b onto the change record, in place of the owning ticket and the witnesses of its execution account. Since J-93 S2 the front names greenline's homes and commands by their nouns, their paths and commands on the skill's references page.

  15. METHODOLOGY.md:103 tool details

    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 the end of a step of the change, 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-step cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode.

    Credits: tjcages

  16. references/greenline.md:1 scope

    The skill's references page opens: greenline's mechanics for the skill, the paths and commands its front names by their nouns, held apart from the upstream prose since J-93 S2.

  17. references/greenline.md:5 relocate

    progress-check's mechanics: the recorder and the work guide whose format a house ruling follows, held apart since J-93 S2.

What it left out

tjcages

tjcages, progress-check/SKILL.md: 13 of 38 sentences left out
  1. **Install globally:** only when the user asks to persist this behavior across agents or projects. left out: 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))
  2. 4 sentences taken
  3. Send a routine update only when at least 30 minutes have passed **and** one of these is true: a milestone completed, verified progress rose by at least 10 percentage points, or the next action materially changed. left out: 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 the end of a step of the change, 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-step cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode. replaced by line 38 of SKILL.md
  4. 15 sentences taken
  5. ## Install globally left out: 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.
  6. Prefer installing this skill globally through the available Agent Skills CLI so one source works across supported agents: left out: 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))
  7. ```bash npx skills add tjcages/skills --skill progress-check -g --agent '*' ```
  8. If the user explicitly requests native always-on instructions instead:
  9. Detect each installed agent's documented user-level instruction mechanism.
  10. Merge the progress rules without overwriting existing instructions.
  11. Make the change idempotent and avoid repository-level instruction files.
  12. If an agent supports only UI-managed rules, give the exact settings location and a copy-ready block instead of inventing a file path.
  13. Verify each changed target and state whether a new session is required.
  14. Do not claim an unsupported agent was configured.
  15. Do not modify unrelated preferences. 9 sentences left out: 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 while long work runs and the moment the user asks to change the cadence, before any preference is saved).

tjcages, progress-check/EXAMPLES.md: all 31 sentences taken

tjcages, progress-check/METHODOLOGY.md: 18 of 73 sentences left out
  1. At least 30 minutes since the previous routine update. left out: 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 the end of a step of the change, 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-step cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode.
  2. 23 sentences taken
  3. ## 5. Global installation left out: 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.
  4. The portable default is a global Agent Skills installation: left out: 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 while long work runs 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))
  5. ```bash npx skills add tjcages/skills --skill progress-check -g --agent '*' ```
  6. This lets compatible agents discover the same skill without maintaining copies of the rules in several products.
  7. If the user explicitly wants native always-on rules, detect each product's documented user-level mechanism at execution time.
  8. Preserve existing content, add one identifiable section, make repeated runs idempotent, and avoid project files when a user-global mechanism exists.
  9. For UI-only products, report the exact settings location and provide the block; do not invent a filesystem path. 5 sentences left out: 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 while long work runs and the moment the user asks to change the cadence, before any preference is saved).
  10. 11 sentences taken
  11. Score each item 0, 1, or 2.
  12. A usable implementation scores at least 10/12 with no zero.
  13. Eligibility: the method activates only for qualifying work.
  14. Denominator: milestones are observable and evidence-based.
  15. Honesty: percentages follow completed work and round down.
  16. Cadence: routine updates satisfy both gates.
  17. Clarity: one bar and at most three concise items.
  18. Persistence: global installation preserves unrelated configuration. 8 sentences left out: Milestone evidence belongs to the change's acceptance items and the checks greenline check recorded for it, 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 change's acceptance and checks are the readiness measure.
  19. 1 sentence taken
  20. Validate native always-on installation against new agent products as their documented global configuration mechanisms change. left out: 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 the end of a step of the change, 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-step cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode.
  21. Revisit the 30-minute and 10-point defaults only after real usage shows that they are too sparse or still noisy. left out: 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 the end of a step of the change, 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-step cadence in place of the 30-minute default and drops the global-install gap that went with the removed mode. replaced by line 103 of METHODOLOGY.md

tjcages, progress-check/RESPONSE.md: all 15 sentences taken

The ledger entry

greenline's ledger logs how each skill was made and changed, with a reason for each entry.

2026-10-19 2026-10-19-progress-check-front-and-references

progress-check's paths and commands move to a references page

The front names greenline's homes and commands by their nouns and points at a references page, which holds their paths and commands (J-93 S2).

Authorised by
2026-10-18 The operator's words of 2026-10-18 on the redesign (N-56, items 2 and 7), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and, on the ingest procedures, "we wanna have there prose .. what we don't wanna have is there artefact system and fit them to use ours"; and J-93 S2's finalise words of 2026-10-19, "Fast route, merged slices, parallel jobs (Recommended)": a skill's front is the upstream prose its recipe cuts, and its mechanics, where its work lands, its section's form, its depths at each mode and its commands, stand on its references page
Pages it touched
METHODOLOGY.md, SKILL.md, references/greenline.md
Rulings, R1 to R4
  1. the operator's rulings of 2026-10-04, "cool then lock everything in": every change in every mode has one record its steps write, which replaced the tickets' execution accounts, and a habit writes none of its own
  2. R22 of 2026-10-08, the re-cut brief accepted as recommended ("yes amend, with one change"): the names of the roster table and the trial names stand, and show-me stays implicit
  3. J-59, on the operator's words of 2026-10-09 ('okay then implement all of this'): a gist of at most twelve words on every account whose reason is stated; no text, measure or method changes
  4. The operator's words of 2026-10-18 on the redesign (N-56, items 2 and 7), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and, on the ingest procedures, "we wanna have there prose .. what we don't wanna have is there artefact system and fit them to use ours"; and J-93 S2's finalise words of 2026-10-19, "Fast route, merged slices, parallel jobs (Recommended)": a skill's front is the upstream prose its recipe cuts, and its mechanics, where its work lands, its section's form, its depths at each mode and its commands, stand on its references page
4 earlier entries

  1. 2026-10-09 2026-10-09-progress-check-gists

    Every account gets a short gist for the website

  2. 2026-10-08 2026-10-08-progress-check-recut

    Re-cut on the change record and its steps

    Pages it touched: METHODOLOGY.md, SKILL.md

  3. 2026-10-07 2026-10-07-progress-check-refresh

    Upstream unchanged; the snapshot is byte-identical

  4. 2026-10-07 2026-10-07-progress-check-recipe

    Moves to its recipe byte for byte, nothing changed