SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillstech-article-creator

tech-article-creator

Writing & research

View repository

Updated 10-16 08:35

About this skill

Full-Process Technical Article Creation

A production pipeline from topic selection to publishing. Each stage has clear inputs, outputs, and quality gates. Supports entering from any stage.

Configuration

This skill manages all configurable items through config.yaml . Configuration file location:

  • Template file：{skill_dir}/config.yaml(under this skill's directory, containing complete comments and default values)
  • Runtime configuration：{root_dir}/.tech-article-creator.yaml(the actual configuration under the article root directory)

Configuration Loading Flow

On each startup:

  1. Check whether {root_dir}/.tech-article-creator.yaml exists
  2. Exists → read directly, enter the corresponding stage
  3. Does not exist → enter first-time configuration guidance

First-Time Configuration Guidance

Copy one from the template file to the runtime path, then guide the user through filling in the core configuration interactively. Each configuration item provides default options, and the user can directly accept the default values.

[Interaction] AskUserQuestion: confirm the following core configurations in sequence (only one at a time):

  1. Article root directory: infer candidate paths from the working directory, let the user confirm or specify
    • Default: current working directory
  2. Version strategy: single version / dual version / custom
    • Default: dual version (technical depth version + accessible story version)
  3. External review: whether to enable external model review; if enabled, confirm the available models
    • Default: not enabled (only use Agent Team internal review)
  4. Publishing platforms: local only / blog / WeChat Official Account / social media (multiple selections allowed)
    • Default: local only (only generate markdown files)

After the user confirms, write the selections to {root_dir}/.tech-article-creator.yaml. Subsequent uses read directly without asking again. The user can manually edit this file at any time to adjust the configuration.

Directory Structure

Generate according to the template in config.yaml :

{root_dir}/
├── {topics_dir}/                     # 选题文件
├── {compliance.rules_file}           # 平台合规规范（如配置）
├── {article_dir}/                    # 单篇文章目录（按模板生成）
│   ├── 大纲.md                       # 含版本标注
│   ├── 原始素材/                      # 素材 + 评审意见
│   ├── {image.output_dir}/           # 配图（如启用）
│   ├── {variant.file_prefix}{标题}.md # 每个版本一个文件
│   └── *.html                        # 排版产物（如需要）

Stage Overview

# Stage Output Gate Condition Advance Method
1 Topic selection Topic recommendations (with priorities) User selection Always Wait for user selection
2 Outline Outline.md + article directory Version annotations complete Always Auto-advance→3
3 Material collection Raw materials/*.md Covers all outline chapters Always Auto-advance→4
4 Outline review Review comments → updated outline Outline finalized after adoption review.models non-empty Auto-advance → 5
5 Writing + internal review Articles of each version (review passed) Agent Team iteration passed Always Auto-advance → 5.5
5.5 Title finalization Final titles of each version User selected Always Wait for user selection
6 External final draft review External review passed Multiple rounds of iteration passed review.models non-empty Auto-advance → 7
7 Manual final review User confirms final draft User approve Always Wait for user confirmation
8 Illustrations Cover image + diagrams Images complete image.enabled Auto-advance → 9
9 Layout/Publishing Artifacts for each platform Publishing complete publish.platforms non-empty Complete

Advancement rules

  • Auto-advance: After a stage completes, proceed directly to the next stage without waiting for the user to say "continue"
  • Wait for user selection/confirmation: Stop and wait for the user only at stage 1 (topic selection), 5.5 (title), and 7 (manual final review)
  • All interactions must use AskUserQuestion options: Provide options for the user to choose from; do not make the user type a description. If free input is truly needed, add a "custom" option among the options

Stage 1: Topic selection

  1. Scan existing articles: Read existing article directories under the root directory and extract the series thread
  2. Collect hot topic sources: WebSearch to query recent tech hot topics
  3. Cross-analysis: Existing articles × hot topics → series gaps / hot topic positioning / long-tail value
  4. Output 3-5 topics: Each includes title, hot topic basis, connection relationship, core content
  5. Saveto {topics_dir}/week{N}-{日期}.md

[Interaction] AskUserQuestion (options): Display the 3-5 topics as options for the user to choose one. Options include the title and a one-sentence core content. The user may choose "custom topic" to enter their own idea. After confirmation, determine the article number (if enabled) and title.

Stage 2: Outline

  1. According to config.yaml in article_dir_template create the article directory (including 原始素材/）
  2. Write outline.md: meta information + structure of each chapter + each section marked with version attribution + material list + illustration list

Core differences across versions—must be planned at the outline stage. According to config.yaml in variants definition, plan differentiated content for each version.

For detailed writing specifications, see references/dual-version-writing-guide.md。

Stage 3: Material collection (auto-advance)

This stage executes automatically without waiting for user confirmation. Start material collection directly after the outline is completed.

Launchparallel subagents to collect by topic division (if the runtime does not support subagents, execute serially), typical groupings:

  • Personal practical material (real cases, configurations, workflows)
  • Tool/technology material (features, comparisons, configuration methods)
  • Industry trend material (hot news, pricing, papers)

Each subagent produces 原始素材/{分类}素材.md, including original content and source citations. After collection, check: whether every outline chapter has material support.

After material collection is complete, output a coverage table (chapter × material source), thenautomatically proceed to Phase 4。

For the detailed guide, see references/material-collection-guide.md。

Phase 4: Outline review (automatic progression)

Only executed when config.yaml has a review model configured in review.models . If not configured, skip this phase and go directly to Phase 5. This phase executes automatically. After material collection is complete, initiate the review directly.

Send theoutline + all material file pathsto the configured review model. Do not send summaries—let the review model read the complete files.

Each review model focuses on different dimensions according to its configured role . Review results are saved to 原始素材/评审意见-{模型名}.md。

Review feedback handling rules (automatic adoption + display):

  • High severity: automatically adopt and update the outline, show the modifications to the user
  • Medium severity: automatically adopt and update the outline, show the modifications to the user
  • Low severity: show to the user but do not automatically adopt (may be ignored)
  • Summarize review findings (table + severity + adoption status), and after showing them to the user,automatically proceed to Phase 5
  • If there are controversial issues (conflicting opinions among review models), use AskUserQuestion（options） to let the user choose which side to adopt

Rate limiting handling: when rate limited, use AskUserQuestion（options） to let the user choose "wait and retry / downgrade model / skip review".

For detailed templates, see references/review-prompt-templates.md。

Phase 5: Writing + internal review (Agent Team, automatic progression)

This phase executes automatically. After outline review is complete, directly start the writing team; after internal review iterations pass, automatically proceed to Phase 5.5.

This is the core phase, using Agent Team to implement parallel writing and multiple rounds of iterative review.

If writing_team.parallel is false or the runtime does not support subagents, switch to serial mode: complete the writing and review of each version in sequence.

Team composition

Dynamically form based on config.yaml the variants and writing_team.reviewers in:

  • Assign each variant a writer
  • Assign writing_team.reviewers according to the reviewer

Execution flow

  1. Create Team, set task dependencies: review tasks blocked by writing tasks
  2. Writers write in parallel: each writer reads the outline (note version annotations) and materials
  3. Supplementary specifications: if compliance.rules_fileis configured, send to the relevant writers and reviewers
  4. First draft complete → reviewer starts reviewing
  5. Iteration loop：
    • reviewer reads the article, outputs review feedback (issue list + severity), sends to the corresponding writer
    • writer notifies reviewer to review again after modification
    • Iterate until all reviewers consider it passed(no high/medium severity issues)
  6. Team disbandment: after all tasks are completed, shut down all teammates

Writer Prompt key points

  • Must finish reading the outline and all materials before starting to write
  • According to the config.yaml for that variant in style、word_count、target_audience writing
  • No AI flavor ("it is worth noting", excessive parallelism, empty connectives)
  • Case anonymization: follow compliance.redaction_strategy

Reviewer Prompt key points

Review according to the writing_team.reviewers configured in focus . General review dimensions include:

  • Factual accuracy, data caliber consistency
  • Code executability (technical version)
  • AI trace detection
  • Whether differentiation between versions is sufficient (not simple deletion)
  • Readability, paragraph length adapted to target readers
  • Compliance check (if there is a compliance configuration)

For detailed writing templates see references/dual-version-writing-guide.md。

Phase 5.5: Title finalization

After the Agent Team internal review passes and before the external final draft review, determine the final title of each version.

Process

  1. Based on the final draft content of each version, generate 4-5 title candidates for each version
  2. [Interaction] AskUserQuestion (options): one separate question for each version, with title candidates displayed as options (including preview to preview the title effect). Users can select "custom title" to enter their own
  3. After the user selects, update the file title and file name

Title rules

Generate titles based on version characteristics. For reference formulas see references/dual-version-writing-guide.md。

Phase 6: External final draft review (automatic progression)

Only executed when the config.yaml in review.models has a review model configured. If not configured, skip this phase. This phase executes automatically. After title finalization, directly initiate external review, and after the review passes, automatically enter Phase 7.

Process

  1. Send the final draft file paths of each version to the configured review model (in parallel where possible)
  2. The review dimensions are similar to Phase 4, but target the complete body text rather than the outline
  3. After receiving review comments, revise the article
  4. Multi-round iteration: after revision, attach a list of "revised items" before sending for review again, to help the reviewer focus on the changed points
  5. Iterate until all models output "final draft review passed"
  6. Notify the user to proceed to manual final review

Common issue types (ordered by historical experience)

  1. Inconsistent data caliber: different versions cite the same data but express it differently
  2. Incorrect configuration steps: the description does not match the actual operation
  3. Imprecise product naming: inaccurate abbreviations or version numbers
  4. Missing source attribution: data is cited but no source is given
  5. Screenshot placeholders not handled：（截图：...）Should be replaced with actual images or changed to HTML comments

Rate limit handling

Same as Phase 4: when rate limited, the user decides; no automatic degradation.

Phase 7: Manual final review

After the external review passes (or after the internal review passes when the external review is skipped), notify the user to conduct the final manual review.

[Interaction] AskUserQuestion (options): Notify the user that the final draft is ready, and provide options:

  • "Approve, proceed to the next step" (continue with illustrations/publishing)
  • "Have revision feedback" (the user enters specific feedback in Other)
  • "Need to review further, will reply later" (pause the process)

At the same time, list common points of concern in the question description for reference: title, substance density, balance of tool recommendations, and promotional content.

After the user selects "Approve", automatically proceed to illustrations/layout/publishing.

Stage 8: Illustrations

Only executed when the config.yaml of image.enabled is true. If not enabled, skip.

[Interaction] AskUserQuestion (options, multiSelect): Based on the illustration list in the outline, list the suggested illustrations as multi-select options, and the user checks the ones to generate. Example options: "Cover image (auto-generated)", "Architecture/flowchart (auto-generated)", "Tool screenshot (must be provided manually)".

Illustration categories

Generated according to the config.yaml configuration in image.types . Use the image generation tool specified by image.skill .

Illustration specifications

  • For diagram text, it is recommended to use the article's language (e.g., use Chinese labels for Chinese articles), while keeping proper nouns in English
  • The cover image should have a concise title (a 2-4 character keyword)
  • Store images uniformly in the {image.output_dir}/ directory
  • Screenshot-type materials must be provided manually by the user and cannot be AI-generated

Stage 9: Layout / Publishing

Only executed when the config.yaml of publish.platforms is non-empty. If not configured, the article is completed as local markdown.

[Interaction] AskUserQuestion (options, multiSelect): Based on the publish.platforms configuration, list the publishable platforms as multi-select options, and the user checks the ones to publish to this time. All are selected by default.

According to the publish.platforms configuration, call the corresponding publishing skill:

Platform Configuration field Output
Blog publish.blog.skill Publish to publish.blog.url
WeChat Official Account publish.wechat.converter_skill + publisher_skill Convert to HTML first, then publish to the drafts box
Social media publish.x.skill Post (optional)

Confirm before publishing to each platform, and verify after publishing.

Security and compliance

Three principles for sensitive data

During cross-model review: minimum disclosure, desensitize before sending, and ensure auditability and rollback capability.

When the article involves a real project: desensitize according to compliance.redaction_strategy , and publish only after the user confirms the degree of desensitization.

Platform compliance

If compliance.rules_fileis configured, the following stages will automatically load that specification:

  • Stage 5 Writing: writer and content-reviewer comply with the compliance specification
  • Stage 6 External review: compliance requirements are attached to the review prompt
  • Stage 8 Illustrations: check whether the images comply with compliance requirements (e.g., brand logo restrictions)
  • Stage 9 Publishing: self-check against the compliance specification before publishing

When compliance.rules_file is not configured, the above stages skip compliance checks.

Common red lines for compliance specifications (for reference)

  • Do not use third-party brand logos (mentioning brand names in text is acceptable)
  • Do not include misleading marketing copy
  • Cite sources when quoting others' content
  • Self-check against compliance guidelines before publishing