2,465 ಸಾರ್ವಜನಿಕವಾಗಿ ಪಟ್ಟಿ ಮಾಡಲಾದ AI-agent "skills" ಗಳ ಹೊಸ ಆಡಿಟ್ ನಡೆಸಿದಾಗ, ಅರ್ಧಕ್ಕಿಂತ ಹೆಚ್ಚು ಕೌಶಲಗಳು ಪ್ರಕಟಿಸಲಾದ ನಿಯಮಗಳನ್ನು (specifications) ಉಲ್ಲಂಘಿಸಿವೆ ಮತ್ತು 7.8 ಪ್ರತಿಶತವನ್ನು ಏಜೆಂಟ್ಗಳು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲ ಏಕೆಂದರೆ ಅವುಗಳಿಗೆ ಅಗತ್ಯವಾದ ಮೆಟಾಡಾಟಾ (metadata) ಇಲ್ಲ ಎಂಬುದು ತಿಳಿದುಬಂದಿದೆ. ಈ ದೋಷಗಳು ಈ ಕೌಶಲಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪತ್ತೆಹಚ್ಚುವ ಮತ್ತು ಲೋಡ್ ಮಾಡುವ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯ ವಿಶ್ವಾಸಾರ್ಹತೆಗೆ ಧಕ್ಕೆ ತರುತ್ತವೆ.
ಈ ಆಡಿಟ್ ಏಕೆ ಮುಖ್ಯ
ಏಜೆಂಟ್-ಸ್ಕಿಲ್ ರಿಜಿಸ್ಟ್ರಿಗಳು (Agent-skill registries) ಡೆವಲಪರ್ಗಳು ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಸಾಮರ್ಥ್ಯಗಳನ್ನು—ಅಂದರೆ ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್ (autonomous agent) ಅಗತ್ಯವಿದ್ದಾಗ ಬಳಸಬಹುದಾದ ಕೋಡ್ ಪ್ಯಾಕೇಜ್ಗಳನ್ನು ಪ್ರಕಟಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತವೆ. ಏಜೆಂಟ್ ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತದೆ, ಪ್ರತಿ ಕೌಶಲದ YAML frontmatter ಅನ್ನು ಓದುತ್ತದೆ (ಇದು ಕನಿಷ್ಠ ಹೆಸರು ಮತ್ತು ವಿವರಣೆಯನ್ನು ಹೊಂದಿರಲೇಬೇಕಾದ ಒಂದು ಸಣ್ಣ ರಚನಾತ್ಮಕ ಪಠ್ಯದ ಬ್ಲಾಕ್ ಆಗಿದೆ), ಮತ್ತು ಆ ಕೌಶಲವು ತನ್ನ ಗುರಿಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಒಂದು ವೇಳೆ frontmatter ಇಲ್ಲದಿದ್ದರೆ ಅಥವಾ ತಪ್ಪಾಗಿದ್ದರೆ, ಆ ಕೌಶಲವು ಏಜೆಂಟ್ನ ಮೆನುವಿನಿಂದ ಮಾಯವಾಗುತ್ತದೆ. ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್ಗಳು ಸಭೆಗಳನ್ನು ನಿಗದಿಪಡಿಸುವ, ಸರ್ವರ್ಗಳ ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಮತ್ತು ಹೆಚ್ಚಿನವುಗಳನ್ನು ಮಾಡುವ ಜಗತ್ತಿನಲ್ಲಿ, ಒಂದು ಮುರಿದ ಕೌಶಲವು ಇಡೀ ಕೆಲಸದ ಹರಿವನ್ನು (workflow) ಹಾಳುಮಾಡುತ್ತದೆ.
ಅಂಕಿಅಂಶಗಳು ಏನನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತವೆ
- 57.8% ಕೌಶಲಗಳು ಕನಿಷ್ಠ ಒಂದು ಸ್ಪೆಕ್ (spec) ಉಲ್ಲಂಘನೆಯನ್ನು ಹೊಂದಿವೆ.
- 29.2% ರಿಜಿಸ್ಟ್ರಿ slug (URL ಐಡೆಂಟಿಫೈಯರ್) ಗೆ ಹೊಂದಿಕೆಯಾಗದ ಹೆಸರನ್ನು ಹೊಂದಿವೆ.
- 18.1% ಮುರಿದ ಪ್ಯಾಕೇಜ್ ಪಥಗಳು (package paths) ಅಥವಾ ಕೆಲಸ ಮಾಡದ ಲಿಂಕ್ಗಳನ್ನು ಹೊಂದಿವೆ.
- 7.8% (192 ಕೌಶಲಗಳು) ಯಾವುದೇ YAML frontmatter ಹೊಂದಿಲ್ಲ, ಇದರಿಂದ ಅವುಗಳಿಗೆ ಹೆಸರಿಲ್ಲ ಅಥವಾ ವಿವರಣೆಯಿಲ್ಲದಂತಾಗಿದೆ.
- 3.8% ಕೇವಲ ಲೇಖಕರ ಕಂಪ್ಯೂಟರ್ನಲ್ಲಿ ಮಾತ್ರ ಇರುವ ಅಬ್ಸಲ್ಯೂಟ್ ಫೈಲ್ ಪಥಗಳನ್ನು (absolute file paths) ಬಳಸುತ್ತವೆ.
- 2.4%
allowed-toolsಫೀಲ್ಡ್ ಅನ್ನು ತಪ್ಪಾಗಿ ಬಳಸುತ್ತವೆ, ಇದರಿಂದ ಏಜೆಂಟ್ಗಳಿಗೆ ಅವುಗಳನ್ನು ಓದಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. - 2.1% ಎನ್ವಿರಾನ್ಮೆಂಟ್ ವೇರಿಯೇಬಲ್ಗಳ (environment variables) ಮೂಲಕ API ಕೀಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತವೆ, ಇದು ಭದ್ರತೆಯ ದೃಷ್ಟಿಯಿಂದ ಅಪಾಯಕಾರಿ.
- 1.3% ಬಾಹ್ಯ ಕಮಾಂಡ್-ಲೈನ್ ಟೂಲ್ಗಳನ್ನು ಘೋಷಿಸದೆ ಬಳಸುತ್ತವೆ, ಇದು ಪೋರ್ಟಬಿಲಿಟಿ (portability) ನಿಯಮವನ್ನು ಉಲ್ಲಂಘಿಸುತ್ತದೆ.
ಪೋರ್ಟಬಿಲಿಟಿ (Portability) ಸಮಸ್ಯೆಗಳು ಅತಿ ಹೆಚ್ಚು ಕಂಡುಬರುತ್ತವೆ. /home/USER/.local/bin/tool ನಂತಹ ಅಬ್ಸಲ್ಯೂಟ್ ಪಥವು ಆ ಕೌಶಲವನ್ನು ಬರೆದ ಡೆವಲಪರ್ಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಇತರ ಯಾವುದೇ ಬಳಕೆದಾರರಿಗೆ ಅದು ವಿಫಲವಾಗುತ್ತದೆ, ಇದು ಸ್ಟ್ಯಾಟಿಕ್ ಚೆಕ್ಗಳು (static checks) ಪತ್ತೆಹಚ್ಚಲಾಗದ ರನ್ಟೈಮ್ ದೋಷಗಳಿಗೆ (runtime errors) ಕಾರಣವಾಗುತ್ತದೆ.
ಆಳವಾದ ವಿಶ್ಲೇಷಣೆ: openclaw ಪ್ರಕರಣ
ಈ ಆಡಿಟ್ openclaw ರೆಪೊಸಿಟರಿಯಲ್ಲಿ (repository) ಒಟ್ಟಿಗೆ ಇರುವ 46 ಕೌಶಲಗಳನ್ನು ಸಹ ಪರಿಶೀಲಿಸಿತು. ತಪ್ಪು ಎಚ್ಚರಿಕೆಗಳನ್ನು (false alarms) ತಡೆಯಲು ಟೆಸ್ಟಿಂಗ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸುಧಾರಿಸಿದ ನಂತರ, ವಿಮರ್ಶಕರು 59 ನೈಜ ದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಿದರು—ಅತಿಯಾದ ಲಿಂಟರ್ಗಳು (linters) ಹಿಂತಿರುಗಿ ತೊಂದರೆ ನೀಡಬಹುದು ಎಂಬುದಕ್ಕೆ ಇದು ಒಂದು ನೆನಪೋಲೆ. ಒಂದು ಟೂಲ್ ಅತಿಯಾದ ಹಾನಿಕಾರಕವಲ್ಲದ ಸಮಸ್ಯೆಗಳನ್ನು ತೋರಿಸಿದಾಗ, ಡೆವಲಪರ್ಗಳು ಅದನ್ನು ಬಳಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತಾರೆ ಮತ್ತು ನಿಜವಾದ ಸಮಸ್ಯೆಗಳು ಪತ್ತೆಯಾಗದೆ ಉಳಿಯುತ್ತವೆ.
openclaw ದೋಷಗಳಲ್ಲಿ ಎರಡು ದೋಷಗಳು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಇನ್ನು ಮುಂದೆ ಇಲ್ಲದ ಫೈಲ್ಗಳನ್ನು ಸೂಚಿಸುತ್ತಿದ್ದವು. ಮೆಂಟೈನರ್ (maintainer) ಆ缺失 (missing) ರೆಫರೆನ್ಸ್ಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸುವ ಮೂಲಕ ಪರಿಹಾರವನ್ನು ವಿಲೀನಗೊಳಿಸಿದರು, ಇದು ಒಂದು ಸಿಂಗಲ್ ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ (pull request) ಹೇಗೆ ಮುರಿದ ಡಿಪೆಂಡೆನ್ಸಿ ಚೈನ್ ಅನ್ನು ಸರಿಪಡಿಸಬಹುದು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.
ಡೆವಲಪರ್ಗಳ ಪ್ರತಿಕ್ರಿಯೆಗಳು
ಆಡಿಟರ್ ಮೂಲ ಕೌಶಲಗಳ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ ಇಶ್ಯೂಗಳನ್ನು (issues) ತೆರೆದರು. ಒಂದು ವರದಿಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಯಿತು; "ಮುರಿದಿದೆ" (broken) ಎಂಬುದನ್ನು ಸ್ಟ್ಯಾಟಿಕ್ ಫೈಲ್ ಇನ್ಸ್ಪೆಕ್ಷನ್ ಮೂಲಕವಲ್ಲದೆ, ವಾಸ್ತವಿಕ ರನ್ಟೈಮ್ ವರ್ತನೆಯ ಮೂಲಕ ನಿರ್ಧರಿಸಬೇಕು ಎಂದು ಮೆಂಟೈನರ್ ವಾದಿಸಿದರು. ಮುರಿದಿರುವಿಕೆಯ ಕಟ್ಟುನಿಟ್ಟಾದ ವ್ಯಾಖ್ಯಾನವು ಕೌಶಲವು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಅನುಗುಣವಾಗಿರಬೇಕು ಎಂದು ಆಡಿಟರ್ ಒಪ್ಪಿಕೊಂಡರು. ಮತ್ತೊಂದು ಇಶ್ಯೂ ಅನ್ನು ಸ್ವೀಕರಿಸಲಾಯಿತು ಮತ್ತು ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಪರಿಹಾರವು ಈಗ ಲೈವ್ ಆಗಿದೆ.
ಯಾರು ಲಾಭ ಪಡೆಯುತ್ತಾರೆ—ಅಥವಾ ನಷ್ಟ ಅನುಭವಿಸುತ್ತಾರೆ
- ಏಜೆಂಟ್ಗಳು ಮತ್ತು ಅಂತಿಮ ಬಳಕೆದಾರರು: ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿ ಕೇವಲ ನಿಯಮಬದ್ಧ ಮತ್ತು ಪೋರ್ಟಬಲ್ ಕೌಶಲಗಳು ಇದ್ದಾಗ ಅವರು ಸುಗಮ ಮತ್ತು ಹೆಚ್ಚು ನಿರೀಕ್ಷಿತ ವರ್ತನೆಯನ್ನು ಅನುಭವಿಸುತ್ತಾರೆ.
- ಕೌಶಲ ಲೇಖಕರು (Skill authors): ಪ್ರಕಟಣೆಯ ಮೊದಲು ತಪ್ಪುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಸ್ಪಷ್ಟ ವ್ಯಾಲಿಡೇಶನ್ ನಿಯಮಗಳನ್ನು ಪಡೆಯುತ್ತಾರೆ, ಇದರಿಂದ ಇಶ್ಯೂ ಟ್ರೈಯೇಜ್ (issue triage) ಪ್ರಕ್ರಿಯೆಯ ಅಲೆದಾಟ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
- ರಿಜಿಸ್ಟ್ರಿ ಆಪರೇಟರ್ಗಳು: ಕಟ್ಟುನಿಟ್ಟಾದ ವ್ಯಾಲಿಡೇಶನ್ ಪೈಪ್ಲೈನ್ಗಳನ್ನು ನಿರ್ಮಿಸಬೇಕು ಅಥವಾ ಸಂಯೋಜಿಸಬೇಕು; ಅವುಗಳಿಲ್ಲದಿದ್ದರೆ, ಇಕೋಸಿಸ್ಟಮ್ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಅಪಾಯವಿದೆ.
ಸಡಿಲವಾದ ವ್ಯಾಲಿಡೇಶನ್ "ಕ್ವಿಕ್-ಅಂಡ್-ಡರ್ಟಿ" (quick-and-dirty) ಸಬ್ಮಿಷನ್ಗಳನ್ನು ಪ್ರೋತ್ಸಾಹಿಸುತ್ತದೆ, ಇದು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಏಜೆಂಟ್ಗಳನ್ನು ಹಾಳುಮಾಡಬಹುದು ಮತ್ತು ದುಬಾರಿ ಡೌನ್ಟೈಮ್ ಅಥವಾ ಭದ್ರತಾ ಅಪಾಯಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.
ವಿರೋಧಾತ್ಮಕ ಅಂಶ: ಎಲ್ಲಾ ಉಲ್ಲಂಘನೆಗಳು ಮಾರಣಾಂತಿಕವೇ?
ಕೆಲವರು ಕೆಲವು "ದೋಷಗಳು" ಹಾನಿಕಾರಕವಲ್ಲ ಎಂದು ವಾದಿಸುತ್ತಾರೆ. ಡಿಸ್ಪ್ಲೇ ಆಗುವ ಹೆಸರಿಗಿಂತ ಸ್ಲಗ್ (slug) ಮೂಲಕ ಕೌಶಲಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಏಜೆಂಟ್ಗೆ ಹೊಂದಿಕೆಯಾಗದ ಹೆಸರು ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರದಿರಬಹುದು. ಲೋಕಲ್ ಡೆವಲಪ್ಮೆಂಟ್ (local development) ಗಾಗಿ ಎನ್ವಿರಾನ್ಮೆಂಟ್ನಿಂದ API ಕೀಗಳನ್ನು ಓದುವುದು ಉದ್ದೇಶಪೂರ್ವಕ ವಿನ್ಯಾಸದ ಆಯ್ಕೆಯಾಗಿರಬಹುದು. ಆದಾಗ್ಯೂ, ಆಡಿಟ್ನ ಪ್ರತಿಶತಗಳು ಸ್ಪೆಕ್ನಿಂದ ಯಾವುದೇ ವ್ಯತ್ಯಾಸವನ್ನು ಉಲ್ಲಂಘನೆಯೆಂದು ಪರಿಗಣಿಸುತ್ತವೆ, ಇದು ಕೆಲವು ಸಮಸ್ಯೆಗಳ ಪ್ರಾಯೋಗಿಕ ಪರಿಣಾಮವನ್ನು ಅತಿಯಾಗಿ ತೋರಿಸಬಹುದು.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
- ಸುಧಾರಿತ ಲಿಂಟರ್ಗಳು (Enhanced linters): ಇವು ನಿಜವಾದ ಪೋರ್ಟಬಿಲಿಟಿ ಬಗ್ಗಳನ್ನು ಮತ್ತು ಸಣ್ಣಪುಟ್ಟ ವಿಚಿತ್ರತೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತವೆ.
- ರಿಜಿಸ್ಟ್ರಿ-ಸೈಡ್ ವ್ಯಾಲಿಡೇಶನ್ ಹುಕ್ಸ್ (Registry-side validation hooks): ಇವು ಅಗತ್ಯವಾದ frontmatter ಇಲ್ಲದ ಅಥವಾ ಅಬ್ಸಲ್ಯೂಟ್ ಪಥಗಳನ್ನು ಹೊಂದಿರುವ ಸಬ್ಮಿಷನ್ಗಳನ್ನು ತಿರಸ್ಕರಿಸುತ್ತವೆ.
- ಸಮುದಾಯ ಚಾಲಿತ ಆಡಿಟ್ಗಳು (Community-driven audits): ಇವು ಸಮಸ್ಯೆಗಳು ಪ್ರೊಡಕ್ಷನ್ ಏಜೆಂಟ್ಗಳಿಗೆ ತಲುಪುವ ಮೊದಲೇ ಗುಪ್ತ ದೋಷಗಳನ್ನು ಹೊರಹಾಕುತ್ತವೆ.
- ಸಂಭವನೀಯ ಸ್ಪೆಕ್ ಪರಿಷ್ಕರಣೆಗಳು (Potential spec revisions): ಇವು
allowed-toolsನಂತಹ ಅಸ್ಪಷ್ಟ ಫೀಲ್ಡ್ಗಳನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತವೆ ಮತ್ತು ಎನ್ವಿರಾನ್ಮೆಂಟ್ ವೇರಿಯೇಬಲ್ಗಳ ಸ್ವೀಕಾರಾರ್ಹ ಬಳಕೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತವೆ.
ಮುಂದಿನ ತಲೆಮಾರಿನ ಟೂಲಿಂಗ್ (tooling) ಬಹುಶಃ ಈ ಪರಿಶೀಲನೆಗಳನ್ನು ಕಂಟಿನ್ಯೂಯಸ್-ಇಂಟಿಗ್ರೇಶನ್ (continuous-integration) ಪೈಪ್ಲೈನ್ಗಳಲ್ಲಿ ಅಳವಡಿಸಲಾಗುವುದು, ಇದರಿಂದ ಕಂಪ್ಲಯನ್ಸ್ (compliance) ಎಂಬುದು ಕೇವಲ ಮ್ಯಾನುಯಲ್ ಕೆಲಸವಾಗದೆ ಸ್ವಯಂಚಾಲಿತ ಗೇಟ್ ಆಗಿ ಬದಲಾಗುತ್ತದೆ.
ತೀರ್ಮಾನ (Takeaway)
A majority of publicly listed AI-agent skills fail basic compliance checks, and a non-trivial slice cannot be selected at all. The findings underline a clear need for stricter validation, better linting tools, and a community culture that treats spec adherence as a prerequisite for publishing. Until those safeguards are in place, agents will continue to stumble over brittle, non-portable skills.