← DayalogsCONTENT HISTORY

Update to Dayalogs

Snapshot Nov 12, 2026 · 12:08 UTC · version 2.0.0

Collection source: downloaded plugin package. These snapshots do not have a confirmed matching collection source. Differences in file lists alone do not establish changes to the package.

WHAT CHANGED

Instructions updated for analyze-dayalogs-results

Full description — Now says: collected Dayalogs survey responses through the Dayalogs MCP. Use for response counts, completed or partial attempts, selected answers, assessment scores,...

Observed in instructions or declared skills. Runtime behavior has not been tested.

Save Dayalogs and check future changes in Following.

Up to 3 plugins free · no card required.

All fields and original values.

Full description

Before

Sep 30, 2026 · 23:01 UTC

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-r...

After

Nov 12, 2026 · 12:08 UTC

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 expor...

Skill instructions

Before

Sep 30, 2026 · 23:01 UTC

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-r...

After

Nov 12, 2026 · 12:08 UTC

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 expor...

Supporting files

Before

Sep 30, 2026 · 23:01 UTC

[{"relative_path":"agents/openai.yaml","size_in_bytes":568}]

After

Nov 12, 2026 · 12:08 UTC

[{"relative_path":"agents/openai.yaml","size_in_bytes":570}]

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,12 +1,16 @@
 ---
 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.
+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.
 ---
 
-# Analyze Dayalogs Results
+# 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.
@@ -20,7 +24,8 @@
    - 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. State filters, version scope, response status, and missing-data treatment alongside the result or export.
+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
 
Full technical diff · 3 changed fields

changed /description

BEFORE
"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."
AFTER
"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."

changed /included_files

BEFORE
[
  {
    "relative_path": "agents/openai.yaml",
    "size_in_bytes": 568
  }
]
AFTER
[
  {
    "relative_path": "agents/openai.yaml",
    "size_in_bytes": 570
  }
]

changed /skill_md_contents

BEFORE
"---\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"
AFTER
"---\nname: analyze-dayalogs-results\ndescription: 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.\n---\n\n# Inspect Dayalogs Responses\n\nAnswer the user's analytical question with the right survey version, response population, and export format.\n\nThis workflow inspects collected responses. A persisted Analysis Result and a\npublished Report are different objects; use their dedicated skills when the user\nrequests transformations, weighting or report authoring.\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. 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.\n9. 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"
Full snapshot data
{
  "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.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 570
    }
  ],
  "name": "analyze-dayalogs-results",
  "skill_md_contents": "---\nname: analyze-dayalogs-results\ndescription: 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.\n---\n\n# Inspect Dayalogs Responses\n\nAnswer the user's analytical question with the right survey version, response population, and export format.\n\nThis workflow inspects collected responses. A persisted Analysis Result and a\npublished Report are different objects; use their dedicated skills when the user\nrequests transformations, weighting or report authoring.\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. 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.\n9. 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 of public snapshot: bae551610c34f6268d324a16ce969315a3f641232b1415740be641c4153cd372