agentleFS
LIghtJUNctionLIghtJUNction/MagicNet/.agents/skills/kamfw/SKILL.md

kamfw

Skill226 starsChanged 16 days agoMITView on GitHub

Maintain MagicNet's shell KAM framework under src/MagicNet/lib/kamfw, including helpers, imports, i18n, logging, install filters, dependency checks, and EXIT handlers.

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 7 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Use this skill only inside the MagicNet repository when changing src/MagicNet/lib/kamfw or callers that depend on it.

    line 8
  2. Distinctive:

    Search the framework and its callers before adding a helper:

    line 12
  3. Very specific:

    Prefer an existing helper.

    line 18
  4. Very specific:

    Use the framework's print, info, warn, error, debug, and success wrappers for user-visible output.

    line 22
  5. Very specific:

    Check optional commands with command -v.

    line 24
  6. Distinctive:

    Verify downloaded content with at least SHA-256.

    line 25
  7. Distinctive:

    Do not rewrite system paths, start durable background processes, or silently downgrade behavior without explicit design and user-visible …

    line 27
  8. Distinctive:

    Keep functions small, single-purpose, and documented with rationale rather than narration.

    line 28
  9. Very specific:

    Follow the owning helper when it uses stricter stdin-only checks such as [ -t 0 ].

    line 42
  10. Very specific:

    Use wrappers for level filtering and console output.

    line 53
  11. Distinctive:

    Do not describe handlers as subshell-isolated.

    line 69
  12. Distinctive:

    Test both interactive and non-interactive branches.

    line 88
  13. Distinctive:

    Run the repository's relevant shell/static tests and record exact commands and results.

    line 92

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

MagicNet KAM Framework

Use this skill only inside the MagicNet repository when changing src/MagicNet/lib/kamfw or callers that depend on it.

Inspect Before Editing

Search the framework and its callers before adding a helper:

rg '<symbol-or-behavior>' src/MagicNet/lib/kamfw src/MagicNet

Prefer an existing helper. Put a reusable helper in src/MagicNet/lib/kamfw/<name>.sh (or the established __name__.sh internal form) and load it through import; do not bury shared helpers in customize.sh or hooks.

Framework Contract

  • Use the framework's print, info, warn, error, debug, and success wrappers for user-visible output. Use raw printf only for formatting that wrappers cannot express, and explain why.
  • Register all user-visible text with set_i18n; retrieve it through i18n/t. List new or changed keys in the PR.
  • Check optional commands with command -v. Missing required dependencies must fail fast through abort with an i18n message.
  • Verify downloaded content with at least SHA-256; add signature verification when the trust model requires it. Never commit keys or secrets.
  • Preserve user configuration by default. Interactive replacement needs explicit confirmation; non-interactive input uses the safe path (skip or create an update file).
  • Do not rewrite system paths, start durable background processes, or silently downgrade behavior without explicit design and user-visible reporting.
  • Keep functions small, single-purpose, and documented with rationale rather than narration.

TTY and Non-Interactive Behavior

There is no framework is_ci helper. Use the repository's existing TTY conventions instead of inventing one:

if [ -t 0 ] || [ -t 1 ]; then
    # interactive-capable path
else
    # safe non-interactive default
fi

Follow the owning helper when it uses stricter stdin-only checks such as [ -t 0 ].

Logging

logging.sh owns log behavior:

  • KAM_LOGLEVEL / set_loglevel: ERROR, WARN, INFO, or DEBUG (default INFO)
  • KAM_DEBUG=1: compatibility alias for debug logging
  • KAM_LOGFILE: default $MODDIR/kam.log
  • KAM_LOG_ROTATE_SIZE: accepts K/M/G suffixes

Use wrappers for level filtering and console output. Direct log remains a file-writing compatibility API.

EXIT Handlers

__at_exit__.sh exposes:

  • at_exit_add, at_exit_remove, at_exit_list, at_exit_clear
  • at_exit_register_trap, at_exit_unregister_trap
  • __at_exit_install_from_filters

Current behavior is important:

  • handlers run in registration order in the current shell via eval;
  • one handler failure is logged and does not stop the remaining handlers;
  • registration installs trap "__at_exit_master_handler" EXIT and does not preserve a pre-existing EXIT trap.

Do not describe handlers as subshell-isolated. Inspect compatibility before composing this helper with another EXIT trap.

Install Filters

Apply filters in this order:

  1. install_exclude
  2. install_include (may override an exclusion)
  3. install_check preview
  4. interactive confirmation where applicable
  5. install

Both source-directory (KAM_MODULE_ROOT) and ZIP (ZIPFILE) flows are supported. Check unzip/zipinfo before ZIP operations and abort with an i18n message when absent.

Verification

For every change:

  1. Exercise the changed helper through the same import path used in production.
  2. Test both interactive and non-interactive branches.
  3. Cover dependency-missing and failure paths.
  4. For install filters, test directory and ZIP inputs plus include-overrides-exclude behavior.
  5. For EXIT handlers, verify order, failure continuation, and interaction with existing traps.
  6. Run the repository's relevant shell/static tests and record exact commands and results.

PR Checklist

Include:

  • what changed and why;
  • new/changed i18n keys;
  • compatibility and security risks;
  • interactive and non-interactive verification;
  • dependency, network-integrity, logging, install, or EXIT-handler checks as applicable.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.