wrapper-module

Audit or create wrapper modules aligning module.nix and default.nix with BirdeeHub idioms.

Updated Jan 25, 2024
One-click install
npx skills add https://github.com/axelcool1234/.dotfiles --skill wrapper-module
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: wrapper-module
Source: https://github.com/axelcool1234/.dotfiles/tree/main/wrappers/code/skills/wrapper-module
Command: npx skills add https://github.com/axelcool1234/.dotfiles --skill wrapper-module

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill removes ambiguity and structural drift in wrapper modules by guiding creation, refactoring, and audits so that generic module.nix files remain reusable and local defaults stay repository-specific.

Core Features & Use Cases

  • Audit Guidance: Step-by-step checklist to compare local wrapper options, naming, and implementation shape against BirdeeHub upstream idioms.
  • Creation Workflow: Clear instructions for splitting a wrapper into a generic module.nix and a repo-specific default.nix using constructFiles, flags, env, passthru, and runShell only when justified.
  • Decision Framework: Criteria for when to keep logic in module.nix versus default.nix, how to name options, and how to model writable runtime state safely.
  • Use Case: Split an existing wrappers/foo.nix into wrappers/foo/module.nix and wrappers/foo/default.nix and update options to match upstream patterns while preserving necessary repo policies.

Quick Start

Audit the wrapper in wrappers/<name> and produce a concise plan to create or adjust module.nix and default.nix so they follow BirdeeHub wrapper-module conventions.

Frequently Asked Questions about wrapper-module

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I split a Nix wrapper module into reusable and repo-specific files?

To split a Nix wrapper module, separate generic logic into a reusable module.nix and repository-specific defaults into default.nix, using constructFiles, flags, and passthru to align with BirdeeHub wrapper conventions.

What is the best way to audit Nix wrapper modules against upstream patterns?

Auditing Nix wrapper modules involves comparing local options and implementation shape against upstream BirdeeHub helper-module patterns by inspecting module.nix, default.nix, and check.nix to validate naming and runtime bootstrap concerns.

When should I use runShell in a Nix wrapper module?

Use runShell in a Nix wrapper module only when justified by runtime bootstrap concerns, ensuring that writable runtime state is modeled safely and does not unnecessarily complicate the generic module.nix structure.

How do I decide which logic goes in module.nix versus default.nix for a wrapper?

Keep generic and reusable wrapper logic in module.nix while placing repository-specific policies and local defaults in default.nix, ensuring options and constructFiles usage remain aligned with upstream BirdeeHub idioms.

Can I refactor an existing wrappers/foo.nix file into a structured wrapper directory?

Yes, you can refactor wrappers/foo.nix into wrappers/foo/module.nix and wrappers/foo/default.nix, updating options and constructFiles usage to match upstream patterns while preserving necessary repository policies.

What are common limitations when aligning local default.nix with BirdeeHub idioms?

Limitations arise when local repository policies conflict with upstream BirdeeHub idioms, requiring careful inspection of module.nix and default.nix to ensure exposed passthru attributes and env variables remain structurally valid.