social-cc-plugin 1.1.0__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,65 @@
1
+ ---
2
+ name: agentic-session-debugger
3
+ description: Use when diagnosing Claude Code session failures, scope drift, loop traps, hidden state, context limits, PATH problems, permission failures, or stuck agent workflows.
4
+ ---
5
+
6
+ # Agentic Session Debugger
7
+
8
+ ## When to use
9
+
10
+ Use this skill when a Claude Code or agentic coding session behaves unreliably and the user needs root cause diagnosis rather than another attempt at the same command.
11
+
12
+ ## Inputs
13
+
14
+ - User goal.
15
+ - Recent commands or actions.
16
+ - Error messages.
17
+ - Files or tools involved.
18
+ - Current working directory.
19
+ - Permission and environment constraints.
20
+ - What changed just before the failure.
21
+
22
+ ## Workflow
23
+
24
+ 1. Restate the intended outcome.
25
+ 2. Identify the failure class, tool, knowledge, communication, permission, environment, or context.
26
+ 3. Capture exact evidence from logs, errors, tests, or terminal output.
27
+ 4. Check scope drift, repeated loops, hidden state, stale context, and conflicting instructions.
28
+ 5. Check environment issues, including PATH, shell, dependency version, working directory, and permissions.
29
+ 6. Reduce the problem to the smallest reproducible step.
30
+ 7. Propose the smallest correction and a verification command.
31
+ 8. Record the lesson if the failure pattern should not recur.
32
+
33
+ ## Output
34
+
35
+ Return:
36
+
37
+ - Intended outcome.
38
+ - Failure class.
39
+ - Evidence.
40
+ - Root cause hypothesis.
41
+ - Minimal reproduction.
42
+ - Fix plan.
43
+ - Verification step.
44
+ - Residual risk.
45
+
46
+ ## Verification
47
+
48
+ - The diagnosis cites actual evidence, not only model intuition.
49
+ - The smallest reproducible case is identified or the reason it cannot be reproduced is stated.
50
+ - Permission failures are not solved by destructive commands.
51
+ - The fix has a clear pass or fail check.
52
+ - Repeated session errors are converted into a reusable rule.
53
+
54
+ ## Safety
55
+
56
+ Do not run destructive commands unless the user explicitly requested them and the target path is verified. Do not print secrets from logs. Redact tokens, passwords, private paths, and personal identifiers.
57
+
58
+ ## Example prompt
59
+
60
+ "Claude Code keeps looping on a failing validator and says the file is fixed, but CI still fails. Diagnose the session."
61
+
62
+ Expected smoke output:
63
+
64
+ - Failure class, evidence, minimal reproduction, likely hidden-state or stale-assumption issue.
65
+ - A concrete verification command and a smaller next fix.
@@ -0,0 +1,65 @@
1
+ ---
2
+ name: ai-disclosure-auditor
3
+ description: Use when auditing AI contribution metadata, human review state, model alias, model dated value, citation counts, fabricated citation count, or disclosure standard across booklets.
4
+ ---
5
+
6
+ # AI Disclosure Auditor
7
+
8
+ ## When to use
9
+
10
+ Use this skill before release, after AI-assisted drafting, or during citation cleanup when the user needs disclosure metadata to match the actual workflow.
11
+
12
+ ## Inputs
13
+
14
+ - Booklet file or set of booklet files.
15
+ - Actual AI tools used.
16
+ - Human review state.
17
+ - Verified citation count.
18
+ - Fabricated citation count.
19
+ - Disclosure standard expected by the project or publisher.
20
+
21
+ ## Workflow
22
+
23
+ 1. Read the frontmatter before the body.
24
+ 2. Confirm `ai_assisted` reflects actual AI use.
25
+ 3. Confirm `ai_tools.name`, `vendor`, `model_alias`, `model_dated`, and `role`.
26
+ 4. Classify contribution level using the project policy, not tone impression.
27
+ 5. Confirm `human_review` and `human_review_date`.
28
+ 6. Compare `verified_citations_count` with the reference list and in-text citation set when available.
29
+ 7. Confirm `fabricated_citations_count` is zero for release material.
30
+ 8. Check `disclosure_standard` against the current project policy.
31
+ 9. Recommend frontmatter corrections and any body disclosure corrections.
32
+
33
+ ## Output
34
+
35
+ Return:
36
+
37
+ - Disclosure verdict.
38
+ - Field-level audit table.
39
+ - Contribution level rationale.
40
+ - Human review evidence needed.
41
+ - Citation count reconciliation.
42
+ - Fabricated citation risk notes.
43
+ - Required release blockers.
44
+
45
+ ## Verification
46
+
47
+ - Model alias and dated model fields are both present.
48
+ - Human review is not upgraded without evidence.
49
+ - Citation counts are not copied from older aggregate files without checking the current file.
50
+ - Release material with fabricated citations is blocked.
51
+ - Aggregate disclosure and per-file frontmatter are consistent.
52
+
53
+ ## Safety
54
+
55
+ Do not expose prompts, logs, private notes, credentials, unpublished clinical data, or reviewer identities unless the user explicitly supplies publication-safe excerpts. Keep the audit at metadata and disclosure level when private context is not needed.
56
+
57
+ ## Example prompt
58
+
59
+ "Audit the AI disclosure fields for all released booklets and tell me which files block v1.1.0."
60
+
61
+ Expected smoke output:
62
+
63
+ - A file-by-file table with pass, partial, or fail.
64
+ - A release-blocker list.
65
+ - A count summary for contribution levels and human review state.
@@ -0,0 +1,61 @@
1
+ ---
2
+ name: apa-doi-verifier
3
+ description: Use when checking APA 7 references, DOI reality, Crossref or PubMed metadata, fabricated citation risk, or booklet 007 citation hygiene for social science manuscripts.
4
+ ---
5
+
6
+ # APA DOI Verifier
7
+
8
+ ## When to use
9
+
10
+ Use this skill when a bibliography, reference list, manuscript section, or AI-generated citation set needs APA 7 cleanup and DOI verification before it is trusted.
11
+
12
+ ## Inputs
13
+
14
+ - Reference list or citations to check.
15
+ - Manuscript discipline.
16
+ - Journal style constraints, if stricter than APA 7.
17
+ - Whether live Crossref, PubMed, publisher, or library lookup is available.
18
+
19
+ ## Workflow
20
+
21
+ 1. Preserve the user's original reference list as the comparison baseline.
22
+ 2. Split references into journal articles, books, chapters, reports, guidelines, preprints, theses, and web sources.
23
+ 3. For journal articles, check title, authors, year, journal, volume, issue, pages, and DOI.
24
+ 4. Use Crossref as the first DOI lane when browsing or a Crossref tool is available.
25
+ 5. Use PubMed or publisher pages as a second lane for biomedical, clinical, psychology, and health sources.
26
+ 6. Flag ambiguous or non-resolving references instead of repairing them by guesswork.
27
+ 7. Convert valid entries into APA 7 style.
28
+ 8. Classify fabricated citation risk as low, medium, high, or confirmed fabricated.
29
+
30
+ ## Output
31
+
32
+ Return:
33
+
34
+ - Cleaned APA 7 reference list.
35
+ - Verification table with status per reference.
36
+ - DOI corrections.
37
+ - Items without DOI and why that may be acceptable.
38
+ - Fabricated citation risk classification.
39
+ - Open verification tasks.
40
+
41
+ ## Verification
42
+
43
+ - Every DOI resolves or is explicitly marked unresolved.
44
+ - No DOI is invented from a title, author, or journal pattern.
45
+ - Author order is preserved unless a source confirms otherwise.
46
+ - Books and official reports are not forced into DOI format.
47
+ - Risk classification distinguishes missing DOI from nonexistent source.
48
+
49
+ ## Safety
50
+
51
+ Do not use synthetic metadata as final truth. Do not claim Crossref, PubMed, Scopus, or Web of Science verification unless it was actually performed in the current session or the user supplied exported evidence.
52
+
53
+ ## Example prompt
54
+
55
+ "Verify these 12 APA references for DOI correctness and classify fabricated citation risk."
56
+
57
+ Expected smoke output:
58
+
59
+ - A table with reference number, source type, DOI status, metadata status, and risk.
60
+ - Corrected APA 7 entries only for verified or user-confirmed sources.
61
+ - A short list of unresolved items for manual lookup.
@@ -0,0 +1,63 @@
1
+ ---
2
+ name: bilingual-booklet-pairing
3
+ description: Use when drafting or reviewing paired tr.md and en.md booklets, checking title parity, frontmatter agreement, heading alignment, translation coverage, or cultural adaptation notes.
4
+ ---
5
+
6
+ # Bilingual Booklet Pairing
7
+
8
+ ## When to use
9
+
10
+ Use this skill whenever a booklet exists or is planned in both Turkish and English and the user needs parity rather than a loose translation.
11
+
12
+ ## Inputs
13
+
14
+ - Paths or text for `tr.md` and `en.md`.
15
+ - Booklet identifier.
16
+ - Target release status.
17
+ - Any known culturally specific examples that should not be translated literally.
18
+
19
+ ## Workflow
20
+
21
+ 1. Confirm both language files exist.
22
+ 2. Compare frontmatter fields, especially `booklet_id`, `version`, `date_published`, `date_last_revised`, `human_review`, citation counts, fabricated citation counts, disclosure standard, license, and status.
23
+ 3. Check that `language` differs correctly and titles are semantically aligned.
24
+ 4. Compare heading structure and section order.
25
+ 5. Identify missing paragraphs, unmatched tables, unmatched diagrams, or unmatched reference items.
26
+ 6. Mark cultural adaptation points where exact translation would weaken the text.
27
+ 7. Check that examples, local institutions, and legal references are appropriate for the language version.
28
+ 8. Return a parity verdict.
29
+
30
+ ## Output
31
+
32
+ Return:
33
+
34
+ - Pair identity.
35
+ - Frontmatter parity table.
36
+ - Heading parity table.
37
+ - Content gaps.
38
+ - Cultural adaptation notes.
39
+ - Citation and disclosure parity.
40
+ - Verdict, pass, partial, or fail.
41
+ - Required fixes before release.
42
+
43
+ ## Verification
44
+
45
+ - Both files share the same `booklet_id`.
46
+ - Both files carry the same citation counts and fabricated citation counts.
47
+ - Heading order is either matched or intentionally adapted.
48
+ - Legal, clinical, and regional terms are not flattened into misleading literal translations.
49
+ - Release status is not recommended until both files pass parity.
50
+
51
+ ## Safety
52
+
53
+ Do not insert private examples, identifiable clinical material, or institutional secrets to make a translation feel realistic. Use anonymized or generic examples unless the user supplies publication-safe text.
54
+
55
+ ## Example prompt
56
+
57
+ "Check parity between booklets/009-ethics-irb/009-01-0001/tr.md and en.md before release."
58
+
59
+ Expected smoke output:
60
+
61
+ - Frontmatter parity, pass or specific field mismatches.
62
+ - Heading parity, pass or named missing headings.
63
+ - Cultural adaptation notes for KVKK, GDPR, IRB, and ethics committee terminology.
@@ -0,0 +1,65 @@
1
+ ---
2
+ name: ethics-irb-ai-protocol
3
+ description: Use when preparing ethics committee, IRB, KVKK, GDPR, EU AI Act, data minimization, and AI disclosure checklists for social science or clinical research projects.
4
+ ---
5
+
6
+ # Ethics IRB AI Protocol
7
+
8
+ ## When to use
9
+
10
+ Use this skill when a research project uses AI in recruitment, consent, data handling, coding, analysis, writing, supervision, or participant-facing interaction.
11
+
12
+ ## Inputs
13
+
14
+ - Research design.
15
+ - Participant population.
16
+ - Data types.
17
+ - AI use case.
18
+ - Jurisdiction or institution.
19
+ - Whether data are identifiable, pseudonymized, anonymized, or synthetic.
20
+ - Submission target, such as ethics committee, IRB, journal, or grant body.
21
+
22
+ ## Workflow
23
+
24
+ 1. Separate screening, research design, data processing, analysis, and writing uses of AI.
25
+ 2. Identify participant risk, vulnerability, consent implications, and data sensitivity.
26
+ 3. Apply data minimization, purpose limitation, access control, retention, and deletion rules.
27
+ 4. Map regulatory layers, including local ethics rules, KVKK, GDPR, EU AI Act transparency duties, and publisher disclosure rules when relevant.
28
+ 5. Define what data must never enter an AI system.
29
+ 6. Draft the AI-use disclosure for methods, ethics application, consent form, and manuscript note.
30
+ 7. Produce a protocol checklist with approval blockers.
31
+
32
+ ## Output
33
+
34
+ Return:
35
+
36
+ - AI use map.
37
+ - Data flow summary.
38
+ - Ethics and legal checklist.
39
+ - Consent language draft.
40
+ - Disclosure language draft.
41
+ - Data minimization rules.
42
+ - Approval blockers.
43
+ - Questions for the ethics committee.
44
+
45
+ ## Verification
46
+
47
+ - Identifiable clinical or participant data are not sent to AI tools by default.
48
+ - Consent language names AI involvement clearly when participant data are affected.
49
+ - Jurisdictional claims are marked as checklist guidance unless a legal source was verified.
50
+ - High-risk or participant-facing AI use is escalated for human approval.
51
+ - Disclosure language matches the actual workflow.
52
+
53
+ ## Safety
54
+
55
+ Do not provide legal advice as a final authority. Do not process raw clinical records, identifiable participant data, or institution secrets. Ask for anonymized summaries when examples are needed.
56
+
57
+ ## Example prompt
58
+
59
+ "Create an ethics committee AI-use checklist for a qualitative interview study where anonymized transcripts may be coded with AI assistance."
60
+
61
+ Expected smoke output:
62
+
63
+ - Data flow, consent, minimization, disclosure, and human oversight sections.
64
+ - A clear rule that non-anonymized transcripts must not be uploaded to AI systems.
65
+ - Approval blockers for vulnerable populations or identifiable data.
@@ -0,0 +1,66 @@
1
+ ---
2
+ name: memory-vault-architect
3
+ description: Use when designing a research vault, MOC structure, source passport, frontmatter standard, retrieval pattern, or durable note architecture for long-running social science projects.
4
+ ---
5
+
6
+ # Memory Vault Architect
7
+
8
+ ## When to use
9
+
10
+ Use this skill when the user needs an academic memory system that can survive multiple projects, long time horizons, bilingual notes, and repeated AI-assisted work.
11
+
12
+ ## Inputs
13
+
14
+ - Research domains.
15
+ - Active projects.
16
+ - Source types.
17
+ - Preferred note tool, if any.
18
+ - Required languages.
19
+ - Collaboration and privacy constraints.
20
+ - Retrieval goals.
21
+
22
+ ## Workflow
23
+
24
+ 1. Identify the vault's purpose, such as literature review, manuscript pipeline, clinical training, teaching, or grant work.
25
+ 2. Separate durable knowledge, active projects, source records, daily work, and archived material.
26
+ 3. Design MOCs for domains, projects, methods, people, institutions, and outputs.
27
+ 4. Define frontmatter fields for source passports, project notes, meeting notes, and synthesis notes.
28
+ 5. Specify retrieval patterns, including tags, aliases, backlinks, saved searches, and index notes.
29
+ 6. Define rules for AI-generated notes, human-reviewed notes, and uncertain claims.
30
+ 7. Provide a migration plan that avoids reorganizing everything at once.
31
+
32
+ ## Output
33
+
34
+ Return:
35
+
36
+ - Vault objective.
37
+ - Folder architecture.
38
+ - MOC map.
39
+ - Frontmatter schemas.
40
+ - Source passport template.
41
+ - Retrieval pattern.
42
+ - Migration steps.
43
+ - Maintenance ritual.
44
+
45
+ ## Verification
46
+
47
+ - The architecture separates sources from interpretations.
48
+ - The system works without relying on a single proprietary tool.
49
+ - AI-generated content is visibly marked until reviewed.
50
+ - Sensitive clinical or participant material has a protected lane.
51
+ - The migration plan is small enough to execute.
52
+
53
+ ## Safety
54
+
55
+ Do not ask for private vault paths, credentials, raw clinical data, or participant identifiers. Use placeholder paths and anonymized examples unless the user explicitly provides safe local paths.
56
+
57
+ ## Example prompt
58
+
59
+ "Design a bilingual research vault for AI and mental health papers, manuscript drafts, Zotero notes, and reviewer response materials."
60
+
61
+ Expected smoke output:
62
+
63
+ - Folder map.
64
+ - MOC list.
65
+ - Source passport frontmatter.
66
+ - Retrieval rules for sources, claims, and manuscript outputs.
@@ -0,0 +1,61 @@
1
+ ---
2
+ name: rebuttal-traceability-matrix
3
+ description: Use when converting reviewer comments into a traceability matrix, accepted partial rejected categories, manuscript change mapping, and editor response drafts.
4
+ ---
5
+
6
+ # Rebuttal Traceability Matrix
7
+
8
+ ## When to use
9
+
10
+ Use this skill after peer review, revise and resubmit, editorial triage, grant review, or supervisor feedback when comments must be answered systematically.
11
+
12
+ ## Inputs
13
+
14
+ - Reviewer comments.
15
+ - Editor letter, if available.
16
+ - Manuscript section map.
17
+ - Constraints, such as word limit, journal tone, or non-negotiable methodological boundaries.
18
+ - Revised manuscript excerpts, if already drafted.
19
+
20
+ ## Workflow
21
+
22
+ 1. Split comments into atomic claims.
23
+ 2. Label each claim as accepted, partially accepted, rejected with rationale, clarification only, or outside scope.
24
+ 3. Map each claim to manuscript sections, tables, figures, appendices, or cover letter only.
25
+ 4. Identify comments that require new analysis, citation support, transparency language, or limitation framing.
26
+ 5. Draft a traceability matrix.
27
+ 6. Draft response text with a respectful, non-defensive tone.
28
+ 7. Flag contradictions between reviewers and suggest editor-facing framing.
29
+
30
+ ## Output
31
+
32
+ Return:
33
+
34
+ - Reviewer comment matrix.
35
+ - Decision category per comment.
36
+ - Manuscript change map.
37
+ - Required evidence or citation checks.
38
+ - Editor response summary.
39
+ - Reviewer-by-reviewer response draft.
40
+ - Residual risks.
41
+
42
+ ## Verification
43
+
44
+ - Every reviewer comment is represented once.
45
+ - Partial acceptance states exactly what changed and what did not.
46
+ - Rejections are evidence-based and respectful.
47
+ - Manuscript locations are specific enough for a coauthor to verify.
48
+ - No unsupported claim is added to satisfy a reviewer.
49
+
50
+ ## Safety
51
+
52
+ Do not invent manuscript changes. Do not claim analyses were run unless outputs are supplied or verified. Preserve reviewer anonymity and remove private editorial metadata before sharing externally.
53
+
54
+ ## Example prompt
55
+
56
+ "Turn these Reviewer 1 and Reviewer 2 comments into a traceability matrix and draft a response letter outline."
57
+
58
+ Expected smoke output:
59
+
60
+ - A matrix with comment ID, reviewer, issue, decision, manuscript location, action, and response draft.
61
+ - A separate list of unresolved evidence needs.
@@ -0,0 +1,63 @@
1
+ ---
2
+ name: regional-access-workflow
3
+ description: Use when planning lawful academic access through DergiPark, ULAKBIM TR Dizin, HEAL-Link, YOK Thesis Center, institutional VPN, library routes, or regional source records.
4
+ ---
5
+
6
+ # Regional Access Workflow
7
+
8
+ ## When to use
9
+
10
+ Use this skill when a researcher needs a lawful and reproducible route to regional academic sources, especially Turkish, Greek, European, university, thesis, or institutional materials.
11
+
12
+ ## Inputs
13
+
14
+ - Source target or research topic.
15
+ - Country, language, or institution scope.
16
+ - Known databases.
17
+ - Access constraints.
18
+ - Whether the user has authorized institutional access.
19
+
20
+ ## Workflow
21
+
22
+ 1. Classify the source need as journal article, thesis, report, guideline, book, dataset, or policy document.
23
+ 2. Route the search to regional sources such as DergiPark, ULAKBIM TR Dizin, YOK Thesis Center, HEAL-Link, university repositories, or library discovery systems.
24
+ 3. Route international metadata to Crossref, PubMed, Scopus, Web of Science, Semantic Scholar, or OpenAlex when available.
25
+ 4. Record access status, metadata status, DOI status, and full-text status separately.
26
+ 5. Keep login, VPN, and institutional identity steps on the user's side.
27
+ 6. Produce a source passport entry for each located item.
28
+ 7. Flag unresolved access problems and lawful next steps.
29
+
30
+ ## Output
31
+
32
+ Return:
33
+
34
+ - Access route map.
35
+ - Search locations.
36
+ - Metadata fields to capture.
37
+ - DOI and identifier status.
38
+ - Full-text access status.
39
+ - Source passport template.
40
+ - Manual user actions.
41
+ - Blockers and alternatives.
42
+
43
+ ## Verification
44
+
45
+ - The workflow never bypasses paywalls, licenses, or institutional access controls.
46
+ - DOI absence is not treated as evidence that a source is invalid.
47
+ - Regional databases are not replaced by global search alone.
48
+ - Full-text status is separated from metadata existence.
49
+ - User-side login actions are clearly marked.
50
+
51
+ ## Safety
52
+
53
+ Do not request or store VPN credentials, library passwords, proxy URLs containing tokens, or institutional session cookies. Do not download full text through unauthorized routes.
54
+
55
+ ## Example prompt
56
+
57
+ "Find a lawful access workflow for Turkish clinical psychology theses and DergiPark articles on digital addiction."
58
+
59
+ Expected smoke output:
60
+
61
+ - YOK Thesis Center, DergiPark, TR Dizin, Crossref, and library discovery lanes.
62
+ - A source passport template with access status and DOI status.
63
+ - Manual login steps left to the user.
@@ -0,0 +1,67 @@
1
+ ---
2
+ name: repo-release-integrity-check
3
+ description: Use before publishing a release to check README, CATALOG, CHANGELOG, CITATION.cff, Zenodo DOI, GitHub release notes, AI disclosure aggregate, booklet frontmatter, and project skills.
4
+ ---
5
+
6
+ # Repo Release Integrity Check
7
+
8
+ ## When to use
9
+
10
+ Use this skill before a tag, GitHub release, Zenodo archive, DOI announcement, or public repository update when metadata drift would damage citation trust.
11
+
12
+ ## Inputs
13
+
14
+ - Target version.
15
+ - Release date.
16
+ - Changed booklet identifiers.
17
+ - Expected DOI state.
18
+ - GitHub release notes, if drafted.
19
+ - CI status or local validation output.
20
+
21
+ ## Workflow
22
+
23
+ 1. Confirm the target version and whether the change is patch, minor, or major.
24
+ 2. Check README and README.tr status blocks.
25
+ 3. Check CATALOG counts and status rows.
26
+ 4. Check CHANGELOG release entry and Zenodo DOI notes.
27
+ 5. Check CITATION.cff concept DOI, version DOI, date, and version fields.
28
+ 6. Check AI disclosure aggregate against booklet frontmatter.
29
+ 7. Check release booklet frontmatter for human review, citation counts, fabricated citations, disclosure standard, license, and status.
30
+ 8. Check `.claude/skills` discovery if the release includes project skills.
31
+ 9. Check issue templates, PR template, workflows, citation check, and secret scan status.
32
+ 10. Produce release blockers and final go or no-go verdict.
33
+
34
+ ## Output
35
+
36
+ Return:
37
+
38
+ - Version verdict.
39
+ - Metadata checklist.
40
+ - Booklet checklist.
41
+ - Skill checklist.
42
+ - DOI and citation checklist.
43
+ - CI and security checklist.
44
+ - Release blockers.
45
+ - Go or no-go decision.
46
+
47
+ ## Verification
48
+
49
+ - Local validator or CI evidence is included.
50
+ - DOI claims are not marked verified unless checked against the release record.
51
+ - README, CATALOG, CHANGELOG, and AI disclosure aggregate agree.
52
+ - Release status is not assigned to unreviewed or citation-unsafe booklets.
53
+ - Branch protection and required checks are noted when they cannot be applied locally.
54
+
55
+ ## Safety
56
+
57
+ Do not create tags, push releases, alter branch protection, or edit repository settings without explicit user intent and current permission evidence. Do not publish tokens or release credentials.
58
+
59
+ ## Example prompt
60
+
61
+ "Run a pre-release integrity check for v1.1.0 after adding project skills."
62
+
63
+ Expected smoke output:
64
+
65
+ - A go or no-go verdict.
66
+ - A table covering README, catalog, changelog, citation, disclosure, skills, CI, and security.
67
+ - A blocker list with exact files to fix.
@@ -0,0 +1,68 @@
1
+ ---
2
+ name: social-science-literature-triage
3
+ description: Use when starting a social science literature review, scoping databases, choosing language layers, checking DOI coverage, or turning booklet 002 and 007 methods into a search protocol.
4
+ ---
5
+
6
+ # Social Science Literature Triage
7
+
8
+ ## When to use
9
+
10
+ Use this skill before a literature review, scoping review, thesis chapter, grant background, or manuscript introduction when the user needs a defensible search plan rather than an immediate prose draft.
11
+
12
+ ## Inputs
13
+
14
+ - Research question or topic.
15
+ - Discipline and population.
16
+ - Time window.
17
+ - Required languages.
18
+ - Preferred databases or regional indexes.
19
+ - Inclusion and exclusion criteria, if already known.
20
+
21
+ ## Workflow
22
+
23
+ 1. Restate the research aim in one precise sentence.
24
+ 2. Classify the evidence need as exploratory, scoping, systematic, narrative, theoretical, or policy-facing.
25
+ 3. Choose database lanes, such as PubMed, PsycINFO, Scopus, Web of Science, Crossref, Semantic Scholar, DergiPark, ULAKBIM TR Dizin, YOK Thesis Center, HEAL-Link, or institutional library routes.
26
+ 4. Define language layers, at minimum English, Turkish, and any regional language requested by the user.
27
+ 5. Build keyword blocks with synonyms, controlled vocabulary where available, and exclusion terms.
28
+ 6. Specify DOI expectations, including which source types can reasonably lack a DOI.
29
+ 7. Produce inclusion and exclusion criteria.
30
+ 8. Identify early bias risks, missing regional sources, database over-reliance, and likely grey literature needs.
31
+
32
+ ## Output
33
+
34
+ Return a compact protocol with these headings:
35
+
36
+ - Review aim.
37
+ - Evidence type.
38
+ - Database lanes.
39
+ - Search strings.
40
+ - Language strategy.
41
+ - DOI and metadata policy.
42
+ - Inclusion criteria.
43
+ - Exclusion criteria.
44
+ - Risk notes.
45
+ - Next action.
46
+
47
+ ## Verification
48
+
49
+ - The protocol names at least two database lanes.
50
+ - Regional access is considered when the topic involves Türkiye, Greece, education, public health, clinical psychology, or local policy.
51
+ - DOI expectations distinguish journal articles from reports, books, theses, and official guidelines.
52
+ - Search strings are reproducible enough for another researcher to run.
53
+ - No fabricated source claims are introduced.
54
+
55
+ ## Safety
56
+
57
+ Do not request passwords, private vault paths, university database credentials, VPN secrets, or raw clinical data. If full-text access requires a logged-in institution, stop at the lawful access workflow and ask the user to retrieve the file through their own authorized route.
58
+
59
+ ## Example prompt
60
+
61
+ "Scope a Turkish and English literature review on AI-assisted clinical psychology supervision, 2020 to 2026, with DOI discipline and regional database coverage."
62
+
63
+ Expected smoke output:
64
+
65
+ - Evidence type, scoping review.
66
+ - Database lanes, PubMed, PsycINFO or Scopus, Crossref, DergiPark, TR Dizin, YOK Thesis Center.
67
+ - Language strategy, English plus Turkish.
68
+ - DOI policy, DOI required for journal articles when available, not required for laws, official guidance, theses, or books.