Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

support-markdown-reference-map

Estrellas4

Forks1

Actualizado10 de abril de 2026 a las 19:36

Reference map for support-markdown modules, plugin packages, dependency layers, Markwon/commonmark-java ownership boundaries, consumer entry points, and Dokka navigation. Use for questions like which package should own this code, where a class should live, or how the library is organized.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

AniTrend

AniTrend/support-markdown

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

Explorador de archivos

2 archivos

SKILL.md

readonly

name	support-markdown-reference-map
description	Reference map for support-markdown modules, plugin packages, dependency layers, Markwon/commonmark-java ownership boundaries, consumer entry points, and Dokka navigation. Use for questions like which package should own this code, where a class should live, or how the library is organized.
argument-hint	Describe the feature, plugin, or consumer workflow you are trying to place or understand

Support Markdown Reference Map

What This Skill Produces

A fast package-placement decision for new or existing code.
A plugin-level map of where to search next.
A consumer-oriented view of which classes are likely to be imported, observed, or extended.
A handoff point when the real question is Markwon or commonmark-java behavior instead of package ownership.

When To Use

Choosing where a new plugin class, controller, span, or listener belongs.
Understanding which package a consumer should import from.
Mapping a downstream use case back to the owning plugin package.
Explaining repo structure before deeper implementation work.

Procedure

Start with the module reference map and identify the plugin package that owns the markdown element.
Match the task to a plugin family before picking a file. For example: inline text effects go to a dedicated plugin package, HTML tag handling goes to html/, shared contracts go to common/.
If the task is really about parser hooks, rendering hooks, or fixture-driven markdown behavior, switch to the support-markdown-plugin-workflow skill after confirming package ownership.
Confirm that the change does not introduce a dependency from :markdown on :app.
Open the Dokka page for the module if you need consumer-facing context or neighboring public types: https://anitrend.github.io/support-markdown/.
If the task changes a public API, also apply the support-markdown-kdoc-dokka skill so the published docs stay aligned.

Outputs To Aim For

Package name and module
Candidate class or file name following existing naming conventions
Relevant neighboring abstractions
Dependency layer if Markwon or commonmark-java behavior is part of the decision
Consumer impact summary

References

module reference map

Más de este repositorio

mismo repositorio

support-markdown-markwon-internals

AniTrend/support-markdown

Deep reference for Markwon plugin internals, commonmark-java AST extension points, Android Spanned rendering, and AniList-Flavored Markdown syntax. Use when implementing new plugins, debugging rendering pipelines, choosing the correct hook layer (processMarkdown vs configureParser vs configureVisitor vs beforeSetText), or understanding how commonmark nodes become Android spans.

2026-04-194

support-markdown-plugin-workflow

AniTrend/support-markdown

Implement or debug support-markdown plugins using real AniList feed fixtures, FeedList.graphql curl validation, and Markwon/commonmark-java extension points. Use for new plugin work, parser or rendering bugs, markdown test design, and deciding whether behavior belongs in processMarkdown, configureParser, configureVisitor, HtmlPlugin handlers, or beforeSetText.

2026-04-194

support-markdown-build-dependencies

AniTrend/support-markdown

Understand and change support-markdown build logic, Markwon/commonmark-java dependency wiring, module dependencies, version catalog entries, Dokka setup, and shared Gradle conventions. Use for buildSrc edits, new dependencies, parser or renderer dependency changes, or documentation pipeline work.

2026-04-104

support-markdown-kdoc-dokka

AniTrend/support-markdown

Write or improve KDoc for public APIs in support-markdown. Use for Dokka updates, plugin class docs, controller docs, listener docs, span docs, and explaining how downstream apps should use or configure Markwon and commonmark-java backed library behavior.

2026-04-104

jenv-gradle-low-ram

AniTrend/support-markdown

Align jenv with .java-version and run Gradle reliably on low-RAM machines. Use for Java mismatch errors, Gradle OOMs, daemon memory pressure, and selecting safe build flags.

2026-04-104

name	support-markdown-reference-map
description	Reference map for support-markdown modules, plugin packages, dependency layers, Markwon/commonmark-java ownership boundaries, consumer entry points, and Dokka navigation. Use for questions like which package should own this code, where a class should live, or how the library is organized.
argument-hint	Describe the feature, plugin, or consumer workflow you are trying to place or understand

Support Markdown Reference Map

What This Skill Produces

A fast package-placement decision for new or existing code.
A plugin-level map of where to search next.
A consumer-oriented view of which classes are likely to be imported, observed, or extended.
A handoff point when the real question is Markwon or commonmark-java behavior instead of package ownership.

When To Use

Choosing where a new plugin class, controller, span, or listener belongs.
Understanding which package a consumer should import from.
Mapping a downstream use case back to the owning plugin package.
Explaining repo structure before deeper implementation work.

Procedure

Start with the module reference map and identify the plugin package that owns the markdown element.
Match the task to a plugin family before picking a file. For example: inline text effects go to a dedicated plugin package, HTML tag handling goes to html/, shared contracts go to common/.
If the task is really about parser hooks, rendering hooks, or fixture-driven markdown behavior, switch to the support-markdown-plugin-workflow skill after confirming package ownership.
Confirm that the change does not introduce a dependency from :markdown on :app.
Open the Dokka page for the module if you need consumer-facing context or neighboring public types: https://anitrend.github.io/support-markdown/.
If the task changes a public API, also apply the support-markdown-kdoc-dokka skill so the published docs stay aligned.

Outputs To Aim For

Package name and module
Candidate class or file name following existing naming conventions
Relevant neighboring abstractions
Dependency layer if Markwon or commonmark-java behavior is part of the decision
Consumer impact summary

References

module reference map