l-gevity-skills

Runs a lightweight change preflight, then routes non-trivial design, refactor, and audit work through only the needed requirements and A.L.C.H.E.M.Y. skills. Explicitly trigger with `/alchemy`, `$alchemy`, or natural phrases such as "do some alchemy", "run alchemy on this", "use alchemy", or "give this an alchemy pass". Use for architecture, complexity, enforcement, shift-left, optimization, modules, vertical slices, abstractions, cross-boundary refactors, consolidation, and over-engineering audits. Explicit invocation on a local bug fix, content or CSS edit, dependency bump, or trivial rename returns a cheap `SKIP` or `DIRECT` dispatch instead of loading every gate. Defines no new domain rules; routes to core sibling skills and task-matched companion skills.

Protocol for updating skills based on user feedback and root-cause analysis to prevent recurring mistakes. Use this skill when deciding HOW and WHEN to evaluate or update other agent skills.

Determines whether graph-structured requirements are ready for architecture, development, and verification, then derives the smallest coherent build-preparation package without inventing requirement meaning. Use when producing capability maps, epics or workstreams, implementation slices, dependency sequencing, contract candidates, domain-model seeds, cross-cutting constraints, acceptance-test references, ADR seeds, technical questions, or explicit ready/partly-ready/not-ready decisions. Do not use for initial discovery or requirement graph normalization.

Grounds proposed requirements in a real actor-bound problem, explicit scope, authoritative sources, evidence, assumptions, priority, and validation confidence. Use when defining or sharpening a problem, extracting obligations or stakeholder needs, separating facts from interpretations and hypotheses, writing solution-free requirement candidates, deciding what belongs in scope, reverse-engineering provisional requirements from existing code, tests, schemas, configuration, public interfaces, documentation, or history, or determining whether requirements are ready for dependency modeling. Do not use for graph construction or implementation planning except to prepare their inputs.

Structures validated requirements into an atomic, traceable, typed dependency graph and derives a trustworthy dependency order. Use when normalizing requirement wording, preserving stable IDs, splitting or merging requirements, modeling dependencies and constraints, detecting duplicates, conflicts, cycles, orphans, stale references, or missing verification, refining requirement-scope boundaries, or producing a graph package. Do not use for initial problem discovery or implementation planning.

Maintains bidirectional traceability between canonical requirements and implementation, verification, decision, and operational evidence. Use when planning, implementing, reviewing, or closing work that must prove which requirement authorized a change, where it is implemented, which executed evidence verifies it, what remains unmapped, or whether references have gone stale. Do not use to invent requirement meaning, normalize the requirement graph, or decide implementation readiness.

Establishes idempotency, self-containment, immutable artifacts, self-healing, zero-downtime, and zero-knowledge security for CI/CD pipelines, including evidence-gated release and production promotion. Use this skill when designing, auditing, or debugging any workflow, release, or deployment pipeline.

Stack-agnostic pattern for declaring and enforcing component boundaries via per-module architecture configs merged into import-graph linter rules. TRIGGER when designing/auditing dependency-rule enforcement, deciding what a per-module file should say, placing a rule, debugging a forbidden edge, or extending the assembler. Consume explicit `Enforcement` handoffs from `architecture-guidelines` by turning enforceable dependency constraints into architecture config rules. SKIP routine edits inside a governed module. For stack implementations see `architecture-as-code-javascript` or `architecture-as-code-python`.

First-principles architectural rules for module/service/abstraction design: minimalism, modularity, functional core, resilience, naming, and concurrency. TRIGGER when introducing a module/service/abstraction, refactoring across module boundaries, applying SOLID, or reviewing architectural concerns (purity, idempotency, naming, fail-fast). SKIP for bug fixes within an existing module, content/copy edits, CSS-only changes, dependency bumps, and trivial renames. Emits an `Enforcement` handoff to `architecture-as-code` when a design decision yields an enforceable dependency constraint.

Moves recurring DevOps and operational work out of individual memory, manual execution, ticket queues, and team-local practice into documented procedures, repo standards, shared platforms, self-service controls, and adaptive feedback loops. Use when reducing toil, designing an improvement roadmap, deciding what to standardize or automate, assessing where operational work currently lives, pruning prose documentation duplicated by code/config/tests/policy-as-code/architecture-as-code, or asking how to move work from humans into durable systems.

JavaScript / TypeScript implementation of the `architecture-as-code` pattern. Per-module `eslint.architecture.mjs` files merged into a single ESLint flat-config and enforced via `eslint-plugin-boundaries`. TRIGGER when: implementing or extending architecture-as-code in a JS/TS repo, debugging an `eslint-plugin-boundaries` rule, or adapting the assembler. SKIP for routine edits inside a governed module. Reads in conjunction with `architecture-as-code` (the pattern, source of truth for schema, rule placement, anti-patterns, and audit checklist) — this skill defines only the JS-specific encoding, assembler code, and gotchas.

Python implementation of the `architecture-as-code` pattern. Per-package `architecture.toml` files merged into a single `import-linter` config and enforced via `lint-imports` (over a Grimp-built import graph). TRIGGER when: implementing or extending architecture-as-code in a Python repo, debugging an `import-linter` contract, or adapting the assembler. SKIP for routine edits inside a governed package. Reads in conjunction with `architecture-as-code` (the pattern, source of truth for schema, rule placement, anti-patterns, and audit checklist) — this skill defines only the Python-specific encoding, assembler code, and gotchas.

Moves bespoke, duplicated, or over-local code down into reusable capabilities outside the immediate implementation: framework-native features, stack-aware approved libraries, internal platform products, managed services, or external standards. Use when assessing whether custom code should be replaced by a lower-level capability, especially an external library or service; when reducing bespoke wrappers around commodity behavior; or when designing an improvement roadmap for reuse and platform leverage. Skip purely in-codebase componentization or patternization unless the target is an approved external library, framework capability, platform product, or managed service.

Places every error detection at the earliest stage of the pipeline that is technically capable of catching it. Use when designing or auditing a CI/CD pipeline, choosing tooling, deciding where a check belongs, or asking "could this have been caught earlier?"

Decides whether functionality solves a real problem and is worth its complexity cost. Use in prospective mode to build, defer, or drop proposed capabilities, and in retrospective mode to keep, simplify, deprecate, delete, or mark existing code obsolete. Trigger for feature triage, backlog grooming, PR scope review, dead-code audits, tech-debt reviews, "is this worth it?", "should we remove this?", "is this defensive check necessary?", and cases involving impossible-state guards, redundant validation, cargo-culted patterns, phantom requirements, or unused generality.

A 3-D spatial coordinate system for the dependency graph. Every component is given an address (X = domain, Y = abstraction tier, Z = layer), dependency coupling is routed through declared adjacent positions, and connection direction is encoded by which face links to which. Long-range and forbidden cyclic connections become structurally expensive instead of merely discouraged. Includes ESLint enforcement via `eslint-plugin-boundaries` and `no-restricted-imports`. TRIGGER when: deciding where a new module/service/layer lives, designing or refactoring the dependency graph, diagnosing layer/cycle/god-object/cross-domain tangles, or configuring dependency- guard lint rules. SKIP for: routine business logic inside an existing module, bug fixes, content/copy edits, CSS-only changes, dependency bumps, trivial renames. For first-principles rules on what goes inside a module see `architecture-guidelines`; for evaluating whether a structural change actually reduces complexity see `structural-simplification`.

A domain-agnostic complexity model and decision protocol. Complexity is treated as a 4-axis vector — D (diversity), K (coupling), P (depth), n (quantity) — and any proposed restructuring is judged by its per-axis effect rather than by intuition. Applies to code, project organization, runtime topology, data models, workflows, UI layouts, organizational structures, and temporal processes. TRIGGER when: evaluating a refactoring, designing a restructuring, or deciding whether a proposed change makes a system simpler or more complex. SKIP for: trivial renames, content edits, dependency bumps, isolated bug fixes that touch no structure. For module-level design discipline see `architecture-guidelines`; for spatial dependency-graph constraints see `geometric-architecture`.

Applies Lean, Kaizen, Six Sigma, Theory of Constraints, and DevOps principles to eliminate waste and improve flow across all aspects of a software project. Use when scanning for optimizations in CI/CD pipelines, developer workflows, code structure, testing strategy, documentation, or the overall value stream. Activate when a review is requested to identify waste, bottlenecks, and improvement opportunities across the project.