docs: align write-up report naming with the findings schema

The findings schema requires a write-up's file name to equal its
directory slug:

    "pattern": "^findings/([a-z0-9][a-z0-9._-]*)/\\1\\.md$"

The orchestrating skills state that convention, but the write-up skill
that actually creates the file asked for an "appropriately-named" report
with two differing example file names, neither of which satisfies the
pattern. The sub-agent prompt template passed only an output directory,
so the constraint never reached the worker.

State the `findings/<slug>/<slug>.md` rule in the skill, the report
format reference, and the sub-agent prompt, while keeping the original
intent that the slug stay descriptive rather than `report`.

Fixes #47

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: mariohercules

sdk/typescript/_bundled_plugin/skills/vulnerability-writeup/SKILL.md

@@ -68,8 +68,8 @@ The produced write-ups must be distributable on their own and not assume access
 5. Confirm that each distinct vulnerability has enough source context to let a worker trace the bug from entry point to bad state. Inspect the finding's recorded locations, reopen the source around each relevant boundary, and give the worker the focused paths, functions, revision, and short source excerpts it needs. If source access is missing, collect the missing files,
    revision, fix diff, or build instructions before drafting, or proceed at explicitly lower confidence when the user accepts that limitation.
 6. If authorized lab access exists, record how to reach it and what safety limits apply. If it does not, instruct the worker to build or reason about PoCs locally and to state what could not be executed.
-7. For each distinct vulnerability, create one directory containing an appropriately-named report file as markdown (e.g. `freebsd-shm-uaf.md`)
-   and a `poc/` directory when PoCs exist. Don't just use a nondescript file name like `report.md`.
+7. For each distinct vulnerability, create one directory named with a descriptive lowercase slug (e.g. `freebsd-shm-ftruncate-uaf-lpe`), and write the report inside it as `<slug>.md`, so the recorded path is `findings/<slug>/<slug>.md`. Add a `poc/` directory when PoCs exist.
+   The file name must match its directory exactly; validation rejects any other name. Keep the slug itself descriptive, so it is clear at a glance what the vulnerability is -- don't fall back to something nondescript like `report`.
 8. Launch exactly one sub-agent for that vulnerability. Give it the raw notes, focused source paths and excerpts, target source tree, vulnerable revision, PoCs, output directory, format rules, lab details, and authorization boundary. Do not give it other vulnerabilities.
 9. Review the worker output immediately. Check technical correctness,
    completeness, line wrapping, self-contained wording, source snippets,
@@ -102,6 +102,8 @@ Inputs:
 - Testing authorization boundary: <what is allowed and forbidden>
 - Required format: `references/report-format.md`.
 - Output directory: <reports-dir>/<slug>
+- Output file: <reports-dir>/<slug>/<slug>.md (the report file name must
+  match its directory exactly; any other name is rejected)
 
 Rules:
 - Before drafting, open and read `references/report-format.md` in full. Its

sdk/typescript/_bundled_plugin/skills/vulnerability-writeup/references/report-format.md

@@ -2,8 +2,8 @@
 
 Use this guide to write a comprehensive vulnerability report that covers the details of a vulnerability, considers options for exploitation and walks the reader through the most effective steps to trigger the bug.
 
-The report should be written in markdown. Use language hints in code snippets to indicate programming language -- e.g. use ```c rather than just ```. Choose an appropriate file name for the report that makes it clear what the vulnerability is at a glance. For example, `freebsd-shm-ftruncate-uaf-lpe.md`.
-Don't just choose the name `report.md` or anything nondescript like that.
+The report should be written in markdown. Use language hints in code snippets to indicate programming language -- e.g. use ```c rather than just ```. Name the report file after the directory that contains it: a report written into `findings/freebsd-shm-ftruncate-uaf-lpe/` must be named `freebsd-shm-ftruncate-uaf-lpe.md`. Validation rejects any other file name, including uppercase letters and spaces.
+Choose that slug so it makes clear what the vulnerability is at a glance. Don't fall back to `report` or anything nondescript like that.
 
 Audience: other vulnerability researchers and security engineers with a deep knowledge of software exploitation and software development. The report must be written in clear English and use precise language. Be warm and somewhat friendly in the manner of your writing, but not overly familiar: as you'd expect a technical write-up to read from one expert to another. Don't sound robotic.