Borrowing it
Nothing to install: this file belongs to akaghef/M3E. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/akaghef/M3E/main/.claude/skills/pr-beta/SKILL.mdgit clone --depth 1 https://github.com/akaghef/M3EWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/akaghef/m3e/pr-beta)<a href="https://agentmods.dev/skills/akaghef/m3e/pr-beta"><img src="https://agentmods.dev/badge/skills/akaghef/m3e/pr-beta/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/akaghef/m3e/pr-beta"><img src="https://agentmods.dev/badge/skills/akaghef/m3e/pr-beta.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00187 | $0.01503 |
| Opus 5.5 | $0.00075 | $0.00601 |
| Sonnet 5.5 | $0.00037 | $0.00301 |
| Haiku 4.5 | $0.00019 | $0.00150 |
Grade A, and why
pr-beta scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 169 lines — stays where its author put it; the contents beside it link to each section on GitHub.
pr-beta — dev-beta 統合PR作成
作業ブランチの変更を dev-beta にマージするためのPRを作成する。 M3Eの統合フロー（Documentation_Rules）に準拠。
前提条件
- 現在のブランチが
dev-beta以外であること - リモートに push 済み（未 push なら自動 push する）
- 未コミットの変更がないこと（あれば警告して停止）
実行手順
Step 1: 状態チェック
# ブランチ確認
BRANCH=$(git branch --show-current)
if [ "$BRANCH" = "dev-beta" ]; then
echo "ERROR: dev-beta 上では使えない。作業ブランチに切り替えてから実行すること。"
exit 1
fi
# 未コミット変更チェック
if [ -n "$(git status --porcelain)" ]; then
echo "WARNING: 未コミットの変更あり。先にコミットすること。"
git status --short
exit 1
fi
Step 2: dev-beta との差分分析
# リモート最新を取得
git fetch origin dev-beta
# コミット一覧（分岐点から現在まで）
git log --oneline origin/dev-beta..HEAD
# 差分統計
git diff --stat origin/dev-beta..HEAD
# 変更ファイル一覧
git diff --name-only origin/dev-beta..HEAD
差分を分析して以下を特定する:
- 変更の主題（何を実装/修正したか）
- 影響範囲（beta/, docs/, scripts/ 等）
- 関連する spec/architecture 文書
Step 3: PRタイトルとボディの生成
コミット履歴と差分から自動生成する。
タイトル規約: {type}: {概要} （70文字以内）
| type | 用途 |
|---|---|
add |
新機能 |
fix |
バグ修正 |
update |
既存機能の改善 |
refactor |
リファクタリング |
docs |
ドキュメントのみの変更 |
test |
テストの追加/修正 |
chore |
ビルド/CI/設定の変更 |
ボディテンプレート:
## 概要
{1-3行の変更概要}
## 変更内容
{変更ファイルとその内容をカテゴリ別に列挙}
## 関連
{関連するspec/ADR/issue/Todo Poolエントリがあれば}
## テスト
- [ ] tsc --noEmit 通過
- [ ] vitest run 通過
- [ ] ビルド成功
{該当しないものは削除}
## daily 更新
- [ ] docs/daily/YYMMDD.md 更新済み
Step 4: Push & PR作成
# リモートに push（未 push の場合）
git push -u origin "$BRANCH"
# PR作成
gh pr create \
--base dev-beta \
--title "{生成したタイトル}" \
--body "{生成したボディ}"
Step 5: 結果報告
PR作成後、以下を報告する:
- PR URL
- 差分サマリー（ファイル数、追加行、削除行）
- マージ前に必要なアクション（daily未更新、テスト未実行等）
ロール別の振る舞い
| ロール | ブランチ | PR先 | 備考 |
|---|---|---|---|
| visual | dev-visual | dev-beta | UI/レンダリング変更 |
| data | dev-data | dev-beta | model/controller変更 |
| data2 | dev-data2 | dev-beta | data 並列ワーカー |
| team | dev-team | dev-beta | Collaboration/Cloud Sync |
| manage | feature branch | dev-beta | 横断的変更 |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 169 lines · 187 tokens per session scan A 8e72c4a89b14
pr-beta is a skill published in the GitHub repository akaghef/M3E (11 stars, last pushed 5d ago), licensed MIT. It adds 187 tokens to every session and 1,503 once invoked, about $0.0007 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-02.
Other skills, from other repositories
review-implement-phase
Implements triaged review actions, commits focused fixes, and posts Done plus resolves threads. Use when the user wants only the implementation phase of the review-framework workflow.
pr
Draft a PR body from OMC's paper trail — the smallest visual that proves the change, evidence consumed from the verify protocol (never re-collected), reversibility from the ADR test on the diff, glossary language throughout.
engram-branch-pr
PR creation workflow for Engram following the issue-first enforcement system. Trigger: When creating a pull request, opening a PR, or preparing changes for review.
verify-behavior
Verify or reproduce visible product behavior by driving the real UI with pi-computer-use's checked tools, requiring verified expect postconditions and durable state evidence for meaningful UI flows. Use when triage needs visual reproduction, implementation needs behavioral proof, review needs interactive confirmation…
github-contributor
A step-by-step guide for contributing code, tests, documentation, or build changes to open-source projects you do not maintain. It explains how to prepare a pull request that follows the project’s rules and is easier for maintainers to review.
revdiff
Review diffs, files, and documents with inline annotations in a TUI overlay, or answer questions about revdiff usage, configuration, themes, and keybindings. Opens revdiff in agterm/tmux/zellij/herdr/kitty/wezterm/cmux/ghostty/iterm2/emacs-vterm, captures annotations, and addresses them. Works in git, hg, and jj repos…