shirokuma-docs 0.1.0-alpha.1

package/plugin/shirokuma-skills-en/skills/showing-github/reference/github-operations.md

@@ -0,0 +1,163 @@
+# GitHub Operations Reference
+
+Shared reference for all session/GitHub skills. Single source of truth for CLI commands, workflows, and conventions.
+
+## Architecture: Issues + Projects Hybrid
+
+| Component | Purpose |
+|-----------|---------|
+| **Issues** | Task management, `#123` references, history |
+| **Projects** | Status/Priority/Type/Size field management |
+| **Labels** | Type identification only (`feature`, `bug`, `chore`) |
+| **Discussions** | Handovers, Specs, Decisions, Q&A |
+
+**Status is managed via Projects fields** (not Labels).
+
+Project naming convention: Project name = repository name (e.g., `blogcms` repo → `blogcms` project).
+
+## Prerequisites
+
+- `gh` CLI installed and authenticated
+- GitHub Project configured (run `/project-setup` if not)
+- Discussions enabled with categories: Handovers, Ideas, Q&A (optional)
+
+## DraftIssue vs Issue
+
+| Feature | DraftIssue | Issue |
+|---------|-----------|-------|
+| `#number` | No | Yes (`#123`) |
+| External reference | No | Yes |
+| Comments | No | Yes |
+| Create command | `projects create` | `issues create` |
+| Use case | Lightweight memo | Full task |
+
+**Recommendation**: Use `issues create` by default for `#number` support.
+
+## shirokuma-docs CLI Reference
+
+Prefer shirokuma-docs CLI over direct `gh` commands. Config in `shirokuma-docs.config.yaml`.
+
+### Issues (Primary Interface)
+
+```bash
+shirokuma-docs issues list                          # Open issues
+shirokuma-docs issues list --all                    # Include closed
+shirokuma-docs issues list --status "In Progress"   # Filter by status
+shirokuma-docs issues show {number}                  # Details
+shirokuma-docs issues create \
+  --title "Title" --body "Body" \
+  --labels feature \
+  --field-status "Backlog" --priority "Medium" --type "Feature" --size "M"
+shirokuma-docs issues update {number} --field-status "In Progress"
+shirokuma-docs issues comment {number} --body "..."
+shirokuma-docs issues close {number}
+shirokuma-docs issues reopen {number}
+```
+
+### Projects (Low-level Access)
+
+```bash
+shirokuma-docs projects list                        # Project items
+shirokuma-docs projects fields                      # Show field options
+shirokuma-docs projects add-issue {number}          # Add issue to project
+shirokuma-docs projects create \
+  --title "Title" --body "Body" \
+  --field-status "Backlog" --priority "Medium"               # DraftIssue
+shirokuma-docs projects get PVTI_xxx                # By item ID
+shirokuma-docs projects update {number} --field-status "Done"
+```
+
+### Discussions
+
+```bash
+shirokuma-docs discussions list --category Handovers --limit 5
+shirokuma-docs discussions get {number}
+shirokuma-docs discussions create \
+  --category Handovers \
+  --title "$(date +%Y-%m-%d) - Summary" \
+  --body "Content"
+```
+
+### Repository
+
+```bash
+shirokuma-docs repo info
+shirokuma-docs repo labels
+```
+
+### Cross-repo Operations
+
+```bash
+shirokuma-docs issues list --repo docs
+shirokuma-docs issues create --repo docs --title "Title" --body "Body"
+```
+
+### gh Fallback (CLI unsupported only)
+
+```bash
+# Labels
+gh issue edit {number} --add-label "label"
+gh issue edit {number} --remove-label "label"
+gh label list
+gh label create "name" --color "0E8A16" --description "Desc"
+
+# Pull Requests
+gh pr list --state open
+gh pr view {number}
+gh pr comment {number} --body "..."
+
+# Repository info
+gh repo view --json nameWithOwner -q '.nameWithOwner'
+
+# Authentication
+gh auth login
+gh auth status
+```
+
+## Status Workflow
+
+```mermaid
+graph LR
+  Icebox --> Backlog --> SpecReview[Spec Review] --> Ready --> InProgress[In Progress]
+  InProgress --> Review --> Testing --> Done --> Released
+  InProgress <--> Pending["Pending (blocked)"]
+```
+
+| Status | Description |
+|--------|-------------|
+| Icebox | Low priority, not yet planned |
+| Backlog | Planned for future work |
+| Spec Review | Requirements being reviewed |
+| Ready | Ready to start |
+| In Progress | Currently working on |
+| Pending | Blocked (document reason) |
+| Review | Code review |
+| Testing | QA testing |
+| Done | Completed |
+| Released | Deployed to production |
+
+## Labels Convention
+
+Labels are used for **Type identification only** (Status is via Projects fields):
+
+| Label | Purpose |
+|-------|---------|
+| `feature` | New functionality |
+| `bug` | Bug fix |
+| `chore` | Maintenance |
+| `docs` | Documentation |
+| `research` | Investigation |
+
+Optional priority labels: `priority:critical`, `priority:high`
+
+## Common Error Handling
+
+| Error | Action |
+|-------|--------|
+| `shirokuma-docs: command not found` | Install: `npm i -g @shirokuma-library/shirokuma-docs` |
+| `gh: command not found` | Install: `brew install gh` or `sudo apt install gh` |
+| `not logged in` / `not authenticated` | Run: `gh auth login` |
+| No project found | Run `/project-setup` to create one |
+| Discussions disabled/category not found | Use local file fallback |
+| `HTTP 404` | Check repository name and permissions |
+| API rate limit | Show cached/partial data |

package/plugin/shirokuma-skills-en/skills/starting-session/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: starting-session
+description: Start a work session showing project status and previous handovers. Use when "start session", "begin work".
+allowed-tools: Bash, Read, Grep, AskUserQuestion
+---
+
+# Starting Session
+
+Start a new work session and display project context.
+
+## Workflow
+
+### Step 1: Fetch Session Context (Single Command)
+
+```bash
+shirokuma-docs session start
+```
+
+This returns JSON with:
+- `repository` - Current repository
+- `git` - Git state (`currentBranch`, `uncommittedChanges`, `hasUncommittedChanges`)
+- `lastHandover` - Latest handover (null if none)
+- `backups` - PreCompact session backups (if any exist from interrupted sessions)
+- `issues` - Active issues with project fields (Done/Released excluded)
+- `total_issues` - Count of active issues
+
+### Step 1b: Backup Detection
+
+If the `backups` field is present, a previous session may have been interrupted before proper handover.
+Show the backup contents (branch, uncommitted changes, recent commits) to help the user recover context.
+
+### Step 2: Display Session Context
+
+Parse the JSON output and display:
+
+```markdown
+## Session Started
+
+**Repository:** {repository}
+**Time:** {current time}
+**Branch:** {git.currentBranch} {git.hasUncommittedChanges ? "(uncommitted changes)" : "(clean)"}
+
+### Previous Handover
+{lastHandover.title or "None found"}
+- Summary: {parse body for Summary section}
+- Next Steps: {parse body for Next Steps section}
+
+### Active Issues
+
+**In Progress:**
+- #{number} {title} (Priority: {priority}, Size: {size})
+
+**Ready ({count}):**
+- #{number} {title}
+
+**Backlog ({count}):**
+- #{number} {title}
+```
+
+Group issues by status: In Progress → Ready → Backlog → Icebox → (no status)
+
+If there are uncommitted changes (`git.hasUncommittedChanges`), inform the user before proceeding.
+
+### Step 3: Ask for Direction
+
+Use AskUserQuestion to present the top items as selectable options. Include the highest-priority In Progress and Ready items as options, plus an "Other" option for free-form input.
+
+If the session has many active items, prioritize showing In Progress items first, then Ready, then top Backlog items (max 4 options total).
+
+## If Item Selected
+
+Route to the appropriate skill based on the issue's status.
+
+### Status-Based Routing
+
+| Issue Status | Delegate To | Reason |
+|-------------|-------------|--------|
+| Backlog | `planning-on-issue` | Needs planning |
+| Planning | `planning-on-issue` | Planning in progress |
+| Spec Review | `working-on-issue` | Implicit approval, start implementation |
+| In Progress | `working-on-issue` | Resume work |
+| Review / Pending | `working-on-issue` | Continue work |
+| (Other / No status) | `working-on-issue` | Default |
+
+### Skill Invocation
+
+```
+Skill: {skill name based on routing table}
+Args: #{number}
+```
+
+`working-on-issue` handles status update, branch creation, plan check, skill selection, execution, and post-work flow.
+`planning-on-issue` handles plan creation and status transitions.
+Do NOT duplicate status updates or branch creation in `starting-session`.
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| `shirokuma-docs: command not found` | Install: `pnpm install` in shirokuma-docs |
+| `gh: command not found` | Install: `brew install gh` or `sudo apt install gh` |
+| `not logged in` | Run: `gh auth login` |
+| lastHandover is null | Show "No previous handover found" |
+| issues is empty | Show "No active issues" |
+| git pull fails | Warn and continue with local base branch |
+
+## Notes
+
+- Always show current time in session header
+- Parse handover body for Summary and Next Steps sections
+- Show items in priority order within each status
+- Done/Released items are automatically excluded by `session start`
+- After item selection, delegate to `working-on-issue` or `planning-on-issue` based on status-based routing (do not duplicate status update or branch creation)
+- Do not use raw `gh` commands directly (use `shirokuma-docs session start` instead)

package/plugin/shirokuma-skills-en/skills/working-on-issue/SKILL.md

@@ -0,0 +1,261 @@
+---
+name: working-on-issue
+description: Work dispatcher that takes an issue number or task description, selects the appropriate skill, and orchestrates the workflow. Use when "work on", "work on #42".
+allowed-tools: Bash, Read, Grep, Glob, AskUserQuestion, TodoWrite
+---
+
+# Working on Issue
+
+Dispatch work to the appropriate skill based on issue type or task description.
+
+**Note**: This skill is for starting **work on a specific task**. For session setup (context display, handover review), use `starting-session` instead.
+
+## Core Concept
+
+This skill is the **entry point for all work**. It analyzes what needs to be done, delegates to the right skill, then executes the workflow sequentially.
+
+```
+/working-on-issue #42 → Analyze → Select Skill → Execute → Commit → PR → Review
+```
+
+The workflow is **always executed sequentially**. No user confirmation between steps.
+
+### TodoWrite Registration (Required)
+
+Register **all chain steps** in TodoWrite **before starting work**.
+
+**Implementation / Design / Bug Fix:**
+
+| # | content | activeForm | Skill |
+|---|---------|------------|-------|
+| 1 | Implement changes | Implementing changes | `nextjs-vibe-coding` / `frontend-designing` |
+| 2 | Commit and push changes | Committing and pushing | `committing-on-issue` |
+| 3 | Create pull request | Creating pull request | `creating-pr-on-issue` |
+| 4 | Run self-review and post results to PR | Running self-review and posting results | `creating-pr-on-issue` Step 6 (no separate invocation needed) |
+
+**Refactoring / Chore:**
+
+| # | content | activeForm | Skill |
+|---|---------|------------|-------|
+| 1 | Make changes | Making changes | Direct edit |
+| 2 | Commit and push changes | Committing and pushing | `committing-on-issue` |
+| 3 | Create pull request | Creating pull request | `creating-pr-on-issue` |
+| 4 | Run self-review and post results to PR | Running self-review and posting results | `creating-pr-on-issue` Step 6 (no separate invocation needed) |
+
+**Research:**
+
+| # | content | activeForm | Skill |
+|---|---------|------------|-------|
+| 1 | Conduct research | Conducting research | `best-practices-researching` |
+| 2 | Save findings to Discussion | Creating Discussion | `shirokuma-docs discussions create` |
+
+Update each step to `in_progress` when starting and `completed` when done.
+When `creating-pr-on-issue` completes (including self-review), mark Steps 3 and 4 as `completed` simultaneously.
+
+## Workflow
+
+### Step 1: Analyze Work
+
+**If issue number provided:**
+
+```bash
+shirokuma-docs issues show {number}
+```
+
+Extract from the response:
+- `title` - What to do
+- `body` - Detailed requirements
+- `type` - Feature / Bug / Chore / Docs / Research
+- `status` - Current status
+- `priority` - Priority level
+- `size` - Size estimate
+
+#### Plan Requirement Check (when issue number provided)
+
+Check whether the issue body contains a `## Plan` section (detected by `^## Plan` line prefix match).
+
+| Plan state | Action |
+|-----------|--------|
+| No plan | → Delegate to `planning-on-issue` to create a plan (all issues) |
+| Plan exists | → Pass the `## Plan` section as context to the implementation skill |
+
+- Plan depth is automatically determined by `planning-on-issue` based on issue content (lightweight/standard/detailed)
+
+#### Transition from Planning Status
+
+When the issue status is Planning:
+
+| Plan state | Action |
+|-----------|--------|
+| Planning + no plan | → Delegate to `planning-on-issue` (continue planning) |
+| Planning + plan exists | → Transition to Spec Review and ask user for approval (no implicit approval) |
+
+For the Planning + plan exists case (e.g., session interruption), display the plan summary and request confirmation.
+
+**If text description provided:**
+
+Classify the work type from keywords:
+
+| Keywords | Work Type |
+|----------|-----------|
+| "implement", "create", "add", "build", "実装", "作成", "追加", "構築" | Implementation |
+| "design", "UI", "デザイン", "印象的", "ランディング" | Design |
+| "fix", "bug", "修正", "バグ" | Bug Fix |
+| "refactor", "clean", "リファクタ", "整理" | Refactoring |
+| "research", "investigate", "調査", "検討" | Research |
+| "review", "audit", "レビュー", "チェック" | Review |
+| "config", "setup", "設定", "セットアップ" | Chore |
+
+### Step 2: Update Status (if issue number)
+
+If the issue is not already In Progress:
+
+```bash
+shirokuma-docs issues update {number} --field-status "In Progress"
+```
+
+**Spec Review implicit approval**: If the issue's Status is Spec Review, the user invoking `/working-on-issue` is an implicit approval of the plan. Transition to In Progress without additional confirmation.
+
+**Transition from Planning**: Follow the "Transition from Planning Status" logic above. If no plan, delegate to `planning-on-issue` (the skill handles status updates). If plan exists, transition to Spec Review and wait for approval.
+
+### Step 3: Ensure Feature Branch
+
+Check current git state:
+
+```bash
+git branch --show-current
+```
+
+If on `develop` (or `main`) and issue number provided, create a feature branch:
+
+```bash
+git checkout develop && git pull origin develop
+git checkout -b {type}/{number}-{slug}
+```
+
+Branch type mapping:
+
+| Issue Type / Work Type | Branch prefix |
+|------------------------|---------------|
+| Feature, Implementation, Design | `feat` |
+| Bug, Bug Fix | `fix` |
+| Chore, Refactoring, Config | `chore` |
+| Docs | `docs` |
+| Research | `chore` |
+
+If already on an appropriate feature branch, stay on it.
+
+### Step 3b: Propose ADR for Feature M+ (Optional)
+
+For **Feature** type issues with **Size M or larger**, suggest creating an ADR (AskUserQuestion).
+
+### Step 4: Select and Execute Skill
+
+Based on work type, invoke the appropriate skill:
+
+| Work Type | Skill | Invocation |
+|-----------|-------|------------|
+| Implementation | `nextjs-vibe-coding` | Skill tool |
+| Design | `frontend-designing` | Skill tool |
+| Bug Fix | `nextjs-vibe-coding` | Skill tool |
+| Refactoring | Direct (no skill) | Edit files directly |
+| Research | `best-practices-researching` | Skill tool (runs as sub-agent via `context: fork`) |
+| Review | `reviewing-on-issue` | Skill tool (runs as sub-agent via `context: fork`) |
+| Chore | Direct (no skill) | Edit files directly |
+
+**Pass context to the skill:**
+- Issue title and body (requirements)
+- Related files mentioned in the issue
+- Current branch name
+
+### Step 5: Sequential Workflow Execution
+
+After the primary skill completes, execute the workflow chain **automatically and sequentially**. No user confirmation between steps.
+
+**Prerequisite**: All chain steps must already be registered in TodoWrite (see "TodoWrite Registration" above).
+Update each step to `in_progress` when starting and `completed` when done.
+
+**Chain sequence by work type:**
+
+| Work Type | Chain |
+|-----------|-------|
+| Implementation / Design / Bug Fix | Work → Commit → PR → Review |
+| Refactoring / Chore | Work → Commit → PR → Review |
+| Research | Research → Discussion |
+
+- Do NOT ask the user between steps — execute each step and move to the next
+- DO report what is happening at each step (one-line status)
+- DO update TodoWrite status for each step (`in_progress` → `completed`)
+- **Self-review loop**: After PR creation, run `reviewing-on-issue` via `creating-pr-on-issue`'s self-review chain (Step 6)
+  - FAIL + Auto-fixable → auto-fix → commit → push (PR updates automatically) → re-review
+  - Maximum 3 iterations (initial review + up to 2 fix-and-review cycles)
+  - Stop loop if issue count increases between iterations
+- The Review step uses `reviewing-on-issue` by default. If the project has additional review checklists or project-specific skills (e.g., in `.claude/skills/`), invoke them alongside `reviewing-on-issue`
+- **Step 4 completion criteria**: Mark as `completed` only after `reviewing-on-issue` has saved its report AND the PR comment has been confirmed posted. Do not mark complete on Self-Review Result return alone
+- **Feedback accumulation**: Record self-review finding patterns to Discussion (Reports). Propose rule creation for frequent patterns (3+ occurrences)
+- If a step fails, stop the chain, report the error with completed/remaining steps summary, and return control to the user
+
+## Arguments
+
+| Format | Example | Behavior |
+|--------|---------|----------|
+| Issue number | `/working-on-issue 42` or `/working-on-issue #42` | Fetch issue, analyze type |
+| Description | `/working-on-issue implement user dashboard` | Classify from text |
+| No argument | `/working-on-issue` | Ask user what to work on |
+
+## Display Format
+
+Show a brief summary before starting work:
+
+```markdown
+## Working on: #{number} {title}
+
+**Type:** {type} → **Skill:** {skill-name}
+**Branch:** {branch-name}
+**Priority:** {priority}
+```
+
+## Edge Cases
+
+| Situation | Action |
+|-----------|--------|
+| Issue not found | Show error, use AskUserQuestion for correct number |
+| Issue already Done/Released | Warn user, use AskUserQuestion to confirm reopen |
+| Issue already In Progress | Continue without status change |
+| Work type unclear | Use AskUserQuestion with work type options |
+| Skill execution fails | Report error, suggest manual approach |
+| Already on wrong feature branch | Use AskUserQuestion: switch branch or continue here? |
+| On `main` instead of `develop` | Switch to `develop` before branching |
+| No argument provided | Show active issues, use AskUserQuestion to pick |
+| Chain fails mid-execution | Report completed steps and remaining steps, return control to user |
+
+## Rule References
+
+This skill depends on the following rules (auto-loaded from `.claude/rules/`):
+
+| Rule | Usage |
+|------|-------|
+| `branch-workflow` | Branch naming, creation from `develop`, PR target |
+| `project-items` | Status workflow, field requirements, body maintenance |
+| `git-commit-style` | Commit message format (delegated to `committing-on-issue` skill) |
+
+## Tool Usage
+
+| Tool | When |
+|------|------|
+| AskUserQuestion | Requirement clarification, approach selection, edge case decisions (unclear work type, issue not found, branch mismatch, etc.) |
+| TodoWrite | Chain step registration (required for all work), multi-issue session progress tracking |
+| Bash | Git operations, `shirokuma-docs issues` commands |
+
+**AskUserQuestion**: Use when user input is genuinely needed (requirement clarification, approach selection, edge case decisions). Do NOT use for workflow step transitions (Commit → PR → Review).
+
+**TodoWrite**: Used for all work. Register all chain steps before starting and update each step's progress as `in_progress` → `completed`.
+
+## Notes
+
+- This skill is the **primary entry point** for work
+- Always update issue status before starting
+- Always ensure correct feature branch
+- Workflow always executes sequentially (Commit → PR → Review)
+- Chain execution stops on error and returns control to user
+- For direct work (Refactoring/Chore), no skill delegation needed

package/plugin/shirokuma-skills-ja/.claude-plugin/plugin.json

@@ -0,0 +1,21 @@
+{
+  "name": "shirokuma-skills-ja",
+  "description": "Japanese version of shirokuma-skills - AI skills and rules for Claude Code",
+  "version": "0.1.0-alpha.1",
+  "author": {
+    "name": "ShirokumaLibrary"
+  },
+  "homepage": "https://github.com/ShirokumaLibrary/shirokuma-docs",
+  "repository": "https://github.com/ShirokumaLibrary/shirokuma-docs",
+  "keywords": [
+    "claude-code",
+    "skills",
+    "rules",
+    "nextjs",
+    "typescript",
+    "japanese",
+    "i18n",
+    "agent-skills"
+  ],
+  "license": "MIT"
+}

package/plugin/shirokuma-skills-ja/rules/best-practices-first.md

@@ -0,0 +1,43 @@
+# ベストプラクティスファーストモード（マネージャー）
+
+**役割**: 専門スキルへの委任を優先し、直接作業を最小化する。
+
+## 推奨エントリーポイント
+
+ユーザーが Issue 番号や作業内容を提供した場合 → `working-on-issue` に委任。
+`working-on-issue` が計画の有無を確認し、未計画なら `planning-on-issue` に自動委任する。
+
+以下の判断フローは `working-on-issue` が適用できない場合のみ使用。
+
+## スキルルーティング
+
+| タスクタイプ | 委任先 | メソッド |
+|-------------|--------|----------|
+| 実装 / デザイン | `nextjs-vibe-coding` / `frontend-designing` | Skill（via `working-on-issue`） |
+| リサーチ | `best-practices-researching` | Skill (`context: fork`) |
+| レビュー | `reviewing-on-issue` | Skill (`context: fork`) |
+| Claude 設定 | `claude-config-reviewing` | Skill (`context: fork`) |
+| Issue / Discussion 作成 | `managing-github-items` | Skill |
+| GitHub データ表示 | `showing-github` | Skill |
+| 探索 | `Explore` | Task (ビルトイン) |
+| アーキテクチャ | `Plan` | Task (ビルトイン) |
+| 該当なし | 新しいスキルを提案 | — |
+
+## 直接対応OK
+
+簡単な質問、軽微な設定編集、スキル結果の微調整、確認ダイアログ。
+
+## ツール使い分け
+
+- **AskUserQuestion**: 指示からの逸脱、複数アプローチの選択、エッジケースの判断
+- **TodoWrite**: 3ステップ以上のタスク、マルチ Issue、委任チェーン
+
+## エラー回復
+
+障害発生時は根本原因を分析し、**必ずシステム改善を提案**（設定ファイルへの変更）。
+「次回気をつけます」ではなく、設定ファイルの具体的な変更を提示すること。
+
+## GitHub 操作
+
+- `shirokuma-docs gh-*` CLI を使用（直接 `gh` は禁止）
+- クロスリポジトリ: `--repo {alias}` を使用

package/plugin/shirokuma-skills-ja/rules/config-authoring-flow.md

@@ -0,0 +1,39 @@
+# 設定ファイル作成フロー
+
+Claude Code の設定ファイル（ルール、スキル、エージェント、出力スタイル、プラグイン）を作成・更新する際は、このフローに従い品質と一貫性を確保してください。
+
+## 必要なツール
+
+| ツール | タイプ | タイミング |
+|--------|--------|-----------|
+| `managing-rules` | スキル | ルールの作成・更新時 |
+| `managing-skills` | スキル | スキルの作成・更新時 |
+| `managing-agents` | スキル | エージェントの作成・更新時 |
+| `managing-output-styles` | スキル | 出力スタイルの作成・更新時 |
+| `managing-plugins` | スキル | プラグインの作成・更新時 |
+| `claude-config-reviewing` | スキル | 設定の作成・更新後（品質チェック） |
+
+## フロー
+
+1. **書く前に**: 関連する managing-* スキルを起動してベストプラクティスとテンプレートを取得
+2. **書く**: スキルのガイダンスに従い設定ファイルを作成・更新
+3. **書いた後に**: `claude-config-reviewing` スキルを実行して品質を検証
+
+### 例: 新しいルールの作成
+
+```
+1. managing-rules スキルを起動 -> テンプレートとベストプラクティスを取得
+2. plugin/shirokuma-skills-ja/rules/my-rule.md を作成
+3. claude-config-reviewing スキルを起動 -> 品質と一貫性を検証
+```
+
+## 適用対象
+
+- `.claude/rules/`, `.claude/skills/`, `.claude/agents/`, `.claude/output-styles/`, `.claude/commands/` への新規ファイル作成
+- `plugin/` ディレクトリ（skills, agents, rules, plugins）への新規ファイル作成
+- 構造的な変更を伴う既存設定ファイルの更新（タイポ修正は除く）
+
+## 例外
+
+- 軽微なタイポ修正や1行のみの編集はフルフロー不要
+- ユーザーから明示的に指示された場合、レビュースキルのステップはスキップ可能

package/plugin/shirokuma-skills-ja/rules/git-commit-style.md

@@ -0,0 +1,21 @@
+# Git コミットスタイル
+
+Conventional Commits 形式: `{type}: {description} (#{issue-number})`
+
+**タイプ**: `feat` | `fix` | `refactor` | `docs` | `test` | `chore`
+
+## プロジェクト固有ルール
+
+- 1行目は72文字以内、命令形（"add feature" not "added feature"）
+- 該当する場合は Issue 番号を参照: `(#39)`
+- **`Co-Authored-By` 署名は付けない**
+- `--no-verify` 禁止、明示的な依頼なしに amend 禁止、ベースブランチに force push 禁止
+
+## コード言語
+
+| 要素 | 言語 |
+|------|------|
+| コード / 変数名 | English |
+| コメント / JSDoc | 日本語 |
+| コミットメッセージ | 日本語（プレフィックスは English: `feat:`, `fix:` 等） |
+| CLI 出力 | i18n 辞書 (`i18n/cli/`) |