Home

Taroskyのオーガニゼーションで共有しているワークフロー＆複合アクションです。

ワークフロー

.github/workflowsに格納されています。それ自体で完結します。各オプションはymlファイルの先頭に記載されているinputs項目で確認できます。オプションはjob内のwithで指定します。

PHPUnit

PHP+MySQL+WordPressをインストールし、ユニットテストを行います。リポジトリにcomposerが入っており、PHPUnitをcomposer scriptから実行できる必要があります。デフォルトのコマンドは test です。変更する場合は composer_command: unittest というように指定してください。

jobs:
  test:
    strategy:
      matrix:
        php: [ '7.3', '7.4', '8.0' ] # PHP versions to check.
        wp: [ 'latest', '5.9' ]      # WordPress version to check.
    uses: tarosky/workflows/.github/workflows/wp-unit-test.yml@main
    with:
        php_version: ${{ matrix.php }}
        wp_version: ${{ matrix.wp }}

コードカバレッジ

coverage: true を指定すると、pcovを使ったコードカバレッジ計測が有効になります。結果はGitHub Job Summaryに出力され、coverage.xml（Clover形式）がartifactとしてアップロードされます。

jobs:
  test:
    strategy:
      matrix:
        php: [ '7.4', '8.0' ]
        wp: [ 'latest', '5.9' ]
    uses: tarosky/workflows/.github/workflows/wp-unit-test.yml@main
    with:
        php_version: ${{ matrix.php }}
        wp_version: ${{ matrix.wp }}
        # PHP 8.0 + latest の組み合わせでのみカバレッジを計測
        coverage: ${{ matrix.php == '8.0' && matrix.wp == 'latest' }}

呼び出し側の phpunit.xml.dist に <coverage> セクションが必要です。また、composer test が PHPUnit を直接呼んでおり、-- でPHPUnit引数を渡せる前提です。

<coverage processUncoveredFiles="true">
  <include>
    <directory suffix=".php">./src</directory>
  </include>
</coverage>

WordPressのテスト環境を動作させるためには、WordPressテストスイートを用意しなければならず、WP-CLIチームがメンテナンスしているinstall-wp-tests.shなどを使うことが求められます。

このアクションでは指定したWordPressとPHPのバージョンをインストールし、MySQLを起動してテストのための環境を用意します。

wp-envのようなDockerを使って開発している場合はGitHub ActionsでDockerを動かすことでローカルと同じテスト環境を再現できます。

PHP CodeSniffer

PHPでcomposerをインストールし、スクリプトを実行します。composer lint で動作します。コマンド名を変更する場合は composer_command: lint_php で指定してください。

jobs:
  phpcs:
    uses: tarosky/workflows/.github/workflows/phpcs.yml@main
    with:
      version: 8.0

PHP Short Open Tag

PHP8.0から <? が非推奨となりましが、この記法はPHP_CodeSnifferでは見つけることができないケースがあり、この結果、本番環境でFatal Errorを起こすことがありました。このワークフローではPHPファイルをスキャンし、ショートオープンタグを見つけるとエラーになります。

pathでスキャンするパスを指定してください。デフォルトはリポジトリルートです。

jobs:
  php-shor-open-tag:
    uses: tarosky/workflows/.github/workflows/php-short-open-tag.yml@main
    with:
      path: 'wp-content/themes/my-theme' # WordPressを丸ごとディレクトリに入れている場合など

PHP Lint

Wordpress公式ディレクトリでは、SVNのpre-commitフックでphp -l file.php を全PHPファイルに対して実行し、エラーが起きるとリジェクトします。composerなどを利用している場合、vendorディレクトリの中にある依存ライブラリがひっかかるケースもあり、なおかつデプロイという最終段階になってはじめて露見するので、事前にこのチェックを通過しておくとわかりやすいです。 pathでスキャンするパスを指定してください。デフォルトはリポジトリルートです。

W.I.P ビルドスクリプトの指定などは実装予定です。

jobs:
  phplint:
    uses: tarosky/workflows/.github/workflows/phplint.yml@main
    with:
      version: 8.1 # デプロイする際のPHPバージョンがわかっている場合など
      path: 'wp-content/themes/my-theme' # WordPressを丸ごとディレクトリに入れている場合など

npmテスト

Nodeをインストールし、npmでテストを行います。npm スクリプトで lint が動作することが前提です。また、packageにコマンド名を渡すことで、ビルドが成功するかを検証することも可能です。これはdependabotなどを有効にしている場合に活用できます。

node_version を省略すると、リポジトリルートの .node-version ファイルから自動的にバージョンを読み取ります。.node-version で統一管理している場合は省略を推奨します。

jobs:
  assets:
    uses: tarosky/workflows/.github/workflows/npm.yml@main
    with:
      # node_version を省略すると .node-version を自動参照
      command: test # デフォルトは lint
      package: build # この場合、 npm run build を実行。指定なしなら何もしない

明示的にバージョンを指定することもできます。

jobs:
  assets:
    uses: tarosky/workflows/.github/workflows/npm.yml@main
    with:
      node_version: "22"
      command: lint

backlog

Backlogの課題番号がコミットメッセージに含まれている場合、通知を行います。

tarosky-bot というユーザーがBacklogの当該プロジェクトのメンバーになっている必要があります。
BACKLOG_API_KEY という名称でAPIキーがプロジェクトまたは組織で利用できる必要があります。
secrets: inherit を指定し、BacklogのAPIキーをワークフローが利用できるようにしてください。
host を変更すると、Backlog スペースを変更できます。

jobs:
  notify:
    uses: tarosky/workflows/.github/workflows/backlog.yml@main
    with:
      project: PJ_STANDARD
    secrets: inherit

タグをブランチに限定する

タグでプロダクションをリリースするような場合、そのタグがメインブランチに所属しているかどうかを確認します。リリース用のジョブの前に実行してください。

jobs:
  # タグ付きコミットなら、それがmainブランチにあるのかチェックする
  tags-check:
    uses: tarosky/workflows/.github/workflows/check-tag-in-branch.yml@main
    if: contains(github.ref, 'refs/tags/')
    with:
      allowed_branch: "main"
  # リリース作業のジョブ
  release:
    needs: tag-check # mainブランチのタグだけで実行
    environment:
      name: production
      url: https://example.com
    steps:
      # 以下、リリース作業のステップ

自動PR

設定したトリガーから指定するブランチへのPRを自動で作成します。デフォルト値では main ブランチへのPRが指定されており、staging ブランチから main ブランチへの自動PR作成を想定しています。PRのマージ先ブランチ名、PRタイトル、PRボディテキスト、付与するラベルを指定できます。

name: Auto PR to main branch from staging
on:
  push:
    branches: [staging]
jobs:
  auto-pr:
    uses: tarosky/workflows/.github/workflows/auto-pr.yml@main

Claude 系ワークフロー共通: モデル指定

Claude PR レビュー / Claude Issue トリアージ / WP Plugin Audit / Claude Assistant は、いずれも model input でモデルを指定できます。デフォルトは sonnet（エイリアス） です。

指定方法	例	挙動
エイリアス（推奨）	`sonnet` / `opus` / `haiku`	Claude Code が実行時点の最新モデルに解決する。モデルが廃止されても壊れない
フル ID	`claude-sonnet-5` など	そのモデルに固定する。挙動・単価を変えたくない場合に使う。廃止されると動かなくなるので注意

    with:
      model: opus  # レビュー品質を優先したいリポジトリ（決済を扱うなど）

エイリアスの場合、新しいモデルが出ると挙動と単価が予告なく変わります。実際に解決されたモデル ID とコストは、各ジョブの Job Summary（および Report Claude model ステップのログ）に出力されるので、そこで確認してください。

Claude PR レビュー

CIが通ったPRをClaudeが自動レビューします。WordPressプラグイン開発の観点（フック・セキュリティ・パフォーマンス・設計）でコードレビューし、リスク・スコープのラベルを付与します。

前提条件: リポジトリのシークレットに ANTHROPIC_API_KEY が設定されていること。

# .github/workflows/claude-review.yml
name: Claude Code PR Review

on:
  workflow_run:
    workflows: ["Test Plugin"] # CIワークフロー名に合わせて変更
    types: [completed]

jobs:
  setup:
    if: |
      github.event_name == 'workflow_run' &&
      github.event.workflow_run.conclusion == 'success' &&
      github.event.workflow_run.event == 'pull_request' &&
      github.event.workflow_run.head_repository.full_name == github.repository
    runs-on: ubuntu-latest
    outputs:
      pr_number: ${{ steps.pr.outputs.number }}
    steps:
      - name: Get PR number from branch
        id: pr
        env:
          GH_TOKEN: ${{ github.token }}
        run: |
          PR_NUMBER=$(gh pr list \
            --repo "${{ github.repository }}" \
            --head "${{ github.event.workflow_run.head_branch }}" \
            --json number --jq '.[0].number')
          echo "number=$PR_NUMBER" >> "$GITHUB_OUTPUT"

  auto-review:
    needs: setup
    if: needs.setup.outputs.pr_number != ''
    uses: tarosky/workflows/.github/workflows/claude-review.yml@main
    with:
      plugin_name: my-plugin-name  # ← プラグイン名に変更
      ci_checks: "PHPStan Level 5, PHPCS, PHPUnit"  # ← 実際のCIチェック内容に変更
      pr_number: ${{ fromJSON(needs.setup.outputs.pr_number) }}
      head_sha: ${{ github.event.workflow_run.head_sha }}
    secrets: inherit

プラグイン固有の観点を追加したい場合は custom_focus を指定します。

    with:
      plugin_name: rich-taxonomy
      ci_checks: "PHPStan Level 5, PHPCS, PHPUnit, asset build"
      pr_number: ${{ fromJSON(needs.setup.outputs.pr_number) }}
      head_sha: ${{ github.event.workflow_run.head_sha }}
      custom_focus: |
        - Singleton パターンの遵守
        - リライトルール変更時の flush_rewrite_rules 確認

追いコミットがあった場合は、前回のレビューコメントを参照した差分レビューを自動的に行います。

bot が作成した PR について:

Claude Tag（Slack から PR を作成する機能）など bot が起点となった PR は、claude-code-action の bot ガードにより既定では自動レビューが弾かれます（Workflow initiated by non-human actor）。本ワークフローは allowed_bots を既定で claude に設定しているため、Claude Tag 由来の PR でも自動レビューが走ります。他の bot（例: dependabot）も許可したい場合や全 bot を許可したい場合は指定を変更します。

    with:
      plugin_name: my-plugin-name
      pr_number: ${{ fromJSON(needs.setup.outputs.pr_number) }}
      head_sha: ${{ github.event.workflow_run.head_sha }}
      allowed_bots: 'claude,dependabot'  # デフォルト: 'claude'（'*' で全 bot 許可）

⚠️ public リポジトリで '*' を指定すると外部 App が誘発できる余地が広がります。呼び出し側で fork（head_repository != github.repository）は除外していますが、必要な bot 名だけを列挙するのが安全です。

Claude Issue トリアージ

未ラベル・内容が薄いIssueをClaudeが週次でトリアージします。ラベル付け・補足コメント・重複検出を自動で行います。

前提条件: リポジトリのシークレットに ANTHROPIC_API_KEY が設定されていること。

# .github/workflows/issue-triage.yml
name: Issue Triage

on:
  schedule:
    - cron: '0 1 * * 1'  # 毎週月曜 01:00 UTC
  workflow_dispatch:      # 手動実行も可能

jobs:
  triage:
    uses: tarosky/workflows/.github/workflows/issue-triage.yml@main
    with:
      plugin_name: my-plugin-name  # ← プラグイン名に変更
    secrets: inherit

対象期間を変更したい場合は days を指定します（デフォルト: 30日）。

    with:
      plugin_name: my-plugin-name
      days: 14  # 過去2週間のIssueのみ対象

動作内容:

アクション	条件
`bug` / `enhancement` / `question` / `wontfix` ラベル付与	全対象Issue
`duplicate` ラベル + 参照コメント	既存Issueと重複していると判断された場合
補足コメント（再現手順等を依頼）	本文が薄い・再現手順がないバグ報告など
`ai-triaged` ラベル付与	処理完了したIssue（次回以降スキップされる）

WP Plugin Audit

WordPress.org APIとサポートフォーラムのデータを基に、プラグインの健全性をClaudeが監査します。競合プラグインとの比較、サポートトレンドの分析、メンテナンス状態のチェックを行い、アクション可能なIssueを自動作成します。

前提条件: リポジトリのシークレットに ANTHROPIC_API_KEY が設定されていること。

# .github/workflows/plugin-audit.yml
name: Plugin Health Audit

on:
  schedule:
    - cron: '0 3 1 * *'  # 毎月1日 03:00 UTC
  workflow_dispatch:
    inputs:
      dry-run:
        description: 'trueならIssue作成しない'
        type: boolean
        default: false

jobs:
  audit:
    uses: tarosky/workflows/.github/workflows/plugin-audit.yml@main
    with:
      slug: my-plugin-slug  # ← WordPress.org のプラグインslugに変更
      language: 'ja'
      max_issues: 3
      dry_run: ${{ github.event.inputs.dry-run == 'true' }}
    secrets:
      ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

Issue作成数を変更したい場合は max_issues を指定します（デフォルト: 5）。

    with:
      slug: my-plugin-slug
      max_issues: 10        # 最大10件のIssueを作成
      dry_run: true          # まずドライランで確認

分析観点:

観点	内容	ラベル
サポートフォーラム	未解決率・繰り返しパターンの検出	`support-trend`
競合比較	タグベースで類似プラグインを検索し機能ギャップを分析	`feature-gap`
健全性	最終更新日・WP互換性・PHP要件・解決率	`health-alert`

自動作成されるラベル: wp-plugin-audit, support-trend, feature-gap, health-alert

重複防止: 既存の wp-plugin-audit ラベル付きIssueとタイトルを比較し、類似Issueはスキップされます。

Claude Assistant

Issue やPR のコメントで @claude とメンションすると、Claudeが文脈を読み取って応答します。コードの質問、リファクタ依頼、Issue の相談など、自由な対話に利用できます。

前提条件: リポジトリ（またはOrganization）のシークレットに ANTHROPIC_API_KEY が設定されていること。

# .github/workflows/claude-assistant.yml
name: Claude Assistant

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  assistant:
    uses: tarosky/workflows/.github/workflows/claude-assistant.yml@main
    secrets: inherit

モデルやトリガーフレーズを変更したい場合は with で指定します。

    with:
      model: opus                  # デフォルト: sonnet（「モデル指定」参照）
      trigger_phrase: '@claude-bot'  # デフォルト: @claude

アクセス制御: リポジトリに対して write 権限を持つユーザー（OWNER / MEMBER / COLLABORATOR）のみがトリガーできます。外部ユーザーのコメントはスキップされます。

他のClaudeワークフローとの違い:

ワークフロー	用途
Claude PR レビュー	CI通過後に自動でコードレビュー
Claude Issue トリアージ	週次スケジュールで自動でラベル付け
Claude Assistant	`@claude` メンションで対話的に応答

Playground Preview

PRごとにWordPress Playgroundのプレビューリンクを自動生成します。PRにプッシュするとプラグインがビルドされ、Playgroundで即座に動作確認できるURLがPRコメントに投稿されます。

2つの共有ワークフローで構成されています。

ワークフロー	トリガー	役割
`playground-preview-build.yml`	`pull_request`	プラグインZIPをビルドしてアーティファクトとしてアップロード
`playground-preview-publish.yml`	`workflow_run`	アーティファクトを公開URLに配置し、PRにプレビューコメントを投稿

前提条件:

リポジトリに .distignore ファイルがあること（ZIPから除外するファイルの一覧）
ビルドコマンドが正常に動作すること（デフォルト: composer install --no-dev --prefer-dist && npm ci && npm run package）

呼び出し側のリポジトリには以下の2ファイルを用意します。

ビルドワークフロー（PR時に実行）:

# .github/workflows/playground-build.yml
name: Playground Build

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  build:
    uses: tarosky/workflows/.github/workflows/playground-preview-build.yml@main

パブリッシュワークフロー（ビルド完了後に実行）:

# .github/workflows/playground-publish.yml
name: Playground Publish

on:
  workflow_run:
    workflows: ["Playground Build"]  # ↑のワークフロー名に合わせる
    types: [completed]

jobs:
  publish:
    if: >
      github.event.workflow_run.conclusion == 'success' &&
      github.event.workflow_run.event == 'pull_request'
    uses: tarosky/workflows/.github/workflows/playground-preview-publish.yml@main
    secrets: inherit

カスタマイズ例:

ビルド設定を変更したい場合は with で指定します。

  build:
    uses: tarosky/workflows/.github/workflows/playground-preview-build.yml@main
    with:
      plugin_slug: my-plugin       # デフォルト: リポジトリ名
      php_version: '8.0'           # デフォルト: 7.4
      node_version: '20'           # デフォルト: .node-version を自動参照
      build_command: 'npm ci && npm run build'  # ビルドコマンドを変更
      retention_days: 3            # アーティファクト保持日数（デフォルト: 7）

パブリッシュ側で古いアーティファクトの保持数を変更できます。

  publish:
    uses: tarosky/workflows/.github/workflows/playground-preview-publish.yml@main
    with:
      plugin_slug: my-plugin       # ビルド側と合わせる
      artifacts_to_keep: '5'       # PR毎に保持する古いアーティファクト数（デフォルト: 2）
      release_tag: ci-artifacts    # ZIPをホストするリリースのタグ（デフォルト: ci-artifacts）
      keep_release_draft: false    # 下記「注意」を参照（デフォルト: false = 公開）
    secrets: inherit

⚠️ ホスティング用リリースは公開状態が必須:

プレビュー用ZIPは GitHub Actions のアーティファクト（認証が必要でブラウザから直接ダウンロードできない）を、ci-artifacts というリリースのアセットとして再ホストすることで公開URL化しています。ここで使う upstream アクションはこのリリースを下書き（draft）で作成しますが、draft リリースのアセットは匿名アクセスで 404 になり、Playground が ZIP を取得できません。

そのため本ワークフローは expose 後にこのリリースを自動で公開（publish）します（keep_release_draft: false、デフォルト）。ZIPを別の公開経路で配信していてリリースを draft のままにしたい場合のみ keep_release_draft: true を指定してください。

仕組み:

PRにプッシュすると playground-preview-build.yml がプラグインをビルドし、ZIPをアーティファクトとしてアップロード
ビルド成功後 playground-preview-publish.yml が workflow_run で起動
アーティファクトを ci-artifacts リリースのアセットとして再ホストし、公開URL化（リリースが draft の場合は自動で公開）
WordPress Playgroundのブループリントを生成し、PRにプレビューリンク付きのコメントが自動投稿される

WP Compat Check

WordPress本体のアップデートで影響しうる箇所を、互換性カタログとリポジトリのコードを照合して検出し、Issue を作成・更新します。1リポジトリ×1リリースにつき1 Issue（タイトル「WordPress 7.2 互換性チェック」など）で、再実行時は本文を更新し、チェック済みの項目は引き継ぎます。

前提条件: なし（シークレット不要）。カタログは実行時に GitHub Pages から取得するので、@main 以外に固定しても最新のカタログで照合されます。

# .github/workflows/wp-compat.yml
name: WP Compat Check

on:
  schedule:
    - cron: '0 0 * * 1' # 毎週月曜。ベータ・RC期間中に新しい変更を拾う
  workflow_dispatch:
    inputs:
      to:
        description: 更新先（例 7.2、latest）
        default: latest
      from:
        description: 現在のバージョン（空なら readme の Tested up to）
        default: ''

jobs:
  check:
    uses: tarosky/workflows/.github/workflows/wp-compat-check.yml@main
    permissions:
      contents: read
      issues: write
    with:
      to: ${{ inputs.to || 'latest' }}
      from: ${{ inputs.from || '' }}

input	デフォルト	説明
`to`	`latest`	更新先。`latest` はカタログの最新（ベータ・trunk を含む）。`7.1` は 7.1 系の最新、`7.1.0` は厳密に 7.1.0
`from`	`''`	現在のバージョン。空なら readme の `Tested up to`、無ければ更新先の直前のリリース。長く更新していないサイト向けに `6.6` のように指定すると、間のリリースをすべて照合する
`path`	`.`	照合するディレクトリ
`exclude`	`''`	追加で除外するディレクトリ名（カンマ区切り）。`vendor`・`node_modules`・`build`・`dist`・`tests` は常に除外
`label`	`wp-compat`	Issue のラベル（無ければ作成）
`dry_run`	`false`	`true` なら Issue を作らず Job Summary にだけ出力

検出結果は次の3つに分かれます。

該当: 関数・フック・クラス・ハンドルなどが一致（重大度低は折りたたみ）
目視チェック: シンボルでは判定できない重大な変更（エディタの iframe 化など）
参考: 関連パッケージを使っているだけのもの（折りたたみ）

重大度中以上の該当が無ければ Issue は作成しません。動的なフック名・vendor/ 内のライブラリ・CSS の見た目の変化は検出できないので、メジャーアップデート前の目視確認は引き続き必要です。カタログの作り方は wp-compat/README.md を参照してください。

カタログは tarosky/workflows 側で毎日自動更新されます（WordPress のベータ・RC・正式版や新しい Dev Notes を検出）。更新が公開されると Slack に通知され、各リポジトリの Issue は次回の定期実行で更新されます。

watchtower 通知

リリース時に tarosky/watchtower へ通知し、プラグインの更新を検知できるようにします。

シークレット・鍵は不要です。GitHub の OIDC トークンを取得して watchtower へ POST するだけなので、外部パートナーが参加する taro-* リポにもそのまま配置できます。
呼び出し元ジョブに permissions: id-token: write を付与してください。reusable 側ジョブの id-token: write はここから継承されます。
プラグイン名は body に送りません。watchtower 側が OIDC トークンの repository クレームから導出するため、別リポが他プラグインのリリースを詐称できません。
release: { types: [released] } で発火します（prerelease は除外）。

name: Notify watchtower on release

on:
  release:
    types: [released]   # prerelease も拾うなら [released, prereleased]

jobs:
  notify:
    permissions:
      id-token: write   # 必須。reusable 側へ継承される
      contents: read
    uses: tarosky/workflows/.github/workflows/watchtower-notify.yml@main
    # 既定値と変えたい場合のみ with を指定:
    # with:
    #   endpoint: https://watchtower.maintic.com/notify
    #   audience: watchtower
    #   slug: my-plugin   # リポ名 ≠ プラグイン slug / monorepo の場合のみ

通常はプラグイン slug を送る必要はありません。watchtower 側が OIDC トークンの repository クレーム（tarosky/kestrel → kestrel）から導出します。
リポ名 ≠ プラグイン slug（例: tarosky/kestrel の中身が kestrel-wp）や monorepo の場合は slug を指定してください。未指定のままだと watchtower 側で照合できず、通知が静かに無視されます。

input	デフォルト	説明
`endpoint`	`https://watchtower.maintic.com/notify`	watchtower の通知エンドポイント URL
`audience`	`watchtower`	OIDC token の audience。watchtower 側 `WATCHTOWER_OIDC_AUDIENCE` と一致させる
`slug`	`''`（空）	プラグイン slug。リポ名と異なる / monorepo の場合に指定。未指定ならリポ名（repository クレーム由来）が使われる

デバッグ:

症状	原因の可能性
401	audience 不一致 / トークン失効 / 署名検証失敗
403	`repository_owner != tarosky`、または `event_name != release`（fork や別 org からの呼び出しは弾かれる）
5xx	watchtower 側の問題。Cloud Run ログ（`gcloud run services logs read watchtower`）を確認
OIDC トークン取得失敗	呼び出し元ジョブに `permissions: id-token: write` を付けているか確認

複合アクション

複合アクションは job.steps で指定します。workflowと同様、オプション項目をwithで指定します。

distignore

.distignore ファイルがリポジトリにある場合、記載されているファイルをすべて削除します。リリース前の処理などに便利です。

jobs:
  release:
    steps:
      - name: Clean Package
        uses: tarosky/workflows/actions/distignore@main

wp-readme

README.md をWordPressに対応した readme.txt に変換します。wp-readmeを利用しています。

jobs:
  release:
    steps:
      - name: Generate readme.txt
        uses: tarosky/workflows/actions/wp-readme@main

versioning

GitHubのタグ情報を元に、style.cssなどのタグを書き換えます。prefix を指定すると、　version から削除する文字列を指定できます。

jobs:
  release:
    steps:
      - name: Versioning
        uses: tarosky/workflows/actions/versioning@main
        with:
          version: ${{ github.ref }} # 大体の場合はGitHubのタグを参照します。
          files: style.css # カンマ区切りで記載できます。

claude-model-summary

anthropics/claude-code-action の実行ログ（execution_file）から、実際に解決されたモデル ID とコストを Job Summary に出力します。Claude 系の共有ワークフローでは組み込み済みです。独自に claude-code-action を使うワークフローで利用する場合は、Claude のステップに id を付けて呼び出します。

      - name: Run Claude
        id: claude
        uses: anthropics/claude-code-action@v1
        with:
          claude_args: --model sonnet
          # ...

      - name: Report Claude model
        if: always() && steps.claude.outputs.execution_file != ''
        uses: tarosky/workflows/actions/claude-model-summary@main
        with:
          execution_file: ${{ steps.claude.outputs.execution_file }}
          requested_model: sonnet

kunoichi-deploy

ビルド済みの zip を Kunoichi Market に新しいバージョンとして登録します（POST /wp-json/makibishi/v1/deploy）。デプロイキーは商品ごとに発行されます。マーケットの**商品編集画面（サイドの「デプロイキー」）**で発行し、表示されたキーを repository secret（例: KUNOICHI_DEPLOY_KEY）に登録してください。キーは発行直後に一度しか表示されません。失効も同じ画面から行えます（管理者は wp makibishi deploy-key create|list|revoke も使えます）。

on:
  release:
    types: [published]

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      # ... checkout / versioning / zip 作成 ...
      - name: Deploy to Kunoichi Market
        uses: tarosky/workflows/actions/kunoichi-deploy@main
        with:
          deploy-key: ${{ secrets.KUNOICHI_DEPLOY_KEY }}
          file: my-plugin.zip # zip は <slug>/ ディレクトリで包んでおくこと

入力	必須	既定値	説明
`deploy-key`	✓	—	デプロイキー（`mkbs_…`）
`file`	✓	—	アップロードする zip のパス
`version`		`github.ref_name`	登録するバージョン（`x.y.z`。先頭の `v` は可）
`endpoint`		`https://kunoichiwp.com`	マーケットの URL。ステージングに送るときに変更する
`slug`		商品スラッグ	ファイル名に使うスラッグ
`force`		`false`	同じバージョンが登録済みなら上書きする
`basic-auth-user` / `basic-auth-password`		空	Basic 認証付きの環境（ステージング等）用。両方指定したときのみ有効

出力 file に、登録されたファイル名（例: my-plugin-1.2.3.zip）が入ります。同じバージョンを再送すると 409 で失敗するので、バージョンを上げるか force: true を指定してください。

ステージングへ送る例（tarosky/kunoichi-sample-plugin で利用中）:

        with:
          deploy-key: ${{ secrets.KUNOICHI_DEPLOY_KEY }}
          file: my-plugin.zip
          endpoint: https://ts-kunoichimarket-staging.click
          basic-auth-user: ${{ secrets.STAGING_BASIC_AUTH_USER }}
          basic-auth-password: ${{ secrets.STAGING_BASIC_AUTH_PASSWORD }}

Note

デプロイキーは常に X-Makibishi-Deploy-Key ヘッダーで送ります（Authorization は Basic 認証が使うため）。Basic 認証付きの環境で invalid_username などの 401 が返る場合は、WordPress が Basic 認証の情報をアプリケーションパスワードとして検証しています。

Navigation Menu

Repository navigation

Home

ワークフロー

PHPUnit

コードカバレッジ

PHP CodeSniffer

PHP Short Open Tag

PHP Lint

npmテスト

backlog

タグをブランチに限定する

自動PR

Claude 系ワークフロー共通: モデル指定

Claude PR レビュー

Claude Issue トリアージ

WP Plugin Audit

Claude Assistant

Playground Preview

WP Compat Check

watchtower 通知

複合アクション

distignore

wp-readme

versioning

claude-model-summary

kunoichi-deploy

Uh oh!

Clone this wiki locally