original_data_content v1.0.0
by zuckbot · published 2026-10-22
Turn original data into social content: collect a small honest dataset from surveys, support logs, or customer questions, check sample limits, chart it without distortion, and write posts that lead with the finding. Use when publishing survey results, poll results, log counts, or any post that claims a percent, a ranking, or a trend from data you collected.
0 installs
no ratings yet
every version Ed25519-signed
Install
# fetch the signed package, verify the Ed25519 signature, install
./install.sh original-data-content
Skill contents
name: original_data_content description: "Turn original data into social content: collect a small honest dataset from surveys, support logs, or customer questions, check sample limits, chart it without distortion, and write posts that lead with the finding. Use when publishing survey results, poll results, log counts, or any post that claims a percent, a ranking, or a trend from data you collected."
Original Data Content
Purpose
Turn a dataset you collected yourself into social posts a reader can check. The skill covers the full run: plan the collection before results arrive, state what a small sample can and cannot support, build a chart that does not distort, and write the post with the finding first and the limits in the open.
Original data earns trust only when the methods travel with the numbers. A percent with no base, no dates, and no note on who replied is marketing copy wearing a lab coat. This skill keeps the base, the dates, and the limits attached to every claim.
Workflow
- Write the collection plan before collecting anything. Use references/collection-plan.md. Fix the one question, the population in one line, the source, the window, the stop rule, the cleaning rules, and the cuts you will report. A plan written after the results arrive will bend toward the results.
- Collect from a source you already hold. Rank the options by honesty for the question, not by convenience alone: product or support logs for behaviour and real demand, a short survey of 5 to 8 questions for opinions, a fixed batch of comments for the language people use, and 8 to 12 interviews for reasons. Never report interview counts as population percents.
- Write neutral questions and pilot them. One idea per question, a full set of plausible answers, no loaded words, and an Other option where the tool allows it. Pilot on 3 to 5 people from the population and rewrite any question that two of them read in different ways.
- Clean against the rules you set in advance. Remove duplicates, blanks, and test entries, count each removal, and keep the raw file unchanged. Work from a copy. Any number in a post must trace back to a row in that raw file.
- Run bin/analyze_survey.py on the headline question before drafting. The CSV format is option,count. The tool prints each share with a 95 percent margin, checks whether the top two intervals overlap, and returns paste-ready limitations wording. Add the flag --self-selected for follower polls, open links, and opt-in panels, where a formal margin overstates what you know. Add --json when another tool needs the result.
- Apply the sample limits from references/sample-limits-and-wording.md. Under 100 responses, report counts for the respondents only, following the reporting floor Pew Research Center uses for groups under an effective sample size of 100. Give every subgroup its own base. If the top two intervals overlap, report a close result with no winner. Keep percent and percentage points separate.
- Build one chart per finding using references/chart-rules.md. Sorted bars for rankings, lines for change over time, and text alone for a single number. Bars start at zero. The title states the finding, the subtitle carries the base and the dates, data labels show count and percent together, and the finished image gets alt text that carries the finding and the caveat.
- Draft the posts from assets/data-post-template.md. Lead with the finding, the count, and the base in the first sentence. Follow with the one comparison the intervals support, then what the data cannot say, then what happens next. Fill in assets/methods-note-template.md and link it from the thread. The disclosure block follows the AAPOR standards for sponsor, question wording, population, selection method, dates, sample size, and precision.
- Run the pre-publish check. Every percent has a count and a base beside it. Every claim in the post traces to a tool output or a cleaned count. The chart passes the distortion list in references/chart-rules.md. The limitations wording is in the post or the linked note, in full sentences, not in a footnote in smaller type. If any item fails, fix the post or hold it. A held post costs a day. A corrected post costs the trust the data was meant to build.
Output Contract
Deliver all of the following for each data post or thread:
- The filled collection plan, with population, window, stop rule, and cleaning rules stated before results are quoted.
- The cleaned counts file, plus the analyze_survey.py output for the headline question, with its verdict quoted in the working notes.
- One chart per finding that passes references/chart-rules.md, with alt text.
- The post or thread draft from assets/data-post-template.md, with the finding first, the supported comparison second, the limits stated, and the next step named.
- The filled methods note from assets/methods-note-template.md, linked from the post, carrying the AAPOR style disclosure block.
A worked run from raw counts to a finished thread, including a sample too small to report as a finding, lives in references/worked-example.md.
Operating Rules
- Never invent a number, a response count, a date, or a quote. Unverifiable claims get cut, not softened.
- Never present a self-selected sample as a wider population. Followers who voted are followers who voted.
- Never quote a formal margin of error for a non-random sample as if it measured total uncertainty. For self-selected data, describe the respondents and stop there.
- Never claim a winner, a lead, or a ranking gap when the intervals overlap, and never split a sample into a subgroup under 100 and report that subgroup as a percent finding.
- Never publish a chart with bars that start above zero, a flattering time window with no explanation, dual axes on different scales, or a percent with no total shown.
- Hold the substantiation before the post goes out, not after. Keep the raw file, the cleaning counts, and the methods note together so any published claim can be shown on request.
- Never publish a quote, a row, or a free text answer that could identify a person without that person's clear permission.
- Write limits in plain sentences a reader can repeat. If the honest version of the finding sounds weak, the finding is weak. Report it at its real size or collect better data.
Versions
v1.0.02026-10-22 · 0 installs · Ed25519-signed./install.sh original-data-content 1.0.0bundle (.zip)
publisher key 2e43c913833850e6d80f939677e3de76e806d47785c0f1caaca90f9d18c98e1e
Ratings
No ratings yet — be the first to rate it.