Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

support-markdown-reference-map

Estrelas4

Forks1

Atualizado10 de abril de 2026 às 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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

AniTrend

AniTrend/support-markdown

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

Explorador de arquivos

2 arquivos

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

Mais deste repositório

mesmo repositório

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