Tech Route Maker

Tech Route Maker

Purpose

Use this skill to turn source materials into evidence-grounded editable technical route diagrams for research and engineering projects across multiple disciplines.

Primary users are researchers, students, academic writers, engineering teams and agent/tool builders preparing paper framework figures, method overview diagrams, thesis proposal routes, defense visuals, course-design diagrams, engineering system routes and workflow pipelines.

Campaign or advertising routes are legacy/experimental use cases. Do not make them the default direction unless the user explicitly asks for them.

Portability

This skill is intentionally agent-agnostic. SKILL.md is the source of truth for Codex/OpenAI-style skill loaders and any agent that understands skill folders. Other adapters in the repository point back here:

• AGENTS.md for generic coding agents.
• CLAUDE.md for Claude-style project context.
• GEMINI.md and .gemini/settings.json for Gemini CLI.
• .cursor/rules/tech-route-maker.mdc for Cursor.
• .github/copilot-instructions.md for GitHub Copilot coding agent.
• .aider.conf.yml for Aider-style workflows.

Default Interaction Policy

Do not interrupt the user with a long sequence of questions, but do not guess domain or delivery preferences from a field-agnostic request.

Before final rendering, explicitly establish the domain context and confirm the requested output format, target medium, layout family and visual style. Present one concise grouped choice with sensible defaults; allow single or multiple output formats. If the source explicitly proves a domain fact, extract it with an evidence locator instead of asking the user to repeat it.

Default behavior:

• Never render a final technical route diagram from a field-agnostic request such as "draw a technical route diagram" without first identifying the discipline, subfield, project type, research object, method family and evaluation logic.
• If source files are available, extract domain context only from explicit source evidence. Ask one concise field-specific clarification question for every material gap rather than silently inventing it.
• If the user asks for a quick draft before the field is complete, mark domain_context.confidence as low, keep missing items in unresolved_questions, and report that the output is not final.
• If the user asks in Chinese for 开题, 课题申报, 项目申请, 基金, 论文技术路线图, or a Chinese research route diagram, prefer the Chinese academic presets below.
• If the user asks for an editable presentation figure, generate pptx, svg and json.
• If the user asks for a paper or research figure, generate svg, pptx and json.
• If the user asks for a maintainable system diagram, generate drawio, svg and json.
• If the user asks for Draw.io, diagrams.net, online editing, import code, copyable code, or "能复制到draw.io的代码", include drawio-code and explain how to paste the XML into diagrams.net.
• If the user asks for documentation output, generate markdown, mermaid and json.
• If the user asks for long-term maintenance, add drawio.
• If the user asks for all formats, render pptx, svg, drawio, drawio-code, excalidraw, mermaid, html, markdown and json.

Always record the selected preset and output formats in selected_preset and metadata.selected_output_formats. Always record the discipline-specific context in domain_context. Always state that generated editable files are drafts that require factual, wording and visual revision before publication or submission.

Domain Context Policy

Technical route diagrams are domain-sensitive. A diagram for computer vision, materials science, energy engineering, biomedical research, mechanical control, environmental field studies and social science should not share the same semantic grammar.

Before final rendering, establish:

• discipline: broad field.
• subfield: specific direction.
• project_type: paper figure, thesis proposal, grant application, engineering report, system architecture, experiment workflow, review framework, or similar.
• research_object: concrete object under study.
• method_family: main method type.
• application_area: intended use context.
• data_or_materials: source data, samples, materials, devices, documents, or field records.
• technical_objects: algorithms, modules, variables, devices, experiments, mechanisms, controls, or system components.
• domain_constraints: sample size, equipment, standards, deployment, ethics, cost, timeline, or data-quality constraints.
• evaluation_metrics: measurable success criteria.
• expected_outputs: figure, model, prototype, report, mechanism, dataset, application plan, or deliverable.

Read references/domain-profiles.md when the domain is unclear, unfamiliar, or likely to affect node semantics.

Examples:

• Computer vision / PV defect detection: separate dataset, annotation, augmentation, model architecture, training, ablation, evaluation and deployment.
• Materials science: separate material design, preparation, characterization, performance testing, mechanism analysis and application validation.
• Energy systems: separate system boundary, source/load data, optimization model, operation strategy, scenario validation and engineering deliverables.
• Biomedical research: separate sample/cohort, grouping/intervention, assays, mechanism/statistics, validation and biological or clinical significance.
• Social science: separate theory, hypotheses, variables, data collection, empirical model, robustness and implications.

Default Presets

Use these presets unless the user explicitly chooses a different layout, format bundle or visual style.

academic-method:
  purpose: Academic method framework
  trigger_hints: [paper, manuscript, review, method, experiment, publication figure, academic figure]
  outputs: [pptx, svg, json]
  layout: academic-method-framework
  style: academic-blue

thesis-proposal:
  purpose: Thesis/proposal technical route
  trigger_hints: [proposal, research plan, thesis, grant, topic application, opening report]
  outputs: [pptx, svg, drawio, json]
  layout: proposal-matrix-route
  style: presentation-clean

engineering-system:
  purpose: Engineering system route
  trigger_hints: [engineering system, energy system, control system, hardware system, platform design, architecture]
  outputs: [pptx, svg, drawio, html, json]
  layout: engineering-architecture-route
  style: dark-technical

workflow-pipeline:
  purpose: Workflow or tool pipeline
  trigger_hints: [software tool, agent skill, pipeline, workflow, automation, documentation]
  outputs: [svg, markdown, mermaid, json]
  layout: horizontal-stages
  style: minimal-gray

chinese-thesis-proposal:
  purpose: Chinese thesis/proposal poster route
  trigger_hints: [中文技术路线图, 开题报告, 课题申报, 论文技术路线, 研究方案, 毕设, 学位论文]
  outputs: [pptx, svg, drawio, html, json]
  layout: cn-proposal-poster-route
  style: cn-polished-pastel-academic

chinese-grant-application:
  purpose: Chinese grant or project application route
  trigger_hints: [基金申请, 项目申请, 申报书, 科研项目, 研究内容, 科学问题]
  outputs: [pptx, svg, drawio, html, markdown, json]
  layout: cn-grant-application-route
  style: cn-soft-grant-report

academic-paper-framework-cn:
  purpose: Chinese academic method framework
  trigger_hints: [中文论文方法框架, 研究框架图, 方法路线图, 论文图, 技术路线]
  outputs: [pptx, svg, drawio, json]
  layout: cn-research-method-matrix
  style: cn-blue-green-proposal

engineering-project-report-cn:
  purpose: Chinese engineering project report route
  trigger_hints: [工程项目, 项目汇报, 系统路线图, 能源系统, 平台建设]
  outputs: [pptx, svg, drawio, html, json]
  layout: cn-ppt-mainline-route
  style: research-ppt-blue

Required Clarification

Ask one concise clarification question when:

• No source material or topic is available.
• The discipline, subfield, project type, research object, method family or evaluation metrics are missing and cannot be inferred from source evidence.
• The user requests a final figure but gives no target audience or use case and several presets fit equally well.
• The user asks for a specific output environment but the format is ambiguous.
• A requested format conflicts with editability or with available renderer support.
• The source evidence is too weak to decide whether a node is source-supported or inferred.

Do not ask repeated setup questions when reasonable defaults are available. Start from a draft route, expose assumptions, and let the user revise.

Advanced Options

Show advanced choices only when the user asks to choose formats, style, layout, presets, or says advanced mode.

Advanced output formats:

1. pptx - editable in PowerPoint or WPS.
2. svg - editable in Figma, Illustrator or Inkscape.
3. drawio - editable in diagrams.net.
4. drawio-code - copyable Draw.io XML for diagrams.net / draw.io.
5. excalidraw - editable whiteboard-style scene.
6. mermaid - text-editable Markdown diagram.
7. html - interactive preview with node details.
8. markdown - project documentation page.
9. json - structured source file for re-rendering.

Advanced layout families:

1. academic-method-framework
2. proposal-matrix-route
3. engineering-architecture-route
4. horizontal-stages
5. vertical-research-route
6. layered-architecture
7. timeline-swimlane
8. wide-collaboration-map
9. cn-proposal-poster-route
10. cn-grant-application-route
11. cn-research-method-matrix
12. cn-wide-project-map
13. cn-monochrome-linework-route
14. cn-ppt-mainline-route
15. cn-a4-stage-route

Advanced visual styles:

1. academic-blue
2. blue-green-research
3. monochrome-paper
4. presentation-clean
5. minimal-gray
6. nature-style-editorial
7. high-contrast-accessible
8. dark-technical
9. schematic-precision
10. premium-scientific
11. cn-polished-pastel-academic
12. cn-blue-green-proposal
13. cn-soft-grant-report
14. cn-reviewer-linework
15. cn-defense-poster

Workflow

1. Confirm the source scope: current repository, a specific directory, a document set, or pasted project notes. When local files are available, run trm ingest --output-dir evidence-pack to freeze their paths and SHA-256 hashes before extraction.
2. Inspect project evidence before diagramming:

• README, docs, notebooks, papers, reports, briefs or notes.
• PDF, LaTeX, manuscript text, method sections, supplements, proposal documents or task briefs.
• Directory structure, manifests and config files.
• Entrypoints, API routes, model/training/inference scripts, data-processing scripts and deployment files when they clarify the system.
• Tests, examples and outputs when they clarify validation or deliverables.

1. Build a source-grounded foundation:

• Problem, gap, objective, assumptions, audience and intended reader effect.
• Discipline, subfield, project type, research object, method family, application area and evaluation metrics.
• Ordered method/process steps and non-droppable core substeps.
• Inputs, outputs, artifacts, variables, metrics, claims, evidence and risk items.
• For papers: figure slot, reader question, caption burden and terminology/acronym integrity.
• For engineering: system boundary, modules, data/energy/material flow, validation and deliverables.

1. Select the closest preset and output bundle using the default policy.
2. Extract a route model with this minimum logic:

problem or objective -> inputs/data -> methods/modules -> implementation/training/inference -> validation/evaluation -> outputs/applications.

1. Create or update tech-route.json before rendering any user-facing format.
2. Run trm validate tech-route.json --strict. Treat incomplete domain context, unverified hashes, evidence gaps, inferred nodes and unresolved questions as final-render blockers.
3. Render selected editable formats. Use --allow-draft only when the user explicitly requests an unfinished working draft.
4. Report generated files, warnings, quality report findings and recommended manual review steps.

Route Model

Use references/route-schema.md for the JSON schema. Keep every visible node traceable. A final diagram requires at least one hash-verified source evidence item for every visible node. Draft-only inferred nodes must set is_inferred: true, link to an assumption, remain separate from evidence coverage and block final rendering until resolved.

Use references/paper-framework-integration.md for paper-grounded and publication-figure rules, especially when the input is a manuscript, thesis, proposal, academic project, or method description.

Use references/domain-profiles.md to choose field-specific route grammar. Do not apply computer-vision, lab-experiment, engineering-system, biomedical or social-science semantics to each other unless the source explicitly combines them.

Use concise node labels:

• Prefer 3 to 9 words.
• Keep each stage to 2 to 6 nodes when possible.
• Use edge labels for semantic transitions such as feeds, trains, validates, optimizes, deploys, supports, or the user's language equivalent.
• Keep variables, temporary artifacts, scores, metrics, parameters and pass-through states on edges, tags or legends unless the source proves they are actual modules.
• Separate the semantic graph used for audit from the visual graph that will be rendered.
• Compress repeated actors, samples, panels, rows, arrows or equivalent flows unless each visible repetition adds source-grounded meaning.
• Keep edge labels in tech-route.json, HTML, Markdown and quality reports by default. Do not render them on the main diagram canvas unless the user explicitly enables renderer_overrides.show_edge_labels, because labels on connector lines often collide with arrows and node text.
• Keep node-to-node semantic edges out of the main diagram by default. Render a small number of straight stage-to-stage arrows instead. Only render node-level edges when the user explicitly enables renderer_overrides.show_node_edges.

Output Formats

Read references/output-options.md before explaining format tradeoffs.

Editable constraints:

• PPTX: use native shapes, text boxes and connector lines; do not paste a screenshot as the main diagram.
• SVG: use editable text, rectangles, paths and lines; do not rasterize the diagram.
• Draw.io: use editable mxCell nodes and edges.
• Draw.io copy code: generate tech-route.drawio-code.xml as plain XML. Tell the user to open diagrams.net / draw.io, create a blank diagram, use Extras > Edit Diagram, paste the XML, confirm, and then edit the shapes.
• Excalidraw: use editable scene elements.
• Mermaid: keep the .mmd source as text.
• HTML: keep interaction data in structured JSON or embedded object data.
• Markdown: include Mermaid source and evidence tables when useful.
• JSON: keep the route source complete enough to re-render.
• Quality report: include evidence coverage, inferred node count, unresolved questions and manual review suggestions.

Layout And Style

Read references/layout-patterns.md before building tech-route.json for an unfamiliar layout.

Read references/visual-styles.md before setting a theme.

Read references/local-style-study.md when the target is a Chinese academic, thesis, grant, project-application, or research-report technical route diagram.

For proposal and research-report diagrams, prefer polished academic template language: white canvas, clear title, matrix or framework sections, low-saturation logical regions, dashed boundaries where they clarify grouping, and white editable node cards.

Use a left phase axis only when the user explicitly asks for a long vertical route. Do not use the vertical phase-axis layout as the default academic format.

For PPT-facing research and engineering diagrams, prefer cn-ppt-mainline-route: 16:9 canvas, five-stage horizontal mainline, enlarged stage/support text, 2 to 3 short support modules un

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Stephen-studying
• Source: Stephen-studying/tech-route-maker
• License: MIT

Install and usage instructions live in the source repository linked above.