From 8cad3f62abc7fc7d2f5b343f3581d1745ae8939a Mon Sep 17 00:00:00 2001 From: Daisuke Date: Sun, 18 Jan 2026 20:12:31 +0900 Subject: [PATCH 1/2] feat(skill): add commit-message-generator skill - Add custom skill for generating Conventional Commits messages - Include guidelines for commit splitting and message formatting - Automate commit message suggestion workflow --- .../skills/commit-message-generator/SKILL.md | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 .github/skills/commit-message-generator/SKILL.md diff --git a/.github/skills/commit-message-generator/SKILL.md b/.github/skills/commit-message-generator/SKILL.md new file mode 100644 index 0000000..19ff1f1 --- /dev/null +++ b/.github/skills/commit-message-generator/SKILL.md @@ -0,0 +1,33 @@ +--- +name: commit-message-generator +description: Generate appropriate commit messages based on Git diffs +--- + +## Prerequisites +- This Skill retrieves Git diffs and suggests meaningful commit messages +- Message format should follow Conventional Commits +- Commit messages should have a one-line Conventional Commits header, an optional blank second line, and from the third line onward include a bulleted list summarizing the changes +- Commit messages should be in English +- **Never perform Git commit or Git push** + +## Steps +1. Run `git status` to check modified files +2. Retrieve diffs with `git diff` or `git diff --cached` +3. Analyze the diff content and determine if changes should be split into multiple commits +4. For each logical group of changes: + - List the target files + - Generate a message in English compliant with Conventional Commits + - Suggest the command: `git add && git commit -m ""` +5. If changes are extensive and should be split, provide: + - Rationale for the split + - Multiple commit suggestions with their respective target files and messages + +## Commit Splitting Guidelines +- Split commits when changes span multiple logical concerns (e.g., feature + refactoring) +- Group related files that serve the same purpose +- Keep each commit focused on a single, atomic change + +## Notes +- **This Skill must never execute `git commit` or `git push`** +- Only suggest commands; execution is entirely at user's discretion +- Users must explicitly perform commits and pushes themselves -- 2.49.1 From cd3f16babd29808b7eab6a7d5e1576aadb96931a Mon Sep 17 00:00:00 2001 From: Daisuke Date: Sun, 18 Jan 2026 20:13:20 +0900 Subject: [PATCH 2/2] feat(blog): add post about managing multiple vterm instances in Emacs - Add post-7.md covering buffer renaming technique for multiple vterm sessions - Include practical use cases and step-by-step guide - Target Emacs users who want to improve terminal workflow efficiency --- src/blog/post-7.md | 50 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 src/blog/post-7.md diff --git a/src/blog/post-7.md b/src/blog/post-7.md new file mode 100644 index 0000000..2068478 --- /dev/null +++ b/src/blog/post-7.md @@ -0,0 +1,50 @@ +--- +title: 'How to Open Multiple vterm Instances in Emacs Using Buffer Renaming' +pubDate: 2026-01-18 +author: 'Nakahara Daisuke' +tags: ["Emacs", "vterm"] +--- + +## Introduction + +If you're using [vterm](https://github.com/akermu/emacs-libvterm) in Emacs, you've probably encountered situations where you need multiple terminal instances running simultaneously. + +This article shows you how to leverage buffer renaming to open multiple vterm instances in Emacs. + +## The Problem: Can You Only Open One vterm? + +By default, when you run `M-x vterm` to start a vterm session and then execute `M-x vterm` again, it simply switches to the existing vterm buffer instead of opening a new terminal. + +This behavior leads many users to believe that "you can only run one vterm instance at a time." + +## The Solution: Rename Your Buffers + +The trick is simple: **by renaming the existing vterm buffer, you can create additional vterm instances**. + +### Step-by-Step Guide + +1. Launch your first vterm with `M-x vterm` +2. Execute `C-x x r` or `M-x rename-buffer` +3. Enter a new buffer name (e.g., `*vterm-dev*`, `*vterm-git*`, etc.) +4. Run `M-x vterm` again to open a new vterm instance + +Repeat these steps as many times as needed to create multiple vterm buffers. + +## Real-World Use Cases + +Here's how I use this workflow in my daily development: + +- **vterm-copilot**: Interactive development with GitHub Copilot CLI +- **vterm-main**: General command execution and file operations + +By managing multiple vterm instances, you can complete all your work without ever leaving Emacs. + +## Conclusion + +With the rise of AI-powered CLI tools, terminal-based workflows are becoming increasingly important. For Emacs users, mastering vterm is more valuable than ever. + +I hope this article helps you boost your development productivity in Emacs! + +--- + +> **Note**: The review and translation were assisted by an AI generative model. The author is responsible for the final content. -- 2.49.1