From 61a66df27d4d3be3152795ea598e910755054bce Mon Sep 17 00:00:00 2001 From: Xevion Date: Sun, 18 Jan 2026 20:41:24 -0600 Subject: [PATCH] config: add lazy* tools to mise and expand Question tool guidance --- home/.managed/mise/config.toml | 3 +++ home/dot_claude/CLAUDE.md.tmpl | 44 +++++++++++++++++++++++++++------- 2 files changed, 39 insertions(+), 8 deletions(-) diff --git a/home/.managed/mise/config.toml b/home/.managed/mise/config.toml index 3e2144d..4ec8692 100644 --- a/home/.managed/mise/config.toml +++ b/home/.managed/mise/config.toml @@ -23,3 +23,6 @@ bun = "latest" imagemagick = "latest" curlie = "latest" delta = "latest" +lazydocker = "latest" +lazyssh = "latest" +lazyjournal = "latest" diff --git a/home/dot_claude/CLAUDE.md.tmpl b/home/dot_claude/CLAUDE.md.tmpl index 4a39123..a71e4d1 100644 --- a/home/dot_claude/CLAUDE.md.tmpl +++ b/home/dot_claude/CLAUDE.md.tmpl @@ -155,6 +155,11 @@ When a project uses `assert2`: ## Git Commits +### Branch Configuration + +- **Default branch is `master`, not `main`** for all GitHub repos under `Xevion/` (e.g., `Xevion/Pac-man`) +- When referencing branches or creating pull requests, assume `master` as the base branch + ### Safety & Best Practices - **Do NOT add co-authoring or attribution to Claude Code/AI** @@ -192,17 +197,40 @@ When a project uses `assert2`: ### Question Tool Usage -- **Use for complex tasks and design decisions**: - - Architectural choices - - Multiple implementation approaches - - Feature design options - - Clarifying & confirming important requirements, especially vague or conflicting ones -- **Do NOT use for trivial details**: - - Variable naming - - Minor formatting choices +**CRITICAL: Use the Question tool proactively, especially during planning phases.** + +**When planning ANY non-trivial task, STRONGLY prefer asking questions to confirm:** +- Which approach to take when multiple valid options exist +- Whether assumptions about user intent are correct +- Implementation strategy before writing code +- Prioritization when multiple sub-tasks could be done +- Design decisions that affect architecture or user experience + +**Use the Question tool for:** +- **Planning & Task Breakdown** - Before starting work, confirm the approach: + - "I see 3 ways to implement this feature. Which approach do you prefer?" + - "Should I prioritize performance or readability for this refactor?" + - "Do you want me to update tests first, or implement the feature first?" +- **Architectural choices** - Major design decisions that affect structure +- **Multiple implementation approaches** - When there are valid alternatives +- **Feature design options** - User-facing behavior and interface decisions +- **Clarifying & confirming important requirements** - Especially vague or conflicting ones +- **Ambiguous requests** - Any time you're guessing what the user meant + +**Do NOT use for trivial details:** +- Variable naming (unless it's a public API) +- Minor formatting choices +- Implementation details that don't affect behavior + +**Best Practices:** - **Prefer multi-select when appropriate**, single-select when mutually exclusive +- Ask questions EARLY in the workflow, not after you've already committed to an approach +- Present options clearly with pros/cons when relevant +- Don't ask multiple sequential question prompts - batch related questions together when possible - User appreciates being consulted on larger, more abstract decisions +**Remember**: Asking questions during planning is NOT a sign of weakness - it's professional practice. Users prefer being consulted over having to fix wrong assumptions later. + ### When NOT to Build/Run - ❌ After type checking passes - building is unnecessary