fix(skill): strengthen details-tag and local-test-verification guidance

[worktrunk-bot]

Summary

Two recurring behavioral issues found in hourly review of 14 Claude CI runs (12 successful, 2 cancelled) from the past hour:

1. Long comments posted without <details> tags (3 sessions)

The running-in-ci skill says to use collapsible sections for detailed analysis, but the guidance was too vague — it only mentioned "file-by-file breakdowns, code snippets." The bot consistently posts multi-section technical analyses (headers, tables, surveys) without collapsing them.

Evidence:

• Run 22967850131 on PR merge: add --no-ff flag for merge commit (semi-linear history) #1438: 2,274-char comment with 3 headers, a table, and multi-paragraph analysis — all inline
• Run 22967464601 on issue Allow worktree-path in project config + support config inheritance from parent directories #1413: 75-line survey of 25+ tools organized into 5 pattern categories with tables — all inline

Fix: Added a concrete threshold (~15 lines, multiple headers/tables) and made clear that technical analyses always need collapsible sections.

2. Local test failures characterized as "pre-existing" without verification (3rd recurrence)

This is a recurrence of #1335 and #1384. The grounded-analysis guidance exists at lines 316-320 of the skill, but the bot doesn't apply it when running local tests before pushing — only when monitoring CI after pushing.

Evidence:

• Run 22967660638 creating PR feat(switch): make --no-cd print-only in picker mode #1445: Bot ran local cargo test, saw 61 failures in ci_status and switch_pr test categories, and said "These look like CI-related test failures which are likely pre-existing or environment-dependent" — without running gh api to verify main branch CI. The bot then pushed and created the PR anyway.

Fix: Added an explicit "Verifying local test failures before pushing" subsection in the CI Monitoring section, placed right at the decision point where this pattern occurs.

Other sessions reviewed (no issues found)

Run	Type	PR/Issue	Behavior
22968844823	review	#1004	Correctly approved after CI fix commit
22968816869	review	#1446	Clean approval of small change
22968147534	review	#1445	Correctly stayed silent on self-authored PR
22967879945	review	#1442	Correctly stayed silent after tests addressed
22967793926	review	#1443	Correctly stayed silent on self-authored PR
22967450550	review	#1004	Correctly dismissed approval after CI failure
22968542106	mention	#1438	Clean wrap-up comment
22967695706	mention	#1443	Clean inline reply + code fix
22967564028	mention	#1442	Excellent diagnosis of codecov blind spot

Positive patterns: Shell quoting was correct across all 12 sessions (temp files with single-quoted heredocs). Self-authored PR handling was correct (silent, no self-approval). Review thread replies used the correct API endpoint.

Test plan

• Verify the skill file is well-formed and the new sections read clearly
• Monitor next hourly review for improvement in <details> tag usage

🤖 Generated with Claude Code

[max-sixty]

1. I think both of those comments are fine — someone asked for a survey, and it replied with a full response. We should be putting supporting details into <details> blocks, but it doesn't mean that no response can be long

2. yes, good change

[worktrunk-bot]

Good call on #1 — those were direct answers to questions, not boilerplate around a short conclusion. I've added a "when NOT to use <details> tags" section clarifying that long replies are fine when the content is the answer (e.g., a requested survey). Kept the existing threshold guidance for cases where length is supporting detail.

Pushed in b7adfa8.

[max-sixty]

just make one cohesive paragraph of when to use details tags

[worktrunk-bot]

Consolidated into a single paragraph — use <details> for supporting detail around a short conclusion, but keep the full content inline when the length is the answer. Pushed in 7d6a8bd.