freeze

The skill silently collects analytics data (writing to ~/.gstack/analytics/skill-usage.jsonl) without explicit user consent or clear documentation in the manifest. Users are not informed that their usage patterns, repository names, and timestamps are being logged, creating a privacy concern and violating transparency principles for data collection.

fix Add explicit user disclosure in the skill description and setup flow. Update the manifest to declare analytics collection as a sensitive capability. Require explicit user consent before collecting any data. Alternatively, remove silent analytics collection and use only explicit logging with user awareness.

The documentation claims the freeze boundary 'prevents accidental edits, not a security boundary' and acknowledges that Bash commands like 'sed' can bypass it. This contradicts the earlier security framing that the freeze 'blocks' and 'restricts' edits. Users may incorrectly rely on this as a security control when it provides only weak operational protection.

fix Clearly document in the initial description that freeze is an operational guard, not a security boundary. Add prominent warnings that users with Bash access can circumvent restrictions. Rename or reframe the feature to avoid security terminology ('freeze' → 'scope limiter' or similar). Update all descriptions to consistently convey the actual threat model.

The skill logs analytics data including repository name extracted via git without explicit user consent or manifest permission. This creates an unintended side channel that leaks repository metadata (repo names) to local analytics files during normal operation, potentially exposing sensitive project information.

fix Remove analytics logging entirely, or if logging is necessary, require explicit user opt-in via configuration and document in the skill manifest. Do not collect or log git repository information without explicit user consent.

The skill writes to ~/.gstack/analytics/skill-usage.jsonl without any manifest-declared permission for this file or directory. This exceeds the skill's declared scope and creates persistent state that accumulates across sessions, potentially allowing tracking of skill usage patterns beyond what the user authorized.

fix Either declare analytics file write permissions in the skill manifest with clear user visibility, or remove analytics logging entirely. If analytics are needed, implement explicit user opt-in and transparent documentation.

The analytics data collection is embedded in the skill setup without any warning or consent prompt to the user. The code silently logs skill usage, repository names, and timestamps to ~/.gstack/analytics/skill-usage.jsonl without informing the user that their activity is being tracked. This violates privacy principles and user expectations.

fix 1. Add a prominent warning in the documentation explaining that usage analytics will be collected. 2. Implement an explicit AskUserQuestion asking for permission to enable analytics before logging occurs. 3. Provide a mechanism to disable analytics collection. 4. Clearly document what data points are collected and how long they are retained.

Analytics data collection including repository names and timestamps occurs without user disclosure at the point of collection or in the skill manifest. Users activating this skill have no notice that telemetry will be sent, violating standard privacy and transparency expectations for LLM skills that may process sensitive project information.

fix Add an explicit AskUserQuestion during skill activation to inform the user that usage analytics will be collected and what data will be captured. Include an option to opt-out. Update the skill manifest to declare analytics as a sensitive capability. Log this telemetry transparently and allow users to disable it.

The skill silently creates and writes to ~/.gstack/analytics/skill-usage.jsonl without any user confirmation or awareness. This violates user autonomy by creating persistent tracking data on the local system without consent, and the use of 2>/dev/null suppresses any feedback about file creation.

fix Remove silent file writes. If analytics logging is required, implement explicit user configuration and prompts before any file creation. Ensure errors are visible and users can opt-out completely.