Initial commit
This commit is contained in:
Zhongwei Li
47
commands/commit.md
Normal file
47
commands/commit.md
Normal file
@@ -0,0 +1,47 @@
|
||||
# Commit Changes
|
||||
|
||||
You are tasked with creating jj commits for the changes made during this session.
|
||||
|
||||
## Process:
|
||||
|
||||
1. **Think about what changed:**
|
||||
- Review the conversation history and understand what was accomplished
|
||||
- Run `jj status` to see current changes
|
||||
- Run `jj diff` to understand the modifications
|
||||
- Consider whether changes should be one commit or multiple logical commits
|
||||
|
||||
2. **Plan your commit(s):**
|
||||
- Identify which files belong together
|
||||
- Draft clear, descriptive commit messages
|
||||
- Use imperative mood in commit messages
|
||||
- Focus on why the changes were made, not just what
|
||||
|
||||
3. **Present your plan to the user:**
|
||||
- List the files you plan to include for each commit
|
||||
- Show the commit message(s) you'll use
|
||||
- Ask: "I plan to create [N] commit(s) with these changes. Shall I proceed?"
|
||||
|
||||
4. **Execute upon confirmation:**
|
||||
- Use `jj describe` to set the commit message for the current working copy
|
||||
- Use `jj split` if multiple logical commits are needed
|
||||
- Show the result with `jj log -n [number]`
|
||||
|
||||
## Important:
|
||||
- **NEVER add co-author information or Claude attribution**
|
||||
- Commits should be authored solely by the user
|
||||
- Do not include any "Generated with Claude" messages
|
||||
- Do not add "Co-Authored-By" lines
|
||||
- Write commit messages as if the user wrote them
|
||||
|
||||
## Jujutsu-specific notes:
|
||||
- Jujutsu automatically tracks all changes in the working copy
|
||||
- Use `jj describe` to set the commit message
|
||||
- Use `jj split` to split changes into multiple commits if needed
|
||||
- Use `jj squash` to combine commits if necessary
|
||||
- The working copy revision is automatically updated
|
||||
|
||||
## Remember:
|
||||
- You have the full context of what was done in this session
|
||||
- Group related changes together
|
||||
- Keep commits focused and atomic when possible
|
||||
- The user trusts your judgment - they asked you to commit
|
||||
91
commands/create_prs.md
Normal file
91
commands/create_prs.md
Normal file
@@ -0,0 +1,91 @@
|
||||
# Create Pull Requests from Stack
|
||||
|
||||
You are tasked with creating pull requests for all changes in the current jj tree.
|
||||
|
||||
## Process:
|
||||
|
||||
1. **Ask about PR configuration:**
|
||||
- Ask the user: "Should all PRs be based on the main branch, or should each PR be based on its direct parent branch?"
|
||||
- Ask the user: "Should the PRs be created as drafts or published immediately?"
|
||||
- Wait for user responses before proceeding
|
||||
|
||||
2. **Understand the current state:**
|
||||
- Run `jj log` to visualize the current commit tree
|
||||
- Identify which commits need PRs
|
||||
- Understand the branch structure and relationships
|
||||
|
||||
3. **Push branches to origin:**
|
||||
- Run `jj git push --allow-new` to push all branches
|
||||
- Parse the output to identify which branches were pushed
|
||||
- Track the branch names and their corresponding commits
|
||||
|
||||
4. **Create PRs for each new branch:**
|
||||
- For each new branch that was pushed:
|
||||
- Determine the commit range for changes (use `jj log` and `jj diff`)
|
||||
- Generate a clear, descriptive PR title based on the commit message(s)
|
||||
- Create a PR body that describes the changes:
|
||||
- Summarize what changed and why
|
||||
- Include relevant context about the implementation
|
||||
- Do NOT include Claude attribution or co-author information
|
||||
- Determine the base branch:
|
||||
- If user chose "main branch": use main (or master)
|
||||
- If user chose "parent branch": use the direct parent commit's branch
|
||||
- Create the PR:
|
||||
- If user chose "drafts": Run `gh pr create --draft -H <bookmark-name> --base <base-branch> --head <branch-name> --title "<title>" --body "<body>"`
|
||||
- If user chose "published": Run `gh pr create -H <bookmark-name> --base <base-branch> --head <branch-name> --title "<title>" --body "<body>"`
|
||||
- Store the PR URL and branch name for later use
|
||||
|
||||
5. **Build the stack information:**
|
||||
- Determine the order of PRs from closest to main to furthest
|
||||
- For each PR, identify its position in the stack
|
||||
|
||||
6. **Update all PR descriptions with stack links:**
|
||||
- For each PR created:
|
||||
- Build the stack section showing all PRs in order
|
||||
- Mark the current PR with `<-- This PR`
|
||||
- Use `gh pr edit <PR-URL> --body "<updated-body>"` to add the stack section
|
||||
- Stack format:
|
||||
```md
|
||||
Stack:
|
||||
- https://github.com/<org>/<project>/pull/<id>
|
||||
- https://github.com/<org>/<project>/pull/<id2> <-- This PR
|
||||
- https://github.com/<org>/<project>/pull/<id3>
|
||||
```
|
||||
|
||||
7. **Generate summary:**
|
||||
- Create a summary table showing:
|
||||
- Bookmark/branch name
|
||||
- Corresponding PR URL
|
||||
- Base branch
|
||||
- Present this to the user
|
||||
|
||||
## Important:
|
||||
|
||||
- **NEVER add co-author information or Claude attribution**
|
||||
- PRs should be authored solely by the user
|
||||
- Do not include any "Generated with Claude" messages
|
||||
- Do not add "Co-Authored-By" lines
|
||||
- Write PR descriptions in the user's voice
|
||||
|
||||
## Jujutsu and GitHub CLI notes:
|
||||
|
||||
- `jj git push --allow-new` will push all branches and output which ones are new
|
||||
- Use `jj log -r 'bookmarks()'` to see all bookmarks
|
||||
- Use `jj diff -r <revision>` to see changes for a specific commit
|
||||
- Use `gh pr create` to create PRs programmatically
|
||||
- Use `gh pr edit` to update PR descriptions after creation
|
||||
- Use `gh pr list --json url,number,headRefName` to query existing PRs if needed
|
||||
|
||||
## Error handling:
|
||||
|
||||
- If push fails, report the error and stop
|
||||
- If PR creation fails for a branch, report it but continue with other branches
|
||||
- If PR description update fails, report it but continue with other PRs
|
||||
- At the end, report any errors encountered
|
||||
|
||||
## Remember:
|
||||
|
||||
- The stack visualization helps reviewers understand dependencies
|
||||
- PRs based on parent branches create a more granular review process
|
||||
- PRs based on main are simpler but may have larger diffs
|
||||
- Each PR should stand alone in its description despite being part of a stack
|
||||
60
commands/rebase.md
Normal file
60
commands/rebase.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# Rebase Current Changeset
|
||||
|
||||
You are tasked with rebasing the current changeset onto the primary branch.
|
||||
|
||||
## Process:
|
||||
|
||||
1. **Determine the primary branch:**
|
||||
- Run `jj log -r 'bookmarks()' --no-graph` to list all bookmarks
|
||||
- Check if `main` or `master` exists in the bookmark list
|
||||
- If `main` exists, use it as the primary branch
|
||||
- If `main` doesn't exist but `master` does, use `master` as the primary branch
|
||||
- If neither exists, ask the user: "What is the name of your primary branch?"
|
||||
- Wait for the user's response before proceeding
|
||||
|
||||
2. **Pull latest changes:**
|
||||
- Run `jj git fetch` to fetch the latest changes from the remote
|
||||
- This ensures we're rebasing onto the latest version of the primary branch
|
||||
|
||||
3. **Identify the changeset to rebase:**
|
||||
- Run `jj log -r 'mine() & ::@'` to see the current changeset and its ancestors
|
||||
- The current changeset is marked with `@` in the log
|
||||
- Identify the changeset ID of the current working copy (the one with `@`)
|
||||
|
||||
4. **Rebase the changeset:**
|
||||
- Run `jj rebase -s <changeset-id> -d <primary-branch>`
|
||||
- Where `<changeset-id>` is the ID of the current working copy
|
||||
- Where `<primary-branch>` is the primary branch determined in step 1
|
||||
- This rebases the current changeset and all its descendants onto the primary branch
|
||||
|
||||
5. **Show the result:**
|
||||
- Run `jj log` to display the updated commit tree
|
||||
- Confirm to the user that the rebase was successful
|
||||
|
||||
## Important:
|
||||
|
||||
- **DO NOT rebase changesets that are part of bookmarks you plan to delete**
|
||||
- Only rebase the current changeset chain, not other branches
|
||||
- If there are conflicts during rebase, report them to the user and stop
|
||||
- Use `jj git fetch` instead of `jj git pull` to avoid automatic merging
|
||||
|
||||
## Jujutsu-specific notes:
|
||||
|
||||
- `jj rebase -s <source> -d <destination>` rebases the source changeset and all its descendants
|
||||
- The `-s` flag specifies the source changeset to rebase
|
||||
- The `-d` flag specifies the destination to rebase onto
|
||||
- Jujutsu handles rebasing automatically, updating the working copy
|
||||
- Use changeset IDs or revision expressions (like `@` for current working copy)
|
||||
|
||||
## Error handling:
|
||||
|
||||
- If `jj git fetch` fails, report the error and stop
|
||||
- If the primary branch doesn't exist locally, report this and ask the user to verify
|
||||
- If rebase fails due to conflicts, report the conflicts and provide guidance
|
||||
- If the user is not on a changeset that can be rebased, explain why
|
||||
|
||||
## Remember:
|
||||
|
||||
- Rebasing updates the working copy to be based on the latest primary branch
|
||||
- This is useful before creating pull requests or pushing changes
|
||||
- The user trusts your judgment to identify the correct changeset to rebase
|
||||
Reference in New Issue
Block a user