Oss Plan
Produce an execution plan before writing substantial code for a public open-source project. Use when starting or extending a feature to define the narrowest end-to-end slice, validation per step, trust boundaries, deployment path, and public-repository risks. Keeps the project runnable after every step. Does not write implementation code.
Release Deploy
Prepare a public open-source project for release and deploy it to a detected target. Use at a release or submission boundary to verify setup, docs, secrets, tests, lint, build, and licenses, then follow the target-specific deployment path. Runs expensive checks sequentially. Never publishes, tags, commits, pushes, or deploys without explicit user intent.
Test And Debug
Diagnose and repair a failing test, build, or runtime error in a public open-source project using the narrowest reproduction and validation. Use when something is broken and the cause is not yet known. Classifies the failure, isolates a reproduction, applies the smallest fix, and confirms with a targeted check. Does not add features.
Implementation Integrity
Audit an implementation for unnecessary artifacts, test manipulation, hardcoded shortcuts, fake success, bypassed product paths, and unsupported completion claims
Oss Bootstrap
Prepare a new public open-source repository, or convert a small existing directory into a clean publishable starting point. Use for an empty or nearly empty repo, a first local commit, or a first remote push. Do not use for routine feature work or releasing an established project. Never commits, creates a remote, or pushes unless explicitly requested.
Public Code Review
Review the current diff or a specified set of files as public open-source code before publishing or merging. Use to check code quality, public-repository safety (secrets and private data), documentation trustworthiness, provenance, onboarding, and maintainability. Reports grouped findings; does not fix them unless asked.
Dependency Review
Evaluate whether to add a new runtime or development dependency to a public open-source project before adding it. Use whenever a new package is proposed. Weighs standard-library alternatives, cost, transitive impact, maintenance, license, supply-chain risk, and low-resource effect, then decides add, do not add, or defer. Does not install anything.
Implement Minimal
Implement the smallest complete change that satisfies the current acceptance criteria for a public open-source project. Use when writing or editing code after a plan or a clear acceptance criterion exists. Avoids speculative abstraction, unrelated changes, obvious comments, and unverified validation claims. Keeps the project runnable after the increment.