# Ddg Apple Feedback Review > Invoke ONLY when the user explicitly runs /ddg-apple-feedback-review or names this skill by name. Do NOT auto-invoke from symptom/intent matching. If the user asks about Apple feedback, iOS or macOS issues, user reports, or feedback triage without naming this skill, answer directly instead. - Skill: `duckduckgo/ddg-apple-feedback-review` (Agent Skill) - Install (CLI): `npx skillmds@latest add duckduckgo/ddg-apple-feedback-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/duckduckgo/ddg-apple-feedback-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: duckduckgo (https://skillmd.com/u/duckduckgo) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/duckduckgo/ddg-apple-feedback-review --- # Apple Feedback Review ## Overview Apple-side feedback is fragmented across five Asana projects (in-app feedback, Privacy Pro feature requests, Privacy Pro issues, internal product feedback, and App Store reviews) and split between iOS and macOS. This skill fetches all relevant sources, deduplicates by task GID, clusters reports into named issue groups, and presents a per-platform summary with a separate App Store reviews section. The output is a one-shot snapshot, not a query interface. **Sensitive data halt:** An organization-level instruction requires you to stop and surface a `⚠️ SENSITIVE DATA` warning if any task surfaced by this skill contains legal (SILO, ACP, attorney-client privilege), HR (performance, compensation, terminations, PIPs), finance (M&A, budget details), or security (audits, incidents) content. List the triggers and ask for explicit confirmation before continuing - do not include such tasks in the report unsolicited. ## When NOT to use - Alerting or monitoring (this is a snapshot, not a watcher). - Individual task triage (use Asana directly). - Anything that needs a feedback database or repeated queries against the same window (the skill re-fetches from Asana every time). ## Lethal trifecta note This skill accesses Asana, an internal data source. A session-level hook blocks WebFetch and most non-allowlisted MCP tools for the rest of the session once Asana is touched. If the user needs WebFetch, Slack, or other non-allowlisted tools afterwards, run this skill in a separate session. The hook in this environment is also stricter about **Bash**: once Asana has been touched, Bash calls that look like they're "preparing report content to post back" are denied, including `python3`, `jq`, and `rm` on scratch files. This skill is therefore designed to run **without Bash post-Asana** - all task data stays in tool-call context, the report HTML is built in-message, and there are no scratch files to clean up. ## Parameters This skill accepts optional arguments. Parse them from the free-text args string passed to the skill. | Parameter | How to detect | Default | |-----------|--------------|---------| | **platform** | The literal token `ios` or `macos` (case-insensitive). If absent, run both. | `both` | | **days** | A number followed by `d`, `days`, or just a bare number (e.g. `14d`, `30 days`, `14`) | `7` | | **asana_url** | Any token starting with `https://app.asana.com/`. The destination Asana task to write the report into. | *(none - output inline)* | | **keywords** | Any remaining words after extracting `platform`, `days`, and `asana_url`. Multiple keywords separated by commas, or by spaces if no commas are present. | *(none - no text filter)* | Extract `asana_url` first (most specific), then `platform`, then `days`, then treat what remains as keywords. **Examples:** | Invocation | platform | days | asana_url | keywords | |------------|----------|------|-----------|----------| | `/ddg-apple-feedback-review` | both | 7 | *(none)* | *(none)* | | `/ddg-apple-feedback-review ios` | ios | 7 | *(none)* | *(none)* | | `/ddg-apple-feedback-review macos 14d` | macos | 14 | *(none)* | *(none)* | | `/ddg-apple-feedback-review 30 days vpn` | both | 30 | *(none)* | `vpn` | | `/ddg-apple-feedback-review ios sync, bookmarks` | ios | 7 | *(none)* | `sync`, `bookmarks` | | `/ddg-apple-feedback-review macos 14d ai chat, tab bar` | macos | 14 | *(none)* | `ai chat`, `tab bar` | | `/ddg-apple-feedback-review macos 14d https://app.asana.com/0/123/456` | macos | 14 | `https://app.asana.com/0/123/456` | *(none)* | | `/ddg-apple-feedback-review ios https://app.asana.com/0/111/222 vpn` | ios | 7 | `https://app.asana.com/0/111/222` | `vpn` | When keywords contain commas, split on commas and trim each keyword. When there are no commas, treat each remaining word as a separate keyword. Multi-word keywords must be comma-separated (e.g. `ai chat, dark mode`). ## Asana projects Feedback is fragmented across multiple projects on the Apple side. The skill fetches from each relevant source per platform, then merges and dedupes by task GID. ### iOS feedback bucket (grouped together by issue) | Project | GID | Filter | |---------|-----|--------| | iOS Feedback | `1206584483643184` | none | | iOS Privacy Pro Feature Request Feedback | `1207941309648065` | none | | iOS Privacy Pro Issues | `1207941520938527` | none | | Internal Product Feedback | `1204912272578138` | `Platform (Internal Feedback)` = "iOS Browser" | To filter Internal Product Feedback to iOS Browser, pass: ``` custom_fields: {"1204912272636857.value":"1204912272636860"} ``` The `.value` suffix on the field GID is required - without it the Asana API returns `custom_fields.: Not a valid search parameter for custom fields`. `1204912272636857` is the Platform (Internal Feedback) field; `1204912272636860` is the "iOS Browser" option. ### iOS App Store Reviews bucket (separate section, different schema) | Project | GID | Filter | |---------|-----|--------| | iOS App Store Reviews | `807511686726007` | none | ### macOS feedback bucket (grouped together by issue) | Project | GID | Filter | |---------|-----|--------| | macOS Feedback | `1199178362774117` | none | | MacOS Privacy Pro Feature Request Feedback | `1207941308245573` | none | | MacOS Privacy Pro Issues | `1207941519901927` | none | | Internal Product Feedback | `1204912272578138` | `Platform (Internal Feedback)` = "macOS Browser" | To filter Internal Product Feedback to macOS Browser, pass: ``` custom_fields: {"1204912272636857.value":"1204912272636859"} ``` (Same `.value` suffix requirement as above.) ### macOS App Store Reviews bucket (separate section, different schema) | Project | GID | Filter | |---------|-----|--------| | macOS App Store Reviews | `1203758364504327` | none | ## Steps ### 1. Parse parameters and calculate the date window Extract **platform**, **days**, and **keywords** from the args string using the rules above. Compute the ISO 8601 date for `days` days ago from today. Use this as the `created_at_after` filter. Echo the parsed parameters back to the user before fetching: > Searching feedback from the last **{days}** days for **{platform}**{keywords ? `, filtered by: **{keywords joined}**` : ""}{asana_url ? `. Report destination: {asana_url} (task GID: {extracted_gid})` : ""}. Including the extracted task GID lets the user sanity-check it before any write happens. Extract the GID right now using the rules in step 8.1, even though the write itself is later. Decide which buckets to fetch: - `platform = ios`: iOS feedback bucket + iOS App Store Reviews - `platform = macos`: macOS feedback bucket + macOS App Store Reviews - `platform = both`: all four buckets ### 2. Fetch recent feedback tasks (with pagination) For each project in each selected bucket, use `asana_search_tasks`. The API returns at most 100 results per call, so paginate to collect all tasks within the time window. If **keywords** were provided, make one search request **per keyword** using the `text` parameter, then merge and deduplicate results by task GID. This is necessary because `asana_search_tasks` accepts only a single text query. **No scratch directory.** This skill keeps all task data in tool-call context across steps 2-7 and assembles the final report HTML directly in step 8.5's `asana_update_task` call. There is no `mktemp` / `$scratch_dir`, no on-disk JSON dumps, no `jq` pipelines, and no cleanup step. If a step here ever suggests writing Asana data to disk, treat that as a bug in the skill and ignore it. The `opt_fields` below intentionally **excludes `notes`** - the macOS Feedback project alone returns ~80+ tasks per day and the full notes blob blows past the tool-result token cap. Fetch `notes` only on a task-by-task basis in step 3 when needed for grouping. **Use slim `opt_fields` for iOS Feedback and macOS Feedback.** These two projects carry 30+ custom fields per task (Reporter, Ban Type, Search Area, SAM Severity values, etc. - most irrelevant to clustering). A 100-task page with `custom_fields.name,custom_fields.display_value` is ~110 KB and reliably exceeds the inline tool-result cap. Drop the custom fields from the bulk fetch on these two projects; cluster from task titles alone; then in step 6 sample 5-10 representative tasks per Top-3 cluster and fetch *those* with full custom fields via `asana_get_task` for the deep dive. Other projects (Privacy Pro, Internal Product Feedback, App Store Reviews) carry fewer fields and fit comfortably with full custom fields at `limit=100`. | Project | `limit` | `opt_fields` | |---------|---------|--------------| | iOS Feedback (`1206584483643184`) | `100` | `name,created_at,completed` | | macOS Feedback (`1199178362774117`) | `100` | `name,created_at,completed` | | Privacy Pro / Internal / App Store Reviews | `100` | `name,created_at,completed,custom_fields.name,custom_fields.display_value` | Tradeoff: the Top-3 deep dive runs against a *sample* (5-10 tasks per cluster) rather than the full population. Annotate "sampled N of M" in the deep-dive output so the reader knows. Net win: ~3-4x fewer pagination rounds on the heavy projects (a 3-day window fits in ~2 pages instead of ~9), and a higher safety ceiling on long windows. **Spillover fallback (if a Privacy Pro / Internal / App Store Reviews query spills).** Uncommon at `limit=100` for those projects, but possible on a 30-day window or after schema bloat. When the MCP server reports a tool-result spillover for those projects, drop `custom_fields.name,custom_fields.display_value` from their `opt_fields` to match the slim-default treatment used for iOS / macOS Feedback, and sample per-cluster in step 6 the same way. Do **not** attempt to recover the spilled file via `jq`, `cat`, or any other shell tool - this skill does not assume Bash is available post-Asana, and Bash will likely be denied at this point in the session even if it appears to exist. iOS Feedback / macOS Feedback already use slim `opt_fields` by default, so this only affects the other projects when they spill. **First request (per project, per keyword, or once if no keywords):** ``` workspace: "137249556945" projects_any: created_at_after: completed: false text: custom_fields: sort_by: "created_at" sort_ascending: false limit: 100 opt_fields: ``` `workspace` is a **required** parameter on `asana_search_tasks`; `137249556945` is the DDG workspace GID (visible in any DDG Asana URL of the form `https://app.asana.com/1/137249556945/...`). Omitting it returns a validation error. `completed: false` is a **filter** that excludes resolved tasks at the API level - without it, completed feedback consumes pagination slots against the per-page `limit` and the 1000-task safety cap, and resolved issues can leak into the grouped output. The `completed` field also stays in `opt_fields` so the value is readable on each task as a sanity check. **Pagination loop (per project, per keyword query):** After each response, check whether the result count equals the request's `limit`. If so, there are likely more tasks to fetch. To get the next page, take the `created_at` timestamp of the **oldest** (last) task in the current batch and use it as the `created_at_before` filter for the next request, keeping `created_at_after` unchanged: ``` workspace: "137249556945" projects_any: created_at_after: created_at_before: completed: false text: custom_fields: sort_by: "created_at" sort_ascending: false limit: 100 opt_fields: ``` Repeat until: - A batch returns fewer than 100 (you have reached the end), **or** - You have fetched **1000 tasks per project per keyword** (10 pages) as a safety cap. macOS Feedback alone can return 400+ tasks in a 5-day window; a 14-day or 30-day query may approach this. If the cap is hit, note prominently in the output that results were truncated and the deep dive may be biased toward recent items. After all queries for a bucket complete, merge all tasks within the bucket and deduplicate by task GID. Each bucket is processed independently. ### 3. Read task details where needed For tasks whose names alone are not descriptive enough to classify, use `asana_get_task` to read the full description (`notes` or `html_notes` field). Only do this selectively to avoid excessive API calls - start by grouping on task names first. When calling `asana_get_task`, the data protection hook requires tag fields in `opt_fields`. Use: ``` opt_fields: "name,notes,html_notes,custom_fields,custom_fields.name,custom_fields.display_value,tags,tags.name" ``` ### 4. Group by distinct issue (per bucket) Analyse the task names (and descriptions where read) and cluster them into distinct issue groups. Use your judgement to identify common themes such as: - Same error message or symptom described in different words - Same feature area (e.g. "AI Chat", "VPN", "Sync", "Bookmarks", "Privacy Pro") - Same user action triggering the problem - Exact or near-duplicate reports For each group, choose a short, descriptive label (e.g. "AI Chat fails to respond", "Privacy Pro VPN disconnects on cellular"). Group the iOS feedback bucket separately from the iOS App Store Reviews bucket (and same for macOS). The two have different schemas and should be presented separately. **Handling high-volume long tails:** A single platform-bucket can return hundreds of tasks per week. Most cluster into a small number of named groups, but a long tail of one-off reports (specific website breakage, niche feature requests, generic praise/dissatisfaction) typically remains. When more than ~40 tasks remain unclustered after named groups are formed: - Roll them into a single trailing group called **"Miscellaneous / long-tail user feedback"** with a one-paragraph theme summary and a sample of links (cap the link list at ~50 entries; note "(...remaining N items truncated)" if there are more). - Do not include this group in the Top 3 deep dive. **Known low-signal clusters to call out as count-only groups:** - **Quit Time Survey submissions** (macOS) - tasks named "Via First Quit Time Survey", "Feedback submitted via quit time survey", or similar. These are auto-generated when a user closes the app and answers the survey without free-text. They can total ~70+ in a 5-day window. Group them as count-only, do not enumerate every link, and do not include in the Top 3 deep dive (they have no narrative to deep-dive into). - **Data Import failures** (macOS) - tasks whose body starts with `Import source: ` and `Error: DuckDuckGo_Privacy_Browser.` / `BrowserServicesKit.`. These are auto-generated by the importer on failure. Worth grouping by importer family (Chromium / Firefox / CSV / HTML Bookmarks / 1Password) since the failing module is itself the signal. Eligible for the Top 3 deep dive when volume warrants it. ### 5. Present the summary Output is structured per platform. If `platform = both`, render the iOS sections first, then the macOS sections. For each bucket, output a section per group with: - **Heading**: short descriptive label for the issue, with the count in parentheses (e.g. `### Privacy Pro VPN disconnects on cellular (8)`) - **Date range**: earliest and latest creation date in the group - **Links**: a bullet list of **5-10 representative tasks** by recency (not every task in the group). For groups with more than 10 tasks, list the most recent 5-10 and note "(...remaining N items, see Asana project view)". The full enumeration belongs in Asana's project filter, not the snapshot. Format each link as a clickable Asana link using the project GID the task came from and the task GID: `- [Task name](https://app.asana.com/0//)`. When a task appears in multiple projects of the bucket (rare due to dedup), link to the primary project. Do NOT include Asana user names or assignees in the task name - anonymise per data protection policy. - For the count-only noise clusters above (Quit Time Survey, etc.), skip the link list entirely and just show the count plus a one-line description. Sort groups by count descending (most-reported issues first). After all groups in a bucket, add a brief bucket summary: - Total feedback items in the window - Number of distinct issue groups identified - Top 3 issues by volume **Don't hand-type GIDs from memory.** A single mistyped digit breaks the link silently. The GIDs you need are already in the JSON tool-result text returned by `asana_search_tasks` (step 2) and `asana_get_task` (step 6). When you emit each `
    • `, transcribe the GID and name verbatim from those tool results - copy the digits, do not paraphrase or abbreviate. HTML-escape `&`, `<`, `>`, and `"` in the name; everything else (Unicode, emoji, punctuation, apostrophes) passes through. There is no scratch-file step here - the tool results are still in your context, so build the link list directly in the same `asana_update_task` call. ### 6. Top 3 deep dive (per platform feedback bucket) For the **3 highest-count actionable issue groups** in each platform's feedback bucket (not the App Store Reviews bucket - see below), perform a deeper analysis of the tasks' custom field metadata to surface environmental patterns. **Skip count-only noise clusters** (Quit Time Survey, miscellaneous long-tail) when picking the top 3 - even if they have the highest counts, they have no narrative to deep-dive into. Note in the bucket summary if the top-by-count group was skipped for this reason. If fewer than 3 actionable groups exist (or fewer remain after skipping noise clusters), do as many as you have - just one is fine. Drop the section entirely if there are zero. **Sample per cluster.** For iOS Feedback / macOS Feedback the bulk fetch in step 2 used slim `opt_fields`, so custom fields are not on the bucket-level records. Instead: 1. Pick **5-10 representative tasks** by recency from each Top-3 cluster. 2. Issue all sample fetches in parallel within the same message - they are independent. Use `asana_get_task` per task with: ``` opt_fields: "name,notes,custom_fields,custom_fields.name,custom_fields.display_value,tags,tags.name" ``` (`tags` and `tags.name` are required by the data protection hook.) 3. Build the deep-dive table from the sample. 4. Annotate "sampled N of M" in the table footer or Key takeaway, so the reader knows the metadata is not full-population. Bump from 5 to 10 if a cluster looks borderline (mixed signals across versions, sentiment, etc.). Other-bucket clusters (Privacy Pro, Internal Product Feedback) carry custom fields on the bulk fetch already - no sampling needed. Extract these fields from each sampled task (when present): - **Version** (app version, e.g. `7.216.0.3` on iOS, `1.187.0` on macOS) - **OS Version** (e.g. `iOS 26.4.2`, `macOS 15.6.0`) - **Sentiment** (e.g. `frustrated`, `disappointed`, `confused`) - **Dealbreaker** (True/False) - **Source** (where applicable) Present a breakdown table: | Factor | Finding | |--------|---------| | **OS** | Distribution across major OS versions, specific build numbers | | **App version** | Which app versions are affected - single regression or multi-version? | | **Sentiment** | Distribution of sentiment values across the reports | | **Symptom pattern** | Common recovery steps or trigger actions described across reports | | **Dealbreaker** | How many users flagged this as a dealbreaker | After the table, add a **Key takeaway** paragraph summarising: - Whether the issue is concentrated on a specific OS version or app version - Whether it appears to be a regression in a single release or a persistent issue - Any suggested investigation direction based on the pattern (e.g. "iOS 26.x regression", "Privacy Pro subscription state confusion") ### 7. Top 3 deep dive (per platform App Store Reviews bucket) App Store Reviews tasks have a different schema (Rating, Version, Store - no Sentiment, no Dealbreaker, no OS Version). For the **3 highest-count issue groups** in each platform's App Store Reviews bucket, present a smaller breakdown. Same fewer-than-3 fallback as step 6: do as many as you have. | Factor | Finding | |--------|---------| | **Rating** | Distribution of star ratings (1-5) across the reports | | **App version** | Which app versions are affected | | **Store / locale** | Which country stores the reviews came from (the country flag emoji in the task name is the locale signal) | | **Symptom pattern** | Common complaints or praise points across reports | Then a **Key takeaway** paragraph summarising the rating skew and any version or locale concentration. ### 8. Write report to Asana task (only if `asana_url` was provided) Skip this step entirely when `asana_url` is empty - the report has already been rendered inline by steps 5-7 and there is nothing more to do. When `asana_url` IS provided, the inline render is replaced by a write to the target task's description. Do not also dump the full report inline - end with a short confirmation line containing the task link. #### 8.1 Extract the task GID from the URL Asana URLs come in two shapes. The task GID is the trailing numeric segment in the old format, or the segment after `/task/` in the new format: | URL shape | Task GID | |-----------|----------| | `https://app.asana.com/0//` | last numeric segment | | `https://app.asana.com/0///f` | second-to-last segment | | `https://app.asana.com/1//project//task/` | segment after `/task/` | Strip any trailing `?` query string or `#` fragment before extracting. #### 8.2 Read the current task description Fetch the task with `asana_get_task` to inspect its existing description: ``` task_id: opt_fields: "name,notes,html_notes,tags,tags.name" ``` (`tags` and `tags.name` are required by the data protection hook.) #### 8.3 Warn before overwriting If `notes` is non-empty (treat whitespace-only as empty), the task description is already populated and writing the report will overwrite it. **Stop and ask the user to confirm before proceeding**, even in auto mode - this is a visible-to-others write that can destroy data. Show: - The task's `name`. - The first ~500 characters of the existing `notes`, plus `(...truncated, N more characters)` if longer. - An explicit prompt: "Overwrite this with the generated report? (yes/no)" If the user declines (or anything other than an explicit yes), output the report inline as if no `asana_url` had been provided and skip the write. Do not fall back to appending or to creating a comment - those weren't requested. If `notes` is empty, proceed without prompting. #### 8.4 Format the report as Asana HTML **REQUIRED SUB-SKILL:** Use the `asana-formatting:asana-formatting` skill to convert the markdown report into Asana-compatible HTML. Asana's `html_notes` field accepts a restricted subset of HTML and rejects standard tags like `

    `, `
    `, ``, ``, `

    ` with a 400 error. The MCP schema lists ``, ``, ``, ``, ``, ``, `
      `, `