Habit, a trial · installs only where you enable it

pr-writing

about 1,700 tokens

pr-writing as it installs, each line coloured by where its words came from.

  • 2 files
  • 0 edits
  • 129 sentences left out
  • 4 sources
  • last changed 2026-10-19
  • trial

The text

SKILL.md

about 1,500 tokens
  • tjcages
  • Matt Pocock's skills
  • Cursor's team kit
  • HumanLayer
  • greenline

---

name: "pr-writing"

description: "Write or review a commit message, a PR title or a PR body that says what changed and why: the diff read first, a subject under 50 characters in the imperative, a body of what and why, never how, and a PR body of what changed, why, how to verify, the risk and the notes, linking the change record. Use when a commit message, a PR title or a PR body is about to be written or reviewed."

---

tjcagespr-writing/SKILL.md

# PR writing

greenlineOpens the trial habit: it writes, and the landing is close's

pr-writing is a trial habit, installed only where the workspace's `trials` names it, for the moment a commit message, a PR title or a PR body is about to be written or reviewed, at whatever step the work is in, most often build and close. It writes no record of its own: the change record holds the why, and a PR body is a projection of that record that links it. Pushing the branch and opening the PR are the landing the close step offers, done only on the owner's word as AGENTS.md says, and editing a PR on the forge waits for that word too; this habit keeps the writing. The sentences themselves are the prose habit's to cut, and the visual a PR body carries is show-me's.

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.

tjcagespr-writing/SKILL.md

**These are requirements, not preferences.** A message that breaks one gets rewritten, not shipped.

## Operating order

### 1. Read the diff first

greenlineReads the staged diff, or the change's commits found by their trailertjcagespr-writing/SKILL.md

Read `git diff --staged --stat` for a commit, and for a PR the change's commits, which the change's status lists by their trailer; then the real hunks. You cannot state *why* from a file list.

greenlineHeadings drop upstream's section marks into a METHODOLOGY.md not carried

### 2. Write the subject

tjcagespr-writing/SKILL.md

Under 50 characters. Capitalized. No period. Imperative mood.

Test every subject: **"If applied, this commit will ___."** If the sentence breaks, the subject is wrong.

```

Add retry guard to the token refresh path

```

Banned first words: `Added`, `Adding`, `Adds`, `Fixed`, `Fixes`, `Updated`, `Changes`, `WIP`, `Misc`, `Various`. Banned anywhere in a subject: emoji, ticket IDs, `[tags]`, trailing `.`.

greenlineThe repository's own commit convention governs the subject; none is added

Where the repository keeps a commit convention of its own, such as a type prefix or a tracker's key, it governs the subject's form, and these rules apply only where it is silent; where it keeps none, add none.

greenlineHeadings drop upstream's section marks into a METHODOLOGY.md not carried

### 3. Blank line, then body wrapped at 72

tjcagespr-writing/SKILL.md

No exceptions — `rebase`, `format-patch`, and `git log` all break without the blank line, and the default pager does not wrap.

greenlineHeadings drop upstream's section marks into a METHODOLOGY.md not carried

### 4. Body says what and why, never how

tjcagespr-writing/SKILL.md

The diff already says how. The body says: the problem that existed, why this solution, what you rejected, what it costs.

greenlineEvery commit of a change ends with the change's trailer

The last line of every commit of a change is its trailer, as AGENTS.md says.

greenlineStep 5 hands the sentences to the prose habit

### 5. Apply the prose habit

Every sentence, in commits and PR bodies both, is prose: the prose habit's catalog of tells and its measurement in place of the adjective apply, and a PR body is a briefing a reviewer reads in under a minute.

greenlineHeadings drop upstream's section marks into a METHODOLOGY.md not carried

### 6. Fill the PR body template

greenlineThe template gains a notes field and links the change record last

```markdown

## What changed

<1 to 3 sentences. Active voice, present tense.>

## Why

<The problem. The reason for this solution. What you rejected.>

## How to verify

1. <One action per step.>

2. <Expected result, stated concretely.>

## Risk

<What breaks if this is wrong. How to roll it back.>

## Special things to note

- <A reviewer warning, a migration, a deliberate omission, or None.>

Change record: `.greenline/ledger/<id>.md`

```

tjcagespr-writing/SKILL.md

Drop a section only when it is genuinely empty, and say so: `Risk: none — docs only.`

greenlineThe PR body projects and links the change record, with show-me's visual

The body is a projection of the change record, never a second home for it: What changed and Why come from the record's sections, How to verify from its verify section and the checks the change recorded, and the last line links the record. Where the change alters a shape, a flow, a hierarchy or a file layout, What changed carries the smallest visual the show-me habit gives for it, after its sentences.

HumanLayervisual-pr/SKILL.md

- Keep **Special things to note** to 1-3 bullets. Prioritize reviewer warnings, migrations, compatibility constraints, deliberate omissions, or surprising decisions. Write `- None.` when there are no special considerations.

greenlineThe evidence fills the template's How to verify

**How to verify** carries the evidence:

Matt Pocock's skillspr/SKILL.md

Concrete evidence that the change works. Show a before and after.

Screenshots are S-tier - when the environment is set up for it and the change is visual.

Execution-based evidence is A-tier. Test results, console output. Show the exact test that now fails and passes, using pseudocode.

greenlineThe merge danger fills the template's Risk

**Risk** names the merge danger:

Matt Pocock's skillspr/SKILL.md

Describe whether it's a one-way or two-way door. You can walk back through two-way doors, but not one-way doors. A PR that is cheap to roll back is lower risk. Changes that involve destructive actions or hard-to-reverse decisions are one-way doors.

The blast radius is the potential impact or scope of the changes introduced by this PR. Consider all possibilities. Examples are layout shift, breakages for consumers, mobile responsiveness, etc.

greenlineReviewer guidance joins as step 7 in place of the lint gate

### 7. Make it easy to review

Cursor's team kitmake-pr-easy-to-review/SKILL.md

When code behavior should stay untouched, prefer PR description and review notes:

- Add a TL;DR that matches the actual diff.

- Separate core files from generated or mechanical files.

- Call out risky behavior changes, migration order, rollout plan, and test coverage.

- Link issue trackers, dashboards, or design docs when they explain intent.

greenlineA reviewability fix edits the body and notes, never a commit

A reviewability fix changes the PR body and the review notes, never a commit: rewriting a change's history is not this habit's. The tree the reviewer reads, `git rev-parse HEAD^{tree}`, stays the one the change's checks ran on; never offer a PR whose tree changed unintentionally.

greenlineThe push and PR are close's landing; this habit offers the edit

### 8. Leave the push and the PR to the landing

Writing the messages and the body is this habit's work. Pushing the branch and opening the PR are the close step's landing, offered there in one line and never here. Editing the PR's body on the forge is outward too: offer it, and do it on the owner's word.

tjcagespr-writing/SKILL.md

## Non-negotiables

1. Never `git commit -m` for a change that needs a body. Use a message file or a heredoc.

2. The PR title obeys the subject rules exactly — 50 characters, imperative, no period.

3. A squash-merge message is a commit message. Same rules.

4. Never let a template heading survive with placeholder text under it.

5. If you cannot state the *why*, you do not understand the change yet. Go read the diff again.

Cursor's team kitmake-pr-easy-to-review/SKILL.md

## Guardrails

- Never hide meaningful behavior changes inside "cleanup".

- Do not bypass hooks unless the user explicitly asks.

- If the PR is too large to make reviewable with notes, recommend splitting instead of polishing around the problem.

SKILL.md as installed, byte for byte SHA-256 965859ec55dfa49eb25e3c92878dc3b10fe5521f00b8d23ba81637d33432dd87

references/greenline.md

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

# PR writing: the practice's mechanics

This page holds where pr-writing'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 commit listing, the trailer's form and the recorder

## Where its work lands

`greenline status --change <id>` lists a change's commits by their trailer, `Greenline-Change: <id>`, the last line of every commit of the change; the checks the change recorded are those `greenline check` wrote.

What greenline wrote

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

  1. SKILL.md:8 scope

    One opening paragraph in the habit's own voice: the situation its block row keys it by, that it is a trial installed only where trials names it, that it writes no record and the PR body projects the change record, that the push and the PR are the close step's landing on the owner's word while this habit keeps the writing, and the habits beside it.

  2. SKILL.md:10 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:18 pointer

    The diff read first is the staged one for a commit and the change's commits for a PR, which greenline finds by their trailer as a set, never a branch's range against main. 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.

    Credits: tjcages

  4. SKILL.md:20 pointer

    A heading without upstream's section mark, which points into METHODOLOGY.md, a page the habit does not carry: the operating order is the whole method here.

    Credits: tjcages

  5. SKILL.md:32 method

    The repository's own commit convention decides, neither source's: pr-writing's conventional commits only within 50 characters and another source's prefixes alike (contradiction 28). R1

  6. SKILL.md:34 pointer

    A heading without upstream's section mark, which points into METHODOLOGY.md, a page the habit does not carry: the operating order is the whole method here.

    Credits: tjcages

  7. SKILL.md:38 pointer

    A heading without upstream's section mark, which points into METHODOLOGY.md, a page the habit does not carry: the operating order is the whole method here.

    Credits: tjcages

  8. SKILL.md:42 scope

    The commit message carries the change's trailer, which the block requires of every commit and the build step writes on its last line. 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:44 scope

    The language contract duplicates the prose habit, which owns the sentences of a commit message and a PR description; the step keeps its number and names the habit.

    Credits: tjcages

  10. SKILL.md:48 pointer

    A heading without upstream's section mark, which points into METHODOLOGY.md, a page the habit does not carry: the operating order is the whole method here.

    Credits: tjcages

  11. SKILL.md:50 method

    The template keeps pr-writing's order and fields, adds visual-pr's notes field, and ends on the link to the change record in place of a tracker's closing line, since the PR body is a projection of the record. R1

    Credits: tjcages and HumanLayer

  12. SKILL.md:72 method

    The PR body projects the change record and links it, in pr-writing's order, with a visual from the show-me habit where the change alters a shape, in place of the summary menu that leads mattpocock's body (contradiction 27). 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. R2

    Credits: tjcages and Matt Pocock's skills

  13. SKILL.md:76 scope

    A bridge: mattpocock's evidence tier fills the template's How to verify.

  14. SKILL.md:84 scope

    A bridge: mattpocock's merge danger fills the template's Risk.

  15. SKILL.md:90 scope

    The reviewer guidance of make-pr-easy-to-review joins the operating order as its seventh step, in place of the lint gate the habit does not carry.

  16. SKILL.md:99 method

    The tree-identity line of make-pr-easy-to-review, in greenline's words for a fix that rewrites no history: the fix touches the body and the notes alone, and the tree stays the one the checks ran on. R1

    Credits: Cursor's team kit

  17. SKILL.md:101 method

    A PR is opened only on the owner's word, since it is outward, in place of the lint gate that ran before gh pr create; the push and the PR are the close step's landing, offered only there as the block states, and this habit offers only the forge edit beside its writing. R3

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

  19. references/greenline.md:5 relocate

    pr-writing's mechanics: the command that lists a change's commits, the trailer's form and the recorder, held apart since J-93 S2.

What it left out

tjcages

tjcages, pr-writing/SKILL.md: 30 of 58 sentences left out
  1. Full rules: [METHODOLOGY.md](./METHODOLOGY.md).
  2. Before/after: [EXAMPLES.md](./EXAMPLES.md).
  3. Chat shape: [RESPONSE.md](./RESPONSE.md). 3 sentences left out: The pointers to METHODOLOGY.md, EXAMPLES.md and RESPONSE.md are dropped: the habit carries the operating order alone, its language contract duplicating the prose habit and its examples and chat shape left upstream.
  4. 4 sentences taken
  5. `git diff main...HEAD --stat` then the real hunks. left out: The diff command reads a branch's range against main; greenline reads the staged diff for a commit and the change's commits, found by their trailer, for a PR. replaced by line 18 of SKILL.md
  6. 1 sentence taken
  7. ### 2. Write the subject (§1) left out: A heading without upstream's section mark, which points into METHODOLOGY.md, a page the habit does not carry: the operating order is the whole method here. replaced by line 20 of SKILL.md
  8. 9 sentences taken
  9. ### 3. Blank line, then body wrapped at 72 (§1) left out: A heading without upstream's section mark, which points into METHODOLOGY.md, a page the habit does not carry: the operating order is the whole method here. replaced by line 34 of SKILL.md
  10. 1 sentence taken
  11. ### 4. Body says what and why, never how (§2) left out: A heading without upstream's section mark, which points into METHODOLOGY.md, a page the habit does not carry: the operating order is the whole method here. replaced by line 38 of SKILL.md
  12. 2 sentences taken
  13. ### 5. Apply the language contract (§3–4)
  14. Every sentence, in commits and PR bodies both:
  15. | Rule | Source | Test |
  16. |---|---|---|
  17. | Active voice, present tense | Google | Who does it? Name them. |
  18. | ≤20 words per instruction, ≤25 per statement | STE | Count it. |
  19. | One instruction per sentence | STE | Two verbs → two sentences. |
  20. | One word, one meaning, everywhere | STE | Same thing, same noun. No synonyms. |
  21. | Keep articles (`the`, `a`) | STE | Telegraph style is a defect. |
  22. | ≤3 words per noun cluster | STE | `user account creation failure` → rewrite. |
  23. | Second person `you`, never `we` | Google | `we refactored` → `this change refactors`. |
  24. | Conditions before instructions | Google | `If X, do Y` — never `Do Y if X`. |
  25. | Sentence case headings, serial commas | Google | — |
  26. | Code font for identifiers, paths, flags | Google | — |
  27. | ISO dates (`2026-08-12`) | Google | Never `08/12/26`. |
  28. Banned words: `simply`, `just`, `easily`, `obviously`, `please`, `leverage`, `utilize`, `in order to`, `various improvements`, `under the hood`, `out of the box`, `low-hanging fruit`.
  29. Banned opener: `This PR ...` — do not pre-announce. 17 sentences left out: The language contract duplicates the prose habit, which owns these sentences. replaced by line 44 of SKILL.md
  30. ### 6. Fill the PR body template (§5) left out: A heading without upstream's section mark, which points into METHODOLOGY.md, a page the habit does not carry: the operating order is the whole method here. replaced by line 48 of SKILL.md
  31. ```markdown ## What changed <1–3 sentences. Active voice, present tense.> ## Why <The problem. The reason for this solution. What you rejected.> ## How to verify 1. <One action per step.> 2. <Expected result, stated concretely.> ## Risk <What breaks if this is wrong. How to roll it back.> Closes ABC-123 ``` left out: The template gains visual-pr's notes field and links the change record in place of the tracker's closing line. R1 replaced by line 50 of SKILL.md
  32. 1 sentence taken
  33. ### 7. Gate before you push
  34. ```bash bash scripts/pr-lint.sh ```
  35. Exit non-zero → fix the message.
  36. Do not run `gh pr create` on a failing message. 4 sentences left out: The lint gate runs a script the snapshot does not hold and gates gh pr create; opening a PR is outward and waits for the owner's word. R1 replaced by line 101 of SKILL.md

HumanLayer

HumanLayer, visual-pr/SKILL.md: 40 of 43 sentences left out
  1. # Describe a Pull Request
  2. Create or update the pull request for the current task with a concise description that helps a reviewer understand why the change exists and the shape of the implementation.
  3. ## Workflow
  4. Read the description template:
  5. `Read({SKILLBASE}/references/pr_description_template.md)`
  6. Identify or create the pull request:
  7. Check the current branch for a PR with `gh pr view --json url,number,title,state,baseRefName,headRefName 2>/dev/null`.
  8. If no PR exists, inspect `git status --short --branch` and the commits on the current branch.
  9. Commit task-related changes when needed, push the branch with an upstream, and create a PR for it.
  10. Follow the repository's git safety protocol.
  11. Ask the user to select a PR only when the current branch has no relevant work and there is no safe current-branch PR to create.
  12. Gather only the context needed to explain the change:
  13. Read the ticket and any relevant task artifacts.
  14. Read the complete PR diff and enough surrounding code to understand behavior and ownership.
  15. Use `gh pr view` to collect PR metadata and changed files.
  16. Read `{SKILLBASE}/references/show-me.md` for the visual-outline conventions used in the PR body.
  17. Write the PR description using the template:
  18. Keep **Why the change** to exactly one sentence. 18 sentences left out: The workflow reads a template through a harness's Read call, creates and pushes the PR through gh and reads a ticket; only its notes field is taken, and opening a PR waits for the owner's word.
  19. 3 sentences taken
  20. Make **Change outline** a compact, `/show-me`-inspired structural view rather than prose or a file-by-file changelog.
  21. Include only the views that help explain this PR:
  22. SQL table and endpoint contract changes, plus pseudocode for business logic.
  23. key data structure / type changes
  24. A shallow file tree showing changed responsibilities.
  25. React component tree changes, including important hooks, state, and package boundaries.
  26. Call-tree, call-stack, control-flow, or data-flow changes.
  27. Prefer `diff` blocks when showing changes to an existing shape.
  28. Show the complete target shape when most of it is new or diff notation would obscure ownership or order.
  29. Keep each view focused on what a reviewer needs.
  30. Omit categories that did not change. 11 sentences left out: The change outline repeats the show-me habit, whose visual the PR body takes where the change alters a shape. replaced by line 72 of SKILL.md
  31. optionaL: if you are aware of a ticket id/url, a humanlayer task url, or related plan/document urls, or other relevant links, include them in the header, otherwise omit the header
  32. Save and publish the description:
  33. Use `.humanlayer/tasks/{task-slug}/pr-description.md` when the task directory exists; otherwise use `.humanlayer/tasks/pr-{number}/description.md`.
  34. Update the PR with `gh pr edit {number} --body-file {output-path}`.
  35. Confirm the update succeeded.
  36. Report completion:
  37. Read `{SKILLBASE}/references/describe_pr_final_answer.md`.
  38. Respond using that final answer template with the PR URL, saved description URL, and concise list of changed files. 8 sentences left out: The header links, the .humanlayer task directory, gh pr edit and the final-answer template are the vendor's homes and tools; the PR body links the change record.
  39. Always read and follow `{SKILLBASE}/references/pr_description_template.md`.
  40. Do not expand the PR body beyond that template.
  41. Write as one human talking to another: avoid jargon and slang, and use simple, coherent, concise language. 3 sentences left out: The template and the plain-language rule are pr-writing's template and the prose habit's.

Matt Pocock's skills

Matt Pocock's skills, pr/SKILL.md: 36 of 49 sentences left out
  1. Use this template for writing the PR body:
  2. ```markdown ## Summary <diagram, diff-sketch, or tree> ## Evidence - **Before:** <screenshot/output/failing test run> **After:** <screenshot/output/passing test run> ## Merge Danger **Door:** <one-way or two-way> <optional: description> **Blast Radius:** <one-word description> <optional: potential ramifications of merge> ``` 2 sentences left out: The template that leads with a summary visual gives way to pr-writing's order, the visual from the show-me habit where the change alters a shape (contradiction 27). R1 replaced by line 72 of SKILL.md
  3. ## Sections
  4. Skip all preambles and keep prose brief.
  5. Use the user's domain language from `GLOSSARY.md`. 3 sentences left out: Brief prose and the glossary's words are the prose habit's, which owns the sentences.
  6. ### Summary
  7. Pick the smallest view that makes the key point clear.
  8. Show logic or an algorithm as pseudocode:
  9. ```text on(save) if content is unchanged return cached result write new content return fresh result ```
  10. Show runtime control flow as a call tree:
  11. ```text submitForm createSession persistPrompt launchAgent navigateToSession ```
  12. Show UI structure as a component tree, including state and module boundaries that matter:
  13. ```text <SessionPage> (apps/example/src/routes/session.tsx) useSessionEvents() <SessionToolbar> <RunSkillButton> (packages/ui) ```
  14. Show file responsibility or a broad refactor as a shallow file tree:
  15. ```text src/ ├── commands/ # parses user actions ├── sessions/ # owns session state └── transport/ # sends API requests ```
  16. Show component interaction, control flow, or data flow with Mermaid:
  17. ```mermaid sequenceDiagram participant User participant UI participant Daemon User->>UI: choose command UI->>Daemon: send expanded prompt Daemon-->>UI: stream result ```
  18. Use `diff` when the point is what changes and the surrounding shape already exists.
  19. Match the diff shape to the topic.
  20. For a component change:
  21. ```diff <SessionPage> useSessionEvents() <SessionToolbar> + <RunSkillButton /> <SessionTimeline> + <SkillResultCard /> ```
  22. For a file-layout change:
  23. ```diff src/ ├── commands/ +│ └── show-me.ts # expands the slash command ├── sessions/ -└── transport.ts +└── transport/ + ├── client.ts + └── stream.ts ```
  24. For a call-tree or call-stack change:
  25. ```diff submitForm createSession persistPrompt + expandSkillMention launchAgent - navigateToSession + navigateToSession + subscribeToEvents ```
  26. For a state or control-flow change:
  27. ```diff on(save) - write content + if content is unchanged + return cached result + write new content + invalidate cache ```
  28. Show the whole block when most of it is new, when omitted context would hide ownership or order, or when the user needs a copyable target shape:
  29. ```ts function expandSkill(command: string): string { const skillName = command.slice(1); return `use the ${skillName} skill`; } ```
  30. #### Guidance
  31. Place each visual next to the short text it supports.
  32. Keep only the calls, files, props, states, and boundaries needed to answer the user's current question or the options to resolve the current discussion point.
  33. You may use one of these, you may use several, it is unlikely you will use all of them.
  34. Use your judgement and don't overwhelm the user. 29 sentences left out: The summary menu repeats the show-me habit almost word for word, as its credits say; the PR body takes its visual from show-me. replaced by line 72 of SKILL.md
  35. ### Evidence left out: The heading gives way to the bridge into How to verify. replaced by line 76 of SKILL.md
  36. 6 sentences taken
  37. ### Merge Danger left out: The heading gives way to the bridge into Risk. replaced by line 84 of SKILL.md

Cursor's team kit

Cursor's team kit, make-pr-easy-to-review/SKILL.md: 23 of 32 sentences left out
  1. # Make PR Easy to Review
  2. Prepare a PR so a reviewer can quickly understand the intent, important files, and risk.
  3. The default goal is reviewability without behavior changes. 3 sentences left out: The title and the goal of make-pr-easy-to-review give way to pr-writing's, which this habit grafts its guidance into.
  4. ## Workflow
  5. Resolve the target PR from the user-provided URL or current branch.
  6. Inspect commits, diff size, changed paths, generated files, and PR description.
  7. Identify reviewability issues: noisy commits, stale description, unrelated changes, mixed mechanical and logic changes, missing tests, or unclear reviewer entry points.
  8. Propose a plan before rewriting history or force-pushing. 5 sentences left out: The workflow resolves a PR on the forge and plans a history rewrite or a force-push, which is never taken: the habit writes the messages and the notes. R1
  9. Apply safe improvements, then verify the tree or diff still matches the intended code. left out: The tree-identity check of a safe improvement is written in greenline's words for a fix that rewrites no history. R1 replaced by line 99 of SKILL.md
  10. ## History Cleanup
  11. Only rewrite history when the user asks for it or agrees to the plan.
  12. Before rewriting:
  13. ```bash gh pr view <PR> --json title,headRefName,baseRefName,state,commits git fetch origin <headRefName> <baseRefName> ORIGINAL_TREE=$(git rev-parse origin/<headRefName>^{tree}) ```
  14. Good commit groupings usually follow dependency order:
  15. Schema/storage or generated API definitions.
  16. Core logic.
  17. Wiring and integration.
  18. UI or surface behavior.
  19. Tests.
  20. After rewriting, verify content identity:
  21. ```bash echo "Original tree: $ORIGINAL_TREE" echo "Current tree: $(git rev-parse HEAD^{tree})" git diff origin/<headRefName> --stat ```
  22. Do not push if the tree changed unintentionally. 13 sentences left out: History cleanup rewrites and force-pushes an open PR through gh, which is never taken; its tree identity check stands in the written line. R1 replaced by line 99 of SKILL.md
  23. ## Reviewer Guidance left out: The heading gives way to the operating order's seventh step. replaced by line 90 of SKILL.md

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-pr-writing-front-and-references

pr-writing'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
SKILL.md, references/greenline.md
Rulings, R1 to R8
  1. the operator's rulings of 2026-10-08 on the intake R3 ("everything is good", and "yes go ahead" on the portable forms of R21), the verdicts standing and every contradiction ruled as recommended: pr-writing is a new trial habit, a combine with tjcages' pr-writing as its spine and mattpocock's pr (its evidence tier and merge danger), make-pr-easy-to-review (its reviewer guidance and the tree-identity line, never its history rewrite) and visual-pr's notes field grafted; the PR body is a projection that links the change record, in pr-writing's order with a visual from the show-me habit where the change alters a shape (contradiction 27); the repository's own commit convention decides, neither source's (contradiction 28); and a PR is opened only on the owner's word, since it is outward
  2. the operator's rulings of 2026-10-08 on the intake R3 ("everything is good", and "yes go ahead" on the portable forms of R21), the verdicts standing and every contradiction ruled as recommended: pr-writing is a new trial habit, a combine with tjcages' pr-writing as its spine and mattpocock's pr (its evidence tier and merge danger), make-pr-easy-to-review (its reviewer guidance and the tree-identity line, never its history rewrite) and visual-pr's notes field grafted; the PR body is a projection that links the change record, in pr-writing's order with a visual from the show-me habit where the change alters a shape (contradiction 27); the repository's own commit convention decides, neither source's (contradiction 28); and a PR is opened only on the owner's word, since it is outward; 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": a skill's front is the upstream prose its recipe cuts, and greenline's mechanics, where the step's work lands, its section's form, its commands and its depths at each mode, stand on its references page (J-93 S2)
  3. the operator's rulings of 2026-10-08 on the intake R3 ("everything is good", and "yes go ahead" on the portable forms of R21), the verdicts standing and every contradiction ruled as recommended: pr-writing is a new trial habit, a combine with tjcages' pr-writing as its spine and mattpocock's pr (its evidence tier and merge danger), make-pr-easy-to-review (its reviewer guidance and the tree-identity line, never its history rewrite) and visual-pr's notes field grafted; the PR body is a projection that links the change record, in pr-writing's order with a visual from the show-me habit where the change alters a shape (contradiction 27); the repository's own commit convention decides, neither source's (contradiction 28); and a PR is opened only on the owner's word, since it is outward; The operator's cards of 2026-10-14 on part 4 of the-whole-change, each "Rule as proposed", under N-49's root card that the owner chooses where the change's checkout lives: the proposal names where the change's commits will go, read from local facts with no network command, the current branch when it is not the default branch or there is no remote and a new branch greenline/<id> otherwise, the owner's answer final; a worktree holds the change's checkout only on the owner's request and only where the harness runs the session in it, and no fresh agent runs in one of its own; the close step offers the landing in one line by the setup, a push and a pull request where the remote is a forge, a local merge where there is no remote, or the branch left, each only on the owner's word, the push and pull-request rule moving into the block and the close step while pr-writing keeps the writing method; and a plan's tickets share the planning change's branch, each ticket's commits carrying its own trailer, and the planning change's close offers the landing for the whole
  4. the operator's rulings of 2026-10-08 on the intake R3 ("everything is good", and "yes go ahead" on the portable forms of R21), the verdicts standing and every contradiction ruled as recommended: contradictions 27 and 28 as recommended, the PR body a projection that links the change record, never make-pr-easy-to-review's history rewrite, and a PR opened only on the owner's word, since it is outward
  5. under 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
  6. 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
  7. The operator's cards of 2026-10-14 on part 4 of the-whole-change, each "Rule as proposed", under N-49's root card that the owner chooses where the change's checkout lives: the proposal names where the change's commits will go, read from local facts with no network command, the current branch when it is not the default branch or there is no remote and a new branch greenline/<id> otherwise, the owner's answer final; a worktree holds the change's checkout only on the owner's request and only where the harness runs the session in it, and no fresh agent runs in one of its own; the close step offers the landing in one line by the setup, a push and a pull request where the remote is a forge, a local merge where there is no remote, or the branch left, each only on the owner's word, the push and pull-request rule moving into the block and the close step while pr-writing keeps the writing method; and a plan's tickets share the planning change's branch, each ticket's commits carrying its own trailer, and the planning change's close offers the landing for the whole
  8. 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
3 earlier entries

  1. 2026-10-14 2026-10-14-pr-writing-keeps-the-writing

    The push and PR become close's landing; the habit keeps writing

    Pages it touched: SKILL.md

  2. 2026-10-09 2026-10-09-pr-writing-gists

    Every account gets a short gist for the website

  3. 2026-10-08 2026-10-08-pr-writing-recipe

    Enters as a trial habit for PRs the owner approves

    Pages it touched: SKILL.md