open source

<objective> Find open-source solutions for $ARGUMENTS (or the current topic if no arguments provided).

Search for existing libraries, tools, and projects that solve the problem. Don't build what already exists. </objective>

<intake_gate>

<context_analysis> First, analyze $ARGUMENTS to extract what's already provided:

• What problem needs solving
• Language/framework requirements
• License requirements
• Integration constraints

Only ask about genuine gaps - don't re-ask what's already stated. </context_analysis>

<initial_questions> Use AskUserQuestion to ask 2-4 questions based on actual gaps:

If language unclear:

• "What language/framework?" with options: Python, JavaScript/Node, Swift, Go, Rust, Language agnostic, Other

If license unclear:

• "License requirements?" with options: Any open source, Permissive only (MIT/Apache), GPL OK, Commercial use required, Other

If maintenance unclear:

• "How important is maintenance?" with options: Must be actively maintained, Recent activity OK, Abandoned OK if it works, Other

If integration unclear:

• "Must integrate with?" with options: Nothing specific, Existing codebase, Specific framework, Other

Skip questions where $ARGUMENTS already provides the answer. </initial_questions>

<decision_gate> After receiving answers, use AskUserQuestion:

Question: "Ready to search for open-source solutions, or would you like me to ask more questions?"

Options:

1. Start search - I have enough context
2. Ask more questions - There are details to clarify
3. Let me add context - I want to provide additional information

If "Ask more questions" → generate 2-3 contextual follow-ups, then present decision gate again If "Let me add context" → receive input, then present decision gate again If "Start search" → proceed to research </decision_gate>

</intake_gate>

<process> After intake complete:

1. Define what we need (problem, requirements, constraints)
2. Search for open-source options
3. Evaluate each option
4. Verify maintenance status for each option:
   • Check last commit date (not just "last updated" on package registry)
   • Check issue response time (open recent issue, see if maintainers respond)
   • Check contributor count and bus factor (is it one person or a team?)
   • Flag if: last commit >1 year OR all commits from 1 person OR issues go unanswered
5. Assess build vs. use tradeoffs
6. Recommend best option or confirm need to build </process>

<output_format>

Open Source Research: [Need]

Strategic Summary

[2-3 sentences: what's available, recommendation, key consideration]

What we need

[Problem to solve, key requirements]

License requirements

[MIT/Apache/GPL-compatible/etc.]

Options Found

[Option 1: package-name]

• Repo: [GitHub URL]
• What it does: [Brief description]
• Stars/Downloads: [Popularity indicators]
• Last commit: [Date - from repo, not registry]
• Contributors: [Count - note if 1-person project]
• Issue response: [Active/Slow/Inactive - check recent issues]
• License: [License type]
• Fits our need: [Yes/Partial/No] - [why]
• Concerns: [Issues, gaps, risks]

[Option 2: package-name] [Same structure...]

[Option 3: package-name] [Same structure...]

Comparison

Build vs. Use Analysis

Use existing:

• Pros: [Proven solution, community support, faster start]
• Cons: [Less control, potential bloat, dependency risk]

Build custom:

• Pros: [Exact fit, full control, no dependencies]
• Cons: [Complexity to build, maintenance burden]

Recommendation: [Use Option X / Build custom] because [reasoning]

Implementation Context

<claude_context> <if_use>

• package: [exact package name and version]
• install: [installation command]
• docs: [documentation URL]
• examples: [example code or reference]
• gotchas: [known issues, quirks, workarounds] </if_use> <if_build>
• scope: [what to build]
• approach: [technical approach]
• reference: [can use Option X as reference for patterns]
• complexity: [S/M/L] </if_build> <integration>
• imports: [how to import/require]
• patterns: [usage patterns]
• testing: [how to test integration] </integration>

</claude_context>

Next Action: Prototype with chosen library, evaluate deeper, or spec out custom build

Sources

• [Source name/package]: [URL] - [date accessed]
• [Source name/package]: [URL] - [date accessed] </output_format>

<artifact_output> Save the research to a file:

1. Create directory structure if it doesn't exist:

   • [current-working-directory]/artifacts/research/

2. Generate filename from topic:

   • Get current date in YYYY-MM-DD format
   • Slugify the topic (lowercase, hyphens for spaces)
   • Format: YYYY-MM-DD-[topic]-open-source.md
   • Example: 2025-01-15-midi-libraries-open-source.md

3. Write the complete research to the file

4. Report to user: "Saved to artifacts/research/[filename]" </artifact_output>

<success_criteria>

• Search is thorough (not just first result)
• Maintenance status is verified (not abandoned)
• License compatibility is checked
• Build vs. use tradeoff is honest
• Implementation context has exact package info Claude needs
• Recommendation saves complexity without creating technical debt
• Output saved to artifacts/research/ directory </success_criteria>