xevion/dotfiles
1
0
Fork 0
mirror of https://github.com/Xevion/dotfiles.git synced 2026-01-31 06:24:13 -06:00
Code Issues Packages Projects Releases Wiki Activity

config: add lazy* tools to mise and expand Question tool guidance

Browse Source
This commit is contained in:
Xevion
2026-01-18 20:41:24 -06:00
parent fcda511c44
commit 61a66df27d
2 changed files with 39 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
home/.managed/mise/config.toml
+3
View File
@@ -23,3 +23,6 @@ bun = "latest"
imagemagick = "latest" imagemagick = "latest"
curlie = "latest" curlie = "latest"
delta = "latest" delta = "latest"
lazydocker = "latest"
lazyssh = "latest"
lazyjournal = "latest"
home/dot_claude/CLAUDE.md.tmpl
+36 -8
View File
@@ -155,6 +155,11 @@ When a project uses `assert2`:
## Git Commits ## 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 ### Safety & Best Practices
- **Do NOT add co-authoring or attribution to Claude Code/AI** - **Do NOT add co-authoring or attribution to Claude Code/AI**
@@ -192,17 +197,40 @@ When a project uses `assert2`:
### Question Tool Usage ### Question Tool Usage
- **Use for complex tasks and design decisions**: **CRITICAL: Use the Question tool proactively, especially during planning phases.**
- Architectural choices
- Multiple implementation approaches **When planning ANY non-trivial task, STRONGLY prefer asking questions to confirm:**
- Feature design options - Which approach to take when multiple valid options exist
- Clarifying & confirming important requirements, especially vague or conflicting ones - Whether assumptions about user intent are correct
- **Do NOT use for trivial details**: - Implementation strategy before writing code
- Variable naming - Prioritization when multiple sub-tasks could be done
- Minor formatting choices - 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 - **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 - 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 ### When NOT to Build/Run
- ❌ After type checking passes - building is unnecessary - ❌ After type checking passes - building is unnecessary