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.
In this repository6 other files it gives its agents.
- AGENTS.mdAGENTS.md
- android-cliSkill
- magicnet-device-debuggingSkill
- perfetto-sqlSkill
- perfetto-trace-analysisSkill
- recipe-maintenanceSkill
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
- Very specific: line 8
Use this skill only inside the MagicNet repository when changing src/MagicNet/lib/kamfw or callers that depend on it.
- Distinctive: line 12
Search the framework and its callers before adding a helper:
- Very specific: line 18
Prefer an existing helper.
- Very specific: line 22
Use the framework's print, info, warn, error, debug, and success wrappers for user-visible output.
- Very specific: line 24
Check optional commands with command -v.
- Distinctive: line 25
Verify downloaded content with at least SHA-256.
- Distinctive: line 27
Do not rewrite system paths, start durable background processes, or silently downgrade behavior without explicit design and user-visible …
- Distinctive: line 28
Keep functions small, single-purpose, and documented with rationale rather than narration.
- Very specific: line 42
Follow the owning helper when it uses stricter stdin-only checks such as [ -t 0 ].
- Very specific: line 53
Use wrappers for level filtering and console output.
- Distinctive: line 69
Do not describe handlers as subshell-isolated.
- Distinctive: line 88
Test both interactive and non-interactive branches.
- Distinctive: line 92
Run the repository's relevant shell/static tests and record exact commands and results.
≈ “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.
Files
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/MagicNetPrefer 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, andsuccesswrappers for user-visible output. Use rawprintfonly for formatting that wrappers cannot express, and explain why. - Register all user-visible text with
set_i18n; retrieve it throughi18n/t. List new or changed keys in the PR. - Check optional commands with
command -v. Missing required dependencies must fail fast throughabortwith 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
fiFollow 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, orDEBUG(defaultINFO)KAM_DEBUG=1: compatibility alias for debug loggingKAM_LOGFILE: default$MODDIR/kam.logKAM_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_clearat_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" EXITand 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:
install_excludeinstall_include(may override an exclusion)install_checkpreview- interactive confirmation where applicable
- 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:
- Exercise the changed helper through the same import path used in production.
- Test both interactive and non-interactive branches.
- Cover dependency-missing and failure paths.
- For install filters, test directory and ZIP inputs plus include-overrides-exclude behavior.
- For EXIT handlers, verify order, failure continuation, and interaction with existing traps.
- 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.
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
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.

