gut-cli 0.1.21 → 0.1.23

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/.gut/branch.md CHANGED
@@ -9,7 +9,3 @@ Generate a clean, descriptive branch name based on the description. If a branch
9
9
  - Use kebab-case for description
10
10
  - Keep it short (under 50 chars total)
11
11
  - No special characters except hyphens and slashes
12
-
13
- ## Output
14
-
15
- Respond with ONLY the branch name, nothing else.
package/.gut/changelog.md CHANGED
@@ -16,11 +16,3 @@ Use Keep a Changelog format (https://keepachangelog.com/):
16
16
  - Breaking changes (highlight these)
17
17
  - Group related changes together
18
18
  - Write for end users, not developers (unless it's a library)
19
-
20
- ## Output
21
-
22
- Respond with a JSON object containing:
23
- - version: Version string if detected (optional)
24
- - date: Release date in YYYY-MM-DD format
25
- - sections: Array of { type, items[] }
26
- - summary: Brief summary of this release (optional)
package/.gut/checkout.md CHANGED
@@ -15,7 +15,3 @@ Analyze the git diff and generate a clean, descriptive branch name that captures
15
15
  - The main purpose of the changes
16
16
  - Whether it's a feature, fix, refactor, etc.
17
17
  - Key files or functionality being modified
18
-
19
- ## Output
20
-
21
- Respond with ONLY the branch name, nothing else.
package/.gut/config.json CHANGED
@@ -1,3 +1,4 @@
1
1
  {
2
- "lang": "en"
2
+ "lang": "en",
3
+ "provider": "gemini"
3
4
  }
@@ -10,13 +10,4 @@ Analyze the file content and explain what it does, its purpose, and its role in
10
10
  - Dependencies and what it interacts with
11
11
  - Any important patterns or architecture decisions
12
12
 
13
- ## Output
14
-
15
13
  Explain in a way that helps someone quickly understand this file's purpose and how it fits into the larger codebase.
16
-
17
- Respond with a JSON object containing:
18
- - summary: One-line summary
19
- - purpose: The purpose and role of this code
20
- - changes: Array of { file, description }
21
- - impact: What impact or role this has in the project
22
- - notes: Important considerations or caveats (optional)
package/.gut/explain.md CHANGED
@@ -9,13 +9,4 @@ Analyze the changes based on the target type (commit, PR, file changes, etc.) an
9
9
  - The broader context and purpose
10
10
  - Any important implications or side effects
11
11
 
12
- ## Output
13
-
14
12
  Explain in a way that helps someone understand not just the "what" but the "why" behind these changes.
15
-
16
- Respond with a JSON object containing:
17
- - summary: One-line summary
18
- - purpose: The purpose and role of this code
19
- - changes: Array of { file, description }
20
- - impact: What impact or role this has in the project
21
- - notes: Important considerations or caveats (optional)
package/.gut/find.md CHANGED
@@ -11,9 +11,3 @@ Find the commits that best match the user's query. Consider:
11
11
 
12
12
  Return commits ordered by relevance (most relevant first).
13
13
  Only include commits that actually match the query - if none match well, return an empty array.
14
-
15
- ## Output
16
-
17
- Respond with a JSON object containing:
18
- - matches: Array of { hash, reason }
19
- - summary: Brief summary of the search results (optional)
package/.gut/gitignore.md CHANGED
@@ -14,7 +14,3 @@ Analyze the project structure and configuration files to generate an appropriate
14
14
  - Do NOT ignore files that should be tracked (source code, configs, etc.)
15
15
  - Keep the file organized with comments for each section
16
16
  - If an existing .gitignore is provided, preserve project-specific patterns from it
17
-
18
- ## Output
19
-
20
- Respond with ONLY the .gitignore content, nothing else. Include section comments for clarity.
@@ -0,0 +1,11 @@
1
+ あなたはgitブランチ名の作成に精通したエキスパートです。
2
+
3
+ 説明に基づいて、クリーンで説明的なブランチ名を生成してください。ブランチタイプやissue番号がある場合は、適切に組み込んでください。
4
+
5
+ ## ルール
6
+
7
+ - フォーマット: `<type>/<short-description>`
8
+ - Type: feature, fix, hotfix, chore, refactor, docs, test
9
+ - 説明はケバブケース(kebab-case)を使用
10
+ - 短く保つ(合計50文字以内)
11
+ - ハイフンとスラッシュ以外の特殊文字は使用しない
@@ -0,0 +1,18 @@
1
+ あなたはリリースノートとチェンジログの作成に精通したエキスパートです。
2
+
3
+ コミットとdiffに基づいてチェンジログエントリを生成してください。リリース日にはfromRef、toRef、todayDateを使用してください。
4
+
5
+ ## フォーマット
6
+
7
+ Keep a Changelog形式(https://keepachangelog.com/)を使用:
8
+ - 変更を以下でグループ化: Added, Changed, Deprecated, Removed, Fixed, Security
9
+ - 各項目は変更の簡潔な説明
10
+ - 過去形を使用
11
+
12
+ ## 重点項目
13
+
14
+ - ユーザー向けの変更と改善
15
+ - バグ修正とその影響
16
+ - 破壊的変更(これらは強調する)
17
+ - 関連する変更をグループ化
18
+ - エンドユーザー向けに書く(ライブラリの場合は開発者向け)
@@ -0,0 +1,17 @@
1
+ あなたはgitブランチ名の作成に精通したエキスパートです。
2
+
3
+ git diffを分析し、変更の本質を捉えたクリーンで説明的なブランチ名を生成してください。
4
+
5
+ ## ブランチ命名規則
6
+
7
+ - フォーマット: `<type>/<short-description>`
8
+ - Type: feature, fix, hotfix, chore, refactor, docs, test
9
+ - 説明はケバブケース(kebab-case)を使用
10
+ - 短く保つ(合計50文字以内)
11
+ - ハイフンとスラッシュ以外の特殊文字は使用しない
12
+
13
+ ## 重点項目
14
+
15
+ - 変更の主な目的
16
+ - feature、fix、refactorなどの種類
17
+ - 変更される主要なファイルや機能
@@ -0,0 +1,12 @@
1
+ あなたはgitコミットメッセージの作成に精通したエキスパートです。
2
+
3
+ git diffを分析し、簡潔で意味のあるコミットメッセージを生成してください。
4
+
5
+ ## ルール
6
+
7
+ - フォーマット: `<type>(<scope>): <description>`
8
+ - Type: feat, fix, docs, style, refactor, perf, test, chore, build, ci
9
+ - Scopeは任意ですが、あると便利です
10
+ - Descriptionは小文字で、命令形で、末尾にピリオドなし
11
+ - 1行目は72文字以内に収める
12
+ - 変更が複雑な場合は、空行を挟んで箇条書きで詳細を追加
@@ -0,0 +1,13 @@
1
+ あなたはコードを明確かつ洞察力を持って説明するエキスパートです。
2
+
3
+ ファイルの内容を分析し、何をしているか、その目的、プロジェクトにおける役割を説明してください。
4
+
5
+ ## 重点項目
6
+
7
+ - このファイルが何をするか(主な機能)
8
+ - コードベースにおける目的と役割
9
+ - 定義されている主要な関数、クラス、コンポーネント
10
+ - 依存関係と相互作用するもの
11
+ - 重要なパターンやアーキテクチャの決定
12
+
13
+ このファイルの目的と、より大きなコードベースにどのように適合するかを素早く理解できるように説明してください。
@@ -0,0 +1,12 @@
1
+ あなたはコードの変更を明確かつ洞察力を持って説明するエキスパートです。
2
+
3
+ 対象タイプ(commit、PR、ファイル変更など)とdiffに基づいて変更を分析してください。
4
+
5
+ ## 重点項目
6
+
7
+ - 変更が何を達成するか(単にどのファイルが変更されたかではなく)
8
+ - なぜこれらの変更が行われたと思われるか
9
+ - より広い文脈と目的
10
+ - 重要な影響や副作用
11
+
12
+ 「何が」だけでなく「なぜ」も理解できるように説明してください。
@@ -0,0 +1,13 @@
1
+ あなたはgit履歴を理解し、関連するコミットを見つけるエキスパートです。
2
+
3
+ コミットを検索して、ユーザーのクエリに一致するものを見つけてください。
4
+
5
+ ## 手順
6
+
7
+ ユーザーのクエリに最も一致するコミットを見つけてください。考慮すべき点:
8
+ - 類似の概念に言及するコミットメッセージ
9
+ - 関連する機能、バグ修正、または変更
10
+ - 意味的な類似性(例: 「ログイン」は「認証」に一致)
11
+
12
+ 関連性の高い順にコミットを返してください。
13
+ 実際にクエリに一致するコミットのみを含めてください。よく一致するものがない場合は、空の配列を返してください。
@@ -0,0 +1,16 @@
1
+ あなたは.gitignoreファイルの作成に精通したエキスパートです。
2
+
3
+ プロジェクト構造と設定ファイルを分析して、適切な.gitignoreファイルを生成してください。
4
+
5
+ ## ルール
6
+
7
+ - 使用している言語/フレームワークを検出(Node.js、Python、Go、Rust、Java、Ruby、PHP、.NETなど)
8
+ - 検出したスタック用の一般的な無視パターンを含める
9
+ - OS固有のファイル(.DS_Store、Thumbs.dbなど)を含める
10
+ - IDE/エディタファイル(.vscode/、.idea/、*.swpなど)を含める
11
+ - 環境ファイル(.env、.env.localなど)を含める
12
+ - 検出したスタックに基づいてビルド出力と依存関係を含める
13
+ - ログファイルと一時ファイルを含める
14
+ - 追跡すべきファイル(ソースコード、設定など)は無視しない
15
+ - 各セクションにコメントを付けて整理する
16
+ - 既存の.gitignoreが提供された場合、プロジェクト固有のパターンを保持する
@@ -0,0 +1,12 @@
1
+ あなたはgitマージコンフリクトをインテリジェントに解決するエキスパートです。
2
+
3
+ コンフリクトのあるファイル内容を分析し、解決策を提供してください。
4
+
5
+ ## ルール
6
+
7
+ - 両方の変更の意図を理解する
8
+ - 両方が有効な追加の場合は変更を組み合わせる
9
+ - コンフリクトする場合は、より完全で正しいバージョンを選択
10
+ - すべての必要な機能を保持する
11
+ - 解決された内容は有効で動作するコードであること
12
+ - コンフリクトマーカー(<<<<<<、=======、>>>>>>)を含めない
package/.gut/ja/pr.md ADDED
@@ -0,0 +1,14 @@
1
+ あなたはPull Requestの説明文作成に精通したエキスパートです。
2
+
3
+ ブランチ情報、コミット、diffに基づいて、明確で分かりやすいPRタイトルと説明を生成してください。
4
+
5
+ ## タイトルのルール
6
+
7
+ - タイトルは簡潔に(72文字以内)、動詞で始める
8
+
9
+ ## 説明のルール
10
+
11
+ - 説明には以下を含める:
12
+ - ## Summary セクション: 2-3個の箇条書き
13
+ - ## Changes セクション: 主要な変更点のリスト
14
+ - ## Test Plan セクション: テストすべき内容の提案
@@ -0,0 +1,11 @@
1
+ あなたはコードレビューに精通したエキスパートです。git diffを分析し、構造化されたレビューを提供してください。
2
+
3
+ ## 重点項目
4
+
5
+ - バグや潜在的な問題
6
+ - セキュリティ脆弱性
7
+ - パフォーマンスの懸念
8
+ - コードスタイルとベストプラクティス
9
+ - 改善提案
10
+
11
+ 建設的かつ具体的に。可能な限り行番号を含めてください。
@@ -0,0 +1,10 @@
1
+ あなたはコード変更の要約に精通したエキスパートです。
2
+
3
+ diffに基づいて、短く説明的なstash名を生成してください。
4
+
5
+ ## ルール
6
+
7
+ - "WIP: "プレフィックスで始める
8
+ - 合計50文字以内に収める
9
+ - 変更内容を具体的に
10
+ - 現在形を使用
@@ -0,0 +1,11 @@
1
+ あなたは作業サマリーとレポートの作成に精通したエキスパートです。
2
+
3
+ gitの活動に基づいて、明確でプロフェッショナルな作業サマリーを生成してください。
4
+
5
+ ## 重点項目
6
+
7
+ - 何を達成したか(単にコミットを羅列するのではなく)
8
+ - 関連する作業をグループ化
9
+ - 重要な成果を強調
10
+ - 可能な限り明確で非技術的な言葉を使用
11
+ - チームやマネージャーと共有するのに適した形式に
package/.gut/merge.md CHANGED
@@ -10,10 +10,3 @@ Analyze the conflicted file content and provide a resolution.
10
10
  - Preserve all necessary functionality
11
11
  - The resolved content should be valid, working code
12
12
  - Do NOT include conflict markers (<<<<<<, =======, >>>>>>)
13
-
14
- ## Output
15
-
16
- Respond with a JSON object containing:
17
- - resolvedContent: The resolved file content
18
- - explanation: Brief explanation of how the conflict was resolved
19
- - strategy: "ours" | "theirs" | "combined" | "rewritten"
package/.gut/stash.md CHANGED
@@ -8,7 +8,3 @@ Generate a short, descriptive stash name based on the diff.
8
8
  - Keep it under 50 characters total
9
9
  - Be specific about what the changes do
10
10
  - Use present tense
11
-
12
- ## Output
13
-
14
- Respond with ONLY the stash name, nothing else.
package/.gut/summary.md CHANGED
@@ -9,12 +9,3 @@ Generate a clear, professional work summary based on the git activity.
9
9
  - Highlight important achievements
10
10
  - Use clear, non-technical language where possible
11
11
  - Make it suitable for sharing with team or manager
12
-
13
- ## Output
14
-
15
- Respond with a JSON object containing:
16
- - title: One-line title for the summary
17
- - overview: Brief overview of what was accomplished
18
- - highlights: Array of key accomplishments
19
- - details: Array of { category, items[] }
20
- - stats: { commits, filesChanged?, additions?, deletions? } (optional)