albert-workspace

Generate a weekly status summary covering PRs opened/merged/closed by Albert, issues triaged, spec alignment progress, and blockers awaiting human input.

Triage incoming GitHub issues across supervised Altertable repositories. Use when processing new issues, labeling bugs and feature requests, detecting duplicates, requesting minimal reproductions, or marking stale issues.

Notification-driven maintainer routine to identify actionable work across supervised Altertable repositories. Relies on GitHub notifications and API to monitor activity and respond to issues and PRs requiring attention. Use when starting a maintenance session to process notifications and prioritize work.

Bootstrap or update an Altertable SDK repository from a versioned API spec. Use when given a target GitHub repository (e.g. altertable-ai/altertable-lakehouse-ruby) and a spec version tag (e.g. v0.1.0) to set up a git submodule, implement missing functionality, and submit a PR. Also use when a new spec version is released and the SDK needs to be updated to match.

Defines conventions for releasing open-source SDKs and libraries. Use when releasing a new version of an SDK, writing changelogs, or publishing to a language registry (npm, PyPI, Maven, etc.).

Keep shared configuration, community files, and CI templates consistent across all SDK repositories. Use when auditing cross-repo consistency or propagating a change (license, contributing guidelines, CI updates, bot config) to multiple SDK repos.

Review community pull requests against Altertable SDK standards. Use when reviewing contributor PRs, checking naming conventions, test coverage, changelog entries, and deciding whether to approve, request changes, or close.

Cross-repo consistency routine dispatched by the heartbeat. Checks spec drift and synchronizes community files across all SDK repositories. Use when the heartbeat needs to verify spec alignment and community file consistency.

Defines how to write README files for Altertable open-source SDK repositories. Use when creating or updating a README for monorepo roots or package-level SDKs. Enforces section order, copy-paste-ready examples, API/config tables, and modern OSS trust signals (badges, package matrix, contributor workflow).

Implement an SDK against a versioned spec. Use when sdk-bootstrap dispatches to Phase 5 — read the spec from specs/<type>/SPEC.md, implement per requirements, validate, and package. Takes SDK type (product-analytics, lakehouse) as input.