skill: add import-security-issue-from-md (batch on-ramp from markdown findings)

[potiuk]

Summary

Adds a third on-ramp variant to the security-issue handling process — alongside import-security-issue (Gmail-driven) and import-security-issue-from-pr (public-PR-driven). The new skill takes a markdown file containing one or more pre-formatted security findings (typically AI security review output, a /security-review pass over an upstream branch, or a third-party SAST report exported as markdown) and creates one <tracker> tracking issue per finding.

	import-security-issue	import-security-issue-from-pr	import-security-issue-from-md
Source	Gmail / PonyMail thread	<upstream> PR	Markdown file
Reporter present	Yes (external researcher)	No (PR author)	No (file is the report)
Reporter-reply step	Yes	Skipped	Skipped
Initial board column	Needs triage	Assessed	Needs triage (every finding still goes through Step 3)
Cardinality	1 thread → 1 tracker	1 PR → 1 tracker	1 file → N trackers

Expected input shape

Per finding, separated from the next finding by --- on its own line:

# <Title>
## Details
## Location
## Impact
## Reproduction steps
## Recommended fix
---
**Severity:** HIGH|MEDIUM|LOW|UNKNOWN
**Status:** Open
**Category:** <free-text>
**Repository:** <owner>/<repo>
**Branch:** <ref>
**Date created:** YYYY-MM-DD

Behaviour highlights

• Single proposal table for the whole batch (not per-finding round-trips). User replies once with go or skip 1,4.
• Default disposition: import all unless rejected upfront — same pattern as import-security-issue.
• Every finding lands as Needs triage regardless of the source's **Severity:** HIGH tag — the source's tags are recorded as informational only; CVSS scoring and CWE assignment happen at allocation, not at import.
• Duplicate guard searches <tracker> for overlapping titles and surfaces possible duplicates inline in the proposal (soft signal — user decides).
• No reporter-reply step: the file is the report.
• Confidentiality: input file treated as private security-team material; same rules as <security-list> content.

Body field mapping

The standard 11-field issue body is populated from the markdown sections:

Source	Target
## Details + ## Impact + ## Reproduction steps	The issue description (verbatim, with sub-headings)
## Recommended fix	collapsible <details> at end of body
**Repository:** + **Branch:**	Affected versions (literal text — release-train mapping happens at allocation)
**Severity:**	Severity
**Category:**	CWE (free-text; actual CWE assigned during triage)
## Location URL pointing at a <upstream> PR	PR with the fix

Out of scope (potential follow-ups)

• A Python parser tool that emits structured JSON — skill-only is enough for the current shape; promote later if other input shapes start to need parsing.
• Auto-detection that ## Location URL is a <upstream> PR vs. a vulnerable source file (currently pattern-matches the URL).
• Resume-on-the-same-file after a partial-batch failure beyond the existing duplicate-guard.

Test plan

• ✅ prek passes on the new SKILL.md (trailing whitespace, EOF newline, etc.).
• The skill is loaded into the available-skills list (verified via /skill list).
• End-to-end dry-run against a real markdown file is left for the security team's first invocation — the skill's "propose, then default to import" pattern means the first run shows the proposal without committing any tracker writes.

🤖 Generated with Claude Code