l-gevity

@l-gevity source repo

21 skills
0 followers
7 hours ago last updated

▌
Alchemy · l-gevity
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.

0
installs
▌
Standup · l-gevity
Composes a short daily standup from verified repository state only: recent commits, open pull requests, issues, CI runs, deadline risk, architectural debt, and requirements drift. TRIGGER when the user asks for a standup, a daily update, or "what is the status today", or invokes `/standup` (Claude) or `$standup` (Codex). SKIP for release notes, changelogs, sprint reports, retrospectives, incident reports, and any narrative allowed to contain unverified claims. Reads project parameters (deadlines, requirements gate, coverage artifact) from a project profile outside this skill; never invents them and never carries a finding over from an earlier standup without rechecking it.

0
installs
▌
Push Out · l-gevity
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.

0
installs
▌
Bring Down · l-gevity
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.

0
installs
▌
Test Strategy · l-gevity bundle
Designs and audits risk-driven test strategies that map grounded requirements, acceptance criteria, quality risks, architecture, and escaped defects to the smallest sufficient evidence portfolio. Use when deciding what to test, which design technique or test fidelity to use, when to use real dependencies versus fakes, stubs, or mocks, how to manage test data and environments, or whether unit, component, integration, contract, E2E, exploratory, property, fuzz, performance, resilience, or recovery testing is justified. Also use to audit hollow assertions, redundant coverage, flaky tests, and residual risk. Do not use for framework-specific test implementation, pipeline placement or gating, or trace evidence state; hand those to stack skills, defect-shift-left, ci-cd-reliability-architecture, and requirements-traceability.

0
installs
▌
Defect Shift Left · l-gevity
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?"

0
installs
▌
System Optimization · l-gevity
Applies Lean, Kaizen, Six Sigma, Theory of Constraints, queueing/flow science, and DevOps delivery metrics (DORA) 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.

0
installs
▌
Architecture As Code · l-gevity
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` or `morphogenetic-architecture` 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`.

0
installs
▌
Requirements Topology · l-gevity
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.

0
installs
▌
Continuous Improvement · l-gevity
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.

0
installs
▌
Requirements Grounding · l-gevity bundle
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, defining measurable expected outcomes without turning them into acceptance criteria, deciding what belongs in scope, sweeping quality characteristics for unstated non-functional obligations, 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.

0
installs
▌
Architecture Guidelines · l-gevity
First-principles architectural rules for module/service/abstraction design: minimalism, modularity, functional core, resilience, layer self-sufficiency, integration, naming, and concurrency. TRIGGER when introducing a module/service/abstraction, refactoring across module boundaries, applying SOLID, deciding whether a control may rely on the layer beneath it, designing an integration edge between applications or services, 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.

0
installs
▌
Implementation Readiness · l-gevity
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, riskiest-assumption ordering, parallel-ready slices, 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.

0
installs
▌
Requirements Traceability · l-gevity
Maintains bidirectional traceability between canonical requirements and implementation, verification, decision, operational, and outcome 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, whether a linked outcome hypothesis is supported by current measurement, what remains unmapped, or whether references have gone stale. Do not use to invent requirement or hypothesis meaning, normalize the requirement graph, decide implementation readiness, or issue a functionality-worth verdict.

0
installs
▌
Structural Simplification · l-gevity
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 placement and evidence-weighted dependency-topology constraints see `morphogenetic-architecture`.

0
installs
▌
Morphogenetic Architecture · l-gevity bundle
Design and audit evolving, evidence-weighted software topology. Start with a rapid declared-topology scan; escalate to full analysis for restructuring, multi-field evidence, broad scope, ambiguity, or a deep audit. Place components by domain, abstraction tier, and layer; preserve directed interfaces; compare imports, runtime flow, co-change, shared data, and failure propagation; then place, keep, move, split, merge, or introduce a boundary. TRIGGER when placing a module/service/layer, refactoring dependency topology, discovering bounded contexts, diagnosing cycles, god-components, cross-domain tangles, or hidden runtime coupling, or comparing observed behavior with declared architecture, or revisiting a closed prediction window. SKIP for routine in-boundary logic, isolated bug fixes, content/CSS edits, dependency bumps, and trivial renames. Use `architecture-guidelines` for component internals, `structural-simplification` for complexity deltas, and `architecture-as-code` for enforceable dependency rules.

0
installs
▌
Architecture As Code Python · l-gevity
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.

0
installs
▌
Evolutionary Database Design · l-gevity
Designs and audits compatible, staged, reversible changes to persisted or serialized data shape: database schemas, event and message schemas, API payloads, and file formats. Use when a change adds, renames, moves, narrows, reinterprets, or removes a stored or serialized element, changes a key or identity, transfers write ownership, or needs a backfill; when deciding whether old and new code versions can coexist against one schema during rollout and rollback; when planning an expand/contract transition, its reversal steps, and the evidence that permits the contract step; or when auditing never-contracted expansions, semantic drift, unowned data, and migrations without a reversal path. Do not use for component placement, requirement meaning, test technique, pipeline stage placement, gating, or evidence state; hand those to morphogenetic-architecture, requirements-grounding, test-strategy, defect-shift-left, ci-cd-reliability-architecture, and requirements-traceability.

0
installs
▌
CI CD Reliability Architecture · l-gevity bundle
Establishes idempotency, self-containment, immutable artifacts, self-healing, zero-downtime, and zero-knowledge security for CI/CD pipelines, including delivery-strategy choice, evidence-gated release, and production promotion. Use this skill when designing, auditing, or debugging any workflow, release, or deployment pipeline.

0
installs
▌
Architecture As Code Javascript · l-gevity
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.

0
installs
▌
Functionality Complexity Tradeoff · l-gevity bundle
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, requirement-pinned mechanism, or unused generality, and evidence-driven revisits of outcome hypotheses after release.

0
installs

21 published skills