Dnnecessary/skills

Author Content Methodology Analysis

Input Contract

The caller must provide:

• input_dir or a clear list of files/document content
• output_dir
• Author or account name
• Optional article list, preferably including title, link, and publication date
• generate_html: default true
• sync_lark: default true

If input is insufficient, it will first search for discoverable content within the workspace; only ask the user for sample body text if none is found. Must not analyze based solely on titles.

Supported formats and processing boundaries:

• Markdown/TXT: Use built-in parser.
• DOCX: Prefer python-docx; explicitly error if unavailable.
• Extractable text PDF: Prefer pypdf; scanned PDFs without text require OCR and must not fabricate body text.
• Feishu docs: First read via the current lark-doc skill, then treat the body as input.
• When multiple formats are mixed, unify into article records but preserve original file paths and source types.

Output Contract

Always write to the caller's provided output_dir:

<output_dir>/
  <blogger>-methodology-report.md
  <blogger>-copywriting-framework.md
  <blogger>-analysis-data.json
  <blogger>-article-features.csv
  <blogger>-methodology-dashboard.html              # Default generated learner-perspective dashboard
  <blogger>-feishu-sync.json                        # Generated upon successful sync
  <blogger>-competitor-title-samples.json            # Generated when competitor samples are provided

All root-level artifacts are uniformly named using the pattern "<blogger>-<function>.<extension>". <blogger>-analysis-data.json and <blogger>-article-features.csv are auditable deliverables, not temporary files. Reports, HTML, and Feishu content must use the same analysis data. Only skip generation or sync when the user explicitly requests "do not generate HTML" or "do not sync to Feishu".

This skill generates its own copywriting framework using references/copywriting-framework-template.md and does not rely on an external skill named creator-copywriting-framework.

Workflow

1. Build Sample List

• Run the deterministic analysis script:

  python3 scripts/analyze_corpus.py \
    --input "<input_dir>" \
    --output "<output_dir>"
  

• The script handles format parsing, deduplication, image reference preservation, basic statistics, and article-level features.

• With fewer than 5 articles, only perform descriptive analysis and explicitly note low stability; with fewer than 3 articles, do not output trends, evolution, or stable style conclusions.

• With more than 50 articles, prioritize full basic statistics; sample only if context or processing cost is clearly too high, and disclose the sampling method.

2. Preprocess Body Text

• Remove noise such as navigation, ads, and copyright footnotes.
• Remove image Markdown from the plain text analysis copy, but retain the original positions, relative paths, and adjacent text in article records for visual analysis.
• Preserve heading hierarchy, lists, quotes, cases, data, and conclusion sections.
• Distinguish original excerpts from model summarizations; retain the mapping of evidence to article titles.

3. Detailed Data Analysis

First read <blogger>-analysis-data.json and <blogger>-article-features.csv, then complete the interpretative analysis according to references/data-analysis-framework.md. Deterministic indicators must not be re-estimated by the model. Default coverage includes:

• Sample quality and data completeness
• Publishing frequency, periodicity, continuity, and temporal distribution
• Length, paragraphs, sentences, images, and structural complexity
• Distribution of themes, motifs, objects, scenarios, problems, and content types
• Keywords, terms, concept combinations, and semantic associations
• Headline length, hooks, sentence structures, objects, promises, and headline-body consistency
• Openings, body, transitions, conclusions, CTAs, and common narrative paths
• Argumentation units such as opinions, facts, causality, comparisons, counterexamples, boundaries, and suggestions
• Evidence types: data, citations, experiments, cases, authoritative sources, and experience
• Entity networks: people, companies, products, technologies, events, industries, locations, and models
• Strength of judgment, certainty, time scales, risk attitudes, and value orientations
• Vocabulary, sentence length, rhythm, rhetorical devices, colloquialism, technicality, and readability
• Target readers, usage scenarios, pain points, content promises, and reader benefits
• In-body action prompts (comments, downloading materials, purchases) – observed only as writing structure
• Image density, image-text positioning, and visual content role (when data available)
• Evolution of themes, expression, and judgment over time (when publication dates available)
• Cross-relationships between themes and headlines, structure, evidence, length, CTA, etc.
• Anomalous samples, content gaps, over-concentration, and series opportunities
• Do not analyze platform-level metrics (reads, shares, likes, bookmarks, follows, or conversions)
• Headline method breakdown: overall statistics on numbers in headlines, suspense questions, pain points, timeliness, clear benefits; representative headlines explained with formulas, reasons, imitation methods, and applicability conditions
• Article structure demonstration: explain rhythm with opening tasks, middle tasks, and closing tasks, and provide executable exercises for learners
• How to learn publishing rhythm: observe the author's content supply pattern using publication days, day-of-week distribution, multiple articles per day, and intervals between articles; then design a sustainable rhythm based on the learner's time, evidence accumulation speed, and creative stage
• Competitor topic radar: publicly search for competitor headlines, recording source links, topic types, and sample boundaries

Data and representative samples are used only to explain the author's methods. The dashboard must not be written as a scoring, self-check, pass/fail, or improvement report for the author. Platform backend performance metrics must not enter the dashboard. Other non-computable content must not be estimated or fabricated. Word frequency cannot be directly equated to author attitude; subjective labels such as theme, quotes, emotion, and stance must include classification rules and evidence.

The default output adopts a learner's perspective, not just evaluating the blogger. Each core module must explain:

• Exactly what this blogger does;
• Why this method is effective;
• Which abilities are worth learning;
• What exercises the learner can execute;
• Which aspects depend on personal experience, resources, or platform conditions and cannot be directly copied;
• How to judge if the method has been internalized as a personal skill, rather than just imitating surface style.

Subjective labels need to be written into the annotations of <blogger>-analysis-data.json, each containing:

dimension,label,article_ids,evidence,rule,confidence

This ensures that conclusions about themes, stance, readers, and quotes in the report are traceable back to specific articles.

4. Extract Methodology

The main report uses references/report-template.md. Data sections reference indicators and article IDs from <blogger>-analysis-data.json and do not create a second set of numbers; methodology sections explain the data facts and must include at least:

The "Sample Description" section of the report must include dataset_sha256 for consistency verification.

1. Author Positioning & Content Persona
2. Reader Persona & Content Benefits
3. Content Asset Map
4. Topic System
5. Analytical Framework
6. Judgment Criteria
7. Expression Templates
8. Case Library
9. Quote Style
10. Content Gaps & Topic Opportunities
11. Reusable Writing SOP
12. Risks & Boundaries
13. Sample List

For each key conclusion, try to cite 2-5 article titles, short excerpts, or cases. Keep original excerpts necessary and brief; abstract templates must be marked as "Abstract Template", and structured examples must be marked as "Not Original Author Text".

5. Generate Standalone Copywriting Framework

Generate <blogger>-copywriting-framework.md using references/copywriting-framework-template.md. The template defines the structure but does not preset any author-specific phrasing; all formulas must be derived from sample evidence, including:

• Topic scaffolding
• 8-15 headline formulas
• Multiple opening templates
• At least 3 body structures
• Paragraph sentence patterns and transition sentences
• Quote sentence pattern generator
• Closing CTAs
• 1-2 structured examples (switching themes, cases, wording)
• Pre-publication checklist and forbidden boundaries

Only learn the structure; do not replicate the author's unique expressions or impersonate the author.

6. Auto-generate HTML

The HTML dashboard is a standard deliverable of this skill, not an optional chat attachment. When generating, it must read references/interactive-dashboard-template.md and directly use the built-in scripts/generate_dashboard.py of this skill; do not substitute a different general-purpose BI template.

Default command:

python3 scripts/generate_dashboard.py \
  --data "<output_dir>/<blogger>-analysis-data.json" \
  --output "<output_dir>/<blogger>-methodology-dashboard.html"

HTML and Markdown must share the deterministic statistics from <blogger>-analysis-data.json. Model-generated methodology summaries can be written back to annotations as supplementary data but must not overwrite script-computed fields.

The dashboard must maintain the following fixed structure:

1. Overview at a Glance
2. Positioning & Value
3. Content Map
4. Topic Methods
5. Article Writing
6. Opinions & Evidence
7. Language Style
8. What to Learn
9. Growth & Operations
10. Learning & Transfer

All sections are from the learner's perspective, focusing on answering "What should I learn and how should I learn it?" and must not revert to author self-checks, article scoring, or platform performance analysis. The footer should only contain a brief source note and disclaimer; do not include a standalone "Data & Boundaries" section.

After generation, check the browser console, main interactions, and visual readability.

Skip HTML generation only when the user explicitly requests not to, i.e., generate_html=false.

7. Auto-sync to Feishu

First check source boundaries:

• If all samples are from public URLs or public article archives: default to sync.
• If samples come from local interviews, internal documents, private Feishu docs, or sensitive scans trigger a match: pause auto-upload and ask for user confirmation.

After confirming sync is allowed, load lark-doc:

1. First complete the local Markdown.
2. If <blogger>-feishu-sync.json already contains an accessible doc_token, update that document; otherwise create a new document.
3. Write and verify according to the current lark-doc skill's API specification.
4. Write doc_token, URL, title, content fingerprint, and update time into <blogger>-feishu-sync.json.
5. After verifying key chapters exist, return the URL.

Failure to sync to Feishu must not affect the completion status of local files.

Skip Feishu sync only when the user explicitly requests not to, i.e., sync_lark=false.

Quality Thresholds

• <blogger>-analysis-data.json and <blogger>-article-features.csv must be generated by scripts.

• Conclusions are based on body text and disclose sample boundaries.

• Observable statistics must be clearly distinguished from subjective summarizations.

• Data analysis should cover all computable dimensions where possible, and clearly mark unavailable fields.

• Every significant statistic must explain its measurement definition, denominator, classification rules, or calculation method.

• Each data module must link to representative articles and methodological inspiration.

• Every core module must have evidence and reusable actions.

• If cases are insufficient, explicitly state "No stable case library formed."

• Do not infer author intent that cannot be supported by the sample.

• All local output paths must be within output_dir.

• HTML and Feishu sync are completed by default; if the user explicitly opts out, record the skip reason.

• HTML navigation must consist of ten fixed sections, and the footer must include source notes and a disclaimer.

• HTML must not contain a standalone "Data & Boundaries" section, nor modules that evaluate the author (e.g., self-checks, scoring, pass/fail).

• Final validation run:

  python3 scripts/validate_outputs.py "<output_dir>"
  

References

• references/report-template.md: Read when generating the main report.
• references/data-analysis-framework.md: Read when performing detailed data analysis.
• references/copywriting-framework-template.md: Read when generating the standalone copywriting framework.
• references/interactive-dashboard-template.md: Read when generating the default HTML dashboard.
• references/analysis-data.schema.json: Shared analysis data structure.
• scripts/analyze_corpus.py: Parses corpus and generates deterministic feature data.
• scripts/generate_dashboard.py: Generates offline HTML from shared data source.
• scripts/validate_outputs.py: Validates consistency of data, reports, HTML, and sync metadata.