voklab

change-strategy

Change-mode discipline for existing code — classify every change as Patch, Extend, Refactor, Rewrite, or Replacement before the first edit, and never mix modes in one diff. Use when modifying existing code with no mode declared, when a request says rewrite, refactor, modernize, migrate, replace, or port, and when a fix starts drifting into restructuring.

codebase-navigation

Use when entering an unfamiliar repo, locating relevant code, tracing behavior, debugging, or working in a large or chaotic codebase. Builds task-scoped understanding without reading the whole repository.

layline-doctrine

The always-on engineering baseline for every task touching code or config: priorities, scope, footprint, evidence, dependencies, failure handling, security, review, reporting. Use for all software work, and invoke the matching Layline capability skill whenever a task fits one — scope-minimalism (how much to build), testing-strategy (what to test), codebase-navigation (unfamiliar code, debugging), change-strategy (modifying existing code), ops-automation (shell, playbooks, scheduled jobs, monitoring checks) — at every matching task, not only the first.

ops-automation

Production scripting and ops automation — shell scripts, config-management playbooks and roles, scheduled jobs, monitoring checks. Use when writing or reviewing automation that runs unattended, repeatedly, or against a fleet, when a change touches high-impact system surfaces, and when planning patching or provisioning runs.

scope-minimalism

Build restraint — how much gets built, and no more. Use before implementing a task or plan step, when deciding whether to add an abstraction, layer, wrapper, helper, or dependency, when a diff outgrows its task, and when asked to simplify or cut over-engineering.

Testing & QA Listed

testing-strategy

Test design for changed behavior — what to check and at which level. Use when deciding what tests to write, change, or skip; when fixing any bug; when choosing between unit, integration, and end-to-end coverage; when introducing mocks or fakes; and when a test is flaky.