auto: 2026-06-22_18:00 changes

1 files changed, 9 insertions, 0 deletions

diff --git a/skills/module-audit-and-test.json b/skills/module-audit-and-test.json
new file mode 100644
index 0000000..5dfddcc
--- /dev/null
+++ b/skills/module-audit-and-test.json
@@ -0,0 +1,9 @@
+{
+  "name": "module-audit-and-test",
+  "description": "",
+  "tags": [],
+  "category": "dev",
+  "created": "2026-06-18T00:41:25.711Z",
+  "updated": "2026-06-18T00:41:25.711Z",
+  "content": "---\nname: module-audit-and-test\ndescription: Procedural guide for auditing module source code and performing rigorous testing to ensure stability, security, and performance.\ntags: [modules, audit, testing, quality-assurance, dev]\n---\n\n# Module Audit & Testing Workflow\n\nThis skill provides a standardized approach to auditing existing modules and testing new or modified code within the WebX11 ecosystem.\n\n## 1. Audit Phase (Static Analysis)\nBefore running code, perform a static review of the module source.\n\n### Steps to Audit:\n1. **Retrieve Source**: Use `view_module(name=\"ModuleName\")` to examine the code.\n2. **Security Check**: \n   - Look for unsafe command executions or uncontrolled input handling.\n   - Ensure destructive operations (e.g., `write_file`, `delete_file`) have appropriate guards or confirmations.\n3. **Logic Review**:\n   - Check for edge cases in parameters.\n   - Verify that the module handles errors gracefully (try-catch blocks).\n   - Ensure the module adheres to the expected return formats (JSON, strings, etc.).\n4. **Dependency Check**: Verify that all required helper functions or external APIs are correctly called and exist.\n\n## 2. Testing Phase (Dynamic Analysis)\nOnce the audit is complete, validate the module's behavior in a sandbox environment.\n\n### Testing Strategy:\n- **Happy Path**: Test the most common use case with valid inputs.\n- **Boundary Testing**: Test with empty strings, extremely large inputs, or null values.\n- **Error Path**: Intentionally provide invalid inputs to see if the module returns a helpful error instead of crashing.\n- **Integration Testing**: If the module interacts with other system components (VFS, Web, etc.), verify the end-to-end flow.\n\n### Execution Loop:\n1. **Edit/Modify**: Use `edit_module(name=\"ModuleName\")` to apply fixes.\n2. **Isolated Test**: Use `test_module(name=\"ModuleName\")`. This runs the module in a temporary context without affecting the global state.\n3. **Live Reload**: If tests pass, use `reload_module(name=\"ModuleName\")` to push the changes to the active system.\n\n## 3. Validation Checklist\n- [ ] Does the module perform its intended function?\n- [ ] Does it handle errors without crashing the terminal?\n- [ ] Are there any obvious security vulnerabilities?\n- [ ] Is the code clean and maintainable?\n- [ ] Does it perform efficiently without causing system lag?\n\n## Summary of Commands\n| Action | Command |\n| :--- | :--- |\n| View Source | `view_module(name=\"...\")` |\n| Modify Code | `edit_module(name=\"...\")` |\n| Test Sandbox | `test_module(name=\"...\")` |\n| Deploy | `reload_module(name=\"...\")` |\n| Check Status | `get_module_status()` |\n"
+}
\ No newline at end of file