VS Code on KnightLiブログ

エージェントスキルを使用して、VS Code の Copilot の「コミットメッセージの生成」機能を置き換える

Mon, 06 Apr 2026 13:09:49 +0800

VS Code の GitHub Copilot の「コミットメッセージの生成」は非常に便利な機能です。クォータを使い果たした後のリセット期間は非常に長くなります。この記事は、ローカルエージェントスキルを使用してこの機能を置き換える試みです。

問題と目標

この記事の目的は、直接実装できる代替手段のセットを提供することです。つまり、git-commit-push-zh スキルエージェントを使用して、標準化された送信とプッシュを完了します。

代替: `git-commit-push-zh`

このスキルは、「現在の変更」を固定プロセスに収束します。

変更ステータスを表示します。
現在のブランチを確認します。
変更を一時的に保存します。
中国語の提出情報を生成します。
コミットを実行します。
リモートブランチにプッシュします。

対応するコマンドは次のとおりです。

git status --short
git branch --show-current
git add -A
git commit -m "<中文提交信息>"
git push origin <当前分支>

情報提案仕様書の提出

推奨される統一形式:

`1`	`<类型>(<范围>): <中文摘要>`

タイプの例:

feat: 新機能
fix: 問題を修正
docs: ドキュメントの更新
refactor: コードのリファクタリング
chore: メンテナンスの変更

例：

feat(site): 新增全站 head 广告脚本注入
fix(i18n): 修正 relref 相关文章链接路径
chore(content): 合并 AI 工作流分类到 AI工具

一般的な障害シナリオ

nothing to commit: 現在、送信する変更はありません。プッシュを停止してください。
push が失敗しました: 最初に権限、リモートブランチのステータス、競合を確認してください。
SSH/権限の例外: 認証情報と権限を確認して、再試行してください。

付録: オリジナル `SKILL.md`

次の内容は git-commit-push-zh の元のドキュメントであり、その後の再利用とメンテナンスを容易にするためにそのまま保持されます。

---
name: git-commit-push-zh
description: 在当前 Git 仓库中将“当前更改”完成一次标准提交流程：检查状态、暂存变更、生成中文提交信息、执行 commit 并 push 到当前分支对应远端。用户提出“提交代码”“提交当前更改”“生成中文提交信息并推送”“git commit push 中文说明”等请求时使用。
---

# 中文提交并推送

使用此技能将当前仓库改动一次性提交并推送到远端。

## 工作流程

1. 查看变更状态：`git status --short`。
2. 确认当前分支：`git branch --show-current`。
3. 暂存当前变更：`git add -A`。
4. 生成中文提交信息（简洁、可检索）。
5. 执行提交：`git commit -m "<中文提交信息>"`。
6. 执行推送：`git push origin <当前分支>`。

## 提交信息规范（中文）

1. 建议格式：`<类型>(<范围>): <中文摘要>`。
2. 类型示例：`feat`、`fix`、`chore`、`docs`、`refactor`。
3. 摘要要求：准确描述本次改动，不写空话。
4. 若仅少量变更，也保持可读性与可检索性。

示例：

- `feat(site): 新增全站 head 广告脚本注入`
- `fix(i18n): 修正 relref 相关文章链接路径`
- `chore(content): 合并 AI 工作流分类到 AI工具`

## 错误处理

1. 若无可提交变更（nothing to commit），明确告知并停止 push。
2. 若 push 失败，先回报关键错误（权限、远端不存在、冲突等）。
3. 常见 SSH/权限问题可在用户确认后重试高权限环境。

## 输出约定

1. 汇报提交哈希、分支名、提交信息。
2. 汇报 push 结果（成功或失败原因）。
3. 仅在确有失败时提供下一步最小操作建议。

プラグインによって引き起こされる VS Code の高い CPU 使用率をトラブルシューティングする方法

Wed, 01 Apr 2026 00:00:00 +0000

VS Code が突然フリーズしたり、ファンが激しく回転したり、CPU が長時間占有されたりした場合、最も一般的な原因は通常、エディタ自体ではなく、拡張プラグインの競合またはプラグインの異常な動作です。

この記事では、問題を特定するために最も時間を節約できる方法を優先して、すぐに実行できる一連のトラブルシューティングパスを示します。

最初に最速の位置決めを実行します: Extension Bisect を開始します

Start Extension Bisect の核となるアイデアは次の二項対立です。各ラウンドでは、拡張機能の半分が一時的に無効になり、再起動されます。「問題がまだ存在するかどうか」というフィードバックを通じて、疑わしいプラグインが見つかるまで範囲がすぐに狭められます。

操作手順:

Ctrl+Shift+P (macOS では Cmd+Shift+P) を押してコマンドパネルを開きます。
Start Extension Bisect を入力して実行します。
再起動するたびに、CPU 使用率とフリーズが再発するかどうかを観察します。
数回繰り返すと、VS Code によって疑わしい拡張機能のリストが表示されます。

位置決め後に何をするか

疑わしいプラグインを見つけたら、次の順序で対処することをお勧めします。

まずプラグインを最新バージョンに更新してください。
改善が見られない場合は、プラグインを一時的に無効にして 1 ～ 2 日間観察してください。
置き換え可能な機能を持つプラグインについては、より軽量なソリューションへの置き換えが優先されます。
このプラグインを使用する必要がある場合は、その詳細設定を確認し、不要なリアルタイム分析、インデックス作成、または監視機能をオフにしてください。

見落とされがちな2つの「増幅器」

主な原因がプラグインである場合でも、次の構成により CPU の問題が増幅されます。

検索範囲が大きすぎます
たとえば、ビルド製品、依存関係ディレクトリ、ログディレクトリをグローバル検索に含めると、引き続きプラグインとファイルインデックスに高い負荷がかかります。
ファイル監視には大きなディレクトリまたはソフトリンクが含まれています
ソフトリンク、キャッシュディレクトリ、および自動生成されたディレクトリは、簡単に多数のファイルイベントをトリガーし、拡張機能が繰り返し動作する可能性があります。

ディレクトリは、settings.json で適切に除外できます。たとえば、次のようになります。

{
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true
  },
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/node_modules/**": true,
    "**/dist/**": true
  }
}

提案をレビューする

問題のあるプラグインを見つけた場合は、プラグイン名、トリガーとなるシナリオ、最終的な処理方法の 3 つの情報を記録することをお勧めします。
このようにして、次回環境を移行するかシステムを再インストールするときに、同様の問題をすぐに回避できます。

要約する

VS Code の高い CPU 使用率をトラブルシューティングするには、最初に Start Extension Bisect を使用して迅速に特定し、次に検索範囲とファイル監視範囲を組み合わせて収束させるのが最も効果的です。
最初に配置を決めてから最適化する方が、「多数のプラグインをやみくもに無効にする」よりも時間を節約でき、安定性も高くなります。