This repository is an open skill library for code knowledge mapping, legacy-system understanding, central knowledge-repository building, and mixed-stack project analysis.

It is built by drawing on selected ideas and working principles from zread and sdd-riper, then upgrading and extending them into a more team-oriented skill library for long-term project knowledge reuse, cross-service analysis, mixed-stack mapping, and central knowledge-base maintenance.

For Chinese readers, start here:

• README.zh-CN.md

It is organized around two sibling skills maintained in one place:

1. backend-service-spec-skill
2. cross-tech-stack-spec-skill

The goal is to keep backend-oriented knowledge mapping and cross-tech-stack extensions in a single repository so they are easier to maintain, publish, and read.

The base skill and the extension skill now both use their formal names directly:

• backend-service-spec-skill
• cross-tech-stack-spec-skill

That means users should now invoke the base skill directly by its current formal name.

For example:

Use $backend-service-spec-skill to analyze this backend microservice project.

If this is your first time in the repository, use this root README as the entry guide:

1. Read this file to understand the two skills, their boundaries, and the common entry prompts.
2. If your target is a backend, microservice, legacy system, or platform service repository, continue with the Backend Service Spec Skill README.
3. If your target is mobile, H5, Python, or a mixed-stack workspace, continue with the Cross Tech Stack Spec Skill README.

If you mainly want to know what backend-service-spec-skill can do before reading the full child README, start with the command overview below.

This is the primary skill in the repository for backend systems, microservice landscapes, legacy codebases, and platform-style service repositories.

Use it when:

• you need a first-pass service landscape
• you want to identify which services deserve deeper analysis next

Typical outputs:

• service inventory
• service boundaries
• upstream/downstream dependencies
• service-landscape overview pages
• architecture diagram and service call graph by default in a standard run

Read more:

• Backend Service Spec Skill README
• Backend Skill Command Output Map

Use it when:

• you have identified a high-value service
• you want a vertical analysis of modules, interfaces, dependencies, and responsibilities

Typical outputs:

• single-service structure pages
• interface inventory
• dependency pages
• service rule or convention pages
• upstream/downstream dependency diagram and module architecture diagram by default in a standard run

Read more:

• Backend Service Spec Skill README
• Backend Skill Quick Start

Use it when:

• you want to trace a real request chain or message chain
• you need to separate sync calls, async messaging, compensation, and real-time channels

Typical outputs:

• key route-chain pages
• sync/async split views
• closure-status pages
• sequence diagram and route call graph by default in a standard run

Read more:

• Backend Service Spec Skill README
• Backend Skill Command Quick Reference

Use it when:

• you already have service-level facts and want to consolidate them into domain-level knowledge
• you are preparing long-lived artifacts for a central knowledge repository

Typical outputs:

• business-domain pages
• domain-to-service mapping pages
• domain-level rule pages
• domain context diagram by default in a standard run

Default output rule:

• for the four backend core commands, a standard-output run now means text pages + companion Markdown/Mermaid diagrams
• users only need to call out diagrams separately when they want narrower scope, special naming, or text-only output

Read more:

• Backend Service Spec Skill README
• From mydocs To A Central Knowledge Repository

If you want the shortest path to first use:

1. Read Backend Skill Quick Start
2. Read Backend Skill Command Quick Reference
3. Return to the Backend Service Spec Skill README for the complete explanation

If you want the full picture:

1. Read this root README first
2. Then read the Backend Service Spec Skill README
3. Then read the Backend Skill Usage Guide
4. If the project is mixed-stack, continue with the Cross Tech Stack Spec Skill README

Many users understand that mydocs/ is the output root, but do not immediately know what each subdirectory is for. The simplest way to read it is:

The directory most likely to be misunderstood is mydocs/context/:

• it is not a private folder for one single service
• it is better understood as the global cross-cutting context layer within the current analysis scope
• it mainly serves cross-end, cross-service, and cross-route collaboration
• its boundary is the systems included in the current analysis scope, not every repository in an organization

If you are unsure where to start, choose an entry point by scenario:

• For the overall service landscape: start with create_codemap
• For one important service: start with service_deep_dive
• For a real cross-service chain: start with crate_router_map
• For long-lived domain knowledge: finish with build_domain_map
• For mixed-stack projects: use $backend-service-spec-skill as the base workflow and enable $cross-tech-stack-spec-skill

When the extension skill runs as a standard-output mixed-stack pass, companion Markdown/Mermaid diagrams should normally be generated together with the text pages.

Typical default diagrams:

• mixed-stack architecture diagram
• cross-layer call graph
• page/app/backend/task/callback/bridge sequence diagram when a route needs explicit ordering
• interface mapping diagram when enable_contract_map is enabled and evidence supports it
• gateway forwarding diagram when enable_gateway_map is enabled
• context propagation diagram when enable_context_propagation_map is enabled
• producer/topic/consumer route diagram when enable_async_contract_map is enabled

Read more:

• Cross Tech Stack Spec Skill README
• Extension Skill Command Output Map
• Mixed-Stack Diagram Output Guidelines
• Mixed-Stack Diagram Output Example Template
• Mermaid Safety Checklist

This repository also includes skill-usage companion files:

• License
• Installation Guide
• Directory And Terminology Baseline
• From mydocs To A Central Knowledge Repository
• Central Knowledge Repository And OpenSpec Collaboration

It also includes generic integration guidance for other AI development tools that support rules, instructions, prompts, or documentation context.

If your main question is how skill outputs should land in a central knowledge repository, the shortest path is:

1. read From mydocs To A Central Knowledge Repository
2. then read Central Knowledge Repository And OpenSpec Collaboration

Location:

• ./backend-service-spec-skill/

Use this skill when the repository is mainly a legacy backend system, a microservice landscape, or a platform service family.

Core capabilities:

• cross-service create_codemap
• cross-service build_domain_map
• crate_router_map
• service_deep_dive

Read next:

• Backend Skill Quick Start
• Backend Skill Command Output Map
• Backend Skill Command Quick Reference
• Backend Skill Metadata
• Backend Skill Usage Guide
• Backend Skill README

Location:

• ./cross-tech-stack-spec-skill/

Use this skill when the repository spans mobile, H5, Python, bridge, backend, MQ, callback, or other cross-tech-stack boundaries.

Core enhancements:

• workspace layering
• mixed-stack noise control
• communication evidence levels
• interface mapping
• mixed-stack architecture and cross-layer diagrams
• mixed-stack domain mapping
• incremental update mode
• eight optional switch-controlled deep-analysis pages

Read next:

• Extension Skill Metadata
• Detailed Extension Usage Guide
• Extension Skill Command Output Map
• Extension Skill Command Quick Reference
• Mixed-Stack Diagram Output Guidelines
• Mermaid Safety Checklist
• Full Analysis Mode
• Optional Switch Extensions
• Extension README

• the repository is mainly backend or microservice oriented
• service-level language is still accurate enough
• cross-stack adaptation is not needed

• the repository is mobile-first, H5-first, Python-first, or mixed-stack
• interface and router analysis must cross frontend, gateway, backend, MQ, callback, or task layers
• backend-only wording would distort the project structure

• you want the backend skill as the main workflow
• and you need mixed-stack adaptation on top of it

Recommended wording:

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

Use $backend-service-spec-skill to analyze this backend microservice project with standard outputs.
Generate the normal text pages and companion Markdown/Mermaid diagrams together.

Use $backend-service-spec-skill to run a lightweight full analysis on this backend microservice project.
Requirements:
1. classify project scope first
2. run create_codemap
3. run service_deep_dive on 1 to 2 high-value services
4. run crate_router_map on 1 to 2 key chains
5. generate standard outputs, including companion Markdown/Mermaid diagrams by default
6. stay strictly grounded in code facts

Use $backend-service-spec-skill to run a heavy full analysis on this backend microservice project.
Requirements:
1. classify project scope first
2. run create_codemap
3. run service_deep_dive on multiple high-value services
4. run crate_router_map on multiple key chains
5. run build_domain_map last
6. generate standard outputs, including companion Markdown/Mermaid diagrams by default
7. output validation pages and unresolved-chain summaries
8. stay strictly grounded in code facts

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

Use $backend-service-spec-skill as the base workflow, and enable $cross-tech-stack-spec-skill for mixed-stack adaptation.
Generate standard outputs and companion Markdown/Mermaid diagrams together.

Use $backend-service-spec-skill as the base workflow, enable $cross-tech-stack-spec-skill, and turn on enable_contract_map + enable_gateway_map + enable_field_lineage + enable_context_propagation_map + enable_error_semantics + enable_async_contract_map + enable_external_dependency_dossier + enable_interface_verification_assets for a full enhanced analysis.
Generate standard outputs and companion Markdown/Mermaid diagrams together.

Use $backend-service-spec-skill as the base workflow, enable $cross-tech-stack-spec-skill,
turn on enable_contract_map + enable_gateway_map + enable_field_lineage + enable_context_propagation_map + enable_error_semantics + enable_async_contract_map + enable_external_dependency_dossier + enable_interface_verification_assets,
and generate separate standard artifacts for all enabled capabilities, including companion Markdown/Mermaid diagrams.

Note:

• full analysis mode can consume substantially more tokens
• it also increases scan time and output size
• see Full Analysis Mode for guidance

• Team Standard Workflow
• Full Analysis Mode
• From mydocs To A Central Knowledge Repository
• Central Knowledge Repository And OpenSpec Collaboration
• Scenario Command Recipes
• Trace A Full Chain From An Interface Or Feature
• Anchor Selection Guide

1. Read the backend quick-start guide first.
2. Then read the backend-service README or usage guide.
3. If the project is mixed-stack, continue to the extension README.
4. If deeper interface analysis is needed, continue to the extension usage guide and optional-switch guide.

• Team Standard Workflow
• Personal Workflow For Backend-Microservice Projects
• Backend Skill Command Output Map
• Backend Skill Command Quick Reference
• Extension Skill Command Output Map
• Extension Skill Command Quick Reference

For Chinese readers, start here:

• Chinese Root README
• Chinese Guide: mydocs To Central Knowledge Repository
• Chinese Guide: Knowledge Repository And OpenSpec Collaboration
• Backend Skill Chinese Quick Start
• Backend Skill Chinese README
• Extension Skill Chinese README
• Extension Chinese Usage Guide