ℹ
Purpose & Capability
Name/description (enforce file placement) aligns with the instructions (where to put .md and .sh files). However, the mapping is hard-coded to absolute paths under /Users/tobymorning/Desktop/core/ and AINative-website, which is specific to one developer/environment and unlikely to be appropriate for other users/projects. The skill claims to 'enforce' rules but provides no code or declared hooks (pre-commit, CI, filesystem watcher) to implement enforcement.
ℹ
Instruction Scope
SKILL.md gives explicit, prescriptive rules and a checklist for "before creating" files. It does not instruct the agent to read secrets or external endpoints. But it implicitly requires the agent/operator to inspect filesystem locations and file creation contexts (e.g., detect root vs docs/ or scripts/). The instructions do not specify how enforcement occurs, how to detect attempted file creation, or how to handle projects with different root paths—so there's a gap between claimed enforcement and actionable steps.
✓
Install Mechanism
Instruction-only skill with no install spec and no code files — lowest-risk installation surface. Nothing is downloaded or written to disk by the skill package itself.
✓
Credentials
No environment variables, credentials, or config paths are requested. The skill does not ask for unrelated secrets or broad system access in its metadata. The only concern is the use of absolute user-specific paths in the instructions (not a credential issue, but a scope/usability issue).
✓
Persistence & Privilege
always is false and the skill is user-invocable; it does not request permanent inclusion or elevated platform privileges. There is no code that modifies other skills or global config.
What to consider before installing
This skill appears to be a policy document: it tells an agent or human how to place documentation and scripts, but it does not include any implementation (hooks, watchers, linters) or a way to adapt to other projects. Before installing or relying on it, consider: (1) the rules are tied to /Users/tobymorning/... — if you are not that user, ask for a configurable base path or generalized rules; (2) it claims to 'enforce' but provides no enforcement mechanism — decide whether you need a pre-commit hook, CI job, or linter and implement that separately; (3) test the rules in a non-production repo to ensure the agent won't block legitimate workflows; (4) if you expect an automated agent to act on these rules, explicitly limit filesystem access and clarify how the agent should detect file creation attempts; (5) if you want this as a template, request removal of hard-coded absolute paths and addition of configuration parameters (project root, allowed exceptions). These issues are implementation/usability concerns rather than clear malicious behavior, but they are important to resolve before adoption.
