skills

Create, organize, review, or refactor Tolaria Markdown vault content using the Tolaria knowledge method. Use when working with notes, inbox cleanup, canonical frontmatter schema, note types, projects, responsibilities, procedures, topics, people, events, workspaces, semantic fields, underscore system properties, typed relations, parser/UI filtering expectations, capture to organize workflows, or vault conventions. Do not use for general product strategy, positioning, or Tolaria app implementation work unless the task directly concerns vault content, frontmatter conventions, or schema behavior.

Diagnose and resolve GNU Stow failures, conflicts, and unsafe symlink states. Use when a Stow command reports conflicts, refuses to stow because target paths already exist, needs ownership checks, has tree folding or refolding surprises, involves risky flags such as --adopt, --defer, --override, --ignore, or --no-folding, uses multiple stow directories, or requires a safe dry-run troubleshooting workflow. For clean happy-path stow/restow workflows, prefer manage-stow-packages or manage-stow-dotfiles.

Manage home-directory dotfiles and hidden configuration files with GNU Stow. Use when the user wants to organize a dotfiles repository, stow configuration into $HOME or ~/.config, use --dotfiles with dot- prefixed paths, migrate or adopt existing dotfiles, write dotfile-focused .stowrc defaults, restow dotfile packages, or troubleshoot hidden-file layouts. Prefer debug-stow-conflicts for failed Stow commands and manage-stow-packages for non-dotfile software package farms.

Manage general GNU Stow symlink farms for software, tools, or data packages outside specialized dotfile migrations. Use when the user wants to create, inspect, stow, unstow/delete, restow, or reorganize Stow packages; choose stow and target directories; configure .stowrc; run safe dry-runs; or reason about package directories, installation images, relative symlinks, target trees, and tree folding. Prefer manage-stow-dotfiles for home dotfiles and debug-stow-conflicts when Stow reports conflicts or unsafe existing paths.

Create a new devcontainer.json from scratch for projects without existing devcontainer configuration. Bootstrap minimal working setups using pre-built images, Dockerfiles, or Docker Compose. Use when initializing devcontainers for new projects, setting up a devcontainer for the first time, or when no .devcontainer/devcontainer.json exists. Also applies when the user says "I need a devcontainer", "setup devcontainers for my project", or describes starting fresh — even without explicit "devcontainer.json" mentions.

Create GitHub Actions workflows for CI/CD automation. Use when setting up automated testing, building, publishing, or any workflow that responds to GitHub events like push, pull requests, or scheduled runs. Special support for devcontainer feature publishing workflows with test discovery and OCI registry publishing. Also applies when the user mentions "create a workflow", "set up GitHub Actions", "automate publishing", or describes CI/CD needs for their repository — even without explicit GitHub Actions knowledge.

Diagnose devcontainer build failures and startup issues by analyzing error logs and identifying root causes. Use when container builds fail, feature installations error, startup crashes occur, or when the user pastes build logs showing errors. Also applies for "permission denied" issues, network timeouts, "failed to create" errors, or any devcontainer troubleshooting scenario — even if described as "my container won't start", "build is failing", or "feature won't install" without explicit log mentions.

Search for devcontainer features in official (containers.dev) and community catalogs. Find and compare features for languages (Node, Python, Go), databases (PostgreSQL, Redis), and development tools. Use when looking for a specific feature ID, exploring available tools, or needing feature installation options. Also applies when the user asks "what features are available for [tool]?", "find me a [tool] feature", or describes wanting to add capabilities to their devcontainer without knowing the exact feature name.

Create and update devcontainer features following containers.dev specification. Use when creating new features, updating existing features with version bumps, adding configurable options, or managing feature dependencies. Automatically detects changes and determines version bump type (patch for content changes, minor for mechanism/dependency changes). Also applies when the user mentions "create a feature", "update my feature", "bump version", "add options to my feature", or describes maintaining devcontainer features for distribution via OCI registries like ghcr.io.

Migrate and update legacy devcontainer configurations to current standards. Handle schema version upgrades, deprecated property conversions (appPort to forwardPorts, extensions to customizations), and legacy feature ID modernizations. Use when updating old devcontainer.json files, converting deprecated formats, or aligning with current spec versions. Also applies for "update my old devcontainer", "migrate deprecated settings", or when working with configurations showing schema warnings.

Modify existing devcontainer configurations — add features (languages, databases, tools), configure port forwarding, set environment variables, update base images, or modify lifecycle scripts. Use when extending a current devcontainer setup with new capabilities or changing existing configuration. Also applies when the user mentions "adding Redis to my devcontainer", "configure ports", "update my devcontainer image", or describes modifications to an existing setup — even if they don't explicitly mention "devcontainer.json".