Dayalogs

View saved version →

---
name: analyze-dayalogs-data
description: Prepare and analyze Dayalogs data through the Dayalogs MCP. Use for saved Analyses, frozen Sources, typed Recipes, recodes, derived variables, exclusions, weighting, multiple Results, segment comparisons, or analytical exports. Use response inspection for raw response counts and quality; use report authoring for report layouts and publication.
---

# Analyze Dayalogs Data

Turn an admitted Source into a reproducible Recipe and selected Result without changing collected answers.

## Establish the Source

1. Check the connected account's capabilities and available tools. If Analysis tools are unavailable, report the missing capability; do not simulate a Result or change connections.
2. Read `survey_authoring_help` at `reporting/workflow/help.md` and `reporting/analysis-projects/help.md`. Fetch `reporting/derived-variables/help.md`, `reporting/weighting/help.md`, or `reporting/data-explorer/help.md` only for the requested operation.
3. Identify the logical Survey, concrete version scope, complete/partial selection, fields and analysis unit. Inspect `get_survey_dataset_context` and existing Analyses before creating another one.
4. Reuse the current admitted shared Source when available. `get_survey_dataset` supplies the exact published `source_pin`; create an Analysis with `create_analysis_project` and a fresh UUID `request_id`. Select the returned `source_unit_id` deliberately for linked/repeated data. Respondents and repeated occurrences are different bases.
5. If no admitted Source exists, read `reporting/raw-datasets/help.md`. Preparation and capture do not grant acquisition. Show the exact frozen selection, price and expiry and obtain explicit approval before confirmation, even for zero-price admission. Continuous acquisition needs separate approval of its bounded terms; never infer it from a request to analyze or top up a wallet.

## Build and inspect the Recipe

1. Read `get_analysis_project` and its current draft revision. Save with `save_analysis_recipe`, the observed `expected_revision_id`, and a fresh request UUID. Use either the supported typed flow or the legacy recipe shape from current help, never a mixture.
2. Preserve field identifiers, codebooks, multiple-answer arrays, missing/unavailable states and source snapshots. Add explicit recodes, derived variables, exclusions and weights; never overwrite original answers or silently convert missing values to zero. Keep one weighting step per Result path.
3. Use `preview_analysis_project` for the exact saved revision and chosen terminal Result. Its first 20 source rows are a sample, not a full-population calculation.
4. Explain the proposed changes. Only after explicit approval, call `apply_analysis_project` with `confirm_apply=true`, the current expected revision and a fresh UUID. Continue `calculate_analysis_project` for that returned generation in bounded steps until complete. Preserve the previous published Result while a build is incomplete.
5. Select the exact published terminal Result, including when a Recipe has several outputs. Read rows with `get_analysis_result_rows`; use `explore_analysis_result` for full-Result distributions, summaries and comparisons. Keep the returned rows pin so subsequent reads use the same generation.

## Deliver the result

State the Source pin, Recipe revision, Result, unit, filters, weighted totals and unweighted bases. Distinguish observed differences from causal claims. Route analytical files through `reporting/exports/help.md`; use `get_analysis_project_reports` to obtain the exact `dataset_source` for a requested Report connection.

On a revision conflict, stop and reconcile the returned state; do not silently replace guards. Retry unknown mutation outcomes with the identical request id and payload. Source refresh, automatic feeding, Apply, Report publication, paid export and email delivery are separate actions. Never bypass an active continuous-process protection.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: analyze-dayalogs-results
description: Inspect, explain, and export collected Dayalogs survey responses through the Dayalogs MCP. Use for response counts, completed or partial attempts, selected answers, assessment scores, response confidence, version comparisons, campaign outcomes, or raw-response exports. For saved Analysis Recipes, derived variables, weighting and Results use analyze-dayalogs-data; for report layouts and delivery use create-dayalogs-report.
---

# Inspect Dayalogs Responses

Answer the user's analytical question with the right survey version, response population, and export format.

This workflow inspects collected responses. A persisted Analysis Result and a
published Report are different objects; use their dedicated skills when the user
requests transformations, weighting or report authoring.

## Workflow

1. Identify the stable survey and inspect its versions. Clarify whether the user wants all versions or a concrete version when results may differ materially.
2. Use `get_survey_stats` for the overview and `list_survey_responses` for response-level inspection. Retrieve individual responses only when needed.
3. Distinguish completed responses from partial attempts. Explain the population used in every count or percentage.
4. Use `get_survey_quality` for response confidence and quality signals. Compare versions when the user is evaluating a revised instrument or control questions.
5. For assessments, report points, maximum points, percentage, pass state, and item-level results according to the survey's configured result visibility.
6. Use campaign state and events when the question concerns delivery rather than survey answers. Keep delivery and engagement metrics distinct.
7. Choose an export based on the downstream task:
   - CSV/XLSX for human inspection and common tabular analysis.
   - SAV for SPSS workflows.
   - JSON/NDJSON for structured processing.
   - Include uploaded files only when requested and use the generated manifest to map files to responses.
8. Before a real export, call `export_survey_responses` with `preview=true`, show the user its exact population and cost, and wait for explicit approval. Then send both `confirm_export=true` and the unchanged `confirmation_token`. If the token is stale, show the refreshed preview and ask again; never approve it automatically.
9. State filters, version scope, response status, and missing-data treatment alongside the result or export.

## Interpretation Rules

- Confidence is a review signal, not proof that a respondent is human or truthful.
- A confidence score of 100 means no enabled signal fired; it is not identity verification.
- Disabled quality checks do not contribute to the global score even when their raw signals remain available.
- Do not combine versions silently when wording, logic, answer options, grading, or quotas changed.
- Treat unavailable click tracking as unavailable, never as zero engagement.
- Minimize personal data in summaries and only expose contact or link context relevant to the user's question.

## Safety

- Analysis and export do not imply permission to delete responses.
- Never call `delete_survey_response` without explicit confirmation naming the target response.
- Avoid reproducing access tokens, hidden link secrets, internal grading keys, or unnecessary contact identifiers.

## Completion

Give the answer first, followed by population, version scope, method, and caveats. For exports, name the format and what it contains, including whether partials and uploaded files were included.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: create-dayalogs-report
description: Create, revise, validate, preview, publish, and share Dayalogs Reports through the Dayalogs MCP. Use for reports built from an Analysis Result, charts, trends, comparisons, filters, themes, cover images, print layouts, share links, or report email delivery. Keep report authoring distinct from raw response inspection and Analysis Recipe changes.
---

# Create Dayalogs Reports

Build a Report over the selected Analysis Result, with consistent data, readable charts and deliberate delivery.

## Choose the data and draft

1. Check the account's capabilities and actual available tools. If Reporting tools are unavailable, explain the limitation rather than claiming that a Report was saved or published.
2. Read `survey_authoring_help` at `reporting/workflow/help.md` and the relevant topic under `reporting/`. Use `get_report_context` for the chosen Survey or Report and `get_report_schema` for the current definition contract.
3. Identify the intended audience, questions, population, unit and exact Analysis Result. Obtain its supported `dataset_source` from `get_analysis_project_reports`. Never guess a pin or substitute current raw Survey responses for an unavailable Result.
4. A definition-only draft may omit its data connection. Real-data preview, charts, totals, print and publication require an admitted, applied Result. If it is missing, use the Analysis workflow first; drafting does not authorize acquisition or Apply.
5. For an approved connection, use `connect_analysis_project_report` with the exact returned source and current Report revision when updating. Connecting a Result does not publish the Report.
6. Draft using field identifiers and typed choices from context. Keep fixed population selection distinct from allowed viewer filters. Specify measures, denominators, missing-value handling, comparisons and periods explicitly; multiple-answer percentages may exceed 100%.

## Validate and preview

1. Reuse the chosen theme, branding and owned gallery images. Read `reporting/themes/help.md` for reusable theme changes. Keep each concept's color consistent across charts, legends and periods; respect the author's palette.
2. Run `validate_report`, resolve errors, then `save_report_draft` with explicit create/update intent and the current `expected_revision_id` for updates. On conflict, reconcile deliberately; never retry by silently replacing the revision.
3. Give the returned preview URL. Inspect web and prepared print output when browser access is available, including cover contrast, chart labels, page breaks and filters. Otherwise state clearly that visual checking remains pending.
4. Explain the Result pin, filters, unit, unweighted bases and weighting. Keep interpretation supported by data. Generated written comments have their own availability and explicit request boundary; consult `reporting/dynamic-comments/help.md` only when needed. Audio narration is outside this workflow.

## Publish and deliver only when requested

- After explicit approval, `publish_report` targets the expected current revision. Publication, share-link creation and email sending are distinct steps.
- Use the share-link tools only for the requested scope and validity. Treat link URLs as access-bearing data. Unpublishing withdraws all access without deleting draft/history; individual revocation is permanent for that link.
- For email, first use `get_report_email_options` and `preview_report_email` for an existing published link. Show the selected sender, copy, unique eligible recipients, link scope and exact cost. Only after approval, call `send_report_email` with unchanged settings and the returned unexpired `preview_token`, `confirmed=true` and a unique `request_key` inside the `email` object. If the preview expires or changes, obtain a new approval.
- Retry an unknown send outcome with that same key and payload. Monitor the returned batch; transport acceptance is not confirmed receipt and opens remain estimates

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: create-dayalogs-survey
description: Create, revise, validate, and preview Dayalogs surveys through the Dayalogs MCP. Use when a user wants to turn requirements, questions, a questionnaire, or a research brief into a new survey or a deliberate new survey version. Covers targeted authoring help, validation, explicit create/update intent, optimistic concurrency, and preview-first review.
---

# Create A Dayalogs Survey

Build a valid survey without guessing the schema or silently changing an existing survey.

## Workflow

1. Establish the survey's purpose, audience, source language, question content, required logic, and intended delivery channel. Ask only for information that materially changes the design.
2. Call `survey_authoring_help` with an empty path only when topic discovery is needed. Then request the smallest relevant paths for the question types, logic, assessment, embed, or operational behavior being used.
3. Draft the survey from those current server-side contracts. Do not rely on remembered field names when targeted help is available.
4. Call `validate_survey`. Resolve every schema and semantic error before importing.
5. Determine import intent explicitly:
   - New survey: use `import_survey` with `mode=create`.
   - Existing survey revision: first read the survey, then use `mode=update` with the stable `survey_id` and observed current `version_id` as `expected_version_id`.
   - Never use a slug collision as an implicit update instruction.
6. If the server returns `version_conflict`, stop. Tell the user who changed the survey, when it changed, and the bounded change summary returned by Dayalogs. Reconcile deliberately and obtain a fresh version before retrying. Never auto-retry by merely replacing `expected_version_id`.
7. Use `get_preview_url` and give the user the preview, not a respondent collection link. Summarize important design choices and any assumptions that still need review.
8. Revise through focused patch/append tools when appropriate, preserving the same expected-version guard. Revalidate after material structural changes.
9. When the user requests branding, inspect the current account branding or Survey Design before updating it. Preserve reusable logos and header blocks, distinguish account defaults from Survey inherit/custom/disabled mode, and use the returned `expected_revision` guard. Branding changes do not publish a survey.

## Safety

- Keep the survey in draft until the user explicitly asks to start collection.
- Do not call `go_live_survey` without explicit publication confirmation.
- Do not create a real share link unless the user explicitly asks for one and confirms it when required.
- Treat destructive operations, response deletion, review decisions, sends, and irreversible state changes as separate user-approved work.
- Do not expose grading answer keys or hidden respondent logic in respondent-facing copy.

## Quality Bar

- Prefer the simplest question type that preserves the user's analytical intent.
- Keep mobile completion practical: concise labels, bounded option counts, and no unnecessary introductory steps.
- Ensure conditions refer to values available before they are evaluated.
- Keep randomized blocks free of internal dependencies and repeats unless current authoring help explicitly supports them.
- For embedded surveys, consult the embedded-survey authoring guidance and design for one focused interaction per step.

## Completion

Return the survey title, stable survey id, current version id, draft status, validation result, and preview URL. Mention unresolved assumptions plainly. Never imply that a preview is live collection.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: launch-dayalogs-fieldwork
description: Prepare, test, launch, and monitor Dayalogs survey fieldwork through the Dayalogs MCP. Use for hosted links, LinkSets, embeds, audiences, email campaigns, continuous surveys, file mappings, canonical row batches, quotas, collection dates, delivery tests, collection progress and attributable campaign conversion. Keep preparation, activation and real sending separate.
---

# Launch Dayalogs Fieldwork

Move a reviewed draft into the correct collection channel without accidental publication or sending.

## Choose The Channel

- Hosted link: one reusable entry point for anonymous or metadata-driven access.
- LinkSet: a managed set of individual links, often linked to audience contacts or intended for export to another delivery channel.
- Embed: a modal placement on an approved website origin, backed by an eligible reusable share link.
- Email campaign: a one-off send from a static contact LinkSet, or an explicitly selected continuous campaign with its own invitation list fed by files/external events. A continuous Report does not imply a continuous campaign.

Explain the choice if the user's request could reasonably use more than one channel.

## Workflow

1. Read the current survey and confirm it is the intended version. Preview it before any public action.
2. Check collection dates, quota behavior, link metadata, audience rules, and survey compatibility for the chosen channel.
3. For audiences, use repeatable imports and inspect import status. Do not treat a transport error as proof that a chunk failed; verify the persisted import state before retrying.
4. Create or configure the channel:
   - Use share-link and LinkSet tools for hosted access and personalized links.
   - Use embed compatibility and embed tools for website placements. Restrict origins deliberately.
   - Use campaign tools for email. Call `list_sender_identities` and pass the
     selected `sender_identity` key; never invent a From address. Preview the
     campaign and use `send_survey_campaign_test` before a real send when
     practical. For continuous campaigns, read `survey_authoring_help` path
     `operations/continuous-campaigns/help.md`, create a continuous draft, map the
     current input schema, and obtain explicit approval before activation or real
     invitation admission. Use the single trigger or `add_continuous_survey_campaign_batch`
     with already-mapped canonical rows; browser file mapping is a separate UI path.
5. Ask for explicit confirmation immediately before each public or outbound action: starting collection, creating a real link when guarded, sending a campaign, retrying failed recipients, or another irreversible operation.
6. Start collection only after confirmation. Do not infer approval from the user asking for a preview, link design, or campaign draft.
7. Monitor the resulting channel. Use campaign events and campaign state for queued, sent, delivered, delayed, bounced, complaint, and failed counts.

## Delivery Rules

- Permanent email delivery failures exclude contacts from Dayalogs email campaign queues, but not from LinkSets or link exports that may be delivered through SMS, messaging, or offline channels.
- Explain excluded-recipient counts when a campaign audience is smaller than its source segment.
- Do not expose provider names as user-facing delivery statuses.
- Do not claim click tracking is active when `tracking_available` is false. Report click totals as unavailable, not zero.
- One-off campaigns freeze their survey version when the first real recipients are queued. Continuous invitation attempts pin the applicable version at validated signed Start, not introduction display; importer compatibility guards can retain a previous renderable version. Tests and unsent previews are separate.
- Continuous `idEvent` is optional and literal. An existing ID returns the original invitation without mutation/resend even with changed input; an invalid attempt consumes nothing. Null/omit

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.