notwillk

Design software system architecture using requirements, constraints, data models, APIs, integrations, dependencies, and technical tradeoff analysis. Use when deciding how a system or feature will fundamentally work.

Break software milestones, features, epics, requirements, and architecture plans into executable stories, tasks, and subtasks with clear boundaries and acceptance criteria.

Analyze software project dependencies, blockers, prerequisite work, critical paths, ownership constraints, external dependencies, and sequencing risks. Use when preventing execution deadlocks or delivery surprises.

Estimate software project effort, complexity, uncertainty, capacity, cost, and delivery ranges using scoped work, decomposed tasks, dependencies, and implementation risk.

Define measurable outcomes, KPIs, success criteria, acceptance thresholds, and decision criteria for software products, features, projects, or initiatives. Use when establishing what success looks like.

Generate and frame software product or feature ideas using user problems, market signals, constraints, and opportunity analysis. Use when brainstorming, discovering opportunities, or deciding what should exist and why it matters.

Prioritize software project work items using impact, urgency, dependencies, risk, and effort analysis. Use when planning milestones, ordering backlog items, or deciding what to work on next.

Plan software product or feature roadmaps using milestones, sequencing, release phases, dependencies, risks, and learning goals. Use when creating a high-level execution path.

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 a new repo-local OpenCode skill scaffold

This skill should be used when the user asks to "create a proposal", "design a report", "make a one-pager", "build a PDF", "create a newsletter", "design slides", "make event materials", "design a flyer", or needs help with print-ready HTML documents. Provides brand configuration, CSS patterns for print layout, and document design best practices.

Write type-safe TypeScript with proper narrowing, inference patterns, and strict mode best practices.

Use common project commands via just

Understand project structure, directories, and checks configuration

Use swimlane for task tracking with proper workflow

Astro web framework patterns for content-driven sites. Covers content collections with Zod schemas and loaders, island architecture with selective hydration directives, view transitions with ClientRouter, server-side and hybrid rendering modes, server islands, Astro DB with astro:db, middleware with onRequest, and framework integrations (React, Svelte, Vue). Use when building content-driven websites, configuring island hydration strategies, setting up view transitions, choosing between static and server rendering, integrating UI framework components, defining content collection schemas, or adding middleware.

Create a new repo-local OpenCode skill scaffold

Use common project commands via just

Understand project structure, directories, and checks configuration

Create Agent Skills compatible with the Agent Skills specification. Use when the user wants to create a new skill, needs help with skill structure, wants to validate a skill, or needs guidance on SKILL.md format, naming conventions, or directory structure. Also use when the user mentions creating capabilities for AI agents, packaging expertise, or making reusable agent workflows.

Evaluate skill output quality using systematic testing. Use when you need to test whether a skill produces correct results, set up evaluation frameworks, compare skill versions, measure improvement over baseline, or iterate on skill quality based on test results. Also use when the user wants to grade skill outputs, analyze performance metrics, or create reproducible skill evaluation workflows.

Optimize skill descriptions for reliable triggering. Use when a skill is not activating on the right prompts, activates too often on irrelevant tasks, or when you need to improve the description field to make it more effective. Also use when the user wants to test description accuracy, design eval queries, or iterate on skill descriptions systematically.

Declarative checks-as-code system for validating repository state using YAML-defined shell checks, with optional auto-fix support.

Enforces product requirements as defined in /prd directory. Treats PRDs as source of truth and requires explicit confirmation before any PRD modifications.

Repository command reference for the HostVault project. Contains all available just commands for building, testing, linting, and maintaining the codebase. Use this skill when you need to execute build commands, run tests, check code quality, or perform maintenance tasks on the HostVault Turbo monorepo.

Configure, run, and debug checksy workspace health checks. Use when creating or editing .checksy.yaml files, troubleshooting rule failures, setting up git-based remote configs, using --fix auto-repair, integrating into CI/CD, or generating JSON schemas for IDE validation. Covers severity levels (debug/info/warn/error), preconditions, patterns, caching, and common errors — even if the user just says "health checks", "workspace validation", or mentions YAML config issues without naming checksy explicitly. Does NOT handle infrastructure health checks (Kubernetes probes, Docker HEALTHCHECK, application monitoring) — use this skill specifically for checksy CLI configuration and workspace validation.

Manage GNU Stow symlink farms, package trees, dotfile repositories, and stow/unstow/restow workflows. Use when Codex needs to explain or run stow commands, design a stow directory layout, migrate files into a Stow-managed package, troubleshoot Stow conflicts, use .stowrc, handle dotfiles with dot- prefixes, or reason about target directories, package directories, tree folding, and relative symlinks.