跳到正文
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(原文)

安装前可以查看交给 AI 代理的指令内容。

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.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

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

中文简介正在准备中。当前显示原文说明。

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

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

中文简介正在准备中。当前显示原文说明。

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

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月16日 更新

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月16日 更新

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

中文简介正在准备中。当前显示原文说明。

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

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月16日 更新

查看 hybridlabor-api 的全部技能

报告此技能的问题