ZzzOps

View saved version →

---
name: add-zzzops-goal
description: "ZzzOps v2.1.0 — official plugin. Capture, add, create, or record one durable ZzzOps goal/TODO. Use for new project work or backlog items; writes canonical goal state by default. Not migration, suggestion, triage, or execution."
---

# Add Goal

Run `../../rules/INITIALIZATION.md`, then `../../rules/BACKENDS.md`. Hydrate likely duplicate/relationship matches and needed comments. Persist risk/overrides; interview at [[effective engineering rigor]](../../concepts/effective-engineering-rigor.md): `vibe → light`, `structured → standard`, `agentic → thorough`. This controls depth; legacy policy uses reviewed `requirements_interview.capture_depth` or `standard`. Escalate as required; never silently de-escalate below a risk minimum.

Reuse request, repository, goal, and answer evidence. Ask 1–3 consequential gaps; recommend answers. `light`: outcome, observable acceptance, critical constraints. `standard` adds scope/non-goals, examples, dependencies, risks, authority, verification. `thorough` adds architecture, security, data lifecycle, recovery, operations, rollout, accessibility, compatibility, governance. Challenge subjective success/contradictions. Current user owns requirements/acceptance; no multi-party sign-off.

When unfamiliarity/risk could change architecture, scope, acceptance, or quality, run a bounded blind-spot pass for known unknowns, tacit criteria, and blind spots using the cheapest useful reference, research, alternative, or disposable prototype. Skip well-understood work and fixed ceremony.

Stop when independently actionable/verifiable at that depth or unknowns are explicit blockers. Create one human-first current-schema goal with applicable source/value evidence; never invent answers. Use `$execute-zzzops`.

Git-free creation: capture makes no branch, commit, push, PR, or empty checkpoint.

Apply `../../rules/CONTINUATION.md`; active same-task execute intent may resume once, while capture-only/replacement/stop wins. Confirm outcome/link and only next-affecting relationships/unknowns.

Before stopping or handing off, apply `../../rules/FEEDBACK.md`.

Referenced files: 1

View saved version →

---
name: bootstrap-zzzops-repository
description: "ZzzOps v2.1.0 — official plugin. Bootstrap an empty, early-stage, or established software repository from a product specification into an agent-ready harness and executable product goal DAG. Use to discover, structure, and execute a project through safe PR-gated work."
---

# Bootstrap a ZzzOps Repository

Establish a clear product outcome and the proportionate engineering harness agents need, then execute the authorized product DAG. Bootstrap coordinates policy, ordinary goals, execution, verification, and migration rather than duplicating them.

1. Read [repository and product analysis](../../zzzops/references/bootstrap/ANALYZE.md). Before harness commitment, run the adaptive product interview to establish beneficiaries, observable success, scope/non-goals, initial milestone, constraints, and applicable risk/governance facts. This is discovery, not an approval gate. Classify the repository from evidence and use [[bounded commitment]](../../concepts/bounded-commitment.md) for unknown technical choices.
2. Use `../../rules/INITIALIZATION.md` and `../../rules/BACKENDS.md` after the product brief can inform policy. `$review-zzzops-policy` remains the one mandatory approval before work; persist the brief/resume point and continue after approval. Effective rigor sets discovery and harness depth; never silently de-escalate.
3. Read [goal-DAG planning](../../zzzops/references/bootstrap/PLAN.md). Create or reconcile exactly one canonical top-level product-outcome goal before harness goals, then place justified harness outcomes and initial product milestones beneath it with only their real dependencies.
4. For an empty or minimal repository, follow the [greenfield journey](../../zzzops/references/bootstrap/GREENFIELD.md). For an established repository, follow the [brownfield audit and closure journey](../../zzzops/references/bootstrap/BROWNFIELD.md). Early scaffolds use the parts justified by their evidence.
5. Invoke `$execute-zzzops` for the authorized canonical DAG. Continue from harness outcomes into product milestones through distinct stacked PRs until no [[safe useful work]](../../concepts/safe-useful-work.md) remains. Unresolved product authority or high commitment blocks only the affected chain; required checks, PR review, merge, external-write, deployment, and release gates remain.
6. Report the product goal, classification evidence, created/reused goals, observed verification, ordered PR review queue, hard blockers, and deferred unauthorized scope. Bootstrap is incomplete if the root goal is absent, canonical verification was not observed, or safe authorized product work was left merely because the harness finished. A repeat run reuses canonical state.

Keep `AGENTS.md` compact and reconcile it in place. `$review-zzzops-policy` owns its ZzzOps-adherence block; bootstrap may update stable repository context around that block. Put specialist knowledge in linked dynamic context, and add deterministic guardrails only when their value justifies their machinery.

Before stopping or handing off, apply `../../rules/FEEDBACK.md`.

Referenced files: 1

View saved version →

---
name: execute-zzzops
description: "ZzzOps v2.1.0 — official plugin. Execute the primary ZzzOps goal loop: work all goals, continue, resume, triage, prioritize, reprioritize, unblock, verify, commit, refill, and report. Default executes authorized work. \"dry run\", \"preview\", or \"plan\" performs read-only queue analysis with no writes. Not one-off untracked work."
---

# Execute ZzzOps

Mode: `dry run`, `preview`, or `plan` means read-only inventory, triage simulation, ordering, and blocker reporting; do not initialize/apply, claim, update goals, edit source, run mutating commands, or change Git/external state. Otherwise run the live loop below.

First run `../../rules/INITIALIZATION.md`, then route through `../../rules/BACKENDS.md`. Read `../../rules/GOAL_SYSTEM.md` and the initialized charter; load only what applies.
Track execute intent through `../../rules/CONTINUATION.md` so additive capture can safely resume without nested loops.

Goals labeled `zzzops-feedback` are excluded by default. Include them only when the user explicitly approves inclusion for the current execution session; invocation approval counts, one approval covers all feedback goals, and expires with the session. Never ask per issue. Preserve the choice on every checkpoint/portfolio refresh by using `--include-feedback` only in an approved session.


- Create/triage/decompose: [CREATE.md](references/CREATE.md).
- Unblock and persist unanswered requests: [UNBLOCK.md](references/UNBLOCK.md) and `../../rules/BLOCKERS.md`.
- Select/execute/complete/handoff: [EXECUTE.md](references/EXECUTE.md).
- Source-changing branch topology/review: [BRANCH_REVIEW.md](references/BRANCH_REVIEW.md).
- Pre-handoff diff/dead-code review: [SELF_REVIEW.md](references/SELF_REVIEW.md).
- Tests, delegation, parallelism, or long commands: `../../rules/EXECUTION_STRATEGY.md`.
- Exhausted-queue backlog suggestions: `$suggest-zzzops-work` when explicitly enabled by reviewed PROJECT policy.

Apply PROJECT throughout. Before writes assess [[bounded commitment]](../../concepts/bounded-commitment.md); before switching/stopping persist resumable state. Continue while policy permits [[safe useful work]](../../concepts/safe-useful-work.md); optimize verified value, not count.

Before source work, read PROJECT Git/review/continuation policy and checkpoint only pending local ZzzOps state when required; never absorb unrelated changes or create an empty GitHub-state commit.

Before stopping or handing off, apply `../../rules/FEEDBACK.md`.

Referenced files: 8

View saved version →

---
name: migrate-to-zzzops
description: "ZzzOps v2.1.0 — official plugin. Discover, plan, migrate, or import repository TODOs/backlogs into durable ZzzOps goals. \"dry run\", \"preview\", or \"plan\" gives a no-write report. Default builds review artifacts and applies only after approval; \"apply\", \"migrate\", or \"import\" requests that workflow. Not installation or goal execution."
---

# Migrate to ZzzOps

Mode: `dry run`, `preview`, or `plan` reports candidates and a proposed plan in chat without creating plan/summary files or changing state. Otherwise build the review artifacts below; apply only after explicit approval.

Run `../../rules/INITIALIZATION.md`, then `../../rules/BACKENDS.md`. Use `../../zzzops/templates/project-goals/` for artifact shapes.

1. Run `scripts/inventory.py .`. Treat its candidates, types, confidence, and possible-same-outcome groups only as discovery hints. Read each candidate's evidence, enclosing headings, complete surrounding section, and relevant project context yourself; never infer intent, completion, or identity from the script.
2. Perform one explicit completeness review: inspect relevant source sections (including completed-looking/zero-match sections), disposition every plausible open/conditional outcome, and preserve every source location for possible matches. Compare fingerprints with `.zzzops/migration/STATE.json` and minimal goal discovery; hydrate only plausible duplicate bodies, then material history. Ignore managed/dependency/build/generated areas. Apply PROJECT interview policy to consequential ambiguity and reuse charter answers.
3. Copy the installed plan and summary templates into `.zzzops/migration/`. Classify completion from full context; summarize skipped completed items and propose only open work. Fill goals, value rationale, source disposition, exclusions, and questions. Present proposed outcomes, consequential questions, and the approval needed; link `SUMMARY.md` for detail.
4. Apply the approved plan as native GitHub issues/comments with the current schema label. For an inline TODO/comment, preserve its useful text and append the created GitHub issue URL using the file's existing comment syntax; never delete it as migration cleanup. Update charter, history, and `STATE.json`; delete a dedicated backlog only after full representation. Verify and remove resolved artifacts. Report what was imported, needed action, and what follows; keep fingerprints/state bookkeeping internal.

Only the main agent writes. Repeat runs act only on new fingerprints. Never expose secrets or infer ownership from paths.
Migration capture performs no Git automation.

Before stopping or handing off, apply `../../rules/FEEDBACK.md`.

Referenced files: 3

View saved version →

---
name: review-agentic-engineering
description: "ZzzOps v2.1.0 — official plugin. Review completed software-agent work on explicit request and suggest one or two evidence-based improvements to the user's overall agentic-engineering practice. Read-only; not a scorecard, automatic coaching, repository mutation, or ZzzOps feedback submission."
---

# Review Agentic Engineering

Run only when explicitly invoked. Help the user improve how they use software agents across projects without assuming that friction was their prompting fault.

1. Read [evidence and attribution](references/ATTRIBUTION.md). Inspect several substantial completed work items when available, using evidence already visible in the current environment. Do not create a prompt archive or copy raw project content into attribution input or output.
2. Attribute the evidence through the bounded read-only `coaching attribute` interface. Evaluate expectations relative to effective rigor, task stakes, repository context, specialist context, and facts an agent should have discovered itself.
3. If evidence is insufficient or ambiguous, say so plainly and stop. Do not manufacture advice to fill a report.
4. Select at most two high-value observations. Coach user practice only for genuine specification gaps. For context, skill, tooling, guardrail, verification, implementation, or external causes, name the owning system surface and avoid blaming the user.
5. Make each observation concise: the pattern, why it matters, and one practical improvement or durable destination. Optimize information efficiency, verification, task boundaries, and autonomy—not prompt length.

Remain read-only: do not edit policy, `AGENTS.md`, documentation, skills, tests, CI, goals, or repository files, and do not write to GitHub. Recommend a destination without changing it. `$send-zzzops-feedback` separately submits feedback about ZzzOps itself; never invoke or imitate it here.

Before stopping, apply the privacy boundary in `../../rules/FEEDBACK.md` without recording a new execution report solely because this review ran.

Referenced files: 2

View saved version →

---
name: review-zzzops-policy
description: "ZzzOps v2.1.0 — official plugin. Review, initialize, summarize, reconcile, or adjust ZzzOps project policy. Preferred first workflow; always re-summarizes existing policy."
---

# Review ZzzOps Policy

Follow `../../rules/INITIALIZATION.md`; only this workflow changes or confirms policy.

Before optional tools, reuse capabilities; never invoke an unavailable path—use an alternative or block once.

Run `init inspect` once. Show its `policy_review_table` exactly once before detail or action; never filter rows, even when policy is unchanged and approved. Keep hashes, snapshots, raw settings, and provenance progressive. Offer privacy-safe execution reports. For a missing automated-design section explain enabled/disabled. For missing workflow-adherence sections explain `optional`/`tracked`/`managed` and propose `tracked` for adherence; for missing rigor explain `vibe`/`structured`/`agentic` and propose `structured`—all without inferring approval.

Always foreground approval timing. Recommend `human_at_exhaustion`: policy approval gates execution once, verified per-goal PRs stack until safe work is exhausted, then the user reviews the ordered queue. Explain `human_after_checks` plus completed-dependency gating as the stricter per-goal alternative. Describe [[bounded commitment]](../../concepts/bounded-commitment.md) before automated-design authority; neither option bypasses checks, PR approval, merge authority, or release policy.

Review rigor defaults/escalation/minimums/overrides/interview depth. More rigor costs upfront but cuts ambiguity/rework/regressions; never silently lower or undercut a minimum.

Compare default IDs/digests first. Changed/stale: load full old/new snapshots only for changed or selected sections. Missing legacy provenance stays unknown. Replace matching stored defaults only; report customized values without replacement.

If every required section has valid approval, say `The policy is already approved.` Do not ask for approval or run `init confirm`. Else require explicit approval of the current digest (`approval digest`), then `init confirm`. Approved policy artifacts may enter ordinary PR review without another conversational gate.

Approved adherence: reconcile a bounded `AGENTS.md` block (`BEGIN ZZZOPS WORKFLOW ADHERENCE`); preserve all unrelated instructions.

Before stopping or handing off, apply `../../rules/FEEDBACK.md`.

Referenced files: 1

View saved version →

---
name: send-zzzops-feedback
description: "ZzzOps v2.1.0 — official plugin. Preview and send user feedback plus privacy-safe archived ZzzOps execution reports to the public ZzzOps repository. Requires exact-payload confirmation before the external write."
---

# Send ZzzOps Feedback

Run `../../rules/INITIALIZATION.md`, then read `../../rules/FEEDBACK.md`. Use the resolved Python interpreter for all CLI calls.

Use checkpoint only for readiness; detailed inputs are local reports and explicit feedback, never goal bodies/history.

1. Keep user text separate from execution reports. Before public preview, reject credentials, payment cards, health data, government IDs, and other restricted data.
2. Run `report list` and inspect every valid archived report. Reports contain only constrained machinery codes, numeric impact, and validated ZzzOps build provenance; legacy schema-v2 provenance is explicitly unknown. Malformed or unknown content is a safety failure, so stop without submitting or deleting anything.
3. Pass the feedback through stdin or a securely created temporary UTF-8 file to `feedback prepare`; never put it directly in a command-line argument. By default include all archived reports unless the user selected a subset.
4. Show the exact target, title, labels, and body returned by `feedback prepare`, including cause/build-specific natural-language accounts and the collapsed immutable JSON appendix. State that `david-rzepa/zzzops` is public and ask the user to confirm that exact payload. The `zzzops-feedback` label keeps it outside ordinary execution unless a user approves the feedback queue for that session. Do not submit on an inferred, stale, or general approval.
5. After confirmation, pass the same prompt bytes and selected report IDs to `feedback submit --confirm DIGEST`. The deterministic CLI recomputes the payload, creates the GitHub issue only if the digest still matches, validates the returned issue URL, and then deletes the submitted reports.
6. Return the created issue link. On cancellation, drift, provider failure, or unexpected output, report that nothing was deleted and preserve the reports for retry.

This skill makes one external write only after exact confirmation. It never edits project source, goals, policy, Git state, or unrelated GitHub records.

Referenced files: 1

View saved version →

---
name: suggest-zzzops-work
description: "ZzzOps v2.1.0 — official plugin. Suggest, discover, or audit valuable ZzzOps work from project code, tests, docs, config, and state. \"dry run\", \"preview\", or \"plan\" is the no-write default; \"apply\" writes approved goals, and \"refill\" writes only when authorized by reviewed exhausted-queue policy."
---

# Suggest ZzzOps Work

Run `../../rules/INITIALIZATION.md`, then `../../rules/BACKENDS.md`. Read project instructions, charter, and minimal evidence; hydrate only likely duplicates, and history only when needed.

1. Mode defaults to `dry-run`: no edits to source, Git, goals, or index. `apply` requires explicit user request or a `$execute-zzzops` invocation explicitly allowed by reviewed PROJECT refill policy.
   Always run `<python> <zzzops-cli> --repo . entropy list` once. Validate each returned observation against current repository evidence before ranking it; excluded categories stay pending and invisible under the existing PROJECT refill `allowed_categories` policy. An explicit entropy-review request broadens the same evidence-led repository audit without adding another skill or policy knob.
2. Inspect actual architecture/entry points and relevant active code, tests/evidence, docs, CI/build/config, observability/security/performance/accessibility, and stale paths. Use focused native commands; do not run expensive suites merely for ideas.
3. Compare reviewed and goal-effective engineering rigor with the real harness. Agentic work without CI, prose-only invariants, incomplete canonical verification, unverified security-sensitive work, or repeated unenforced `AGENTS.md` rules becomes a proposed goal—not a silent change. Credit existing context/tools; prefer coherent feedback over tool quantity.
4. Compare charter, goals, and trackers. Reject duplicates, generated/dependency work, speculative rewrites, cosmetic churn, and ideas without an evidenced beneficiary/result.
5. Rank a short high-confidence list by value, risk, unlocks, confidence, difficulty, and feedback speed. Record evidence/criteria/dependencies/probe; present outcome, value, and next decision. Without observation, propose the smallest harness first.
6. Dry-run reports ranked outcomes and no changes. Apply creates only authorized goals with `$add-zzzops-goal` semantics and evidence. During exhausted-queue refill, tag every goal `zzzops-refill`; never copy source labels such as `zzzops-feedback`. Never implement or automate Git while suggesting.

For each inbox observation, inspect only enough current evidence to classify it.
Dismiss stale, disproved, or duplicate observations with `entropy resolve --outcome
dismissed`; leave supported observations pending through dry-run preview, and resolve
them as `captured` only after an ordinary goal is confirmed. The inbox is evidence,
not authority or a second backlog. Return no suggestion when no decay is evidenced.

Exhausted-queue apply honors independent opt-ins:

- `documentation`: missing, stale, misleading, or inaccessible user/developer/operations docs.
- `tests`: evidenced untested behavior, regression, boundary, or missing fast feedback—not percentage theater. Apply PROJECT `test_bug`; `capture_and_ask` records a separate human-blocked TODO before any fix.
- `code_quality_non_behavioral`: behavior-preserving naming, extraction/decomposition, dead/duplicate code cleanup, or monolith splitting. Require unchanged-behavior evidence; exclude features, architecture rewrites, and style churn.

Use only PROJECT-enabled categories and cap, then return to `$execute-zzzops`. Ask about material ambiguity; never manufacture work.

Before stopping or handing off, apply `../../rules/FEEDBACK.md`.

Referenced files: 1

View saved version →

---
name: validate-zzzops-installation
description: "ZzzOps v2.1.0 — official plugin. Validate one repository after ZzzOps installation or upgrade, detect retired local machinery, and remove only fingerprint-proven legacy files after confirmation."
---

# Validate ZzzOps Installation

This workflow owns the installation check, so skip `INITIALIZATION.md`'s validation handoff and do not recurse. Resolve Python and the installed package CLI as described there.

1. Run `installation status`. Automatic routing stops immediately when the current package record is `clean` or `declined`; explicit invocation continues to a fresh audit.
2. Run `installation audit`. Also inspect root agent-instruction files for stale repository-local ZzzOps paths and confirm the package exposes only plugin installation plus the narrowly retained cleanup support. Treat repository evidence as authoritative; do not choose between official and development host installations.
3. If the audit is unsafe or ambiguous, show the exact hazards and stop. Never record success, delete, edit instructions, touch host caches, or change Git state.
4. With no cleanup candidates or instruction conflicts, record `clean` using the exact audit signature.
5. With fingerprint-proven candidates, show the exact files, ignore-block edits, ownership proof, and tracked-file warning from the audit and cleanup dry run. Ask once for explicit removal confirmation. A refusal records `declined` with the exact audit signature, changes nothing, and prevents automatic re-prompting for this package; explicit invocation can retry.
6. After confirmation, run the shipped cleaner with `--apply --yes`. Re-audit, require a safe result with no remaining candidates, then record `clean` using the new signature. Report what was removed and that Git-index deletions remain for the user to review.
7. When routed from another ZzzOps workflow, resume that original workflow exactly once after a confirmed record. Interruption writes no record, so the next invocation safely retries.

The validation record lives in ignored repository-local Git metadata and is keyed by the installed manifest version and complete package digest. It is not an installer lockfile or package source of truth.

Before stopping or handing off, apply `../../rules/FEEDBACK.md`.

Referenced files: 1