Composer Json Validator
PassAudited by ClawScan on May 1, 2026.
Overview
This appears to be a local composer.json linter with no credential or network requirements, but users should notice that it runs a bundled Python script from an unknown source.
This skill is reasonable to use if you are comfortable running its bundled Python script locally. Use an explicit composer.json path, be careful with --strict in CI, and consider reviewing the script first because the registry metadata does not provide an upstream source or homepage.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If invoked on the wrong path, the script may read and analyze an unintended local JSON file, though no artifact evidence shows writing, deletion, or network transmission.
The tool exposes a command-line interface with a user-supplied file path. This is expected for a local validator, but users should be intentional about which file path is provided.
Usage: python3 composer_json_validator.py <command> <file> [--strict] [--format text|json|markdown]
Run it only against the intended composer.json file and review generated output before using it in automated workflows.
Users have less provenance information for independently verifying the script’s origin.
The skill includes a runnable helper script but does not provide upstream source or homepage provenance. No remote installer, package dependency, or hidden download is evidenced.
Source: unknown Homepage: none
Review the bundled script before use, especially in sensitive repositories, and prefer a published source URL in future releases.
Using the skill means executing local Python code from the skill package.
The documented workflow runs a bundled Python script. This is purpose-aligned for a validator and is disclosed, with no eval, dynamic downloads, or shell chaining evidenced.
python3 scripts/composer_json_validator.py lint composer.json
Use it when comfortable running the bundled script, and review the script first if the repository or environment is sensitive.
If wired into CI with --strict, warnings may fail a build or check.
Strict mode intentionally converts warnings into a nonzero exit code. This is disclosed and useful for CI, but it can affect automated pipelines if enabled.
`--strict` | Exit code 1 on warnings (CI-friendly)
Enable --strict only where warning-level findings should block the workflow.
Users may over-weight the status claim when deciding whether to run the bundled script.
The status file makes a broad assurance claim. It is not deceptive by itself, but users should treat it as a publisher status note rather than independent proof of safety.
**Status:** Built, tested, validated. Ready for publishing.
Base trust on the actual script behavior and your own review, not only on the status statement.