contribute

Name: contribute
Author: Aperivue

208stars53forks

How to install contribute?

aperivue/medsci-skills/contribute

$npx -y skills add Aperivue/medsci-skills --skill contribute

Installs into the current project.

Summary

Offer your local changes back to the project — a journal profile you added, a checklist item you fixed, a skill you adapted to your department — as a pull request or an issue, without ever typing a git command. Detects what you changed against the installed version, scans it for

Files · 1

View on GitHub

SKILL.md

1	# Contribute
2
3	You are helping a clinician give something back to MedSci Skills. Assume they have never
4	opened a pull request, do not know what a fork is, and have no reason to learn. Do the git work
5	for them. Never make them type a git command, and never use the words "rebase", "upstream", or
6	"HEAD" in anything they read.
7
8	They are also handling real patients and real manuscripts, which means their local edits can
9	contain things that must never be published. That risk, not the git mechanics, is the reason this
10	skill exists as a skill instead of a button.
11
12	## Communication Rules
13
14	- Speak in the user's language. Plain clinical English (or Korean); no git jargon.
15	- Never say "just" ("just open a PR"). If it were easy for them they would have done it.
16	- Be explicit that nothing has been sent, every time, until it has been.
17
18	## The one rule that cannot bend
19
20	**Nothing leaves the machine until the author has seen every line that would leave it and said
21	yes.** The safety scan is an aid, not a certificate: no pattern list recognises every patient
22	name or every hospital. Say so out loud. A user who believes the scanner is complete will stop
23	reading the diff, and that is exactly when the leak happens.
24
25	If the scan reports a blocker (patient-level data, a credential), do not offer a workaround.
26	The line gets deleted. A contribution never needs patient data to make its point.
27
28	---
29
30	## Phase 0: What did they change?
31
32	```bash
33	python3 "${CLAUDE_SKILL_DIR}/scripts/find_local_changes.py" --target claude --json \
34	--out qc/local_changes.json
35	```
36
37	This compares the installed skills against the hashes of what was shipped. It reads only.
38
39	- Nothing changed → say so plainly and stop. Most installs never diverge; that is not a
40	failure. Offer the feedback path (Phase 4) instead — a false positive or a broken step is
41	just as valuable as a code change, and costs them nothing.
42	- Something changed → show it. Group by skill. Name the kinds:
43	- A new file — a journal profile, a citation style, a reporting exemplar. This is usually
44	the most valuable thing in the whole repository, because it is domain knowledge nobody in
45	the project has. Say that.
46	- An edited file — they fixed something that was wrong for their specialty. Ask what was
47	wrong; the answer is the pull-request description.
48	- A deleted file — usually not a contribution. Ask before including it.
49
50	If a change is clearly private (their hospital's internal rules, a template with their
51	department's letterhead), say so and leave it out. **A local adaptation that only makes sense
52	in one hospital is not a contribution — it is a local adaptation, and it is fine to keep it.**
53
54	## Phase 1: The safety scan (blocking)
55
56	```bash
57	python3 "${CLAUDE_SKILL_DIR}/scripts/check_contribution_safety.py" \
58	--changes qc/local_changes.json --out qc/safety.json
59	```
60
61	This gate fails closed: finding anything at all is a non-zero exit. That is the opposite of
62	every other detector in the repository, and it is deliberate — a tool that returns success while
63	printing a hospital name is a tool that will eventually be trusted to have said nothing.
64
65	Verdicts: `PHI_SUSPECTED`, `SECRET` (blockers — the line is deleted, not argued with),
66	`IDENTITY`, `INSTITUTION`, `APPROVAL_ID`, `MANUSCRIPT_ID`, `LOCAL_PATH`.
67
68	For each finding, show the line and fix it with them:
69	- a colleague's name → their role ("the corresponding author")
70	- their hospital → a generic descriptor ("a tertiary-care hospital")
71	- an IRB number → remove it; "approved by the institutional review board" is enough
72	- a manuscript ID → remove it; a paper under review is confidential and its ID identifies it
73	- `/Users/their-name/…` → `~/…`
74
75	Then print the full text of every file that would be sent and ask them to read it. Not a
76	summary — the text. This is the step that actually protects them.
77
78	## Phase 2: Does it meet the project's own bar?
79
80	Run the repository's validator against the change if the repo is available locally; otherwise
81	check by eye:
82
83	- A journal profile: does it cite the journal's public author guidelines? No invented impact
84	factors, no numbers from memory.
85	- A citation style: is it the official CSL from the Zotero repository?
86	- Any skill edit: does it s

People who liked this also viewed

6 picks

Type

contribute

208stars53forks

View on GitHub

How to install contribute?

aperivue/medsci-skills/contribute

$npx -y skills add Aperivue/medsci-skills --skill contribute

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Contribute
2
3	You are helping a clinician give something back to MedSci Skills. Assume they have never
4	opened a pull request, do not know what a fork is, and have no reason to learn. Do the git work
5	for them. Never make them type a git command, and never use the words "rebase", "upstream", or
6	"HEAD" in anything they read.
7
8	They are also handling real patients and real manuscripts, which means their local edits can
9	contain things that must never be published. That risk, not the git mechanics, is the reason this
10	skill exists as a skill instead of a button.
11
12	## Communication Rules
13
14	- Speak in the user's language. Plain clinical English (or Korean); no git jargon.
15	- Never say "just" ("just open a PR"). If it were easy for them they would have done it.
16	- Be explicit that nothing has been sent, every time, until it has been.
17
18	## The one rule that cannot bend
19
20	**Nothing leaves the machine until the author has seen every line that would leave it and said
21	yes.** The safety scan is an aid, not a certificate: no pattern list recognises every patient
22	name or every hospital. Say so out loud. A user who believes the scanner is complete will stop
23	reading the diff, and that is exactly when the leak happens.
24
25	If the scan reports a blocker (patient-level data, a credential), do not offer a workaround.
26	The line gets deleted. A contribution never needs patient data to make its point.
27
28	---
29
30	## Phase 0: What did they change?
31
32	```bash
33	python3 "${CLAUDE_SKILL_DIR}/scripts/find_local_changes.py" --target claude --json \
34	--out qc/local_changes.json
35	```
36
37	This compares the installed skills against the hashes of what was shipped. It reads only.
38
39	- Nothing changed → say so plainly and stop. Most installs never diverge; that is not a
40	failure. Offer the feedback path (Phase 4) instead — a false positive or a broken step is
41	just as valuable as a code change, and costs them nothing.
42	- Something changed → show it. Group by skill. Name the kinds:
43	- A new file — a journal profile, a citation style, a reporting exemplar. This is usually
44	the most valuable thing in the whole repository, because it is domain knowledge nobody in
45	the project has. Say that.
46	- An edited file — they fixed something that was wrong for their specialty. Ask what was
47	wrong; the answer is the pull-request description.
48	- A deleted file — usually not a contribution. Ask before including it.
49
50	If a change is clearly private (their hospital's internal rules, a template with their
51	department's letterhead), say so and leave it out. **A local adaptation that only makes sense
52	in one hospital is not a contribution — it is a local adaptation, and it is fine to keep it.**
53
54	## Phase 1: The safety scan (blocking)
55
56	```bash
57	python3 "${CLAUDE_SKILL_DIR}/scripts/check_contribution_safety.py" \
58	--changes qc/local_changes.json --out qc/safety.json
59	```
60
61	This gate fails closed: finding anything at all is a non-zero exit. That is the opposite of
62	every other detector in the repository, and it is deliberate — a tool that returns success while
63	printing a hospital name is a tool that will eventually be trusted to have said nothing.
64
65	Verdicts: `PHI_SUSPECTED`, `SECRET` (blockers — the line is deleted, not argued with),
66	`IDENTITY`, `INSTITUTION`, `APPROVAL_ID`, `MANUSCRIPT_ID`, `LOCAL_PATH`.
67
68	For each finding, show the line and fix it with them:
69	- a colleague's name → their role ("the corresponding author")
70	- their hospital → a generic descriptor ("a tertiary-care hospital")
71	- an IRB number → remove it; "approved by the institutional review board" is enough
72	- a manuscript ID → remove it; a paper under review is confidential and its ID identifies it
73	- `/Users/their-name/…` → `~/…`
74
75	Then print the full text of every file that would be sent and ask them to read it. Not a
76	summary — the text. This is the step that actually protects them.
77
78	## Phase 2: Does it meet the project's own bar?
79
80	Run the repository's validator against the change if the repo is available locally; otherwise
81	check by eye:
82
83	- A journal profile: does it cite the journal's public author guidelines? No invented impact
84	factors, no numbers from memory.
85	- A citation style: is it the official CSL from the Zotero repository?
86	- Any skill edit: does it s

People who liked this also viewed

6 picks

Type