acornops

Coordinate AcornOps API and cross-repository contract changes. Use when editing docs/contracts, contract manifests, OpenAPI specs, DTOs, generated clients, request/response schemas, target model APIs, target capability payloads, or code that changes an integration boundary between child repositories. Do not use for purely internal refactors with no public or cross-service behavior change.

Commit and open AcornOps pull requests from the workspace. Use when the user asks to commit, push, open PRs, publish work, or prepare review across one or more child repositories. Handles per-repo commits, draft PRs, related PR links, and validation evidence. Do not use for code review without publishing; use acornops-pr-review instead.

Perform structured AcornOps reviews of existing pull requests across architecture, testing, documentation, and security. Use when asked to review a PR, inspect a diff, assess requested changes, or evaluate an integration-sensitive change. Do not use to commit, push, publish, or open PRs; use acornops-open-pr instead.

Select and execute repository-appropriate validation for AcornOps changes. Use when behavior, deployment configuration, operational runtime paths, or completed contract changes need validation evidence. Do not use as the primary workflow for designing API/schema/manifest changes; use acornops-contract-change for that.

Maintain the AcornOps workspace harness and developer entrypoint. Use when editing workspace.yaml, Taskfile.yml, root README/AGENTS/CLAUDE files, .gitignore, change-sets, shared skills, shared GitHub templates, workspace scripts, harness checks, sync tooling, CI policy, or Codex hook configuration. Do not use for product code inside child repositories.

Preserve AcornOps target model boundaries. Use when adding or changing target types such as Kubernetes clusters, VMs, or future runtimes; target registration, identity, health, credentials, capabilities, lifecycle, routing, UI/API naming, or deployment behavior. Do not use for changes that are purely internal to one existing target implementation with no shared target model impact.

Use when reviewing prose, documentation, article drafts, comments, or submissions for suspected AI-generated writing; when asked to reject AI writing; or when writing should be checked for LLM-like style, fabricated sourcing, generic filler, malformed markup, or formulaic tone before acceptance.

Draft and refine Codex Goals for AcornOps work from plain-language tasks. Use when a user asks to create, write, improve, evaluate, or decide whether to use a Codex `/goal`; when AcornOps work may need persistent multi-turn continuation; or when a task needs an evidence-based completion contract with verification, constraints, boundaries, iteration policy, and blocked stop conditions.

Coordinate AcornOps changes that touch more than one child repository. Use when a task spans multiple repos, needs a shared branch slug, requires related PRs with merge order, or needs workspace-level tracking. For API/schema/manifest boundary changes, also use acornops-contract-change. Do not use for single-repo implementation work unless it creates cross-repo coordination needs.

Preserve diagnosability by validating logs, metrics, health checks, and runtime event signals. Use for API behavior changes, worker/queue updates, streaming paths, retries, or timeout modifications.

Enforce baseline AcornOps security controls for code and infrastructure changes. Use when auth, secrets, access control, RBAC, external integrations, or privileged operations are involved.

Keep AcornOps target-specific logic modular behind explicit adapters. Use when adding or changing Kubernetes, VM, or future target-specific SDK clients, credential handlers, health checks, lifecycle handlers, deployment backends, execution runners, capability implementations, or routing branches. Do not use for target-neutral refactors that do not touch adapter boundaries.