Bug: The shell variable $PREFS_PATH is used in bash snippets without being defined, causing preference read and write operations to silently fail.
_{Severity: HIGH}

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: claude-ops/skills/ops-gtm/SKILL.md#L313

Potential issue: The `ops-gtm/SKILL.md` file uses the shell variable `$PREFS_PATH` in
multiple bash snippets without defining it. When these snippets are executed,
`$PREFS_PATH` expands to an empty string. Consequently, commands like `jq` that attempt
to read from or write to the preferences file will target an empty file path and
silently fail. This prevents the `/gtm setup` command from reading existing preferences
or persisting new user configurations, effectively breaking the skill's ability to
remember settings across sessions.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

🔴 Preference key mismatch: setup saves gtm_project_type but Runtime Context reads gtm_default_audience

The setup section (line 329) saves the Project Type answer under the key gtm_project_type, but this key is never read anywhere. Meanwhile, the Runtime Context (line 32) and the setup auto-scan jq command (line 313) both read gtm_default_audience, which is never saved by any flow. This means:

1. Running /gtm setup and answering "Project type" writes to a dead key (gtm_project_type) — subsequent runs never pick it up.
2. The gtm_default_audience preference is always null/missing, so the audience default never works despite the sub-command routing table (line 77) claiming setup configures "audience".

The preference keys are inconsistent between the setup save operation and the Runtime Context / auto-scan read operations. The setup section at line 329 saves gtm_project_type, but the Runtime Context at line 32 and the jq auto-scan at line 313 read gtm_default_audience. One of these must be corrected to match the other. Additionally, there is no actual audience question in the setup flow (lines 322-327), yet the routing table at line 77 claims setup configures audience. The fix likely involves either: (a) renaming gtm_project_type to gtm_default_audience everywhere and reframing the project type question as an audience question, or (b) adding a separate audience question to setup and updating the Runtime Context and jq to also read gtm_project_type, or (c) deciding which concept (project type vs audience) is the correct one and aligning all references.

Was this helpful? React with 👍 or 👎 to provide feedback.

Severity 7/10 — Smoke test is self-referential and background-incompatible

/gtm brief requires intake questions (AskUserQuestion calls for project name, ICP, etc.). Running it with run_in_background: true means:

1. The sub-command will immediately fail or hang — no user can respond to interactive prompts in a background task.
2. Even if it were fire-and-forget, the result (✓/✗) is reported before the background task completes, making the status always stale/incorrect.

Suggested fix — replace the self-invocation with a lightweight prefs-validation check:

jq -e '.gtm_default_project and .gtm_stage' "$PREFS_PATH" > /dev/null 2>&1 \
  && echo "✓ setup complete — try /gtm plan" \
  || echo "✗ preferences write failed — check $PREFS_PATH"

This verifies the actual output of the setup flow without recursively invoking another sub-command.

Preference key mismatch between setup save and read

Medium Severity

The setup sub-command saves gtm_project_type to preferences, but the Runtime Context section and the setup auto-scan jq command both read gtm_default_audience instead — a key that is never written anywhere. This means "Project type" chosen during setup is silently discarded on subsequent runs, and the gtm_default_audience preference will always be empty, causing the intake flow to re-ask for information the user already provided.

 

^{Reviewed by Cursor Bugbot for commit 8726ac4. Configure here.}

Setup says it saves gtm_project_type, but earlier sections reference gtm_default_audience and instruct intake to read gtm_default_* keys. This looks inconsistent (audience is never collected/saved; project type key name doesn’t match the gtm_default_* pattern). Either add an audience question and save it, or remove the gtm_default_audience references; and standardize the preference key names so intake/setup agree.

The Unpaid catalog and later sections imply /marketing email can scaffold lifecycle flows (e.g., "Klaviyo flows"), but claude-ops/skills/ops-marketing/SKILL.md only documents email metrics/inspection (no flow creation/scaffolding endpoints or commands). As-is, the handoff to /marketing email won’t produce the promised artifacts. Either adjust the wording to match what /marketing email actually does today, or add a corresponding flow-scaffolding capability to /marketing and reference the correct sub-command here.

The Agent Team prompt examples include shell-style placeholders like ${PROJECT_TYPE}, ${STAGE}, and ${MONTHLY_BUDGET}, but these variables are never defined elsewhere in the skill. If passed through literally, the subagents will see the raw placeholders instead of the actual intake values. Consider either interpolating the real intake values before calling Agent(...), or switch the examples to neutral placeholders like [project_type], [stage], [monthly_budget] and explicitly instruct to substitute them.

Markdown tables here start each row with || (double pipe), which renders an extra empty column in most Markdown renderers. Update the table syntax to use a single leading | (and make the same adjustment to the other tables in this file) so the routing table renders correctly.

The channel catalog tables also use || at the start of rows, which will create an unintended blank first column when rendered. Standardize these tables to normal Markdown | ... | formatting for readability (this applies to Paid/Unpaid/Sales/AI Automation tables).

Project intake says to read prefs for gtm_default_* keys, but the rest of the document uses non-default keys like gtm_stage / gtm_monthly_budget (and setup later saves gtm_project_type). As written, setup values may not be picked up during intake. Align the preference key naming (either read the specific keys you write in setup, or rename what setup writes to match the gtm_default_* convention).

The handoff option suggests delegating to /ops cron, but there does not appear to be a corresponding skill/command in this repo (no /ops:cron or ops-cron skill). This would fail at runtime when selected. Consider delegating to an existing mechanism (e.g., ops-daemon / daemon-services scheduling) or remove/replace this option with a supported command.

The setup section’s shell snippet references $PREFS_PATH, but this variable isn’t defined anywhere in the document. Other skills typically define it as ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json before use. Define PREFS_PATH (or inline the full path consistently) to avoid ambiguous instructions and potential mis-writes.