traffic-review

Traffic Review

Conduct a traffic attribution analysis of articles published over a period of time, and produce an analysis/*.md.

Step 0: Load configuration (mandatory)

Before starting the analysis, use Read to load in order:

.claude/skills/traffic-review/framework.md: analysis framework (four pillars of high traffic, low-traffic failure modes, scoring criteria)
.claude/skills/traffic-review/output-template.md: output file structure

Treat these two documents as a hard framework.

Step 1: Determine the scope

From $ARGUMENTS parse the time range or article numbers
If $ARGUMENTS is empty, by default take the most recent 5-7 articles in the README that have traffic data (skip —）
future dates are not accepted

Step 1.5: Must read pending-notes first (if it exists)

ls analysis/pending-notes-*.md Check whether there is a temporary observation file
If there is one, you must Read it once. pending-notes often records key facts that can only be observed at the time: first-hour real-time data, throttling signals, external repost chains, platform anomalies. These facts are no longer available a week later
If pending-notes specifies "weekend review points", absorb them verbatim into the formal review file
After writing the formal review and verifying it is correct, when Step 7 is completealso rm the pending-notes file(the "traffic observation workflow" in CLAUDE.md already specifies: delete pending-notes after the review is complete)
This step was missed once (when writing the 5/4-5/8 review on 2026-05-15, pending-notes was not read, missing the key fact of the 5/6 X throttling, and the review mistakenly attributed the account momentum problem to a topic problem). Since then this step has been strictly mandatory

Step 2: Fetch data

Use Read to read README.md, locate the Articles table
Extract for articles that fall within the scope:#, date, title, file path, X traffic
Keep at least 3 articles, otherwise remind the user that the sample is too small

Step 3: Read the article openings

For each article:

Use Read to read the first 30-40 lines of the file (opening + start of the first section)
Record the opening'sframework: whether it is current-situation entry / story entry / identity call / number entry / menu-listing
Record whether the opening gives an anchor for "this concerns you"

Only read the opening, not the full text. The purpose is to judgethe reader's 10-second judgment, not content depth.

Step 4: Score according to framework.md

Score each article according to the "four pillars of high traffic" in framework.md (each 0/1):

Reader identity locked in one second
Diagnosis + self-rescue structure
Concrete numbers + contrast
Clear emotional hook

At the same time mark whether any item in the "low-traffic failure modes" was hit (suspenseful title, posted on weekend, protagonist too distant, audience too narrow, opening buildup too long, etc.).

Step 5: Find patterns, do not force-fit

Sort the articles by traffic, compare the high group vs the low group
Findwhat the high group has and the low group does notcommon patterns (positive rules)
identify thepitfalls the low group fell into that the high group avoided(negative rules)
If the sample is ≥5 posts, look at the relationship between day of week vs traffic, but clearly note that the sample is insufficient and this is for reference only
Don't treat a single coincidence as a rule: it must be corroborated by at least 2 posts before being written into the positive rules

Step 6: Generate recommendations

Two columns:

Do more of: large audience base, emotional hooks, actionable guides, counterintuitive numbers, platform meta-topics
Avoid: the specific pitfalls hit + failure patterns observed this week

Then give onesingle highest-leverage action: in this batch of data, if you could change only one thing, what should it be. Must be concrete and executable.

Step 7: Output

Write into the structure of output-template.md :

Path:analysis/YYYY-MM-DD 至 MM-DD N篇流量复盘.md(ISO date for easy sorting)
Body entirely in Chinese, paragraphs of 2-4 sentences
No em dashes (——)
No high-frequency AI words (crucial, of great significance, marks, witness, rooted in, etc.)
The negative parallel construction "it's not X, it's Y" at most 1 time
Number readability: keep 3.8k as is, keep percentages as is, write ten-thousands as "2000 万" rather than 20,000,000

After writing the formal retrospective + passing the self-check, immediately rm analysis/pending-notes-*.md clean up the temporary files. This is a hard rule in CLAUDE.md's "traffic observation workflow"; don't leave temporary observations in the repo.

After finishing, return to the user: file path, number of sample articles, highest traffic/lowest traffic, one most critical insight.

Step 8: Next week's plan (if the user requests it)

Important convention: write next week's plan and the traffic forecast into the same retrospective file; don't start a new file.

If the user asks to "write next week's plan" or "forecast next week's traffic" after the retrospective, append at the end of the current retrospective file:

Level-1 heading # 下周计划（M/D-M/D） as section separator
Subsections continue the retrospective's Chinese-numeral numbering (start next week's plan at whatever number the retrospective ended at + 1)
Subsections must include: publishing strategy + schedule, per-post forecasts (with method explanation), risk points, retrospective timing
Forecast method per the .claude/skills/traffic-review/framework.md four pillars + historical comp + time correction
Don't write "hard targets"; only give ranges, medians, observation points, next-cycle retrospective questions

The same md file contains both the retrospective (past) and the plan (future). The next retrospective starts a new file and cites the previous plan at the beginning for forecast-deviation comparison.

Rule appending

If, after reading the retrospective, the user points out "this rule is actually wrong" or "there's another rule I've never noticed", append to framework.md the corresponding section; don't modify SKILL.md or historical content.