本文へ移動
cccskills
無料GitHub で公開

pb-health-weekly

Weekly health report over the BDB repos: git and npm version drift and CI status as an HTML report with auto-remediation off, red CI routed to pb-ci-fix, non-release remediation steps run one at a time after GO. Use for "weekly health check", "ecosystem health", "are all repos green and in sync".

インストール方法を見る

含まれるファイル(1)

  • SKILL.md4.5 KB

SKILL.md(原文)

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

Weekly ecosystem health

What you get: a health report (full HTML report with git and npm drift when the health skill is installed, else a plain markdown report with git drift and CI status) for every repo, red repos handed to pb-ci-fix, and a one-line status. Availability: needs bdb-ecosystem-health (not shipped, aos-internal-staging) for the full report; without it only a plain markdown report, and only when repo_list is given.

Inputs

  • repo_list (optional) — the repos to check; default is the list the bdb-ecosystem-health skill carries

Steps

  1. Preflight — bdb-ecosystem-health listed in the harness skill list or its SKILL.md under the harness skills dir (~/.claude/skills, ~/.agents/skills, ~/.codex/skills, ~/.config/opencode/skills), gh auth status → run log header — skill absent → log "health skill not installed" and fallback mode: repo_list empty → stop with "Availability: needs bdb-ecosystem-health (not shipped, aos-internal-staging) for the full report"; else build a plain markdown report from git/gh facts only (version, tags, CI conclusion per repo; no HTML, no npm drift); gh missing or unauthenticated → log it, give the gh auth login hint, stop
  2. bdb-ecosystem-health (external; skipped when absent, step 3 then builds the report) — repo_list → HTML report with auto-remediation OFF (the report only proposes remediation) → report path in the run log — report exists; no remediation command was run
  3. github — report → table of every repo with version drift and CI conclusion in the run log (gh run list -R <owner/repo> --limit 1 --json conclusion,headSha per repo) — every repo listed; stops for approval (the human confirms which red repos to fix and which to defer)
  4. pb-ci-fix — per approved red repo → one pb-ci-fix run, with its own GO for the push — each red repo names its run log or "deferred: <reason>"
  5. [GO] remediation — per step the skill proposes in its report, except version bumps, tags, changelog edits and publishes, which are never run here: npm or git version drift is routed to pb-release-aos (or the repo's own release PR) and logged as a proposal; the exact command shown in the WAITING FOR GO line with the repo and what it changes. The run stops here until the human types GO. One GO = one remediation step. The playbook cannot know in advance whether the go-gate hook covers a proposed command (Claude Code, OpenCode, agy only): a git push, npm publish or npm version is covered by the go-gate hook where it runs (Claude Code, OpenCode, agy), any other command (an npm install -g, a gh write, an rsync) is not, and for those, and in every harness without the hook, this GO is the only guard. No proposed steps → step skipped
  6. quick-recap — run log → final line 🟢|🟡|🔴 with green, red-fixed, red-deferred and drift counts (n/a in fallback mode) — line written

Run log: production_artifacts/pb-health-weekly-<date>.md in the start directory, never committed; the full HTML report (when the health skill is installed) stays where the skill writes it and is not staged; in fallback mode the report is the run log's markdown table

Rules

  • Anything other than the literal GO (case-insensitive) is not a GO; a GO covers only that one step, one time.
  • A failed check stops the run: write the failure into the run log and report. No silent retries.
  • Write one run-log line per step as it completes (N. done|skipped|failed — artifact — check result) and WAITING FOR GO: <step> at each gate.
  • GO is by contract in every harness. The go-gate hook is only a backstop on Claude Code, OpenCode and agy (Codex: unverified; Cursor, Kimi: none). A missing hook is never permission to proceed.

レビュー

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

同じリポジトリのスキル

概要と使いどころ

Use when manage multiple local CLI agents via tmux sessions (start/stop/monitor/assign) with cron-friendly scheduling.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月12日 更新

Use when a hybrid memory system that provides persistent, searchable knowledge management for AI agents (Architecture, Patterns, Decisions).

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月12日 更新

Reference for how BDB structures autonomous software engineering work — the seven-node dispatcher graph (Architect, TechLead, UI/UX, Engineering, Media/EventTech, Reviewer, Shipping) that /startcycle-graph actually runs. Use when you need the high-level lifecycle framing without inventing your own process.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月12日 更新

Tools are how AI agents interact with the world. A well-designed tool is the difference between an agent that works and one that hallucinates, fails silently, or costs 10x more tokens than necessary. This skill covers tool design from schema to error handling.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月12日 更新

Harness patterns for coding agents — memory, permissions, context engineering, delegation, skills, hooks, bootstrap.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月12日 更新

agenttrail: live map of a multi-agent build in the browser: which plan component is being worked on, by which agent or harness, what is done and what is stuck. Use when a multi-agent pipeline starts (/startcycle, /startcycle-graph, /teamwork-preview) or after a plan-canvas approve, when the user asks to see what the agents are doing ("live map", "build board", "who is running now"), or by yourself whenever a multi-agent run is under way — no user prompt needed.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月12日 更新

hybridlabor-api のスキルをすべて見る

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