Skip to content
cccskills
FreePublished on GitHub

create-issue

Investigate a problem to its root cause and file it as a GitHub Issue with the right labels and an As is / To be / Why / How body backed by primary sources. Use when asked to file, create, or open an issue, or when the `impl` skill hands over a carry-over. Trigger keywords: create issue, file an issue, open an issue, report a bug as an issue.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630 stars(GitHub 630 + cccskills 0)
Works withGitHub

Run score Not tested

See how to install

Files included (1)

  • SKILL.md4.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Problem to file: $ARGUMENTS

This skill posts to GitHub, yet Claude may invoke it (the impl, pr and pr-review skills do), so the side effect is gated by step 6: nothing is posted before the user approves the draft.

A problem handed over from a carry-over ledger — a bullet of the plan file's Carry-over heading (impl step 12) or of a merged PR body's ## Not covered here (impl step 15) — already records its reproduction: the minimal input, the observed output, the suspected cause and its file. That record satisfies step 2; do not investigate again what the bullet states, only what it lacks. Through impl step 15, the approval of step 6 covers two writes at once — creating the issue and marking the bullet in the PR body — and says so.

Steps

  1. Understand the problem. If the description above is empty, ask the user what is happening before anything else. Search for an existing report first — gh issue list --search "<keywords>" --state all and gh pr list --search "<keywords>" --state all — and when one matches, ask the user (kind: scope) whether the new report is the same problem or a different one; sessions run in parallel, so a duplicate is likely.

  2. Find the cause. Unless the user explicitly says to skip investigation, reproduce the problem (a spec test or a temporary script that is discarded afterwards — record the input and the observed output) and locate the cause (file and behavior). The body never contains "not investigated", "cause unknown", or "to be investigated"; if you are about to write one, go back and investigate. For a feature or improvement, the equivalent is confirming what the current code does and where the change belongs.

  3. Collect primary sources. Use the web search and fetch tools available in the session to find the primary source behind the claim: the specification text itself (WHATWG, W3C, WAI-ARIA, RFC, CSS), the paper for an algorithm, or the official documentation of the library. A blog post or a summary is not a primary source. Required for every feature or improvement; required for a bug whenever the spec text is what decides the expected behavior.

  4. Pick labels. Run gh label list --limit 100 and choose from what exists — never type a label from memory. One kind label (Bug, Features: Proposal, Specs, …), every area label that applies (Rule, Parser, Core API, VS Code Extension, Configuration File, …), and the line label for every line the issue applies to: v5 for the dev line, v6 for the next major (Branch Topology in the root CLAUDE.md). Both when the affected code exists on both lines; a file or behaviour that only one line has gets that line's label alone.

  5. Draft the body in English with exactly this structure:

    ## As is

<!-- Current behavior. For a bug: environment (markuplint version, parser,
     Node.js, OS), minimal input, reproduction steps, observed output. -->

## To be

<!-- Expected behavior or desired outcome. -->

## Why

<!-- Rationale with links to the primary sources: the spec section,
     the paper, the official doc. -->

## How

<!-- Cause location and the proposed change: files, functions, approach. -->

    Verify every path and package name you mention (ls, npm view) before it goes into the body. Pick a title that names the symptom or the capability, not the fix.

  6. Confirm with the user through AskUserQuestion (kind: confirmation), not in the text of a response — a question in the text ends the turn. Show the title, the labels, and the full body, with a summary in the user's language if it is not English. Adjust and ask again if asked.

  7. Create the issue. Write the body to a file in the scratchpad directory and run:

    gh issue create --title "<title>" --label "<label>" --label "<label>" --body-file "<path>"

    --body-file avoids the escaping bugs an inline --body invites. No --assignee: it fails for a session whose token is not a collaborator, and the maintainer assigns during triage.

  8. Report the created issue's number and URL. Issues and PRs share one number sequence, so read the number from the output rather than predicting it.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

bench-maintain

Free

Maintenance of the nu-validator coverage benchmark: defend the invariants (nu-only = 0, xref audit green), follow up a nu-validator upstream update (submodule bump / Docker image drift), and regression-check after markuplint rule or spec changes. Use when updating the validator submodule, when a bench refresh surfaces new nu-only entries, when excluded-ids entries go stale, or for the periodic health check. Trigger keywords: bench maintain, bench maintenance, nu update, submodule bump, validator update, bench refresh, nu-only regression, stale excluded-ids, image digest.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630Updated Oct 26, 2026

bench-rule-enable

Free

Enable an existing or newly-added markuplint rule on the nu-validator bench by editing tests/external/bench/config.ts. Covers the flat-rule case (rules: { '<name>': true }) and the severity override case (rules: { '<name>': { severity: 'error' } }) that bench-virtual-rule does not. Use when a rule exists in the registry but the relevant nu fixtures stay nu-only because the rule is not enabled in the bench config, or when a rule's default severity is warning but the spec text it mirrors is a MUST / MUST NOT. Trigger keywords: enable bench rule, bench config flat rule, severity override bench, rule not flagging on bench, warning vs error in bench, escalate severity bench, no-contradictory-aria-prop bench, bench coverage missing rule.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630Updated Oct 26, 2026

bench-setup

Free

Set up the nu-validator benchmark environment — initialise the validator submodule, ensure Docker is running, populate the gitignored raw snapshots via yarn bench:update. Also covers Docker / nu-runner troubleshooting. Use when bench commands fail with "no snapshots found", "Docker daemon not reachable", port 28888 conflicts, or healthcheck timeouts; or when refreshing the bench after a long break. Trigger keywords: bench setup, bench Docker, validator submodule, no snapshots found, Docker daemon not reachable, healthcheck times out, port 28888, yarn bench:update first time, bench install, fresh clone bench.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630Updated Oct 26, 2026

bench-triage

Free

Triage one nu-only fixture from tests/external/snapshots/diff/nu-only.json by reading the spec, then drive its verdict to match-error, match-clean, or nu-over by either fixing markuplint or recording an excluded-ids.json entry. The core per-fixture operation of the nu-validator coverage benchmark. Use when a bench refresh surfaces new nu-only entries, when checking a coverage-claim ("markuplint misses X" / "over-detects Y") against the bench, or when classifying a specific fixture. Trigger keywords: nu-only, ml-only, coverage gap, bench triage, verdict, match-error, match-clean, nu-over, excluded-ids, declare nu over-detection, claim audit, audit fixture, mark-up valid per spec, spec-cited exclusion.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630Updated Oct 26, 2026

bench-virtual-rule

Free

Mirror a preset virtual rule (selectors under `nodeRules` in preset.html-standard.jsonc and similar) into bench/config.ts so the benchmark exercises it. Use when a new disallowed-element / similar selector lands in a preset and the matching nu fixtures remain stuck at nu-only despite the new rule existing in markuplint. Trigger keywords: virtual rule, nodeRules, disallowed-element, preset html-standard, bench config mirror, rule does not fire on bench, preset rule not exercised.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630Updated Oct 26, 2026

bench-xref

Free

Sync benchmark cross-reference blocks onto GitHub Issue bodies via `yarn bench:xref`, manage `tests/external/bench/issue-xref.config.ts` mappings, and run the pre-release checklist. Use when adding / removing / updating a primary or secondary mapping, when an issue closes upstream, when the xref CLI's output disagrees with what's on the issue body, or before cutting a release that touches a rule the benchmark covers. Trigger keywords: bench-xref, issue-xref, xref CLI, GitHub issue body, primary mapping, secondary mapping, umbrella block, pre-release checklist, bench-xref-audit workflow, marker version.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630Updated Oct 26, 2026

See all skills by markuplint

Report a problem with this skill