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.
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.
Up to 3 plugins free · no card required.
All fields and original values.
Full description
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...
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
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...
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
Sep 30, 2026 · 23:01 UTC
[{"relative_path":"agents/openai.yaml","size_in_bytes":568}]
Nov 12, 2026 · 12:08 UTC
[{"relative_path":"agents/openai.yaml","size_in_bytes":570}]
Compare saved observations
Download comparison JSONSKILL.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
"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."
"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
[
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 568
}
][
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 570
}
]changed /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"
"---\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