mlops-async

Wrapper workflow recipe for parent Codex sessions that need to coordinate Python topic delivery with repo-local planner, implementer, and reviewer agents while preserving shared artifact-contract boundaries.

Shared contract for repo-local Codex workflow artifacts. Use when creating, updating, or reviewing custom agents, wrapper skills, and their validation so paths, minimal schemas, and role boundaries stay consistent.

Implement one source SDK API or safe same-family batch from planner output using request-test-first porting, minimal implementation, response and error contract checks, optional tracker updates, and an explicit final decision.

Plan a source SDK API client port before implementation by collecting source evidence, drafting request contracts, classifying risk and stop flags, and preparing implementer handoff output for one endpoint family or safe same-family batch.

Query step status (pending/done) in plan/<topic>/<topic>.step.md with minimal token cost and explicit blocking when incomplete.

Run the sense_env.py scaffold to discover or assert facts about the repository environment. Use this when you need a structured JSON snapshot of the current environment state, or when you need to evaluate a contract's sensing assertions.

Define or normalize Python naming conventions for identifiers, files, folders, and visibility boundaries. Use this when drafting or reviewing Python code style rules centered on names.

Create a valid, repo-visible `plan/<topic>/<topic>.plan.md` for this repository, with correct workflow phases, status transitions, artifact paths, analysis-layer handling, reviewer handoff contract, and stable-library intent handling.

Independently review a repo-visible `plan/<topic>/<topic>.plan.md` for this repository after the plan exists and before execution proceeds. Use this when a topic plan needs a contract-level verdict against the repository workflow and plan-authoring rules.

Define or normalize Python naming conventions for identifiers, files, folders, and visibility boundaries. Use this when drafting or reviewing Python code style rules centered on names.

Review a Python *.plan.md for executability — verifying all 13 required sections, decision completeness, explicit async trigger or exemption citation, async-planning coverage when triggered, step precision, test specificity, and validation coverage before implementation begins.

Run the sense_env.py scaffold to discover or assert facts about the repository environment. Use this when you need a structured JSON snapshot of the current environment state, or when you need to evaluate a contract's sensing assertions.

Implement one source SDK API or a safe same-family batch from planner output using request-test-first API client porting, migration-map-first status updates, response/error contract extraction, and ledger-backed stop decisions.

Analyze source SDK APIs and endpoint families before implementation, producing request-contract evidence, migration-map rows, risk classification, porting order, and stop flags without editing production code.

Query step status (pending/done) in plan/<topic>/<topic>.step.md with minimal token cost and explicit blocking when incomplete.

Design or review Python serialization boundaries as semantic translation gates for API, database, and message payloads.

Write clear, contract-first docstrings using Google Style format with explicit intent and boundaries

Generate or refresh a target project's `.github/copilot-instructions.md` from current sensed facts, installed skills, and plan contracts, with hard stops for stale facts, missing facts, and materially different existing instructions.

Name or repair development branches with semantic prefixes, `<type>/<username>/<short-description>` structure, and migration guidance when work has already started on the wrong branch.

Draft or review semantic commit messages from staged changes, including split signals, business-facing subjects, breaking-change markers, and repair commands such as `git add -p`, `git reset`, and `git commit --amend`.

Run post-merge cleanup and local sync safely after a PR is merged, including STOP POINT 2 resume checks, branch deletion defaults, fast-forward-only sync, and final status verification.

Enforce a strict release gate for PR readiness, version-source synchronization, tagging safety, emergency exceptions, and release repair guidance without bypassing core quality checks.

Design or review public Python function and method signatures for safe defaults, clear parameter ordering, and explicit call-site contracts.

Choose and design general Python async/await code with explicit async boundaries, structured concurrency, and clear cancellation and async-protocol behavior.

Design or review ordinary Python classes with clear public surfaces, disciplined instance state, thin constructors, and limited use of properties and name mangling.

Choose and design synchronous Python context managers for resource lifetime and temporary state restoration. Use this when drafting or reviewing `with` usage, `@contextmanager` versus class-based design, setup/cleanup failure handling, and ambient-state restoration.

Choose clear Python data-model methods. Use this when deciding whether an ordinary class should define foundational dunder methods, expose base container protocols, or rely on dataclass-generated behavior.

Design or review general Python exception handling. Use this when choosing custom errors, translation boundaries, chaining, and when failures should propagate.

Design or review reusable Python library/package architecture with theme isolation, a side-effect-free `core`, and facade/client composition for multi-theme libraries and SDK-style packages.

Choose the right general-purpose Python construct for structured data and contracts. Use this when drafting or reviewing whether code should use Enum, dataclass, ABC, or Protocol.

Design or review regular Python package and module boundaries with explicit public surfaces, disciplined re-exports, safe imports, and clear internal-module contracts.

Design or review conservative Python package layouts with `src/`, `pyproject.toml`, clear library-vs-CLI placement, and tests that exercise packaged code rather than local-path accidents.

Design or review pure Python unit tests in pytest. Use this when choosing assertions, parametrization, fixtures, and unittest.mock patterns without real I/O.

Define or enforce Python type-hint rules for projects that run pyright in strict mode. Use this when drafting typing guidance or reviewing code against a strict typing baseline.