By name: oh-my-second-opinion description: "Contributor workflow for integrating individual review skills into the Second Opinion repo."
Oh My Second Opinion (Contributor Skill)
Purpose
Guide contributors who provide an individual SKILL.md. Extract their process, policy, fragment, and expert content, integrate shared parts into the repo, and preserve attribution for the contributor's unique expertise.
Scope & Trigger
Use when a contributor wants to add or integrate their review skill into this repository. The contributor typically provides a SKILL.md or equivalent text.
Safety & Preflight
- Operate on the current working directory as the target repo.
- Confirm these paths exist before edits: README.md, taxonomy.md, experts/, processes/, policies/, fragments/.
- Read README.md and follow its contributor and taxonomy guidance.
- Do not modify the main SKILL.md unless explicitly requested.
- If the repo structure is missing, stop and ask for confirmation or a new path.
Workflow (Required)
- Intake
- Ask the user about their language usage promptly and make sure all the following interaction uses this language.
- Ask for contributor handle/name and the SKILL.md text or path.
- Ask for any preferred attribution or naming constraints.
- Parse and Classify Split the provided content into these buckets:
- Process: multi-step workflow(s) with ordered steps and output contract.
- Policy: always-on guardrails or organization-wide constraints.
- Fragment: reusable formatting, checklists, output templates, evidence rules.
- Expert: atomic rules or heuristics with tags or component.
- Unknown: unclear content (ask for clarification).
2b) Taxonomy Check
- If the submission introduces new tags, propose taxonomy.md updates.
- Follow the README.md taxonomy guidance and keep tags in English.
- Process Admission Gate (Strict) Because processes are scarce, compare the submitted process to existing ones:
- Goal overlap
- Workflow structure
- Activation/trigger conditions
- Cost/priority profile
If overlap is high, recommend merging or extending an existing process. Only create a new process if it is materially distinct (new risk class, workflow structure, or activation trigger).
- Integration Proposal (Mandatory) Propose:
- Which parts go to shared directories (fragments/, policies/, processes/)
- Which parts remain attributed under experts/
/ or processes/ / - Any deduplication or refinement steps
- Any required taxonomy.md updates and related test updates
- Naming choices for ids and files Explain each concept you mention (policies, experts, processes, fragments, etc.) as if the contributor has not read this project's documentation.
- Rationale Output (Mandatory) Explain the reasoning for each integration choice. Example:
- "Moved checklist to fragments because it is reusable and non-attributed."
- "Kept concurrency heuristics under experts/
because it is personal." - "Merged policy with existing security policy due to identical constraints."
Confirmation Gate (Mandatory) Ask the contributor to confirm or revise the plan before applying changes.
Apply Changes After confirmation:
- Create/update files in experts/, processes/, policies/, fragments/.
- Update tests if new assets are added (tests/test_reviewers.py or tests/test_assets.py).
- Keep changes minimal and focused on the approved plan.
- Follow-up Loop Stay available for further questions or adjustments until the contributor is satisfied.
Integration Rules
- Cardinal rule: all assets and code in this repo must be in English, except for language-specific templates.
- Fragments: reusable guidance or formatting with no personal attribution.
- Policies: always-on constraints; name by domain (security, compat, etc.).
- Processes: curated workflows; require explicit justification.
- Experts: contributor-specific rules and heuristics.
- Deduplicate when overlap is high; preserve attribution notes in provenance or meta.yaml when merging.
Output Style
- Provide a short plan summary, then the rationale, then ask for confirmation.
- Use concise, actionable wording.