Claude Code workflow improvements from rust-genai session

[evansenter]

Summary

Workflow improvements identified during a rust-genai development session. Each item includes the specific friction encountered that motivates the change.

---

1. Add gh issue comment to allowed permissions

Friction experienced: When posting an RFC response to gemicro issue #137, the gh issue comment command required implicit approval even though related commands (gh issue create/view/close/edit) are already allowed.

Session context: After running /rfc-response and drafting a response, the user said "post the rfc response to the issue". I had to run:

gh issue comment 137 --repo evansenter/gemicro --body "..."

This should have been autonomous since we already allow issue creation and editing.

Fix: Add to ~/.claude/settings.json:

"Bash(gh issue comment:*)"

---

2. Fix /watch-ci notification reliability

Friction experienced: Two background CI watch tasks (ba8529e for PR #197, bce6a1a for PR #204) both exited with code 137 (killed). The notifications never fired despite CI completing successfully.

Session context:

• Started watching PR improve-workflow agent cannot call skills (im-lost, etc.) #197 CI in background
• CI passed, but the background task was killed before notification could fire
• Same issue with PR feat(claude-review): Check Feedback Addressed comments before re-raising items #204
• Had to manually check CI status and merge

Root cause hypothesis: The pipe syntax in long-running background tasks may not work reliably:

gh pr checks ... && echo '...' | ~/.claude/hooks/notify.sh

Proposed fix in watch-ci.md: Use here-string instead of pipe:

gh pr checks <PR> --watch --interval 10 && ~/.claude/hooks/notify.sh <<< '{"title":"CI","message":"CI passed on PR #<PR>"}' || ~/.claude/hooks/notify.sh <<< '{"title":"CI","message":"CI failed on PR #<PR>"}'

Or investigate why background tasks are being killed (timeout? memory?).

---

3. Add --post flag to /rfc-response

Friction experienced: After generating the RFC response, there was a manual back-and-forth:

1. I showed the drafted response
2. User said "post the rfc response to the issue"
3. I then ran gh issue comment

Session context: The RFC response was already complete and formatted. The extra confirmation step added friction when the user's intent was clear.

Proposed enhancement to rfc-response.md:

/rfc-response [ISSUE] [--post]

When --post is provided, automatically post after generating. Without flag, show and ask (current behavior for when user wants to review first).

---

4. Clarify MCP merge permission vs discussion requirement

Friction experienced: Confusion about whether I could autonomously merge after user said "merge when CI passes".

Session context:

• User explicitly said "merge the pr when ci passes" for PR improve-workflow agent cannot call skills (im-lost, etc.) #197
• CLAUDE.md says "Merging PRs... Requires Discussion"
• But mcp__github__merge_pull_request is in allowed permissions
• I proceeded with the merge after CI passed, which was correct, but the documentation creates uncertainty

Proposed fix in ~/.claude/CLAUDE.md, update the "Requires Discussion" section:

### Requires Discussion

- Merging PRs - unless user explicitly approves (e.g., "merge when CI passes")
- Closing PRs
- ...

This codifies the pattern: explicit user approval removes the discussion requirement.

---

5. Add cargo add to allowed permissions

Friction experienced: Not encountered this session, but noticed the gap while reviewing permissions.

Context: We have cargo build/test/check/clippy/fmt/run/doc but not cargo add. Adding dependencies is a common development operation that shouldn't require approval.

Fix: Add to ~/.claude/settings.json:

"Bash(cargo add:*)"

---

6. Update /improve-workflow to require motivating context

Friction experienced: This issue itself - when suggesting workflow improvements, the command should instruct Claude to include specific friction/context from the session, not just abstract suggestions.

Session context: The /improve-workflow command output format section says to "Be specific about what each suggestion enables" but doesn't explicitly require motivating context from the actual session.

Proposed fix in improve-workflow.md, add to the Output section:

## Output

Be specific about what each suggestion enables and the setup required.

**Important**: For each suggestion, include the specific friction or issue encountered during the session that motivates the change. Reference specific commands that failed, approvals that blocked work, or back-and-forth that could have been avoided. This context is essential when creating issues against evansenter/dotfiles.

Group suggestions into two categories:
...

And update the Follow-up section:

## Follow-up

When suggesting to create an issue against `evansenter/dotfiles`, **only include Global Improvements**. Each improvement MUST include:
- The specific friction encountered (what went wrong or was inefficient)
- Session context (what you were trying to do when the friction occurred)
- The proposed fix with concrete code/config changes

Local improvements should be tracked in the current repository's issues.

---

Priority

#	Improvement	Priority	Complexity
1	gh issue comment permission	High	Trivial
2	/watch-ci notification fix	High	Medium
3	/rfc-response --post flag	Low	Low
4	Merge permission clarification	Medium	Trivial
5	cargo add permission	Low	Trivial
6	/improve-workflow context requirement	Medium	Trivial

---

🤖 Generated with Claude Code