SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillseliteforge-tech-doc

eliteforge-tech-doc

Design & creation

View repository

Updated 10-15 20:13

About this skill

EliteForge Tech Doc

Goals

  • Generate a reviewable technical design document based on existing materials; do not fabricate facts.
  • Cover all documents and diagrams in the current execution directory: at minimum include a source list and give a disposition conclusion (adopted/background reference/to be confirmed).
  • Prioritize reusing existing terminology, process names, and diagram styles from the repository.

Execution order (do every time)

  1. In the current execution directory, run scripts/list_doc_and_diagram_sources.sh . to inventory materials.
  2. Build a "source list" and read by priority:
    • P0：README*、*design*、*architecture*、*spec*、docs/** core documents.
    • P1: interface, data model, deployment, operations, and troubleshooting documents.
    • P2: long-tail explanatory documents and image assets (at minimum provide a one-line summary; do not omit any).
  3. Build factual basis (suggested fields:结论、证据文件、置信度、备注）。
  4. First read references/tech-doc-template.md, and draft the target document according to the template.
  5. Prioritize reusing existing diagrams:
    • When .mmd/.mermaid/.puml/.plantuml/.drawio exists, prioritize referencing it or rewriting it into diagram blocks with equivalent semantics.
    • When only an image diagram (.png/.jpg/.jpeg/.webp) exists, you may only summarize based on surrounding documents and the file name; mark uncertain items as "to be manually confirmed".
  6. Output the document to the user-specified path; when the user does not specify one, write by default to the current directory ./tech-design.md。
  7. According to references/quality-checklist.md , self-check before replying with the result.

Mandatory constraints

  • Fabricating components, interfaces, processes, states, or sequence relationships is prohibited.
  • Each key conclusion must be bound to at least 1 source file path.
  • When conflicting information is found, the conflict points and the basis for the tradeoff must be explicitly listed.
  • No document/diagram file in the scan results may be ignored; for files that cannot be consumed, the reason must be stated.
  • The output document must include a "source list" and "items to be confirmed".
  • When extensible designs such as plugin-based, SPI, or Hook are involved, a "module extension point design" section must be included; internal interface design is not within the scope of extensibility.

Rules for distilling diagrams and flows

  1. For process-type content, prioritize outputting a "scenario-based structure": trigger conditions, inputs, steps, outputs, and exception branches.
  2. For call chain content, prioritize using mermaid sequenceDiagram to express key participants and call direction.
  3. For state transition content, prioritize using mermaid stateDiagram-v2 to express states and transition conditions.
  4. For pseudocode, retain domain action names; do not replace them with vague descriptions.
  5. For diagram meanings that cannot be confirmed, retain the original file path and mark "to be manually confirmed"; do not guess details.

Minimum structure of the output document

Output according to the template, including at least the following sections:

  1. Document source list
  2. Background and goals
  3. Terminology and boundaries
  4. Core scenario flows (including pseudocode)
  5. Sequence diagram
  6. State diagram
  7. Module extension point design (when there is no extension, write "Extension is not currently supported.", but the heading must not be omitted)
  8. Risks and Items to Be Confirmed

Facilitates tracing from business actions to system implementation.

Output Style

  • Output in Chinese by default, retaining the original text for key terms (such as module names, interface names, and class names).
  • Use short paragraphs and sentences, avoiding vague generalizations.
  • Keep only content of value to review decisions in diagrams and pseudocode, avoiding lengthy repetition.

Reference Material Reading Strategy

Quick Commands

# 1) 盘点当前目录文档和图
skills/eliteforge-tech-doc/scripts/list_doc_and_diagram_sources.sh .

# 2) 生成技术设计文档（文件名可改）
# 输出示例：./tech-design-summary.md

Example Trigger Phrases

  • "Please scan all documents and diagrams in the current directory and produce a technical design document."
  • "Based on the markdown and sequence diagrams in the repository, prepare a solution design draft."
  • "Compile the existing design materials into a reviewable tech design and mark missing information."

Reference Files