ios-fix

The preamble executes telemetry logging to ~/.gstack/analytics/ without explicit manifest declaration or user consent mechanism at skill invocation time. This violates principle of least privilege—a user invoking an 'iOS bug fixer' skill should not automatically trigger analytics writes to undisclosed system paths.

fix Add 'Analytics' to the allowed-tools manifest section. Declare telemetry collection in the skill description. Implement explicit per-session consent gate before any analytics writes in the preamble, or defer all analytics to post-workflow completion where user is aware.

The preamble reads and modifies ~/.gstack/ configuration files (gstack-config calls, feature-prompted markers) without declaring these operations in the manifest's allowed-tools. This is scope creep—configuration mutation is a sensitive capability not reflected in the skill's stated purpose.

fix Explicitly declare all configuration file paths and mutation operations in the skill manifest. Consider moving config checks to a separate bootstrapping step with clear user consent. Alternatively, implement a config-change audit log and user confirmation gate before writing ~/.gstack/ state files.

The manifest describes 'Autonomous iOS bug fixer' but the preamble (lines 36–506) implements a complex multi-feature onboarding pipeline: telemetry prompts, learning artifacts, gbrain sync, routing injection, plan-mode behavior, and writing-style tuning. None of these are iOS-related. This mismatch obscures the true scope of the skill and makes it harder for users to predict what will execute.

fix Either (1) split the preamble into reusable common setup and skill-specific steps, with clear labeling; (2) update the manifest description to accurately reflect the full behavior; or (3) move generic onboarding (telemetry, features, routing) to a separate /setup skill that runs once, not per-invocation.

The preamble spawns background processes (gstack-timeline-log, gstack-telemetry-log) and manages session state (~/.gstack/sessions/) without documenting this behavior in the skill description or providing visibility into what these background tasks do or where they write data.

fix Document all background process spawning in the skill preamble comments. Ensure each background task has a clear purpose statement and writes only to documented paths. Provide a flag to disable background telemetry for users who do not consent.

The 'Iron Law' section emphasizes 'NO FIX WITHOUT A REPRODUCING SNAPSHOT' but earlier preamble sections provide no enforcement mechanism or validation logic to ensure this constraint is honored before the skill's Phase 1 begins. This creates a documentation-code gap where the principle is stated but not enforced.

fix Add a validation checkpoint in the skill workflow (before Phase 1 starts) that confirms a reproducing snapshot exists or has been captured. If missing, explicitly STOP and ask the user to provide one. Log this checkpoint in skill output so it's observable.

The skill instructions include `git rm -r .claude/skills/gstack/` as a consequence of user choice (option A in the vendoring migration prompt) without explicit final confirmation or backup creation. This destructive operation could accidentally delete the user's gstack installation if the prompt logic fails or the user misunderstands the choice.

fix Require a second confirmation (e.g., 'This will permanently delete .claude/skills/gstack/. Type DELETE to confirm.') before executing git rm. Create a timestamped backup copy to ~/.gstack/backups/ before deletion. Provide clear instructions on recovery if the user changes their mind.

The preamble silently deletes session files older than 120 minutes (`find ~/.gstack/sessions -mmin +120 ... -exec rm {} +`) without any log message, user warning, or retention policy documentation. Users have no visibility into what is being cleaned up.

fix Log a message before cleanup: 'Cleaning old session files from ~/.gstack/sessions/'. Write a summary to ~/.gstack/.cleanup-log (e.g., 'Deleted 5 sessions on 2024-01-15 14:30'). Allow users to configure retention time via gstack-config. Document the default 120-minute retention policy in skill comments or CLAUDE.md.

Network requests to telemetry and brain-sync endpoints (gstack-telemetry-log, gstack-brain-sync) are triggered in the preamble without explicit warning in the skill description. Users invoking this skill to fix an iOS bug may not expect network calls to external analytics or artifact-sync services.

fix Add a 'Network' notice to the skill description. Implement a pre-flight check that lists all network operations before the preamble runs. Provide an easy opt-out flag (e.g., GSTACK_OFFLINE_MODE=1) that disables all telemetry and sync calls.

The skill description and documentation omit critical warnings about destructive operations. This skill performs automated code modifications (Phase 3: 'Edit Swift source'), rebuilds applications, and redeploys to real devices without explicit user consent warnings in the skill description itself. Users triggering this skill via voice or text commands like 'fix this ios bug' may not fully understand they are authorizing potentially breaking changes to production code and device state without human review checkpoints.

fix Add explicit warnings in the skill description and preamble section clearly stating: (1) This skill will automatically modify source code and rebuild applications, (2) User should review all proposed fixes before deploying to production, (3) The skill may iterate up to 3 times before escalating, during which the app state may be altered, (4) Device snapshots and test fixtures will be created and committed. Consider adding a confirmation step (AskUserQuestion) before entering Phase 3 that requires explicit user approval of the proposed fix before any code modifications occur.

The preamble establishes operational context and narrative trust (echo statements, config checks, session management) before requesting sensitive actions (config writes, file modifications, auto-decisions in plan mode). This pattern of building trust before asking for permission is a known social engineering technique that can lower the user's threshold for granting sensitive capabilities.

fix Invert the order: declare all sensitive capabilities upfront (before any setup). Use explicit AskUserQuestion gates before first config write, first file deletion, and before enabling auto-decide features. Avoid narrative framing that normalizes privilege escalation.

The skill logs usage data, decisions, learnings, and project context to ~/.gstack/analytics/ and ~/.gstack/projects/ without explicit per-session user consent. The telemetry prompt (lines 225–252) appears much later in the workflow, after logging has already begun. This violates consent ordering—logging should never precede consent.

fix Move the telemetry consent prompt (TEL_PROMPTED check) to the very beginning of the preamble, before any logging. Do not write analytics until after user has consented. Provide a runtime flag (GSTACK_TELEMETRY=off) that blocks all logging until explicitly enabled.

The 'Skill Invocation During Plan Mode' section instructs the agent to 'Treat the skill file as executable instructions, not reference' and to bypass AskUserQuestion gates if the skill workflow begins. This reframes bypassing interactive prompts as correct behavior, potentially allowing the agent to make unreviewed changes in plan mode when the user expected an interactive checkpoint.

fix Clarify that AskUserQuestion gates are NOT optional in plan mode—they are the mechanism for exiting plan mode and requesting user confirmation. Require explicit tool_use of AskUserQuestion before any destructive operations, even in skill workflows. Add a comment: 'Plan mode requires user confirmation for every decision; there are no exceptions.'

Feature discovery prompts (lines 145–177) incrementally normalize auto-enrollment in new systems (continuous checkpoint, model overlays, GBrain integration) by presenting them as helpful defaults. Over time, repeated exposure to 'this feature improves X' can habituate users to accepting new data-collection or auto-behavior features without sustained critical evaluation.

fix Separate feature discovery (informational) from feature enrollment (interactive). Always require explicit opt-in for any feature that involves data collection, auto-commits, or behavior changes. Document the decision so the user can later audit what was auto-enabled.

The GBrain integration section (artifacts sync, brain-sync, remote-MCP mode) uses indirect language ('publish your artifacts', 'index across machines', 'managed by brain server') that normalizes cross-machine data collection without explicitly stating that project code, plans, and design documents may be sent to external systems. The language obscures the scope of what is being collected.

fix Rename 'artifacts' to 'project data' or be specific ('CEO plans, designs, code reviews'). Explicitly state: 'GBrain will copy your project data to a remote GitHub repo for indexing.' Require explicit user consent before any GBrain sync operation. Document which files are included in the 'artifacts' bucket.

The 'Voice' and 'Writing Style' sections describe guardrails (no AI vocabulary, be direct, avoid hype) as 'preferences' and 'nudges' that are 'subordinate' to skill workflow. This framing subtly redefines safety guidelines as optional negotiable constraints rather than hard requirements, which could cause an agent to deprioritize them if a user or skill asks for behavior that conflicts.

fix Reframe safety guidelines as requirements: 'These are not preferences; they are design constraints that all skills must follow.' Remove the word 'subordinate' from the guardrails section. Add a note: 'If a skill or user request conflicts with these guidelines, the guidelines win.'

Context recovery (lines 571–595) automatically loads and exposes prior project artifacts (CEO plans, checkpoints, design documents, learnings, timelines) without prompting the user to confirm that this prior context is still relevant or should be visible. Sensitive project decisions from past sessions may be unintentionally re-exposed.

fix Before loading context, ask: 'Found prior artifacts from [date]. Load them?' If yes, show a summary (file paths, dates) and ask for confirmation before exposing content. Provide a flag to skip context recovery (GSTACK_SKIP_RECOVERY=1) for sensitive sessions.

The question-tuning system uses obfuscated marker syntax (`<gstack-qid:{id}>`) and implicit `(recommended)` label parsing to enable automatic decision-making without explicit user awareness. Users may not understand that their AskUserQuestion responses are being logged and categorized, or that future auto-decisions will be made based on markers they did not explicitly set.

fix Require explicit user opt-in for each auto-decision via a separate AskUserQuestion: 'Allow auto-decisions for [question-id]?' Do not embed decision logic in question markers. Make the question-log and preference system fully transparent and auditable via a command like `gstack-questions --history` and `gstack-questions --preferences`.

Operational self-improvement and learning logging (lines 704–712) normalize persistent collection of user behavior, project quirks, and patterns via `gstack-learnings-log`. Over time, the accumulated learnings create a behavioral profile that may be used for future auto-decisions or recommendations without explicit user review of what was learned.

fix Make learnings collection opt-in, not automatic. Before logging a learning, ask the user: 'Found a pattern: [insight]. Save for future sessions?' Show the learnings file periodically (e.g., weekly) for user review and cleanup. Provide a command to delete learnings or audit what was collected.