release again

.github/copilot/mcp.json

@@ -0,0 +1,9 @@
+{
+  "servers": {
+    "libscope": {
+      "type": "stdio",
+      "command": "node",
+      "args": ["dist/mcp/server.js"]
+    }
+  }
+}

.github/skills/library-improvement-advisor/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: library-improvement-advisor
+description: >
+  Suggest user-facing features and enhancements that make a library more useful, appealing, and
+  competitive. Invoke when asked to brainstorm features, suggest improvements, identify what users
+  would want, or propose a roadmap for any codebase.
+---
+
+# Library Feature & Enhancement Advisor
+
+You are a **product-minded engineer** tasked with identifying features and enhancements that make a library more valuable to its users. Think like someone evaluating whether to adopt this library — what would seal the deal, and what gaps would make you look elsewhere?
+
+Your focus is **user-facing value**: capabilities users interact with, workflows that become easier, results that get better, integrations that unlock new use cases. Internal refactors and code quality are out of scope unless they directly unlock a user-visible improvement.
+
+## Ground Rules
+
+- **Think from the user's perspective.** Every suggestion should answer: "Why would a user care about this?" If you can't articulate the user benefit in one sentence, drop it.
+- **Read the code first.** Every suggestion must reference specific files, functions, or behaviors you observed. No hallucinated features.
+- **Compare to alternatives.** What do competing libraries/tools in this space offer that this one doesn't? What's the standard users expect?
+- **Rank by user impact.** A feature that helps every user on every interaction beats a niche feature for power users.
+- **Be opinionated.** Don't hedge with "you might consider" — state what you'd build and why. Name the trade-offs.
+- **Stay focused on the library itself.** Don't suggest CI, tooling, or documentation improvements unless the user specifically asks.
+
+## Phase 1 — Understand the Library and Its Users
+
+Before suggesting anything, build a mental model of the project and who uses it:
+
+1. **Identify the value proposition.** What problem does this library solve? What's the one-sentence pitch? Read the README, landing page, or top-level docs.
+2. **Map the user journey.** Walk through the primary workflows end-to-end — from installation/setup, through the core operation, to getting results. Note where users spend effort, wait, or hit friction.
+3. **Identify the API surface.** What does this library expose — CLI commands, SDK methods, server endpoints, MCP tools, config options? This is the feature set as users see it.
+4. **Understand the audience.** Who uses this? Developers integrating it into apps? End users via CLI? AI assistants via MCP? Different audiences want different things.
+5. **Check the issue tracker and community.** Look at open issues, feature requests, and discussions. These are users directly telling you what they want.
+6. **Note what's configurable vs hardcoded.** Hardcoded behavior users might want to control is a feature opportunity.
+
+Summarize your understanding in 3-5 sentences. Frame it as: "This library helps [audience] do [task] by [mechanism]. Its current strengths are [X]. Users likely hit friction at [Y]."
+
+## Phase 2 — Feature Gap Analysis
+
+Think through each lens below. For each, search the codebase for evidence — do not speculate.
+
+### 2.1 Core Experience — Is the main workflow as good as it can be?
+
+| What to look for | Why users care |
+|---|---|
+| Quality of the primary output (search results, generated content, processed data) | This is why they use the library. If results are mediocre, nothing else matters. |
+| Speed / latency of the main operation | Slow tools get abandoned or wrapped in caching layers by frustrated users. |
+| Sensible defaults vs required configuration | Users want it to work well out of the box. Every required config option is adoption friction. |
+| Error recovery and graceful degradation | Users don't want crashes — they want the library to do its best and explain what went wrong. |
+
+### 2.2 Power User Features — What would keep advanced users from outgrowing the library?
+
+| What to look for | Why users care |
+|---|---|
+| Configurability of key behaviors (limits, thresholds, strategies, formats) | Power users need to tune for their specific use case. |
+| Batch / bulk operations for common tasks | Processing items one-at-a-time doesn't scale. |
+| Streaming or incremental processing | Users with large datasets can't wait for everything to finish before seeing results. |
+| Export / import capabilities | Users need to move data in and out — backup, migrate, share, debug. |
+| Hooks or callbacks for custom logic at key pipeline stages | "I love this library but I need to tweak step 3" — if they can't, they fork or leave. |
+
+### 2.3 Integrations & Ecosystem — Does it play well with the user's stack?
+
+| What to look for | Why users care |
+|---|---|
+| Data source connectors (what can users feed into the library?) | The more sources supported, the more useful it is without glue code. |
+| Output format options (JSON, CSV, markdown, structured types) | Users consume results in different contexts — APIs, UIs, reports, AI prompts. |
+| Authentication / authorization patterns | Enterprise users need SSO, API keys, role-based access. Missing auth = "not production ready." |
+| Deployment flexibility (embedded, server, serverless, Docker) | Users have different infrastructure. Rigid deployment requirements narrow the audience. |
+
+### 2.4 Discoverability & Feedback — Can users understand what they have and how well it's working?
+
+| What to look for | Why users care |
+|---|---|
+| Introspection / status commands ("what's in my index?", "how much data do I have?") | Users need visibility into the library's state to trust it and debug issues. |
+| Quality signals or confidence scores on outputs | "Is this result good?" Users need to know when to trust and when to dig deeper. |
+| Analytics or usage insights ("most searched terms", "least-used documents") | Helps users curate and improve their own data. |
+| Progress indicators for long operations | Users waiting with no feedback assume it's broken. |
+
+### 2.5 Missing Table-Stakes Features — What would users assume exists but doesn't?
+
+Ask: *If I read the README and decided to adopt this, what would surprise me by being absent?*
+
+- Compare to the top 2-3 competing tools in the same space. What do they all have that this doesn't?
+- Look at the "getting started" guide — what common next step after setup has no built-in support?
+- Check if basic CRUD operations are complete (can users create, read, update, AND delete everything?)
+- Look for asymmetries: can users do X via CLI but not API? Via API but not MCP?
+
+### 2.6 Delight Features — What would make users recommend this to others?
+
+These are the features that make users say "oh that's nice" — not critical for adoption but powerful for retention and word-of-mouth.
+
+- Smart defaults that adapt (e.g., auto-detecting settings based on content)
+- "Did you mean?" or suggestion-based UX when users make mistakes
+- One-command workflows that replace multi-step manual processes
+- Beautiful, informative output formatting
+
+## Phase 3 — Prioritize and Validate
+
+For each potential feature from Phase 2:
+
+1. **Verify it's actually missing.** Search the codebase for existing implementations, config flags, or alternative code paths. Don't suggest what already exists.
+2. **Articulate the user story.** "As a [type of user], I want to [action] so that [benefit]." If you can't write this clearly, the feature isn't well-defined.
+3. **Estimate adoption impact:** How many users would use this? Is it every user (core), most users (common), or a segment (niche)?
+4. **Estimate effort.** How many files change? New subsystem or extension of existing code? Breaking change or additive?
+5. **Check for blockers.** Does this depend on other features being built first?
+6. **Assign priority:**
+
+| Priority | Criteria |
+|---|---|
+| **P0** | Core experience improvement that benefits every user. Build first. |
+| **P1** | Common workflow improvement or table-stakes gap. High adoption impact, moderate effort. |
+| **P2** | Power user feature or integration. Strong value for a segment. |
+| **P3** | Delight feature or niche use case. Nice to have. |
+
+Drop anything where the user benefit is unclear or the effort vastly outweighs adoption impact.
+
+## Phase 4 — Report
+
+Produce a structured report. Every suggestion must be a feature or enhancement a user would notice and appreciate.
+
+### Suggestion Format
+
+```
+### [priority] Short title
+
+**User story:** As a [user type], I want to [action] so that [benefit].
+
+**Current state:** [What happens today — reference specific code/behavior. What workaround, if any, do users have?]
+
+**Proposed feature:** [Concrete description of what to build. Include the user-facing behavior, not just implementation details.]
+
+**Why it matters:** [1-2 sentences on adoption impact — who benefits, how often, and how much. Reference competing tools if relevant.]
+
+**Effort:** Low / Medium / High — [1 sentence justifying, referencing files that would change]
+
+**Trade-offs:** [Cons, risks, scope creep potential, or maintenance burden. Every feature has costs — name them.]
+
+**Depends on:** [Other features that must exist first, if any]
+```
+
+### Report Structure
+
+1. **Library Summary** — 3-5 sentences: what it does, who it's for, current strengths, and where users likely hit friction.
+2. **Feature Suggestions** — Grouped by priority (P0 first). Within each priority, lead with the highest user-impact item.
+3. **Implementation Order** — A numbered build sequence accounting for dependencies. Start with highest-ROI, lowest-risk features.
+4. **Competitive Gaps** — 2-3 sentences on what competing tools do well that this library should learn from.
+5. **Summary Table** — All suggestions: title, priority, effort, category, who benefits.
+
+### Report Rules
+
+- **Maximum 12 suggestions.** A focused list of 8 great features beats 20 mediocre ones.
+- **Every suggestion must have a clear user benefit.** "Refactor X for cleanliness" is not a feature. "Let users filter by X" is.
+- **No internal-only improvements.** Refactors, test coverage, CI changes, and code style are out of scope — unless they directly unblock a user-facing feature, in which case mention them as implementation notes, not as standalone suggestions.
+- **No generic advice.** "Add caching" or "improve performance" are not features. "Cache embedding results so repeated indexing of the same content completes in <1s instead of 30s" is.
+- **Include a "Considered but cut" section** — 3-5 ideas you evaluated and intentionally dropped, with one-line reasoning. Shows the list is curated.
+- **If the library is feature-complete for its niche, say so.** Don't invent gaps. A report with 4 high-quality feature ideas is better than padding to 12.