borrow-ideas-skill.md

name	description
borrow-ideas	Analyze external resources (URLs, images, code snippets, GitHub repos, product pages, design screenshots) and critically evaluate what ideas can be borrowed to improve this app. Use when the user shares a link, screenshot, codebase, design, or any external resource they want to draw inspiration from.

Borrow Ideas

Analyze an external resource, cross-reference it against this app's documentation, business logic, mission, and codebase, then deliver a critical assessment of borrowable ideas.

Workflow

1. Ingest the Resource

Determine resource type and extract maximum information:

• URL to a webpage/article/product: Use WebFetch to read the page content. If it's a docs site with multiple pages, follow key links to build a complete picture.
• GitHub repository URL: Fetch the repository with opensrc to get the full source code, then explore the codebase thoroughly — README, docs, source files, architecture.

  npx opensrc <owner>/<repo>

  Then read from opensrc/ directory. Check opensrc/sources.json for available packages.
• npm package or library: Fetch with opensrc by package name.

  npx opensrc <package-name>

• Image/screenshot: Read the image file directly. Analyze the design, layout, UX patterns, copy, and interactions visible.
• Code snippet: Analyze the code directly from the user's message.
• Docs site URL: Traverse the site — fetch the main page, identify the navigation/sitemap, then fetch key pages to understand the full scope.

Goal: Build a thorough understanding of what the resource does, how it works, what makes it interesting, and what specific patterns/ideas it contains.

2. Review Own App Context

Read project documentation to understand our own app deeply:

1. Mission & vision: Read .docs/platform/overview.md
2. Architecture: Read .docs/platform/architecture.md
3. Design vision: Read .docs/platform/design.md
4. Roadmap: Read .docs/platform/roadmap.md
5. Relevant patterns: Search .docs/patterns/ for patterns related to the resource's domain
6. Existing implementations: Search the codebase (app/, server/, layers/) for similar features or approaches

3. Deliver the Analysis

Structure the output as follows:

What This Resource Does Well

Concise summary of the resource's strongest ideas, patterns, or implementations. Be specific — name the exact features, design patterns, UX flows, or technical approaches.

Relevance to Eslyn

How does this relate to our mission (single-threaded personal AI assistant with sophisticated memory)? Keep this concise. You may mention overall alignment, but do not spend many lines on abstract scoring.

Findings Index

List all meaningful findings in a single table. Do not split product, UX, technical, prompt, or instruction ideas into separate sections. If the resource contains interesting prompts, system instructions, tool-use patterns, or other LLM interaction ideas, explicitly consider them during the analysis and include them as normal findings when they are worth borrowing, testing, or skipping.

Use this exact table shape:

## 📋 Findings Index

| # | Idea | Verdict | Priority / Effort |
|---|---|---|---|
| 1. | <Short title> (<Type>) | ✅ Borrow / 🧪 Test / ⛔ Skip | 🔴 High · ⚒️ Medium |

Rules:

• Use plain numbered items: 1., 2., 3.. Do not invent IDs like BI-01.
• Put the title and type in the same cell: <Title> (UX), <Title> (Product), <Title> (Technical), <Title> (Prompt), etc.
• Remove separate columns for alignment and references.
• Combine priority and effort into one cell.
• Use emojis for visual scanning:
  • Verdict: ✅ Borrow, 🧪 Test, ⛔ Skip
  • Priority: 🔴 High, 🟡 Medium, 🟢 Low
  • Effort: 🪶 Small, ⚒️ Medium, 🧱 Large

Include both positive and negative findings in the same index. If something should be skipped, it still belongs in the table with ⛔ Skip.

Details

After the index, expand each finding in order using a compact two-column table.

Use this exact format per finding:

## 🔍 Details

### 1. <Short title> (<Type>)

| Field | Value |
|---|---|
| Verdict | ✅ Borrow |
| Priority / Effort | 🔴 High · ⚒️ Medium |
| Notes | <Paragraph 1 explaining the idea or pattern.><br><br><Paragraph 2 explaining why/how it fits or does not fit Eslyn.><br><br><Paragraph 3 explaining how to implement or adapt it in our app, or why to avoid it.> |

Rules:

• Do not add labels like Summary, Why, or Implementation inside Notes.
• Write the Notes cell as three short paragraphs:
  • what the idea/pattern is
  • why/how it fits Eslyn, or why it does not
  • how to implement/adapt it, or why to skip it
• Use <br><br> between paragraphs inside the markdown table cell.
• Keep the prose concrete and tied to Eslyn's product shape, architecture, and roadmap.
• Mention relevant files or docs naturally in the implementation paragraph when useful, but do not add a separate refs row.

Guidelines

• Be critical, not enthusiastic. Not everything is worth borrowing. If the resource has little relevance, say so directly.
• Prioritize ideas that align with the app's existing roadmap and architecture. Avoid suggesting rewrites or fundamental pivots unless the idea is truly transformational.
• When the resource is a full project/codebase, don't just skim — traverse docs, key source files, and architecture to understand the full picture before making recommendations.
• Keep implementation suggestions grounded in our actual tech stack and patterns. Reference specific files and patterns from .docs/ when suggesting how to implement.
• If an idea is already partially implemented in our codebase, note what exists and what the resource does differently/better.
• Prompt, tool-use, and instruction patterns are not a bonus section. Evaluate them with the same rigor as UX and product ideas, and include them in the main findings when relevant.