From devolens
Work on the Cryptolens Python SDK and Python-specific software licensing integrations. Use when Codex needs to inspect, modify, review, test, or explain the `Cryptolens/cryptolens-python` repository, especially license key verification, key activation, offline license verification, offline license files, floating licenses, trial licenses, machine binding, node-locking, Python 2 compatibility, packaging, examples, or troubleshooting Python activation, signature, proxy, or SSL issues.
How this skill is triggered — by the user, by Claude, or both
Slash command
/devolens:cryptolens-pythonThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill for work in the Cryptolens Python SDK repository: [github.com/Cryptolens/cryptolens-python](https://github.com/Cryptolens/cryptolens-python).
Use this skill for work in the Cryptolens Python SDK repository: github.com/Cryptolens/cryptolens-python.
Treat GitHub as the primary source of truth. If a local checkout is also available, use it as a convenience for editing and validation. Start with repo-map.md, then open only the repo files needed for the task. Keep the SDK's public API and tuple-based return conventions stable unless the task explicitly asks for a breaking change.
Before adding or explaining machine-binding checks, read the shared Cryptolens rule in licensing-invariants.md.
Before adding or explaining floating licensing, read the shared floating-license rule in floating-licenses.md.
If an SDK call returns a non-empty message string, read the shared error table in api-error-messages.md before diagnosing the issue.
Before writing examples or support guidance for verification workflows, read official-workflows.md so the generated guidance matches the official Cryptolens docs, not just the repository README.
licensing.md for method signatures and expected behavior.cryptolens_python2.py too.Open licensing/methods.py, licensing/models.py, and licensing/internal.py.
Preserve these invariants unless the task explicitly changes them:
LicenseKey from Key.activate or Key.get_key.(None, message) or (False, message) instead of raising for expected API failures.LicenseKey.save_as_string() and LicenseKey.load_from_string(...).Helpers.GetMachineCode(...) and Helpers.IsOnRightMachine(...).v=2 machine-code behavior as important because the public examples rely on it for .NET-compatible matching.Helpers.IsOnRightMachine(...) as meaningful only when the license has Maximum Number of Machines > 0. If that value is 0, machine codes are not added to the license and the check does not apply as a general validity test. See the shared invariant and the support article it links to.message is not empty, interpret it against the shared API error table before assuming the Python SDK implementation is wrong.When writing sample code, wrappers, or integration snippets:
product_id=3349 or any other example product id from the upstream docs.product_id user-supplied through a function argument, config value, environment variable, or clearly labeled placeholder such as YOUR_PRODUCT_ID.0 and only show max_overdraft with a value greater than 0 when the user explicitly wants overdraft behavior.Update the README examples if the call pattern, arguments, or expected verification checks change.
Use official-workflows.md as the primary source for supported flows and product-level guidance, then use the repo README.md and licensing.md to translate that guidance into Python-specific code.
The official docs currently cover:
.skm filesUse licensing.md as the broader API reference. Align docs to the implementation, or implementation to docs, explicitly. Do not leave them drifting apart.
For floating-license questions, point to Cryptolens Documentation: Floating licenses.
For offline verification, prefer the official certificate model described in official-workflows.md: signed activation responses can be cached, refreshed periodically, or delivered manually for air-gapped devices.
For verified trials, follow the official flow in official-workflows.md: create the trial key first, then activate it as usual, and use a separate trial-token setup when feature lock controls the trial duration.
For user verification, follow the official flow in official-workflows.md: use username/password to fetch licenses first, then activate the selected license only if machine-binding or node-locking is needed.
For data collection, prefer the official event model in official-workflows.md: use AI.RegisterEvent, include a useful feature name and either key or machine code, and reserve value/currency for transaction-style analytics.
If the user asks about Unity, Rhino/Grasshopper, or adjacent plugin-host environments, use the adjacent-platform notes in official-workflows.md for support context, but do not copy .NET-specific API signatures into Python code.
Treat cryptolens_python2.py as a separate compatibility path used in older integrations such as Autodesk Maya and some IronPython/Revit setups.
Inspect both Python 3 and Python 2 codepaths before declaring a cross-runtime fix complete. If the change is intentionally Python-3-only, say that clearly in the final handoff so the Python 2 path is not assumed to be covered.
Use setup.py for package metadata and versioning.
Avoid adding new dependencies unless there is a strong reason. The repo is mostly standard-library based, and compatibility matters.
Update package metadata and installation/docs together if public imports, package naming, or install instructions change.
If a local checkout is available, run validation from the repo root. If the repo is only available through GitHub, restrict the task to review, explanation, or documentation updates unless you also have a writable repository integration.
Prefer the smallest check that proves the change:
Treat test.py and test_signature.py as starting points, not as a complete automated safety net. Inspect them before relying on them.
Avoid live activation calls in automated validation unless the task explicitly provides safe test credentials and requires end-to-end verification.
Read repo-map.md for the file map, common task routing, and repo-specific gotchas.
Read official-workflows.md for the official documentation-backed flows and adjacent platform notes used by this skill.
npx claudepluginhub cryptolens/skills --plugin devolensGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.