From 1477642bfb2e19c8efdecf0cdb83156d82041057 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Fri, 22 May 2026 13:49:10 -0500 Subject: chore(todo): close GH-assumption and review-code strengths tasks --- todo.org | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/todo.org b/todo.org index 802f94b..f755530 100644 --- a/todo.org +++ b/todo.org @@ -7,10 +7,12 @@ Project-scoped (not the global =~/sync/org/roam/inbox.org= list). * Rulesets Open Work -** TODO [#A] wrap-it-up Step 3.5 assumes GitHub-family remote :chore:quick: +** DONE [#A] wrap-it-up Step 3.5 assumes GitHub-family remote :chore:quick: +CLOSED: [2026-05-22 Fri] :PROPERTIES: :LAST_REVIEWED: 2026-05-20 :END: +Documented the assumption inline at =wrap-it-up.org= Step 3.5 (chose the lightweight path over a provider-agnostic rewrite): the =gh= lookup expects a GitHub-family host, holds today via DeepSat on GHE, flagged for update if a future Linear project lands on GitLab/Gitea/Bitbucket. Triggered by: 2026-05-16 wrap-it-up github.com cleanup (audit of the same file). Step 3.5 (Linear ticket-state hygiene) at =wrap-it-up.org:207= says "the project's GitHub remote — use =gh pr list ...=". Currently fine in practice: the step is Linear-gated, and the only Linear-using project is DeepSat (on =deepsat.ghe.com=, a GitHub-family host where =gh= works). Would break if a future Linear-using project lived on a non-GitHub host (gitlab, gitea, bitbucket). Either drop the GitHub-family assumption (provider-agnostic lookup, harder) or document the assumption explicitly so future projects know the step needs an update if they don't fit. @@ -959,11 +961,9 @@ public artifacts. Add two output modes: private/internal review may cite =CLAUDE.md= directly; public/team review should translate the rule into the underlying engineering reason without naming personal rulesets. -*** TODO [#A] =review-code=: relax mandatory "three strengths" for tiny or failing diffs +*** 2026-05-22 Fri @ 13:48:14 -0500 Relaxed review-code "three strengths" to up-to-three-or-none -"Three minimum" strengths can force filler on small diffs or bad PRs. Adjust to -"up to three specific strengths; say none found when appropriate" so the review -stays honest and avoids synthetic praise. +Changed all three "three minimum" spots in =review-code/SKILL.md= (Strengths section, Critical Rules DO list, Anti-Patterns) to "up to three specific; say none found on a tiny or weak diff." Reframed the old "No Strengths section" anti-pattern as "Skipping strengths out of laziness" so a substantive diff still demands them while a weak one can honestly report nothing notable. Landed alongside Craig's adjacent edit telling reviewers not to explain why a strength is good (sycophantic padding). *** TODO [#A] =respond-to-review=: remove review-process language from commit messages -- cgit v1.2.3