collecting-wpf-dev-pack-feedback — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited collecting-wpf-dev-pack-feedback (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill turns lessons learned in the current WPF session into a structured improvement-feedback document for the wpf-dev-pack plugin. It does NOT modify wpf-dev-pack and does NOT touch git — it only writes one markdown file to the current working directory, which the user later contributes via pull request.
WPF work happens in projects OUTSIDE the dotnet-with-claudecode repository, and that repo's local clone path differs per machine. Editing wpf-dev-pack from a foreign session is infeasible, so improvements are captured as an accumulable md and contributed separately (see the repo CONTRIBUTING guide).
The feedback document is a reusable artifact contributed across projects. It must describe the technical phenomenon and its causal chain only. The following content is PROHIBITED in any feedback document produced by this skill:
(use generic placeholders such as XxxView, XxxViewModel, XxxService)
Public framework / library / API names (e.g., HelixToolkit, ScottPlot, CommunityToolkit.Mvvm, Prism, DispatcherPriority.ApplicationIdle) are allowed because they are part of the technical context, not identifying information.
Copy this checklist and track progress:
Feedback Collection Progress:
- [ ] Step 1: Auto-draft feedback items from this session
- [ ] Step 2: Augment via interview (AskUserQuestion)
- [ ] Step 3: Sanitize and rewrite each item as a causal description
- [ ] Step 4: Write the md to the current directory
- [ ] Step 5: Audit the completed md for identifying information
- [ ] Step 6: Report path and contribution instructionsReview THIS conversation/session and extract feedback candidates. Look for:
make-wpf-* scaffolder output that was missing or wrongFor each candidate, capture concrete session evidence (what was attempted, what broke, how it was fixed) and a concrete proposal (which file to add/change, what kind: new skill / augment skill / scaffolder modernization / rule addition) and a priority (High / Medium / Low).
If no candidate is found, tell the user there is nothing to report and STOP without writing a file.
Use the AskUserQuestion tool at least once (one or two questions max) to surface items the auto-draft missed. Suggested questions:
Fold the answers into the draft.
Before writing the document, for every drafted item, rewrite the evidence so that it reads as a generic technical phenomenon, not a project incident.
Apply these transformations:
| If the draft contains | Replace with |
|---|---|
| A project / solution / repo name | Omit entirely; refer to "a WPF project" or remove the sentence |
| A developer / team name | Omit entirely |
| A date / time / sprint reference | Omit entirely |
| An absolute or repo-relative path from the originating codebase | A generic shape such as Views/XxxView.xaml, ViewModels/XxxViewModel.cs |
| A project-specific class / namespace / member name | A neutral placeholder such as XxxView, XxxViewModel, IXxxService |
| "We tried X in project Y" | "When X is done with this API" |
| "It broke in our build" | "The control/binding/render path fails because …" |
Each item's evidence section must then describe:
Keep the chain technical and reproducible by any reader, regardless of which project they are working on.
Resolve a short kebab-case <topic> from the $0 argument if provided, else infer it from the session's main subject.
Write the file to <cwd>/<topic>-wpf-dev-pack-feedback.md (current working directory root — do NOT search for or write into any other repo, and do NOT run git). If a file with the same name already exists, append a short disambiguating suffix (e.g., -2) rather than overwriting.
Do NOT prefix the filename with a date (no YYYY-MM-DD-…). The Anonymity policy in this skill forbids dates inside the document body, and the same rule applies to the filename — date prefixes leak when the issue was encountered and defeat anonymity. The filename is exactly <topic>-wpf-dev-pack-feedback.md, nothing prepended.
The document body language is not constrained — use whichever language the session naturally produced (Korean, English, or mixed is all fine). Use this exact structure:
# wpf-dev-pack Feedback — <one-line title>
- **Purpose**: <why this feedback is needed>
- **Scope**: <count of new skills / augmentations / scaffolder modernizations; version bump and README sync notes>
---
## 0. Summary (priority)
| ID | Kind | Target | Priority | One-liner |
|----|------|--------|----------|-----------|
| 1 | New skill / Augment / Modernize / Rule / Knowledge | skills/<...>/SKILL.md or knowledge/<id>/TOPIC.md | High/Medium/Low | ... |
---
## 1. <item title>
### Phenomenon and causality
<Phenomenon: what is observed.
Cause: which framework / library / API behavior produces it.
Effect: the resulting failure mode.
No project name, no developer name, no date, no originating file path,
no project-specific identifier.>
### Proposal (concrete change)
<Which file to add or modify, and what to change>
### Adjacent skill boundaries / cross-links
<Boundary with overlapping skills, and cross-link targets>Add one numbered ## N. section per feedback item.
After the file is written, treat it as an untrusted artifact and run an independent audit against the Anonymity policy. The drafting and the audit must be separate passes — do NOT skip this step even when you are confident the draft is clean.
A skill-scoped PostToolUse hook (declared in this skill's frontmatter, implemented at hooks/FeedbackDocAuditor.cs) performs a pattern-based first-pass audit on every Write/Edit of a *-wpf-dev-pack-feedback.md file while this skill is active. The hook is automatically scoped to this skill's lifetime, so it will not fire during unrelated work in other sessions. On violation it exits with code 2, which surfaces the diagnostic back to this conversation. Treat the hook as a safety net, not a substitute: subtle identifiers (project-specific noun phrases, internal product names) cannot be matched by regex and still require the model audit below.
Read the just-written file back from disk (do not audit the in-memory draft), and verify every checklist item below against the file content:
replaced with neutral placeholders (XxxView, XxxViewModel, IXxxService, etc.)
## N. item's evidence section reads as Phenomenon → Cause →Effect, not as a project incident report
작성일 / 출처 / "Date written" / "Source" /"Originating project" / "Encountered in" style metadata field exists
<topic>-wpf-dev-pack-feedback.md, never YYYY-MM-DD-<topic>-…
Public framework / library / API names (HelixToolkit, ScottPlot, CommunityToolkit.Mvvm, Prism, DispatcherPriority.ApplicationIdle, etc.) are part of the technical context — they pass the audit.
If any checklist item fails:
with neutral placeholders, drop sentences that cannot be salvaged without identifying detail, or rewrite the evidence as a generic technical chain).
Do not proceed to Step 6 until the checklist is fully clean.
Report the absolute path of the written file, then instruct the user:
이 md를dotnet-with-claudecode저장소의FeedbackDocs/에 넣어 Pull Request로 기여해주세요. 자세한 절차는 저장소의 CONTRIBUTING 문서를 참조하세요.
Do not commit, push, or attempt to locate the dotnet-with-claudecode repo.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.