本文へ移動
cccskills
無料GitHub で公開日本語紹介

weekly-audit

Mole CLIのmacOS版とWindows版を、安全性・過剰設計・古い記述・性能・ルール化の漏れから定期点検します。指摘を再検証し、承認された修正と記録まで進めます。

原文原文の説明を見る

Weekly whole-repo audit of Mole CLI (macOS, main) and Mole CLI (Windows, the windows branch) across five dimensions (unsafe, over-design, stale, performance, not yet codified), every finding refuted once before it is reported, then the approved fixes landed per branch. Use for 每周体检, 全面检查 CLI, 看看 Mole 和 Windows 版还有什么要优化 / 沉淀 / 不安全 / 过度设计 / 过时. Not for one reported bug (/hunt), a safety-sensitive diff (bugs), or a PR review (/check).

インストール方法を見る

こんなときに便利

  • Mole CLI両ブランチの定期点検
  • 危険な削除経路や性能問題の確認
  • 古い文書や過剰設計の点検
  • 繰り返す修正をテストやルールに反映

日本語での紹介

できること

Mole CLIのmacOS版とWindows版を定期点検し、安全性、過剰設計、古い記述、性能、テストやルールへの反映漏れを調べます。各指摘について既存の防御や記録済みの判断で否定できないかを一度確かめ、残った問題を根拠、発生場面、最小限の修正案とともに報告します。承認後はブランチごとに修正と検証を進め、監査記録を残します。

こんなときに便利

両方のCLIを継続的に保守し、個別の不具合対応だけでは拾いにくい問題を点検したいときに向いています。前回の未解決項目を追跡したり、繰り返した修正をテストや明文化したルールとして残したりする用途にも使えます。

使い方の例

  • 「両ブランチを週次点検して、根拠が残る問題だけ報告して」
  • 「前回の未解決項目と、テストやルールへの反映漏れを確認して」

注意点

監査は読み取り専用で始め、修正は保守担当者の承認後に行います。5つの観点を並列のサブエージェントで調べる構成です。macOS上ではPowerShellの動作を検証できないため、Windowsの修正確認にはWindows CIが必要です。対象はCLIで、Mole Macと有料アプリのMole for Windowsは範囲外です。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル(3)

  • SKILL.md10.7 KB
  • references/prompts.md5.0 KB
  • references/rule-compression.md4.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Weekly Audit (CLI)

Adapted from Mole Mac's weekly audit (mole-mac .claude/skills/weekly-audit). The first run (2026-10-16, main eb531ba2, windows 159657d5) found mo clean deleting Nix profile generations older than 30 days with no timeout or real preview, the whole ~/Library/Application Support/Steam game library offered as one uninstall data row on macOS while Windows already refuses Steam libraries, a dozen undocumented tuning variables, dead Windows cleanup stubs with tests that cannot fail, per-app forks in mo uninstall <name> and --list, and five stale release lines. Most of the tree was fine; the value is in the few findings that survive refutation. Run it once a week and keep the report short.

Phase 1: Freeze and scope

  • For each branch record git rev-parse HEAD, the remote head, git status --short, and git log --oneline <base>..HEAD. main is this checkout; windows is its own worktree (git worktree list), never checked out over main. Fetch the remote branch read-only (git fetch origin windows) and audit origin/windows when no clean worktree is at its head.
  • Read the newest entry of docs/weekly-audit.md on main: its "Next window from" commits are this run's base per branch, its "Decided, do not re-report" list goes to every agent, and its "Open" items are rechecked first. The codify dimension reads only that window; the others read the whole tree.
  • Exclude tests/tmp-*, .git, build output and other sessions' worktrees from every grep.
  • Pick the scope. Both branches whole on the first run, after a release, or when the window touched more than about 40 source files; otherwise incremental: the files changed in each branch's window, their direct callers, and every Open item. Mole for Windows' first whole-tree run cost about 1.15M sub-agent tokens for 18 findings, most in code untouched for weeks.
  • Read-only until Phase 4. "看看 / 检查 / 跑一遍" never authorizes a write.

Phase 2: Five read-only audits in parallel

One sub-agent per dimension, each started from the matching prompt in references/prompts.md (shared header plus dimension body) so coverage does not drift between runs, each covering both branches and naming which branch every finding belongs to. Read-only: no edit, commit, build, real cleanup or sudo. Tests may run only with MOLE_TEST_NO_AUTH=1 against fixtures; PowerShell behavior cannot run on macOS, so Windows findings rest on reading the code and its Pester tests. Each agent must try to refute every candidate once (find the guard that already blocks it, the test that locks it, or the AGENTS.md / .claude/rules/ / SYNC.md line recording the decision, which may sit on the other branch, so grep both before reporting) and report only survivors, with branch:file:line, a concrete failure scenario and the smallest fix.

  1. Unsafe. macOS: every removal goes through mole_delete / safe_clean / safe_remove or carries a same-line # SAFE: reason; matching stays on exact bundle IDs or paths (no vendor prefix, TeamID or common-word globs); timeouts mean unknown and keep the target, signals cancel; dry-run lists exactly what a real run would remove; every sudo, osascript and launchctl has a test-mode guard; owner commands (brew, go clean, simctl, npm) cannot mutate an unwhitelisted root. Windows: every removal goes through Remove-Safe* / Clear-DirectoryContents and Test-SafePath; junction and identity rechecks before the sink; uninstall leftovers only after Test-MoleInstallFolder. Both: hunt for the Steam shape, a folder of irreplaceable user content (game libraries, VMs, model weights, local-only chat or clipboard databases, sessions) reachable as one cleanup or uninstall target. Do not stop at reading: run find_app_files <bundle-id> <name> against a fixture HOME for launchers that hold such content (Steam, Epic, GOG, Battle.net, Parallels, UTM, Ollama, LM Studio) and check what should_protect_data says; the first run's Steam row was missed by reading alone. List every clean_tool_cache owner command and check it has run_with_timeout, a dry-run that plans with the owner, and a recovery contract that only removes rebuildable state (Nix generations are not).
  2. Over-design. New flags, environment variables or config keys added without a stated rejected default (AGENTS.md treats each as a setting); zero-caller functions (grep strings, eval, declare -f and dynamic names too; tests alone are not callers); same-body helpers scripts/audit_function_duplication.py --list misses because they are written differently; output lines that report routine skips. Existing flags are never proposed for removal without the maintainer.
  3. Stale. Current-state claims in AGENTS.md and .claude/rules/ (both branches), SYNC.md, .claude/skills/**, docs and README copies against the code: every test named as a lock exists (grep -rn '@test "<name>"' tests on main, It '<name>' in Pester on windows), versions, paths, make targets and commands still exist, comments naming removed functions. The "latest stable" and "not released" lines in SYNC.md on both branches go stale with every release; check them against gh release list first. These files deliberately record removed and rejected things; read the context before calling a line stale.
  4. Performance. Forks per item inside loops that scale with app or file count (basename, tr, $(...), stat per entry), repeated du or find over the same root, mdfind / system_profiler / pgrep calls not shared within a run, unbounded waits, startup work on every command. Tie each to a count or a measured time, and check whether it is already cached, pooled or gated by a test such as tests/core_performance.bats.
  5. Not yet codified. In the commit window: an area fixed twice, a behavior fix with no test touched, a lesson living only in memory, an issue reply or one commit message, a rule repeated in several places or grown more than 20% past the size recorded after its last compression (references/rule-compression.md), and fixes on one branch that SYNC.md should route to the other (a safety or correctness contract the other CLI shares) without a row there.

Phase 3: Report

One merged report, ranked by risk: unsafe, codify, performance, over-design, stale. Each row: branch, what, where, evidence, smallest fix, and whether it needs the maintainer (user-visible behavior, a new or removed flag, a recorded decision, a release). Verify the weakest high-severity claim yourself before reporting it: read the code, or reproduce with a fixture HOME and MOLE_TEST_NO_AUTH=1. End with what was checked and found fine, and the questions only the maintainer can answer. Mole for Windows (the paid app) and Mole Mac are out of scope here; note a cross-product item only as a SYNC.md candidate.

Phase 4: Land what the maintainer approves

  • One detached worktree per fix family (git worktree add --detach <dir>/wt-<n> origin/main, or origin/windows; no side branches, the maintainer works on main and windows), no two agents on the same file, local commits only. Start each agent from the fix header in references/prompts.md. Do not put a worktree you run Bats in under /private/tmp: validate_path_for_deletion allows that tree before should_protect_path, so sink tests there fail on clean code (the first run's agents each reported three such false reds). Stack and run the full suite in the main checkout.
  • Every behavior fix carries a test that fails on the old code (red-run by restoring the old source in the worktree) and, when it states a new invariant, the AGENTS.md or .claude/rules/ line on that branch.
  • macOS: ./scripts/check.sh --no-format, shellcheck on changed tests, then the full TERM=xterm-256color MOLE_TEST_NO_AUTH=1 ./scripts/test.sh on the stacked result before pushing main. Windows: gofmt -l cmd, GOOS=windows go build ./cmd/... locally, and the Windows CI result on a pushed branch or PR, because Pester cannot run here; never report a Windows fix as verified from macOS alone. Red-run on CI: push the test-only commit to the draft PR first, wait for the Pester job to fail on it under both powershell and pwsh (or name the shell that stays green and why), then push the fix. When the test reaches into a helper the fix introduced (Pester extracting a function from the script), restoring the old file fails the whole test file at discovery, which proves nothing; break only the judged condition in the new code instead and check that exactly that It fails. The first run's junction test was proven that way after the fact (draft PR #1754).
  • Agent reports are leads. Before stacking, read each agent's deviations from its brief and accept or undo each one, verify every "this does nothing" or "baseline already fails" claim yourself, and close each agent's "not done / outside my files" list in the integration commit. In the first run one agent called opt_diag_memory_pressure a no-op (it prints a warning) and three reported /private/tmp false reds as baseline failures.
  • Items marked "needs maintainer: no" are fixed in the run that reports them once the maintainer approves the batch; only items waiting on a decision carry over in Open, each with the question it waits on.
  • Commit identity and push follow the global Git Safety rules; contributor PRs keep their own review path.
  • An approved rule compression or split follows references/rule-compression.md; its second-agent meaning review is part of the fix, since the mechanical gates passed while 73 real losses remained (2026-10-17).
  • Prepend the run to docs/weekly-audit.md (audited and landed commits per branch, next window, rule volume, fixed / decided / open) in the last main commit of the run.

Output

The report, then after landing: commits per branch, push status, worktree leftovers, each finding's state (fixed and verified / decided not to fix with reason / blocked and what is missing), and each branch's base commit for next week's window, all also written to docs/weekly-audit.md.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

bugs

無料概要あり

Moleの削除やクリーンアップに関わる変更を、過去の不具合パターンから点検します。削除対象の判定、処理時間の上限、キャンセル、試行実行との一致を確認します。

  • 削除やアンインストールの安全性点検
  • キャンセルと処理時間制限の確認
  • 試行実行と実際の削除対象の比較
tw93/Mole7.2万2026年10月21日 更新

mole

無料概要あり

macOS・Windowsのディスク使用量を調べ、削除候補の事前確認から承認後のクリーンアップまで進めます。アプリ削除の案内やシステム状態・削除履歴の確認にも対応します。

  • ディスク容量の内訳を調べたいとき
  • キャッシュ削除の前に内容を確認したいとき
  • 動作が重いパソコンの状態確認
tw93/Mole7.2万2026年10月21日 更新

release-flow

無料概要あり

Mole CLIのリリース準備から公開後の更新確認までを進めます。配布経路の整理、テスト、大文字Vのタグ、配布ファイルの検証、リリースノートへの引き継ぎを扱います。

  • Mole CLIの公開準備を確認したいとき
  • 大文字Vのタグでリリースしたいとき
  • 公開ファイルと更新経路の検証
tw93/Mole7.2万2026年10月21日 更新

release-notes

無料概要あり

既存のMoleリリースに載せる英語・中国語の更新情報を作成し、承認後に反映します。利用者への影響順に変更を整理し、貢献者への謝辞やリアクションも整えます。

  • 英語・中国語のリリースノート作成
  • 利用者への影響順に変更を整理
  • 今回の貢献者への謝辞を確認
tw93/Mole7.2万2026年10月21日 更新

tw93 のスキルをすべて見る

このスキルの問題を報告する