skills/max-sixty__worktrunk
1
0
Fork 0
mirror of https://github.com/max-sixty/worktrunk.git synced 2026-09-14 20:00:38 +08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Worktrunk Bot
2026-09-13 17:15:12 -07:00
committed by GitHub
parent 5dec423110
commit 6c263ed69e
1 changed files with 14 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/skills/running-tend/SKILL.md
+14 -11
View File
@@ -140,6 +140,20 @@ 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 PR that only records it. 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, and annotating a stale value leaves the
duplication that made it stale. If you do recommend a workaround, surface its
downsides in the PR body up front, not only when challenged.
This governs every workflow that opens a PR here, not just issue triage.
## Issue Triage
When you need more information to diagnose a reported bug, the **primary
@@ -228,17 +242,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