---
name: aeo-question-panel-refresh
description: Weekly proposals to improve your AI-answer tracking questions using real buyer language, with quota math and owner approval, without changing tracker configuration.
---

# AEO Question-Panel Refresh

Compare your tracked questions with the language buyers actually use in calls and conversations, then propose up to six additions, swaps or rewords. Send a quota-aware decision to your owner and retain the evidence in the tracking registry. Part of the [Answer Engine Optimization (AEO) skillset](https://type.com/library/skills/answer-engine-optimization).

## When it runs

- Recommended schedule: Wednesdays at 9am in `timezone`.
- DM only `owner`; never post the proposal to the report channel.
- If no meaningful buyer language came in, record one line in the registry's run notes and send no DM.
- This sits between citation-target research and the comparison-page monitor in the weekly cadence.

## Inputs

| Input | What it is | Example |
| --- | --- | --- |
| `brand_name`, `brand_exclusions` | Exact brand spelling and look-alikes not counted | Example Co; Example AI |
| `owner`, `timezone` | Only permitted DM recipient and local timezone | @owner; America/Los_Angeles |
| `tracker_monitors`, `tracker_engines` | Buyer-problem, competitor/category and brand panels, with engine counts | A, B, Brand; 4 engines |
| `quota_per_period`, `period_end`, `used_responses` | Current plan allowance, remaining period and actual usage | Your tracker subscription |
| `buyer_profile` | Audience whose questions the panel should represent | Technical buyer at a midsize company |
| `meeting_sources`, `sales_channels`, `workspace_sources` | Permitted buyer-language sources | Sales/demo calls; #sales; Marketing threads |
| `tracking_registry`, `aeo_master_doc` | Shared active panel, quota rules, proposals and Alert log | The tracking registry; the AEO master doc |

## Before you start

Connect Promptwatch in type.com as a Custom API connection using your Promptwatch project API key. Another tracker works if it provides equivalent `monitors`, `prompts` and `responses` data. Connect read access to meeting notes/transcripts (Granola or equivalent), configured sales conversations and workspace threads, plus Slack or equivalent for the owner's DM.

Find the tracking registry and AEO master doc. On first run create missing docs and their Proposals, Run notes and Alert log sections, then tell the owner where they are. An empty registry is not evidence of an empty tracker: reconcile the active questions, monitors, persona, engines and quota rules against the live tracker before proposing changes. Never invent quota or buyer context.

## Steps

### 1. Read and confirm the active panel

Read the registry's active questions, monitor roles, persona, engines and quota rules. Confirm with `monitors` covering the last 7 days, including promptCount and responseCountInRange; use `prompts` when needed to reconcile actual question text.

Calculate current responses per day as active questions × scheduled engines, accounting for any monitor-specific schedule. A new daily question costs the number of engines per day; a swap costs zero net if schedules and engine coverage match. Use actual tracker usage and remaining period dates.

### 2. Collect buyer language from the last 14 days

Read sales, demo, onboarding and GTM-planning meeting notes/transcripts. Capture verbatim phrases describing a problem, “is there a tool that…” requests, named competitors, security and enterprise readiness.

Search the configured report/sales channels for prospect questions or objections pasted by the team. Search configured workspace threads for demo debriefs, follow-up packets and inbound lead research. Keep full source quotes and source links in the registry; use only the short quote needed in the owner's private DM.

Read the last 7 days of `responses`, size 50 per monitor, noting questions where no engine names any vendor (too generic) or all engines name the same 1–2 incumbents (saturated). Read the AEO master doc's Alert log for questions that repeatedly flag.

### 3. Propose at most six changes

- ADD “<question text>” to <monitor>. Why: verbatim buyer phrase and source. Expected: engines likely to retrieve and the owned page that should answer it. Cost: +<engine count>/day.
- SWAP out “<existing question>” for “<new question>”. Give the data showing generic, saturated, duplicate or off-profile intent. Cost: 0 net for matching coverage.
- REWORD “<existing question>” → “<new text>” when buyer phrasing differs but intent is the same. Show any actual quota cost.

Write questions as `buyer_profile` would type them. No brand names in buyer-problem monitor A; competitor names are allowed in category monitor B. Never duplicate an existing question's intent. Include the target owned page and expected retrieval engines in the full proposal.

Keep the plan within quota and show the math: used responses + current daily use × days left in the period + proposed daily delta × applicable remaining days ≤ `quota_per_period`. Do not hide used responses or treat a per-day delta as the full-period cost. If no meaningful changes are justified, record that fact and do not DM.

### 4. Send the decision and append the evidence

DM only `owner`, maximum 10 lines. Append a dated “<Mon D, YYYY> proposal (awaiting <owner>)” block under Proposals, creating the section if absent. Store full quotes, links, reasoning, expected retrieval/page, swap-out evidence and quota calculations there. Do not edit the active question list.

The owner's approval is a decision record for a human or separately approved workflow. This skill never changes tracker configuration, even after approval.

## What it posts

One private DM, no public report:

```text
Reply "approve 1,3", "approve all" or "skip". Nothing changes until you do.
Panel refresh — <Mon D> · <n> proposals · quota after: <used + projected>/<quota_per_period>
1. ADD|SWAP|REWORD · "<new question>" · <monitor> · from: "<6-word buyer quote>" (<source>) · +<engines>/day or 0
… <one line per proposal, max 6>
Details → <registry link>
```

For swaps and rewords include old wording and new text on the same proposal line. Keep full source quotes and justifications in the registry.

## Output rules

- Lead with the decision the owner must make and exactly how to reply.
- One proposal per line, with the new question verbatim, monitor, six-word source quote and quota cost. No paragraphs.
- Numbers, not adjectives. No preamble, method or caveats unless they change the decision.
- Link the registry once as “Details →”. Hard cap: DM 10 lines.
- Write `brand_name` exactly and exclude `brand_exclusions` in mention counts.

## Safety

- Read-only on every third party: never submit forms, send email/outreach, sign up, comment, vote or post on Reddit, X, LinkedIn or any social/community site.
- Never create, edit, activate or deactivate tracker prompts, monitors, personas, models or schedules.
- Only writes: a private DM to `owner` and scoped appends to the registry's Proposals and Run notes sections. Never DM anyone else or post this proposal in a public channel.
- Never @-mention anyone in a channel or expose credentials, tokens or passwords. Keep buyer quotes within the configured private sources and destination.

## Example configuration

How type.com configures this skill (example):

- Wednesdays 9am America/Los_Angeles; owner Sam. Monitor A: buyer problems; B: competitors/category; Brand: brand questions.
- Audience: technical buyers at companies with 150–1,000 people. Brand type.com; exclude type.ai.
- October 2026 panel: 46 questions × 4 engines = 184 responses/day; Essential quota 6,000 per period. These are example values, never assume them for another account.
- Example buyer-led questions: “hosted Claude Code and Codex for my whole team instead of everyone running it on a laptop”; “how do I share Claude and Codex skills with my team and give each person different permissions”; “alternatives to Codex cloud for running agents across a company”.
- The October 19 question update and October 20 technical-buyer persona change create a baseline break. Track changes in the registry; compare only compatible panel periods.
