Skip to content

skills(running-tend): weigh the root-cause fix in every workflow, not just triage #4086

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
max-sixty merged 3 commits into from
Sep 14, 2026
Merged

skills(running-tend): weigh the root-cause fix in every workflow, not just triage #4086

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
1cb24a7
skills(running-tend): weigh the root-cause fix in every workflow, not…
worktrunk-bot Sep 13, 2026
77d3988
skills(running-tend): widen the section's operative clause with its t…
worktrunk-bot Sep 13, 2026
b05d052
skills(running-tend): state the rule without the incident that produc…
worktrunk-bot Sep 13, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 17 additions & 11 deletions .claude/skills/running-tend/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -140,6 +140,23 @@ The codecov-failure dismissal pattern is different and remains correct:
`codecov/patch`, so dismissing the approval until the coverage gap is
addressed is intentional.

## Weigh the root-cause fix before shipping a workaround

When a mismatch, a false positive, or a stale value has an obvious non-code
workaround (a template change, a config value, an alias, a comment recording
the drift), don't stop there. First check whether the workaround is **lossy or
foot-gunny**, and weigh a proportionate **root-cause code fix** before opening
a docs-only PR. A "docs-only, no risk" framing is not the same as good
guidance — a zero-code-risk change can still steer users toward a
Comment thread
worktrunk-bot marked this conversation as resolved.
Resolved
collision-prone or lossy config, and annotating a stale value leaves the
duplication that made it stale. If you do recommend a config change, surface
its downsides in the PR body up front, not only when challenged.
Comment thread
worktrunk-bot marked this conversation as resolved.
Resolved

This governs every workflow that opens a PR here, not just issue triage. The
nightly sweep's #4069 annotated twelve stale VHS theme colors with

@max-sixty max-sixty Sep 13, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we had guidance against giving references to specific historical events?

@worktrunk-bot worktrunk-bot Sep 13, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes — skill-pr-workflow.md step 3: "State the rule, not the incident that produced it … step 4's PR body is where the case history goes." That paragraph was a straight violation of it, and the case history it repeated is already in the PR body where it belongs.

Dropped the two incident sentences in b05d05268, keeping only the scope clause: "This governs every workflow that opens a PR here, not just issue triage."

`(pre-Starlight; site is …)`; the maintainer replaced all twelve by reading
the hex properties out of `custom.css` at build time.

## Issue Triage

When you need more information to diagnose a reported bug, the **primary
Expand Down Expand Up @@ -228,17 +245,6 @@ across every repo. It's the project's preferred extension point.
5. Link to the [aliases docs](https://worktrunk.dev/extending/#aliases) and
[tips & patterns](https://worktrunk.dev/tips-patterns/).

### Weigh the root-cause fix before shipping a config/docs workaround

When a mismatch or false-positive report has an obvious configurable
workaround (a template change, a config value, an alias), don't stop at
documenting it. First check whether the workaround is **lossy or
foot-gunny**, and weigh a proportionate **root-cause code fix** before
opening a docs-only PR. A "docs-only, no risk" framing is not the same as
good guidance — a zero-code-risk change can still steer users toward a
collision-prone or lossy config. If you do recommend a config change,
surface its downsides in the PR body up front, not only when challenged.

### Don't fix tests by adding skip guards

When a test fails because production code or test setup can't handle some
Expand Down
Loading