← DayalogsCONTENT HISTORY

Update to Dayalogs

Snapshot Sep 30, 2026 · 23:01 UTC · version 1.1.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "name": "analyze-dayalogs-results",
  "description": "Inspect, explain, and export Dayalogs survey results through the Dayalogs MCP. Use when a user asks about response counts, completed or partial responses, selected answers, assessment scores, response confidence, version comparisons, campaign outcomes, or analysis-ready exports.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 568
    }
  ],
  "skill_md_contents": "---\nname: analyze-dayalogs-results\ndescription: Inspect, explain, and export Dayalogs survey results through the Dayalogs MCP. Use when a user asks about response counts, completed or partial responses, selected answers, assessment scores, response confidence, version comparisons, campaign outcomes, or analysis-ready exports.\n---\n\n# Analyze Dayalogs Results\n\nAnswer the user's analytical question with the right survey version, response population, and export format.\n\n## Workflow\n\n1. Identify the stable survey and inspect its versions. Clarify whether the user wants all versions or a concrete version when results may differ materially.\n2. Use `get_survey_stats` for the overview and `list_survey_responses` for response-level inspection. Retrieve individual responses only when needed.\n3. Distinguish completed responses from partial attempts. Explain the population used in every count or percentage.\n4. Use `get_survey_quality` for response confidence and quality signals. Compare versions when the user is evaluating a revised instrument or control questions.\n5. For assessments, report points, maximum points, percentage, pass state, and item-level results according to the survey's configured result visibility.\n6. Use campaign state and events when the question concerns delivery rather than survey answers. Keep delivery and engagement metrics distinct.\n7. Choose an export based on the downstream task:\n   - CSV/XLSX for human inspection and common tabular analysis.\n   - SAV for SPSS workflows.\n   - JSON/NDJSON for structured processing.\n   - Include uploaded files only when requested and use the generated manifest to map files to responses.\n8. State filters, version scope, response status, and missing-data treatment alongside the result or export.\n\n## Interpretation Rules\n\n- Confidence is a review signal, not proof that a respondent is human or truthful.\n- A confidence score of 100 means no enabled signal fired; it is not identity verification.\n- Disabled quality checks do not contribute to the global score even when their raw signals remain available.\n- Do not combine versions silently when wording, logic, answer options, grading, or quotas changed.\n- Treat unavailable click tracking as unavailable, never as zero engagement.\n- Minimize personal data in summaries and only expose contact or link context relevant to the user's question.\n\n## Safety\n\n- Analysis and export do not imply permission to delete responses.\n- Never call `delete_survey_response` without explicit confirmation naming the target response.\n- Avoid reproducing access tokens, hidden link secrets, internal grading keys, or unnecessary contact identifiers.\n\n## Completion\n\nGive 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.\n"
}

SHA-256: f359c02b503e1ac31f1c5de98ab73d237d8f0f3cb37ad9309c7a61d23d98287d