techsmith-reference-architecture
Design a controlled architecture for Snagit capture and Camtasia recording/export workers with local scratch, durable manifests, validation, and artifact promotion. Use when moving beyond one-off scripts. Trigger with "TechSmith architecture", "Snagit automation design", or "Camtasia worker topology".
Allowed Tools
Provided by Plugin
techsmith-pack
18 source-grounded operator skills for safe Snagit and Camtasia desktop automation
Installation
This skill is included in the techsmith-pack plugin:
/plugin install techsmith-pack@claude-code-plugins-plus
Click to copy
Instructions
TechSmith Desktop Media Automation Architecture
Overview
This skill separates orchestration from licensed desktop execution. A control plane stores only job intent and redacted state; approved Windows or macOS workers perform version-pinned product operations on local storage; validators promote immutable outputs to archive or publishing systems after the application closes.
Prerequisites
- Workload classes, data classifications, service objectives, and expected volume
- Endpoint and entitlement inventory with product/version/platform capabilities
- Storage, network, identity, logging, retention, and incident constraints
- Approval owners for capture scope, deployment, activation, and publication
Tool Discipline
Use Read, Glob, and Grep to inspect local scripts, manifests, logs, and tests. Use WebFetch only for current primary TechSmith documentation. Use Write or Edit only after confirming the target repository file and approval boundary.
Current Contract
- Snagit COM jobs run only on licensed Windows workers with an interactive desktop.
- Camtasia active projects and media remain local and non-synced; promoted outputs are immutable artifacts.
- Job manifests carry product version, operation, input hashes, output policy, deadline, and idempotency key.
- Workers expose redacted state transitions, not remote arbitrary-shell access or license secrets.
Licensing and Authentication
TechSmith desktop activation is not API authentication. Resolve individual sign-in versus business-key or approved offline activation before execution. Redact all keys, account identifiers, activation artifacts, and sensitive endpoint details.
Instructions
- Discover existing scripts, workers, endpoints, storage paths, product versions, licenses, and downstream consumers.
- Define job classes and state transitions from accepted through staged, running, validating, promoted, failed, or quarantined.
- Partition workers by platform, product/version, interactive capability, and data classification.
- Design local scratch, durable manifests, checksums, output validation, post-close archival, and retention cleanup.
- Add admission control, per-session capture locks, bounded export workers, health probes, and dead-letter handling.
- Document trust boundaries, failure modes, rollback, recovery-time objectives, and migration from current scripts.
Approval Boundaries
Do not centralize raw license keys, captures, or project media in the control plane. Do not treat desktop workers as generic remote execution hosts.
Output
Return current and target topology, job/state model, trust boundaries, worker capability matrix, data flow, failure handling, migration stages, and unresolved decisions.
Error Handling
| Condition | Response |
|---|---|
| Worker capability unknown | Probe version and supported interfaces before assigning a job class. |
| Active data crosses to sync storage | Stage locally and promote only after product closure and validation. |
| Control plane needs product secrets | Redesign so activation stays endpoint-managed. |
| No idempotency boundary | Add durable job and output identities before enabling retries. |
Examples
The example below shows the minimum redacted evidence expected from a successful invocation of this operator workflow.
control-plane -> signed job manifest -> licensed local worker -> validator -> immutable artifact store