AtomiCloud
@AtomiCloud Organization
Public Skills
ecosystem-upgrade
by AtomiCloud
Drive a whole CyanPrint template-chain (ketone) through an ecosystem upgrade — baseline bump (e.g. nixos-26.05 + nix-registry/v3), modern nix-based generated CI, and republish — safely, in dependency order, and to a fixed point. Use when running /ecosystem-upgrade, performing a chain-wide baseline/registry bump across the ketone templates, upgrading the template ecosystem, or re-running the chain upgrade.
testing-template
by AtomiCloud
Test this CyanPrint template. Use when the user asks to write tests, add test cases, update snapshots, or debug template test failures. Covers test.cyan.yaml format with answer_state, deterministic_state, validate commands, and expected output.
writing-template-typescript
by AtomiCloud
Write or modify CyanPrint template code in TypeScript. Use when the user asks to add prompts, change template logic, modify the entry point, add processors/plugins/resolvers, or change generated output for a TypeScript template. Covers IInquirer question types (text, select, checkbox, confirm, password, dateSelect), processor configuration, and IDeterminism for non-deterministic values.
documenting-template
by AtomiCloud
Document this CyanPrint template into README.MD. Use when the user asks to document the template, write a README, explain how to use the template, or add usage documentation. Reads cyan.yaml and entry point code to generate accurate, artifact-specific docs.
testing-plugin
by AtomiCloud
Test this CyanPrint plugin. Use when the user asks to write plugin tests, add test cases, update snapshots, or debug plugin test failures. Covers test.cyan.yaml format with input directories, config, validate commands, and expected output.
fix-meta-template-test
by AtomiCloud
Debug and fix failing meta-template test cases for the CyanPrint ketone.new-cyanprint repository. Use when a test case fails and you need to trace the root cause back through the meta-template layer. Use when running /fix-meta-template-test.
documenting-plugin
by AtomiCloud
Document this CyanPrint plugin into README.MD. Use when the user asks to document the plugin, write a README, explain plugin configuration, or describe what the plugin validates or transforms. Reads cyan.yaml and entry point code to extract config schema and behavior.
writing-plugin-dotnet
by AtomiCloud
Write or modify CyanPrint plugin code in C#. Use when the user asks to add validation rules, change plugin behavior, modify the entry point, run commands from a plugin, or mutate files. Covers entry point (CyanEngine.StartPlugin), native filesystem I/O (System.IO), and command execution (System.Diagnostics.Process). Plugins receive { Directory, Config } and use native OS operations.
writing-plugin-javascript
by AtomiCloud
Write or modify CyanPrint plugin code in JavaScript. Use when the user asks to add validation rules, change plugin behavior, modify the entry point, run commands from a plugin, or mutate files. Covers entry point (StartPluginWithLambda), native filesystem I/O (fs), and command execution (child_process). Plugins receive { directory, config } and use native OS operations.
writing-plugin-python
by AtomiCloud
Write or modify CyanPrint plugin code in Python. Use when the user asks to add validation rules, change plugin behavior, modify the entry point, run commands from a plugin, or mutate files. Covers entry point (start_plugin_with_fn), native filesystem I/O (pathlib), and command execution (subprocess). Plugins receive { directory, config } and use native OS operations.
writing-plugin-typescript
by AtomiCloud
Write or modify CyanPrint plugin code in TypeScript. Use when the user asks to add validation rules, change plugin behavior, modify the entry point, run commands from a plugin, or mutate files. Covers entry point (StartPluginWithLambda), native filesystem I/O (fs), and command execution (child_process). Plugins receive { directory, config } and use native OS operations.
documenting-processor
by AtomiCloud
Document this CyanPrint processor into README.MD. Use when the user asks to document the processor, write a README, explain processor configuration, or describe file transformations. Reads cyan.yaml and entry point code to extract config schema and file handling.
testing-processor
by AtomiCloud
Test this CyanPrint processor. Use when the user asks to write processor tests, add test cases with input files, update snapshots, or debug processor test failures. Covers test.cyan.yaml format with input directories, config, validate commands, and expected output.
writing-processor-dotnet
by AtomiCloud
Write or modify CyanPrint processor code in C#. Use when the user asks to change file transformations, modify the entry point, handle file processing, or change output generation. Covers entry point (CyanEngine.StartProcessor), CyanFileHelper (ResolveAll/Read/Copy), and VirtualFile (Content/WriteFile). Processor function receives (ProcessorInput, CyanFileHelper) as two parameters.
writing-processor-javascript
by AtomiCloud
Write or modify CyanPrint processor code in JavaScript. Use when the user asks to change file transformations, modify the entry point, handle file processing, or change output generation. Covers entry point (StartProcessorWithLambda), CyanFileHelper (read/write/copy/resolveAll), and VirtualFile (content/read/write). Processor lambda receives (input, fileHelper) as two parameters.
writing-processor-python
by AtomiCloud
Write or modify CyanPrint processor code in Python. Use when the user asks to change file transformations, modify the entry point, handle file processing, or change output generation. Covers entry point (start_processor_with_fn), CyanFileHelper (resolve_all/read/copy), and VirtualFile (content/write_file). Processor function receives (input, file_helper) as two parameters.
writing-processor-typescript
by AtomiCloud
Write or modify CyanPrint processor code in TypeScript. Use when the user asks to change file transformations, modify the entry point, handle file processing, or change output generation. Covers entry point (StartProcessorWithLambda), CyanFileHelper (read/write/copy/resolveAll), and VirtualFile (content/read/write). Processor lambda receives (input, fileHelper) as two parameters.
documenting-resolver
by AtomiCloud
Document this CyanPrint resolver into README.MD. Use when the user asks to document the resolver, write a README, explain conflict resolution strategy, or describe merge behavior. Reads cyan.yaml and entry point code to extract config schema and resolution logic.
writing-resolver-dotnet
by AtomiCloud
Write or modify CyanPrint resolver code in C#. Use when the user asks to change conflict resolution logic, modify merge strategies, handle file origins, or change resolution behavior. Covers entry point (CyanEngine.StartResolver), ResolverInput/ResolverOutput, ResolvedFile, and FileOrigin. Must ensure commutativity and associativity (sort, unique, deterministic ordering).
writing-resolver-javascript
by AtomiCloud
Write or modify CyanPrint resolver code in JavaScript. Use when the user asks to change conflict resolution logic, modify merge strategies, handle file origins, or change resolution behavior. Covers entry point (StartResolverWithLambda), ResolverInput/ResolverOutput, ResolvedFile, and FileOrigin. Must ensure commutativity and associativity (sort, unique, deterministic ordering).
writing-resolver-python
by AtomiCloud
Write or modify CyanPrint resolver code in Python. Use when the user asks to change conflict resolution logic, modify merge strategies, handle file origins, or change resolution behavior. Covers entry point (start_resolver_with_fn), ResolverInput/ResolverOutput, ResolvedFile, and FileOrigin. Must ensure commutativity and associativity (sort, unique, deterministic ordering).
writing-resolver-typescript
by AtomiCloud
Write or modify CyanPrint resolver code in TypeScript. Use when the user asks to change conflict resolution logic, modify merge strategies, handle file origins, or change resolution behavior. Covers entry point (StartResolverWithLambda), ResolverInput/ResolverOutput, ResolvedFile, and FileOrigin. Must ensure commutativity and associativity (sort, unique, deterministic ordering).
testing-resolver
by AtomiCloud
Test this CyanPrint resolver. Use when the user asks to write resolver tests, add test cases with conflicting files, update snapshots, or debug resolver test failures. Covers test.cyan.yaml format with resolver_inputs (directory paths with origin), config, and expected output.
ci-cd-workflows
by AtomiCloud
CI/CD workflow patterns. Use when creating or modifying GitHub Actions workflows.
conventional-commits
by AtomiCloud
Conventional commit conventions. Use when writing commit messages.
docker-push
by AtomiCloud
Docker image build and push to container registry. Use when adding or modifying Docker image builds and pushes to GHCR.
linting
by AtomiCloud
Linting conventions. Use when running or configuring linting.
semantic-release
by AtomiCloud
Semantic release configuration and workflow. Use when configuring releases or understanding versioning.
service-tree
by AtomiCloud
Service Tree (LPSM) naming conventions. Use when naming resources, labels, tags, or when terms like LPSM, landscape, platform, service, module appear.
shell-conventions
by AtomiCloud
Shell script conventions. Use when writing or modifying shell scripts in scripts/.
taskfile-conventions
by AtomiCloud
Taskfile conventions. Use when creating or modifying Taskfile.yaml or tasks/.
upgrade
by AtomiCloud
Upgrade all CyanPrint SDK packages and Docker runtime versions across templates, plugins, and processors (TypeScript, JavaScript, Python, .NET), then run tests to validate. Use when upgrading dependencies, updating SDK versions, refreshing packages, updating Docker images, or running /upgrade.
nix
by AtomiCloud
Use for ALL Nix flake configuration questions. This includes file structure (flake.nix, nix/, .envrc), adding/removing packages or binaries, PATH configuration, development shells, pre-commit hooks, formatters, linters, enforcers, environment variables, adding registries, and how the Nix template structure works. Use when user asks about nix, flake, packages, binaries, shells, PATH, formatting, linting, git hooks, or registries.