├── README.markdown ├── commit.md ├── issue.md ├── lw.md ├── pr.md ├── quiz.md ├── reflect.md ├── resolve.md ├── reverse.md ├── review.md ├── today.md └── work.md /README.markdown: -------------------------------------------------------------------------------- 1 | # Claude Code slash commands 2 | 3 | This is a work in progress as I learn more about Claude Code and its capabilities. The goal is to create a set of slash commands that can be used to interact with Claude Code in a more efficient way. 4 | 5 | - Thanks to [Kieran Klaassen](https://x.com/kieranklaassen) for the inspiration and the initial code snippets. 6 | 7 | ## Available Commands 8 | 9 | ### Development Workflow 10 | - **issue** - Creates well-structured GitHub issues from feature descriptions 11 | - **work** - Analyzes GitHub issue, creates branch, plans implementation, then executes the work 12 | - **pr** - Automates PR creation with code formatting and test verification 13 | - **review** - Provides expert Ruby on Rails code review with line-specific feedback 14 | - **resolve** - Addresses unresolved PR comments with fixes and automated cleanup 15 | - **commit** - Creates git commits with context-aware messages based on current changes 16 | - **reverse** - Rails-focused problem solving through Socratic questioning to avoid over-engineering 17 | 18 | ### Learning & Reflection 19 | - **quiz** - Generates interactive quizzes to reinforce learning from coding sessions 20 | - **reflect** - Captures and saves key learnings from completed tasks 21 | - **lw** - Provide a summary of last weeks work appropriate for non-technical stakeholders 22 | - **today** - Provide a summary of todays work appropriate for non-technical stakeholders 23 | 24 | -------------------------------------------------------------------------------- /commit.md: -------------------------------------------------------------------------------- 1 | --- 2 | allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*), Bash(git branch:*), Bash(git log:*), Bash(rubocop:*) 3 | description: Create a git commit with automated linting and context-aware messages 4 | --- 5 | 6 | ## Context 7 | 8 | ### Current State 9 | - Working directory status: !`git status --porcelain` 10 | - Current branch: !`git branch --show-current` 11 | - Staged changes: !`git diff --staged --stat` 12 | - Unstaged changes: !`git diff --stat` 13 | 14 | ### Detailed Changes 15 | - Full diff (staged and unstaged): !`git diff HEAD` 16 | - Staged changes detail: !`git diff --staged` 17 | 18 | ### Repository History 19 | - Recent commits with graph: !`git log --oneline -10 --graph` 20 | - Commits on current branch (not on main): !`git log --oneline main..HEAD 2>/dev/null || echo "Not branched from main"` 21 | 22 | ## Your Task 23 | 24 | ### Pre-commit Checks 25 | 26 | 1. **Verify there are changes to commit** 27 | - If no changes exist, inform the user and stop 28 | - If only unstaged changes exist, suggest which files should be staged 29 | 30 | 2. **Ruby File Linting** 31 | - Check if any Ruby files (*.rb, *.rake, Gemfile, *.gemspec) are modified in the diff 32 | - If Ruby files are found, run `rubocop -a` to auto-correct any style violations 33 | - If rubocop makes changes, add them to the commit 34 | - Report any remaining rubocop offenses that couldn't be auto-corrected 35 | 36 | 3. **Branch Verification** 37 | - Confirm the user is on the intended branch 38 | - Warn if committing directly to main/master 39 | 40 | ### Creating the Commit 41 | 42 | Based on the changes, create a single git commit following these guidelines: 43 | 44 | **Commit Message Format:** 45 | 46 | Subject line: 47 | - 50 characters or less 48 | - Start with a capital letter 49 | - Do not end with a period 50 | - Use imperative mood ("Add" not "Added") 51 | 52 | Body (optional): 53 | - Blank line between subject and body 54 | - Wrap at 72 characters 55 | - Explain what and why (not how) 56 | - Reference issue numbers if found in branch name (e.g., "Fixes #123") 57 | 58 | **Message Content Guidelines:** 59 | - Write a clear, descriptive message about what changed and why 60 | - Focus on the impact and purpose of the change 61 | - Reference issue numbers if found in branch name (e.g., "Fixes #123") 62 | 63 | **Example format:** 64 | ``` 65 | Add user authentication system 66 | 67 | - Implement JWT token generation and validation 68 | - Add login/logout endpoints 69 | - Include session management middleware 70 | 71 | Closes #42 72 | ``` 73 | 74 | ### Final Steps 75 | 1. Stage all intended changes 76 | 2. Create the commit with a well-crafted message 77 | 3. Show the commit confirmation with `git log -1 --stat` -------------------------------------------------------------------------------- /issue.md: -------------------------------------------------------------------------------- 1 | # Create a GitHub issue for a feature request or bug report based on the provided description. 2 | 3 | You are an AI assistant tasked with creating well-structured GitHub issues for feature requests, bug reports, or improvement ideas. Your goal is to turn the provided feature description into a comprehensive GitHub issue that follows best practices and project conventions. 4 | 5 | First, you will be given a feature description: 6 | 7 | #$ARGUMENTS 8 | 9 | Follow these steps to complete the task, make a todo list and think ultrahard: 10 | 11 | --- 12 | 13 | ### 1. Present a plan: 14 | 15 | - Outline a plan for creating the GitHub issue. 16 | - Include the proposed structure of the issue, any labels or milestones you plan to use, and how you’ll incorporate project-specific conventions. 17 | - Present this plan in tags. 18 | - Include the reference link to feature or any other link that has the source of the user request. 19 | 20 | --- 21 | 22 | ### 2. Create the GitHub issue: 23 | 24 | - Once the plan is approved, draft the GitHub issue content. 25 | - Include a clear title, detailed description, acceptance criteria, and any additional context or resources that would be helpful for developers. 26 | - Use appropriate formatting (e.g., Markdown) to enhance readability. 27 | - Add any relevant labels, milestones, or assignees based on the project’s conventions. 28 | - Use task lists to break down the work if applicable. 29 | 30 | --- 31 | 32 | ### 3. Final output: 33 | 34 | - Present the complete GitHub issue content in tags. 35 | - Do not include any explanations or notes outside of these tags in your final output. 36 | 37 | --- 38 | 39 | Remember to think carefully about the feature description and how to best present it as a GitHub issue. Consider the perspective of both the project maintainers and potential contributors who might work on this feature. 40 | 41 | Make sure to use the GitHub CLI `gh issue create` to create the actual issue after you generate. Assign either the label `bug` or `enhancement` based on the nature of the issue. 42 | -------------------------------------------------------------------------------- /lw.md: -------------------------------------------------------------------------------- 1 | # Weekly Summary of Merged Pull Requests 2 | 3 | 1. Identify today's date and day of week 4 | 2. Calculate the date of the most recent Sunday that has passed 5 | 3. Calculate the date of the Monday before that Sunday 6 | 4. Using the gh cli look at the Pull Requests that have been merged into the main/master branch from that Monday through to that Sunday 7 | 5. Summarize each of these PRs in a single sentence bullet point. 8 | 9 | The target audience is the business owners. 10 | They are not technical so try and articulate the changes in a way that is easy to understand and how it benefits the business. 11 | Use relevant emojis for each bullet point to make it more engaging. 12 | -------------------------------------------------------------------------------- /pr.md: -------------------------------------------------------------------------------- 1 | # Create a pull request for this branch 2 | 3 | If rubocop -a and all test pass then commit and create a PR. Make sure the PR description is clear and concise. 4 | -------------------------------------------------------------------------------- /quiz.md: -------------------------------------------------------------------------------- 1 | # Quiz on Ruby on Rails Techniques just covered in this session 2 | 3 | We've done some substantial work in this session and I would like you to quiz me to cement learning. 4 | 5 | You are an expert Ruby on Rails instructor. 6 | 7 | 1. Read the code we have changed in this session. 8 | 2. Pick **2 non-obvious or interesting techniques** (e.g. `delegate`, custom concerns, service-object patterns, unusual ActiveRecord scopes, any metaprogramming). 9 | 3. For each technique, create **one multiple-choice “single-best-answer” (SBA) question** with 4 options. 10 | 4. Ask me the first question only. 11 | 5. After I reply, reveal whether I was right and give a concise teaching note (≤ 4 lines). 12 | 6. Then ask the next question, and so on. 13 | 14 | When all questions are done, end with: 15 | `Quiz complete – let me know where you’d like a deeper dive.` 16 | -------------------------------------------------------------------------------- /reflect.md: -------------------------------------------------------------------------------- 1 | # Reflect on any learnings from this session 2 | 3 | As you reflect on this task what have you learned? Summarize your learnings into succinct bullet points that are general in nature (not specifically about the task just worked on) and that would help you in future tasks. 4 | This will help you to solidify your understanding and improve your future performance. 5 | 6 | Ask the user if they would like to save these in the CLAUDE.md file. 7 | -------------------------------------------------------------------------------- /resolve.md: -------------------------------------------------------------------------------- 1 | # Resolve Issues in a Pull Request 2 | 3 | When you have a pull request (PR) that has unresolved comments, follow these steps to address them: 4 | 5 | Use the gh cli to pull in the unresolved comments on that PR and fix those issues. Once fixed mark those comments as resolved, run rubocop -a and after all tests pass, then push the changes to the PR branch. 6 | -------------------------------------------------------------------------------- /reverse.md: -------------------------------------------------------------------------------- 1 | # Claude will ask you to describe the problem and your proposed solution. 2 | 3 | You are a pragmatic senior Rails engineer who values simplicity and shipping working code. I'm going to describe a problem/GitHub issue I'm trying to solve. Your job is to: 4 | 5 | 1. First, ask me to describe the problem and my proposed Rails solution 6 | 2. Then, over 3-4 conversation turns, ask focused questions that a practical Rails developer would ask: 7 | - Is this the simplest thing that could work? 8 | - What's the definition of 'done' for this feature? 9 | - Are we using Rails conventions or fighting against them? 10 | - Could we solve this with existing Rails patterns instead of custom code? 11 | - What's the minimal viable solution vs. what could be added later? 12 | - Are we over-abstracting or adding unnecessary complexity? 13 | - How will we know when this is working correctly? 14 | 3. After each response, briefly acknowledge what makes sense and probe deeper into areas that might be over-engineered 15 | 4. Finally, provide an analysis comparing my approach to Rails best practices, highlighting where I could simplify 16 | 17 | Remember: 'You ain't gonna need it' (YAGNI) and 'Convention over Configuration' are core principles. Start by asking me to describe the problem. 18 | 19 | DO NOT provide solutions or diagnose the problem. You are only asking questions to clarify the problem and proposed solution. 20 | -------------------------------------------------------------------------------- /review.md: -------------------------------------------------------------------------------- 1 | # Perform a code review on a pull request. 2 | 3 | You are an expert in code review of Ruby on Rails codebases. Your task is to review the code provided below and provide feedback on its quality, readability, and maintainability. Focus on the following aspects: 4 | 5 | 1. **Code Quality**: Is the code well-structured and does it follow best practices? 6 | 2. **Readability**: Is the code easy to read and understand? Are variable and function names descriptive? 7 | 3. **Maintainability**: Is the code modular and easy to maintain? Are there any potential issues that could arise in the future? 8 | 4. **Performance**: Are there any performance issues or inefficiencies in the code? 9 | 5. **Security**: Are there any security vulnerabilities or concerns in the code? 10 | 11 | Leave your feedback in a clear and concise manner, providing specific examples from the code where applicable. If you suggest changes, explain why they are necessary and how they improve the code. 12 | 13 | Prioritise your feedback in the form of comments on the affected lines of code. This keeps the review focused and actionable. 14 | 15 | Use clear and professional language, and avoid any personal opinions or biases. Focus solely on the technical aspects of the code. 16 | 17 | Review PR $ARGUMENTS using gh api to post line-specific comments. Calculate positions from the patch (not line numbers) and use: 18 | 19 | gh api --method POST repos/{owner}/{repo}/pulls/{PR_NUMBER}/comments -f body='comment' -f commit_id='SHA' -f path='file' -F position=N 20 | 21 | Always use single quotes for complex multi-line strings when using the gh CLI, or use a heredoc format. 22 | 23 | Post a summary comment at the end of the review using the gh cli. Keep the tone of the summary positive, professional and constructive. 24 | 25 | Do not approve or reject the PR, just provide feedback. 26 | -------------------------------------------------------------------------------- /today.md: -------------------------------------------------------------------------------- 1 | # Today's Merged Pull Requests Summary 2 | 3 | 1. Identify today's date and day of week 4 | 2. Using the gh cli look at the Pull Requests that have been merged into the main/master branch today. 5 | 3. Summarize each of these PRs in a single sentence bullet point. 6 | 7 | The target audience is the business owners. 8 | They are not technical so try and articulate the changes in a way that is easy to understand and how it benefits the business. 9 | Use relevant emojis for each bullet point to make it more engaging. 10 | -------------------------------------------------------------------------------- /work.md: -------------------------------------------------------------------------------- 1 | # Work on a GitHub issue (plan and then action todo list) 2 | 3 | You are an experienced software developer tasked with addressing a GitHub issue. Your goal is to analyze the issue, understand the codebase, and create a comprehensive plan to tackle the task. Follow these steps carefully: 4 | 5 | 1. First, review the GitHub issue (use gh cli): 6 | 7 | #$ARGUMENTS 8 | 9 | 2. Next, examine the relevant parts of the codebase. 10 | 11 | Analyze the code thoroughly until you feel you have a solid understanding of the context and requirements. 12 | 13 | 3. Create a new branch from the main branch for this feature. The branch name should be descriptive and relate to the issue. Use the following format: `feature/[issue-number]-brief-description` 14 | 15 | 4. Create a comprehensive plan and todo list for addressing the issue. Consider the following aspects: 16 | 17 | - Required code changes 18 | - Potential impacts on other parts of the system 19 | - Necessary tests to be written or updated 20 | - Documentation updates 21 | - Performance considerations 22 | - Security implications 23 | - Backwards compatibility (if applicable) 24 | - Include the reference link to featurebase or any other link that has the source of the user request 25 | 26 | 5. Think deeply about all aspects of the task. Consider edge cases, potential challenges, and best practices for implementation. 27 | 28 | 6. Present your plan in the following format: 29 | 30 | 31 | [Your comprehensive plan goes here. Include a high-level overview followed by a detailed breakdown of steps.] 32 | 33 | 34 | Remember, your task is to create a plan, not to implement the changes. Focus on providing a thorough, well-thought-out strategy for addressing the GitHub issue. Then ASK FOR APPROVAL BEFORE YOU START WORKING ON THE TODO LIST. 35 | --------------------------------------------------------------------------------