taketomarket 2.2.0 → 2.3.0

package/workflows/utility/playwright-setup.md

@@ -0,0 +1,128 @@
+# Playwright Setup Workflow
+
+## Step 0: First-run inline education
+
+Read `.taketomarket/CONFIG.md`. Parse `first_run_seen` (object) and `inline_education` (boolean, default true).
+
+If `inline_education` is false: skip this step. Else if `first_run_seen.ttm-playwright-setup` is not `true`, print the explainer below verbatim, then mark this skill as seen:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs" first-run mark ttm-playwright-setup
+```
+
+Use this exact check (bash) to decide whether to print: `node "${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs" first-run check ttm-playwright-setup --raw` -- the JSON `seen` field is `true` once the explainer has run before.
+
+### Explainer for `/ttm-playwright-setup`
+
+`/ttm-playwright-setup` installs and configures the Playwright MCP
+required for the visual landing-page gate (gate 4) and any future
+browser-based verification. It detects your existing MCP config,
+adds the Playwright entry, and confirms the tool is reachable from
+the runtime.
+
+Why it matters: the landing-page gate wall includes a Playwright-driven
+visual check, and without the MCP installed it falls back to a softer
+gate. This skill turns the soft gate into a hard one. Treat it as the
+runtime equivalent of installing a missing test dependency.
+
+(Canonical source: `references/inline-education-blurbs.md`. Embedded verbatim because workflows do not @-resolve files at runtime.)
+
+---
+
+**Required reading:** `${CLAUDE_PLUGIN_ROOT}/references/playwright-mcp-setup.md`
+
+## Step 1: Detect current state
+
+```bash
+node ${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs playwright-check --raw
+```
+
+If `detected = true`: print "Playwright MCP already configured for Claude Code." Then AskUserQuestion (priority: critical):
+- "Run smoke test, install for another runtime (Codex/Cursor), or exit?"
+- options: "Run smoke test" / "Install for another runtime" / "Exit"
+
+If "Run smoke test": skip to Step 5. If "Install for another runtime": continue to Step 2 (filter Claude Code out of the candidate list). If "Exit": exit.
+
+## Step 2: Pick target runtime
+
+Even if the current session is Claude Code, the user might be installing for Codex or Cursor. Always ask.
+
+Suggest candidates by checking which dirs exist:
+- `~/.claude/` → Claude Code
+- `~/.codex/` → Codex
+- `~/.cursor/` → Cursor
+
+Then AskUserQuestion (priority: critical):
+- "Which runtime do you want to configure Playwright MCP for?"
+- options: list detected candidates first (marked "(detected)"), then the other runtimes, then "All of them"
+- if user picks "All of them": loop through each in Step 3.
+
+## Step 3: Print install steps for detected runtime
+
+Print the relevant sections from `${CLAUDE_PLUGIN_ROOT}/references/playwright-mcp-setup.md`:
+
+- Section **"1. Install the MCP server"** — the `npx -y @playwright/mcp@0.0.75 --help` pre-warm command and the `node -v` / `npm view @playwright/mcp version` verification.
+- Section **"2. Install the Chrome extension bridge"** — the Chrome Web Store link for "Playwright Extension" (`mmlmfjhmonkocbjadbfplnigmagldckm`), plus the sideload fallback for corporate machines.
+- Section **"3. Configure runtime MCP settings"** — show only the sub-block matching the detected runtime:
+  - **Claude Code:** the `claude mcp add playwright ...` CLI command (preferred) and the equivalent `~/.claude.json` / `~/.claude/settings.json` JSON snippet.
+  - **Codex CLI:** the `~/.codex/config.toml` TOML snippet (`[mcp_servers.playwright]`) and the `codex mcp add` CLI equivalent.
+  - **Cursor:** the `~/.cursor/mcp.json` (or per-project `.cursor/mcp.json`) JSON snippet.
+
+## Step 4: Pause for user
+
+AskUserQuestion (priority: critical):
+
+- question: "Have you completed the install steps above?"
+- options:
+  - "Yes, ready to test"
+  - "I'll do it later"
+
+If "I'll do it later": exit with a reminder that `/ttm-playwright-setup` can be re-run anytime to resume.
+
+## Step 5: Smoke test
+
+If the user said "Yes, ready to test":
+
+- Re-run `node ${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs playwright-check --raw`.
+- Track retry count across re-checks. Cap at 2 failed re-checks.
+- If still not detected: print "MCP server not detected. Common fixes:" followed by the relevant items from the reference's **Troubleshooting** section (Node version too old, runtime needs a full restart to pick up new MCP entries, absolute path required for `npx` on Cursor macOS). Loop back to Step 4.
+- After the 2nd failed re-check, exit the smoke-test loop with: "Couldn't detect Playwright MCP after 2 attempts. See references/playwright-mcp-setup.md Troubleshooting section, fix the issue, then re-run /ttm-playwright-setup."
+- If detected: try a real Playwright call:
+  - Use the MCP `browser_navigate` tool to navigate to `https://example.com` and take a screenshot.
+  - On success: print "✓ Playwright MCP working. takeToMarket capabilities now unlocked."
+  - On failure: print the error and link to the **Troubleshooting** section of `references/playwright-mcp-setup.md`.
+
+## Step 6: Mark CONFIG.md
+
+```bash
+TS=$(node ${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs timestamp --raw | tr -d '"')
+node ${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs config set playwright_mcp_setup_at "$TS"
+```
+
+If the user installed with the Chrome extension bridge (`--extension`), also record that capability so downstream skills can precondition:
+
+```bash
+node ${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs config set playwright_mcp_extension true
+```
+
+Otherwise set it to `false`.
+
+## Step 7: Print next steps
+
+```
+✓ Playwright MCP is configured.
+
+Capabilities now unlocked:
+- /ttm-competitor-scan can render JS-heavy sites.
+- /ttm-linkedin-post can scrape author profiles (requires a logged-in tab in Chrome).
+- /ttm-landing and /ttm-pseo quality gates can run Lighthouse + visual diff.
+
+Run /ttm-next for the recommended next command.
+```
+
+## What if this doesn't fit?
+
+Looks like /ttm-playwright-setup can't do that yet.
+
+- Want a new skill? /ttm-request-skill
+- Existing skill needs work? /ttm-improve-skill

package/workflows/utility/request-skill.md

@@ -0,0 +1,218 @@
+## Step 0: First-run inline education
+
+Read `.taketomarket/CONFIG.md`. Parse `first_run_seen` (object) and `inline_education` (boolean, default true).
+
+If `inline_education` is false: skip this step. Else if `first_run_seen.ttm-request-skill` is not `true`, print the explainer below verbatim, then mark this skill as seen:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs" first-run mark ttm-request-skill
+```
+
+Use this exact check (bash) to decide whether to print: `node "${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs" first-run check ttm-request-skill --raw` -- the JSON `seen` field is `true` once the explainer has run before.
+
+### Explainer for `/ttm-request-skill`
+
+`/ttm-request-skill` is the proposal pipeline for new skills. You
+describe a marketing job you keep doing manually, the skill asks
+structured questions (inputs, outputs, gates, frequency), and
+produces either a local SKILL.md draft you can iterate on or a
+formatted feature request against the upstream repo.
+
+Why it matters: solopreneurs hit recurring marketing tasks that
+nobody else's playbook covers because nobody else has your product.
+Rather than re-prompting from scratch each time, this skill turns
+your repeated workflow into a versioned, gated skill -- the same
+way you'd extract a utility function after writing the same code
+three times.
+
+(Canonical source: `references/inline-education-blurbs.md`. Embedded verbatim because workflows do not @-resolve files at runtime.)
+
+---
+
+<purpose>
+Skill request workflow for /ttm-request-skill. Gathers details about a NEW
+skill the user wants and files a GitHub issue at ranjanrishikesh/taketomarket.
+Prefers the `gh` CLI when installed and authenticated; falls back to opening a
+pre-filled GitHub issue URL in the browser.
+</purpose>
+
+<constraints>
+## Read-Only on the Local Project
+
+This workflow does NOT modify any files in the user's project. It only creates
+a remote GitHub issue (via `gh`) or prints a URL for the user to open.
+
+## Repo Identity
+
+Always file issues at `ranjanrishikesh/taketomarket` (lowercase). Do not infer
+a different repo from local git remotes — this skill files into the upstream
+takeToMarket project.
+
+## No Secrets in Issue Body
+
+Do NOT include API keys, tokens, file paths containing credentials, or any
+content from `.taketomarket/` reference files in the issue body. Only echo the
+user's freeform answers verbatim.
+</constraints>
+
+<process>
+
+## Step 1: Gather details
+
+```
+takeToMarket > REQUEST A NEW SKILL
+```
+
+Use `AskUserQuestion` (priority: critical) to collect:
+
+1. **Skill name** — "What's the skill name you want? (e.g., `ttm-twitter-post`)"
+   - Freeform single-line answer.
+   - If the user omits the `ttm-` prefix, prepend it for them.
+2. **What it does** — "What does it do?"
+   - Freeform, multi-line allowed.
+3. **Use case** — "What's the use case? When would you run it?"
+   - Freeform, multi-line allowed.
+4. **Similar / extends** — "Any existing skill it's similar to or extends?"
+   - Freeform. Optional — accept an empty answer.
+
+Store the answers as `SKILL_NAME`, `DESCRIPTION`, `USE_CASE`, `SIMILAR`.
+
+---
+
+## Step 2: Detect gh CLI
+
+```bash
+GH_STATE="no-gh"
+if command -v gh >/dev/null 2>&1; then
+  if gh auth status >/dev/null 2>&1; then
+    GH_STATE="gh-ready"
+  fi
+fi
+echo "$GH_STATE"
+```
+
+If `GH_STATE` is `gh-ready`, proceed to Step 3.
+Otherwise, proceed to Step 4.
+
+---
+
+## Step 3: If gh-ready, file issue via gh CLI
+
+Build the issue body from the gathered answers, then run:
+
+```bash
+gh issue create \
+  --repo ranjanrishikesh/taketomarket \
+  --title "[Skill request] ${SKILL_NAME}" \
+  --body "$(cat <<'EOF'
+**Skill name:** ${SKILL_NAME}
+**What it does:** ${DESCRIPTION}
+**Use case:** ${USE_CASE}
+**Similar / extends:** ${SIMILAR}
+
+---
+Filed via /ttm-request-skill
+EOF
+)"
+```
+
+(Substitute the variables before passing to the heredoc — the heredoc above is
+quoted to prevent shell expansion of literal `${...}` placeholders that
+should be filled in by you. Build the body string first and pass the resolved
+text via `--body`.)
+
+Capture the resulting issue URL printed by `gh issue create`. Display it to
+the user:
+
+```
+takeToMarket > SKILL REQUEST FILED
+
+Issue: <issue-url>
+
+Thanks for the request. You can track it at the URL above.
+```
+
+Done — exit successfully.
+
+---
+
+## Step 4: If no-gh, generate pre-filled URL
+
+When `gh` is not installed or not authenticated, build a pre-filled GitHub
+issue URL pointing at the `skill-request.yml` template.
+
+URL-encode the title and body. The body fields map to template field IDs:
+`skill-name`, `description`, `use-case`, `similar`.
+
+Construct (conceptually):
+
+```
+https://github.com/ranjanrishikesh/taketomarket/issues/new
+  ?template=skill-request.yml
+  &title=<urlencoded "[Skill request] SKILL_NAME">
+  &skill-name=<urlencoded SKILL_NAME>
+  &description=<urlencoded DESCRIPTION>
+  &use-case=<urlencoded USE_CASE>
+  &similar=<urlencoded SIMILAR>
+```
+
+You can generate the encoded URL with:
+
+```bash
+python3 - <<'PY'
+import urllib.parse
+import os
+title = f"[Skill request] {os.environ['SKILL_NAME']}"
+params = {
+    "template": "skill-request.yml",
+    "title": title,
+    "skill-name": os.environ["SKILL_NAME"],
+    "description": os.environ["DESCRIPTION"],
+    "use-case": os.environ["USE_CASE"],
+    "similar": os.environ.get("SIMILAR", ""),
+}
+qs = urllib.parse.urlencode(params)
+print(f"https://github.com/ranjanrishikesh/taketomarket/issues/new?{qs}")
+PY
+```
+
+(Export `SKILL_NAME`, `DESCRIPTION`, `USE_CASE`, `SIMILAR` to the environment
+before running the snippet.)
+
+Print the URL and instruct the user:
+
+```
+takeToMarket > OPEN IN BROWSER
+
+gh CLI not detected (or not authenticated). Open this URL to file the issue:
+
+<url>
+
+Tip: install `gh` (https://cli.github.com) and run `gh auth login` to file
+issues directly next time.
+```
+
+Done — exit successfully.
+
+</process>
+
+<success_criteria>
+- [ ] Four questions asked via AskUserQuestion (name, description, use case, similar)
+- [ ] gh CLI detection performed (command + auth status)
+- [ ] If gh ready: issue created at ranjanrishikesh/taketomarket with `[Skill request]` prefix and labels via template not required (gh path bypasses template)
+- [ ] If no gh: pre-filled URL printed with template=skill-request.yml and encoded title/body fields
+- [ ] No local files modified
+</success_criteria>
+
+<output>
+No local files modified. Either a GitHub issue is created remotely (gh path)
+or a URL is printed for the user to open (browser path).
+</output>
+
+## What if this doesn't fit?
+
+Looks like /ttm-request-skill can't do that yet. Try one of:
+
+- Existing skill behaving wrong? /ttm-improve-skill
+- Need an overview of the system first? /ttm-101
+- Otherwise file a free-form issue: https://github.com/ranjanrishikesh/taketomarket/issues/new

package/workflows/utility/resume.md

@@ -1,3 +1,33 @@
+## Step 0: First-run inline education
+
+Read `.taketomarket/CONFIG.md`. Parse `first_run_seen` (object) and `inline_education` (boolean, default true).
+
+If `inline_education` is false: skip this step. Else if `first_run_seen.ttm-resume` is not `true`, print the explainer below verbatim, then mark this skill as seen:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs" first-run mark ttm-resume
+```
+
+Use this exact check (bash) to decide whether to print: `node "${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs" first-run check ttm-resume --raw` -- the JSON `seen` field is `true` once the explainer has run before.
+
+### Explainer for `/ttm-resume`
+
+`/ttm-resume` is the session-recovery skill. It loads the active
+campaign's STATE.md, summarizes the last completed phase, lists
+pending work and known blockers, and recommends the exact next
+`/ttm-*` command. It also detects interrupted verify/fix loops so
+you continue from where the loop stopped.
+
+Why it matters: marketing campaigns run across many sessions over
+many days, and context loss between sessions is where things get
+silently dropped. Resume is the equivalent of restoring a debugger
+state: you don't have to remember where you were because the state
+files do.
+
+(Canonical source: `references/inline-education-blurbs.md`. Embedded verbatim because workflows do not @-resolve files at runtime.)
+
+---
+
 <purpose>
 Session recovery workflow for /ttm-resume. Loads campaign state, shows context
 summary (last completed phase, what was done, pending work, blockers), and suggests
@@ -14,7 +44,7 @@ State is loaded directly from CAMPAIGNS/<slug>/STATE.md (no separate handoff fil
 <constraints>
 ## POSITIONING.md is READ-ONLY
 
-**Do NOT modify `.marketing/POSITIONING.md` during this workflow.**
+**Do NOT modify `.taketomarket/POSITIONING.md` during this workflow.**
 
 POSITIONING.md is an architectural invariant. If you detect positioning drift:
 - In verify: use the Escalate option to launch /ttm-positioning-shift
@@ -76,7 +106,7 @@ Parse the full JSON output. Extract:
 
 Also read the FULL STATE.md file (not just CLI output) to get body content:
 ```bash
-Read .marketing/CAMPAIGNS/${SLUG}/STATE.md
+Read .taketomarket/CAMPAIGNS/${SLUG}/STATE.md
 ```
 
 The body contains "Phase:" and "Next step:" lines plus any additional notes,
@@ -142,7 +172,7 @@ Use the phase-to-command mapping to suggest the exact next command:
 
 | Current Phase | Next Command | Notes |
 |---------------|-------------|-------|
-| `created` | `/ttm-research ${SLUG}` | Campaign exists but no research done |
+| `created` | `/ttm-discover ${SLUG}` | Campaign exists but no research done |
 | `researched` | `/ttm-brief ${SLUG}` | Research complete, needs brief |
 | `briefed` | `/ttm-produce ${SLUG}` | Brief ready, needs production |
 | `produced` | `/ttm-verify ${SLUG}` | Assets produced, needs verification |
@@ -247,3 +277,10 @@ It has been ${days} days since last activity. Consider:
 No files modified. This is a read-only command that displays recovery context
 and suggests the next command for the user to run.
 </output>
+
+## What if this doesn't fit?
+
+Looks like /ttm-resume can't do that yet.
+
+- Want a new skill? /ttm-request-skill
+- Existing skill needs work? /ttm-improve-skill

package/workflows/utility/state.md

@@ -1,3 +1,31 @@
+## Step 0: First-run inline education
+
+Read `.taketomarket/CONFIG.md`. Parse `first_run_seen` (object) and `inline_education` (boolean, default true).
+
+If `inline_education` is false: skip this step. Else if `first_run_seen.ttm-state` is not `true`, print the explainer below verbatim, then mark this skill as seen:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs" first-run mark ttm-state
+```
+
+Use this exact check (bash) to decide whether to print: `node "${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs" first-run check ttm-state --raw` -- the JSON `seen` field is `true` once the explainer has run before.
+
+### Explainer for `/ttm-state`
+
+`/ttm-state` is the read-only dashboard. With no argument it prints
+every campaign (active and archived) with its current phase, blockers,
+shipped-asset count, and last activity timestamp. With a slug, it
+prints the per-campaign detail view from that campaign's STATE.md.
+
+Why it matters: state is the truth file in takeToMarket -- not your
+memory, not the conversation history. This skill is how you check
+that truth without mutating it. Use it before running any campaign
+action when you're not sure where you left off.
+
+(Canonical source: `references/inline-education-blurbs.md`. Embedded verbatim because workflows do not @-resolve files at runtime.)
+
+---
+
 <purpose>
 State dashboard workflow for /ttm-state. Displays all campaigns (active and
 archived) in a summary table. No-argument mode shows the full campaign dashboard;
@@ -12,7 +40,7 @@ and enriches with per-campaign STATE.md data.
 <constraints>
 ## POSITIONING.md is READ-ONLY
 
-**Do NOT modify `.marketing/POSITIONING.md` during this workflow.**
+**Do NOT modify `.taketomarket/POSITIONING.md` during this workflow.**
 
 POSITIONING.md is an architectural invariant. If you detect positioning drift:
 - In verify: use the Escalate option to launch /ttm-positioning-shift
@@ -68,14 +96,14 @@ Exit.
 
 **Check for archived campaigns:**
 ```bash
-ls .marketing/CAMPAIGNS/ARCHIVE/ 2>/dev/null
+ls .taketomarket/CAMPAIGNS/ARCHIVE/ 2>/dev/null
 ```
 
 For each archived directory found, read its STATE.md frontmatter to get archive date
 and outcome information.
 
 **Read global state for portfolio context:**
-Read `.marketing/STATE.md` body content (below frontmatter) for portfolio-level
+Read `.taketomarket/STATE.md` body content (below frontmatter) for portfolio-level
 decisions, blockers, and experiments.
 
 ---
@@ -109,9 +137,9 @@ For each active campaign, also display a detail section:
 **Created:** <date> | **Last Updated:** <date>
 **Gate Results:** <summary of pass/fail counts from review.overall_result>
 **Fix Attempts:** <fix.run_count or 0>
-**Decisions in flight:** <from global .marketing/STATE.md body if any>
-**Blockers:** <from global .marketing/STATE.md body if any>
-**Experiments:** <from global .marketing/STATE.md body if any>
+**Decisions in flight:** <from global .taketomarket/STATE.md body if any>
+**Blockers:** <from global .taketomarket/STATE.md body if any>
+**Experiments:** <from global .taketomarket/STATE.md body if any>
 ```
 
 If no active campaigns exist, display:
@@ -198,10 +226,17 @@ If the campaign has no body content in STATE.md, display:
 - [ ] Dashboard displays active campaigns with detail sections
 - [ ] Archived campaigns shown as collapsed rows
 - [ ] Single campaign mode shows full detail when slug provided
-- [ ] Global .marketing/STATE.md body read for portfolio-level context
+- [ ] Global .taketomarket/STATE.md body read for portfolio-level context
 - [ ] No files modified (read-only command)
 </success_criteria>
 
 <output>
 No files modified (read-only command).
 </output>
+
+## What if this doesn't fit?
+
+Looks like /ttm-state can't do that yet.
+
+- Want a new skill? /ttm-request-skill
+- Existing skill needs work? /ttm-improve-skill