Lawful cannabis cultivation · evidence before certainty
CanopyOps is an installable AI skill for cannabis cultivation leaders, agronomists, crop steering teams, quality staff, and compliance operators. It structures room data, observations, facility constraints, and unresolved questions into reviewable plans, incident workups, calculations, CAPA, runbooks, and handoffs.
Advisory decision support · Human authority stays explicit · No direct equipment control
Product fit
Use CanopyOps when the job is to organize evidence, reproduce a calculation, preserve competing explanations, name an approval gate, or hand a decision to the next accountable human.
CanopyOps preserves nine states: observed → measured → calculated → assumed → interpreted → recommended → approved → executed → verified.
Choose one distribution
The repository-native v0.1.5 line and portable v0.1.7 line contain the same operating method in different package topologies. Do not mix their files.
Best for direct GitHub marketplace installation, the branded plugin, standalone source inspection, and repository-native Claude packaging.
Read its evidence boundaryBest for a self-verifying archive with Codex and Claude payloads, package-specific instructions, detached checksum, manifest, and receipt.
Open the published releaseA valid package is not evidence that a host installed, discovered, invoked, or successfully executed it. Those states must be observed separately.
Installation
Before installing, keep operational records outside the skill or plugin directory, confirm your own backup or version-history process, and use fictional or sanitized data for the first run.
CODEX · GITHUB PLUGIN
codex plugin marketplace add Stunspot/CanopyOps
codex plugin add canopyops@collaborative-dynamicsStart a fresh Codex task after installation. Command availability depends on the installed Codex build and workspace policy.
CODEX · PORTABLE v0.1.7
python tools/verify_release.py .."ok": true, and has no findings.codex/canopyops/ directory using a supported local plugin source.CODEX · STANDALONE
Copy the complete repository-native canopyops/ directory so the final path is normally %USERPROFILE%\.codex\skills\canopyops\SKILL.md, then start a fresh task.
Do not copy SKILL.md alone; its persona, workflows, references, templates, examples, adapters, evaluations, and scripts are part of the skill.
CLAUDE.AI · CLAUDE CODE
Claude.ai can upload either supplied skill ZIP unchanged under Customize → Skills. On Enterprise, an organization owner must first enable both Code execution and file creation and Skills. Claude Code can use the complete skill directory at ~/.claude/skills/canopyops/ or a project-local .claude/skills/canopyops/.
Live Claude upload, activation, progressive loading, and script execution are not claimed by the current CanopyOps evidence.
Verify discovery, then reach first value
Start a fresh task or conversation after installation. Explicitly invoke CanopyOps if the host supports it, then keep discovery evidence separate from output quality.
DISCOVERY CHECK
Use CanopyOps to outline the evidence you would need before reviewing a fictional late-flower cannabis humidity excursion. Do not diagnose or recommend operational changes yet.
A discovered CanopyOps skill should request facility context, crop stage, duration, sensor location and method, approved-target source and tolerance, observations, prior conditions, equipment state, and accountable authority.
FIRST COMPLETE WORKUP
Use CanopyOps for a fictional licensed cultivation facility. A late-flower room held 27 C and 78% RH for 42 minutes overnight. One wall sensor recorded the excursion; its calibration status and exact canopy position are unknown. The active target is 25 C and no more than 60% RH, but I have not supplied the approved source or tolerance. Build a provisional incident workup and record. Preserve competing explanations, separate reversible containment from cause-specific correction, identify evidence that would change the next decision, and do not claim that any setting was approved or changed.
Representative workflows
Inputs may be prose, tables, logs, CSV, JSON, approved documents, measurements, images supplied for interpretation, or existing operating records. Outputs are drafts for inspection, not silent execution.
Inputs: facility limits, crop stage, cultivar evidence, targets, labor, measurement methods.
Outputs: crop plan, room runbook, risk register, open-decision list.
Inputs: observations, logs, spatial pattern, timeline, equipment state, prior actions.
Outputs: incident workup, evidence gaps, containment, decision record, CAPA.
Inputs: temperature, RH, leaf temperature, light, irrigation, substrate, runoff, EC, pH.
Outputs: transparent calculations, comparison tables, method caveats, next measurement.
Inputs: readiness observations, sample methods, drying conditions, laboratory evidence, holds.
Outputs: harvest-readiness review, drying log, hold list, release-preparation brief.
Inputs: facility SOPs, labels, current jurisdiction sources, named owners, approvals, deadlines.
Outputs: compliance-verification brief, cultivation decision, crop walk, shift handoff.
Inputs: completed artifact, evidence ledger, unresolved conditions, approval and verification records.
Outputs: review findings, status, blocked conditions, named next owner; never automatic release authority.
Configuration and methods
Ordinary reasoning requires no CanopyOps account, API key, or product configuration file. The meaningful configuration is the operating context you supply: facility, room, crop stage, units, sensor method and location, time window, approved targets and tolerances, applicable SOPs, jurisdiction, owners, and authority.
Optional for ordinary reasoning; required for bundled deterministic utilities and the portable v0.1.7 verifier. Repository-native utilities use the Python standard library.
Facility SOPs, emergency procedures, current labels, current jurisdiction sources, laboratory evidence, and equipment documentation outrank model memory.
Keep facility and crop records in an approved workspace outside the installation tree. CanopyOps does not create backups or manage retention for you.
Troubleshooting, recovery, and cleanup
Confirm the final path ends in canopyops/SKILL.md, the complete package is present, and stale duplicates are disabled. Start a fresh task or restart the host once.
Reinstall the complete matching package. If a script is unavailable, confirm Python 3 and the specific workspace permission; otherwise use the documented manual fallback and label it unverified.
Stop. Compare the detached checksum, discard the failed extraction, extract again into a clean directory, and continue only after the verifier returns no findings.
Identify the installed line, preserve records outside it, replace the complete matching package, start fresh, repeat discovery, and rerun the appropriate verifier. Never overlay v0.1.7 onto v0.1.5.
Remove the plugin through the host, or remove the complete installed skill directory. Disable or delete Claude.ai uploads. Archive or delete extracted packages under your retention policy.
If records were wrongly stored inside the install tree, stop changes, preserve what remains, restore from your already-established backup or version history, and move recovered records outside the package. Never invent missing operational records.
Removing CanopyOps does not delete artifacts stored elsewhere. CanopyOps itself does not back up, synchronize, or clean those records.
Validation and provenance
The current repository suite contains 21 deterministic tests for calculations, validation, package parity, version custody, documentation reachability, release-story consistency, and Pages-local assets. The portable v0.1.7 bundle has its own verifier for package structure and byte custody.
The source, plugin, portable bundle, templates, scripts, schemas, examples, and documentation are present.
Repository tests and the portable verifier can check recorded structure, links, relationships, checksums, archive membership, and parity.
Fresh-host installation, host discovery, invocation, tool execution, useful behavior, field fitness, legal correctness, regulatory currency, or customer outcomes.
Historical v0.1.5 evidence remains historical. Portable v0.1.7 evidence applies only to the exact package objects it names. Current documentation review evidence is bound to its recorded content fingerprint.
Support, contribution, and rights
For a reproducible product defect, open a GitHub issue with sanitized inputs, expected and actual behavior, distribution line, version, host, and exact error. For an active alarm or life-safety event, use facility emergency procedures—not repository support.
Read the troubleshooting guide first, then report a minimal sanitized reproduction.
Support policyPreserve evidence states, safety boundaries, source custody, package-line separation, and deterministic verification.
Contribution guideAuthored Augment material uses CC-BY-ND-4.0; Python, tests, and machine-readable schemas use MIT. Marks remain governed separately.
License · Trademarks