Skip to content

README.md

Latest commit

 

History

History
151 lines (112 loc) · 7.14 KB

README.md

File metadata and controls

151 lines (112 loc) · 7.14 KB
Raw

Cross-Tech-Stack Spec Skill

An explicit extension skill for cross-tech-stack project analysis.

This skill is designed for repositories where backend-service wording is too narrow, including:

  • mobile app repositories
  • H5 / web frontend repositories
  • Python service / worker / task repositories
  • mixed-stack repositories spanning app, page, bridge, backend, callback, and task layers

Important Note

This skill does not replace the base backend-service-spec-skill. It is an opt-in extension.

For normal backend microservice analysis, keep using the base skill. For mixed-stack or non-backend-first projects, explicitly enable $cross-tech-stack-spec-skill.

How To Use

Recommended wording:

Use $backend-service-spec-skill as the base workflow, and enable $cross-tech-stack-spec-skill for mixed-stack adaptation.

For a pure mobile / H5 / Python repo, you can also say:

Use $cross-tech-stack-spec-skill to analyze this project.

If the user wants a one-pass run that exercises the base workflow plus all optional extensions and generates all artifact types, see:

Note:

  • full analysis mode can consume substantially more tokens
  • it also increases scan time and output size for large workspaces

Diagram Output Support

Mixed-stack diagrams are first-class outputs in this extension workflow. Prefer Markdown + Mermaid so the results stay readable for both humans and AI.

Recommended diagram types:

  • global mixed-stack architecture diagram
  • cross-layer call graph
  • page/app/backend/task/callback/bridge sequence diagram
  • code dependency graph versus runtime dependency graph
  • interface mapping diagram
  • context propagation diagram
  • gateway forwarding diagram
  • async contract route diagram

Default trigger rule:

  • when this extension runs as a standard output pass, companion mixed-stack diagrams should be generated by default
  • users do not need to repeat "generate diagrams" in normal cases
  • diagrams should be embedded into the corresponding document by default, and only split to mydocs/diagrams/ when reuse, frequent standalone updates, centralized export/management, or explicit diagram/text separation is needed

Communication Credibility

For communication analysis, this skill recommends a communication matrix with count basis, evidence levels, closure state, and code locations, so conclusions are easier to verify.

How To Read The Output Structure

When this extension runs together with $backend-service-spec-skill, the outputs usually land in one shared mydocs/ structure.

For mixed-stack projects, the directory that most often needs explanation is mydocs/context/:

  • it is not only for backend services
  • it is not a private page set for one app module, one H5 page, or one Python subproject
  • it is the cross-cutting context layer for the current analysis scope

In mixed-stack analysis, mydocs/context/ usually carries:

  • frontend-to-backend interface mappings
  • gateway or forwarding facts
  • field lineage
  • context propagation
  • error semantics
  • async producer/topic/consumer contracts
  • external dependency dossiers

So it is the right place to answer questions like:

  • which backend handler does this page or app entry finally call?
  • how does businessId, sessionId, or requestId move across layers?
  • where is this error code or response structure normalized?
  • which external systems does this capability depend on?

Optional Deep Extensions

If you need finer-grained interface, field, error, context propagation, or cross-team dependency analysis, use the optional switch-controlled extensions. These remain disabled by default and do not change the stable baseline workflow.

What The Commands And Switches Usually Produce

  • extension enabled without switches: workspace layering, communication evidence matrix, interface mapping, mixed-stack key route page, mixed-stack architecture diagram, cross-layer call graph
  • enable_contract_map: contract detail page, request/response field tables, interface mapping diagram
  • enable_gateway_map: gateway/forwarding route page, gateway forwarding diagram
  • enable_field_lineage: field lineage page, field movement diagram when helpful
  • enable_context_propagation_map: context propagation page, context propagation diagram
  • enable_error_semantics: error semantics page, failure-path sequence diagram when helpful
  • enable_async_contract_map: async contract page, producer/topic/consumer route diagram
  • enable_external_dependency_dossier: external dependency dossier page
  • enable_interface_verification_assets: verification assets page

See the full mapping here:

Read Next