keito4 · keito4 · May 7, 2026 · Apr 13, 2026 · May 7, 2026
@@ -1,7 +1,6 @@
 ---
 name: act-local-ci-manager
 description: Use this agent when you need to set up or manage local CI pipeline execution using act (GitHub Actions local runner). This includes: setting up act configuration for testing GitHub Actions workflows locally, configuring Docker environment for act execution, managing secrets and environment variables for local testing, running full CI pipeline validation before pushing code, debugging workflow failures locally, and integrating act with development workflows (pre-commit hooks, VS Code tasks). Examples:\n\n<example>\nContext: The user wants to test their GitHub Actions workflow locally before pushing.\nuser: "I need to test my CI workflow locally before pushing to avoid breaking the build"\nassistant: "I'll help you set up act to run your GitHub Actions workflows locally"\n<commentary>\nSince the user wants to validate CI workflows locally, use the act-local-ci-manager to set up act configuration and run the pipeline.\n</commentary>\nassistant: "Let me use the act-local-ci-manager to configure act for your project"\n</example>\n\n<example>\nContext: The user is experiencing CI failures and wants to debug them locally.\nuser: "My CI is failing on GitHub but I can't reproduce it locally"\nassistant: "I'll set up act so you can run the exact CI environment locally"\n<commentary>\nLocal CI execution with act will help debug workflow failures by providing the same environment as GitHub Actions.\n</commentary>\nassistant: "Let me configure act to replicate your GitHub Actions environment"\n</example>
-model: sonnet
 color: green
 ---
 

@@ -1,7 +1,6 @@
 ---
 name: docs-consistency-checker
 description: Use this agent when: 1) Reviewing pull requests that modify documentation files (README, ADR, XML comments) or public APIs with Swagger/OpenAPI specs, 2) Evaluating PR descriptions that are shorter than 200 characters, 3) Ensuring documentation consistency across different formats and verifying PR descriptions follow the Why/What/How/Risk structure. Examples: <example>Context: User has just created a pull request modifying API endpoints and wants to ensure documentation is consistent. user: "I've updated the user authentication endpoints" assistant: "I'll use the docs-consistency-checker agent to verify all documentation is properly updated and consistent" <commentary>Since the PR involves API changes, the docs-consistency-checker should verify README, ADR, XML comments, and OpenAPI specs are all aligned.</commentary></example> <example>Context: User submitted a PR with a brief description. user: "Fixed login bug" assistant: "The PR description seems brief. Let me use the docs-consistency-checker to evaluate if it meets the Why/What/How/Risk criteria" <commentary>PR description is under 200 characters, triggering the need for documentation review.</commentary></example>
-model: sonnet
 color: cyan
 ---
 

@@ -1,7 +1,6 @@
 ---
 name: playwright-test-generator
 description: Use this agent to automatically generate Playwright E2E tests by observing browser interactions. This agent uses MCP Playwright tools to navigate web applications, record user flows, and generate corresponding test code. Use when: creating new E2E tests, converting manual test cases to automated tests, or generating regression tests for existing features.
-model: sonnet
 color: purple
 ---
 

@@ -1,7 +1,6 @@
 ---
 name: playwright-test-healer
 description: Use this agent to debug and fix failing Playwright E2E tests. This agent analyzes error logs, inspects current page state using MCP browser tools, and provides targeted fixes. Use when: tests are failing due to selector changes, timing issues, or application updates.
-model: sonnet
 color: orange
 ---
 

@@ -1,7 +1,6 @@
 ---
 name: playwright-test-planner
 description: Use this agent to create comprehensive E2E test plans for web applications. This agent explores applications using MCP browser tools to discover features, user flows, and edge cases, then generates structured test plans. Use when: starting E2E testing for a new feature, auditing existing test coverage, or planning regression test suites.
-model: sonnet
 color: blue
 ---
 

@@ -1,7 +1,7 @@
 # Dependabot Auto-merge Workflow
 #
 # Dependabot PR を更新種別に応じて自動処理するワークフロー
-# - patch: CI パス後に自動 squash マージ
+# - patch: CI パス後に自動マージ
 # - minor: 自動承認（マージは手動）
 # - major: ラベル付与してレビュー必須
 #
@@ -41,11 +41,11 @@ jobs:
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}
 
-      # patch: 自動 squash マージ（CI パス後）
+      # patch: 自動マージ（CI パス後）
       - name: Auto-merge patch updates
         if: github.actor == 'dependabot[bot]' && steps.metadata.outputs.update-type == 'version-update:semver-patch'
         run: |
-          gh pr merge "$PR_URL" --auto --squash
+          gh pr merge "$PR_URL" --auto --merge
         env:
           PR_URL: ${{ github.event.pull_request.html_url }}
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

@@ -1,7 +1,7 @@
 # Dependabot Auto-merge Workflow
 #
 # Dependabot PR を更新種別に応じて自動処理するワークフロー
-# - patch: CI パス後に自動 squash マージ
+# - patch: CI パス後に自動マージ
 # - minor: 自動承認（マージは手動）
 # - major: ラベル付与してレビュー必須
 #
@@ -41,11 +41,11 @@ jobs:
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}
 
-      # patch: 自動 squash マージ（CI パス後）
+      # patch: 自動マージ（CI パス後）
       - name: Auto-merge patch updates
         if: github.actor == 'dependabot[bot]' && steps.metadata.outputs.update-type == 'version-update:semver-patch'
         run: |
-          gh pr merge "$PR_URL" --auto --squash
+          gh pr merge "$PR_URL" --auto --merge
         env:
           PR_URL: ${{ github.event.pull_request.html_url }}
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}