agentsclimarketplace

Mermaid validation

Skill JarrydAdaens/agentic_rails_tooling/archived/skills/mermaid-validation

The right rail of Agentic Rails: Reusable skills, agent personas, rules, and workflows for agentic coding IDEs — the tooling rail of the Agentic Rails framework.

Install
npx -y skills add JarrydAdaens/agentic_rails_tooling --skill mermaid-validation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use this skill when validating a Mermaid graph fragment before accepting mapper output or merging partials. It checks structure, scope, and reference plausibility, then returns pass or fail with concrete reasons.

SKILL.md

2.3 KB, as published. Nobody here has run it

Mermaid validation

Check mapper output before the Boss accepts it or before you merge fragments into a final diagram.

When to use

  • After a mapper returns a partial fragment.
  • Before pasting edges into documentation.
  • As a gate in the mermaid-mapper workflow (Boss runs these checks inline).

Inputs

  • Fragment: the proposed Mermaid body lines (edge lines only).
  • Assigned types: the set of type names that must be covered (for workflow rows, the types in that scoutmap row).
  • Optional inventory: full scoutmap or type list from the project for reference checks.

Structural checks

  • Content looks like valid Mermaid graph line syntax (edges with --> or --|>), not prose.
  • No markdown fences, headings, or bullet explanations mixed into the fragment.
  • Node identifiers are plausible type-name tokens (no full sentences).

Scope checks

  • Every assigned type appears at least once as a node (either side of an edge) unless the file truly contains no relationships; if omitted, fail with reason.
  • No invented types that are clearly outside the assignment (unless the user allowed cross-file discovery explicitly).
  • Fragment does not assert relationships that contradict obvious facts if the Boss already loaded the file (when verification is possible).

Reference checks

  • Types mentioned as endpoints should exist in the inventory when an inventory was provided, or be clearly justified as same-file / visible cross-references.
  • Fail or warn (per policy) when an edge names a type that appears nowhere in the codebase and was not in scope.

Output format

Respond with:

  1. Verdict: pass or fail.
  2. Reasons: if fail, a short numbered list of specific problems.
  3. Optional warnings that do not fail the run (for example plausible but unverified cross-file types).

Standalone examples

  • Validate this fragment against assigned types {FooViewModel, BarViewModel}.
  • Check these edges against the current scoutmap before aggregation.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.