How do I install the Likec4 Issue Repro skill?

Run npx skillmds@latest add likec4/likec4-issue-repro in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Likec4 Issue Repro safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Likec4 Issue Repro?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Likec4 Issue Repro free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Likec4 Issue Repro?

likec4 (@likec4) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Likec4 Issue Repro by likec4 — Agent Skill

Name: Likec4 Issue Repro
Author: likec4

Likec4 Issue Repro

Use when reproducing, diagnosing, or verifying a reported LikeC4 bug from a GitHub issue or user report. Trigger for tasks asking whether an issue can be reproduced, requesting a minimal repro, checking bug reports, or turning a reproduction into a focused regression test.

likec4 Updated Sep 17, 2026

File contents

LikeC4 Issue Reproduction

Reproduce with the smallest fixture that exercises the reported behavior, then give a direct yes/no with evidence.

Ground rules

Prefer live GitHub issue data from gh issue view ISSUE --repo likec4/likec4 --comments.
Keep fixtures outside unrelated source changes, usually in a temp directory or a focused test fixture.
Do not churn dependencies. If pnpm fails unexpectedly, check disk space before reinstalling.
If reproduction is blocked, report the exact blocker and the next command that would prove it.

Route the issue

Use the report symptoms to choose the likely code area:

Symptom	Start here
`likec4 gen`, exporters, `--outdir`, generated files	`packages/likec4/src/cli/codegen`
`likec4.config`, project discovery, include paths, excludes	`packages/language-server/src/workspace`
DSL parsing, validation, completions, imports	`packages/language-server`
computed views, predicates, relationships	`packages/core`
diagram rendering, browser behavior, embedded UI	`packages/diagram`, `packages/likec4-spa`, `packages/vite-plugin`

If the route is codegen or project config, also use the corresponding LikeC4 repo skill.

Reproduction workflow

Capture the exact report:

gh issue view ISSUE --repo likec4/likec4 --comments

Build a minimal fixture:

one likec4.config.* if project scope matters
one specification block with only required kinds
one model block with the smallest failing element or relationship shape
one views block only if rendering or codegen needs it

Run the narrowest command that exercises the failure.

Examples:

pnpm --filter @likec4/language-server test -- ProjectsManager.spec.ts
pnpm --filter likec4 test -- codegen
pnpm --filter @likec4/core test -- relationship
pnpm --filter @likec4/diagram test -- path/to/spec

If reproducible, add or update a focused regression test before changing implementation.
Re-run the focused test, then expand only as risk requires:

pnpm --filter PACKAGE test -- SPEC_OR_PATTERN
pnpm --filter PACKAGE typecheck
pnpm exec dprint check CHANGED_FILES
git diff --check

Evidence to report

Use this format:

Reproduced: yes/no.
Fixture: path or short description.
Failing command: exact command and relevant failure.
Fix verification: exact command that passed.
Remaining risk: anything not covered.

---name: likec4-issue-reprodescription: Use when reproducing, diagnosing, or verifying a reported LikeC4 bug from a GitHub issue or user report. Trigger for tasks asking whether an issue can be reproduced, requesting a minimal repro, checking bug reports, or turning a reproduction into a focused regression test.---# LikeC4 Issue ReproductionReproduce with the smallest fixture that exercises the reported behavior, then give a direct yes/no with evidence.## Ground rules- Prefer live GitHub issue data from `gh issue view ISSUE --repo likec4/likec4 --comments`.- Keep fixtures outside unrelated source changes, usually in a temp directory or a focused test fixture.- Do not churn dependencies. If `pnpm` fails unexpectedly, check disk space before reinstalling.- If reproduction is blocked, report the exact blocker and the next command that would prove it.## Route the issueUse the report symptoms to choose the likely code area:| Symptom | Start here || ----------------------------------------------------------- | ----------------------------------------------------------------- || `likec4 gen`, exporters, `--outdir`, generated files | `packages/likec4/src/cli/codegen` || `likec4.config`, project discovery, include paths, excludes | `packages/language-server/src/workspace` || DSL parsing, validation, completions, imports | `packages/language-server` || computed views, predicates, relationships | `packages/core` || diagram rendering, browser behavior, embedded UI | `packages/diagram`, `packages/likec4-spa`, `packages/vite-plugin` |If the route is codegen or project config, also use the corresponding LikeC4 repo skill.## Reproduction workflow1. Capture the exact report:```bashgh issue view ISSUE --repo likec4/likec4 --comments```2. Build a minimal fixture:- one `likec4.config.*` if project scope matters- one `specification` block with only required kinds- one `model` block with the smallest failing element or relationship shape- one `views` block only if rendering or codegen needs it3. Run the narrowest command that exercises the failure.Examples:```bashpnpm --filter @likec4/language-server test -- ProjectsManager.spec.tspnpm --filter likec4 test -- codegenpnpm --filter @likec4/core test -- relationshippnpm --filter @likec4/diagram test -- path/to/spec```4. If reproducible, add or update a focused regression test before changing implementation.5. Re-run the focused test, then expand only as risk requires:```bashpnpm --filter PACKAGE test -- SPEC_OR_PATTERNpnpm --filter PACKAGE typecheckpnpm exec dprint check CHANGED_FILESgit diff --check```## Evidence to reportUse this format:```textReproduced: yes/no.Fixture: path or short description.Failing command: exact command and relevant failure.Fix verification: exact command that passed.Remaining risk: anything not covered.```

Frequently asked questions