Update messaging/Think Harder - based on AI reviews on ScienceStudio at the current state

[azehady]

ChatGPT

Alright — no hype, no sugar-coating. Just a straight technical + product take.

I’ll judge this as if I were:

• a VC seeing a cold repo
• a senior engineer deciding whether to contribute
• a real researcher deciding whether to switch tools

---

TL;DR (Brutally honest)

ScienceStudio is intellectually solid, technically coherent, but currently over-ambitious for its maturity and unclear on its sharpest wedge.
It’s a good project, not yet a compelling product.

It can become one — but only if you narrow the scope fast.

---

What’s genuinely strong (and real)

1. The Word + LaTeX unification is legit

This is not hype.

Most people underestimate this, but you’re right:

• ~60–70% of researchers use Word
• ~10–30% use LaTeX
• Almost nobody serves both well

Overleaf ignores Word users
Word ignores LaTeX users
Zotero/Mendeley don’t touch writing ergonomics

👉 This is a real pain point, especially in interdisciplinary labs.

---

2. Agent-agnostic MCP architecture is well thought out

This is one of the most credible parts of the project.

• Using Claude Code / OpenCode as “brains”
• MCP servers as tools
• Local-first philosophy

This avoids:

• model churn risk
• infra lock-in
• the “we built our own bad AI” trap

Technically: 👍
Architecturally: 👍👍

---

3. Local-first positioning is correct

This matters more than people admit:

• Sensitive unpublished research
• Medical / psych data
• Grant drafts
• IP concerns

This is a real differentiator vs Google Docs / Notion AI.

---

Where it’s weak (and this matters)

1. Too many promises, too little visible “wow”

Right now the README claims:

• IDE
• Word replacement
• LaTeX editor
• PDF manager
• Citation engine
• AI assistant
• Focus mode
• Library search
• Claim verification

That’s 6 startups worth of scope.

From the outside, it feels like:

“This could be amazing one day”

But not yet:

“I need this today”

That’s dangerous.

---

2. OnlyOffice integration is a heavy dependency

This is a quiet risk.

OnlyOffice:

• is powerful
• but heavyweight
• and WebView embedding inside VS Code is fragile

If that integration becomes flaky:

• cursor bugs
• lag
• weird selection issues
  you’ll lose users fast.

Researchers tolerate bugs in LaTeX.
They do not tolerate bugs in Word-style editing.

---

3. Unclear primary user

Right now you’re targeting:

• PhD students
• Medical researchers
• CS/Math researchers
• Bio/Psych Word users

These are very different workflows.

A psych PhD writing in Word does not care about:

• MCP servers
• Claude Code
• agent orchestration

They care about:

• citations
• reviewer comments
• formatting
• references not breaking

Right now the product story is engineer-centric, not researcher-centric.

---

4. No single “killer moment”

Ask yourself honestly:

What is the one thing a user tries in 5 minutes and goes:
“Holy sh*t, this is better than Word/Overleaf”?

Right now, that moment is implied, not demonstrated.

---

What I think the project actually is

Not a Word replacement.
Not an IDE.
Not an AI editor.

It’s a research workflow augmentation platform.

And that’s okay — but you must say it clearly.

---

What I would do if this were my project

1. Pick ONE wedge (this is critical)

If I had to choose today:

👉 “Best local-first AI citation + claim-verification tool for Word users.”

Why?

• Largest user base
• Least competition
• Clear pain
• Immediate value

Everything else becomes secondary.

---

2. Reduce visible scope by 50%

Hide or delay:

• Focus Mode
• Multi-agent language
• Brain switching
• PDF annotations

Surface:

• “Select sentence → Add 3 real citations from your library”
• “Verify if this paragraph is actually supported”

That’s a real hook.

---

3. Stop calling it a Word replacement (for now)

That sets impossible expectations.

Instead:

“A research-grade AI layer on top of Word & LaTeX”

Much safer positioning.

---

Final honest verdict

Is this vaporware?
❌ No

Is this a strong technical foundation?
✅ Yes

Is it product-ready or sharply positioned yet?
❌ Not yet

Does it have a real chance if focused?
✅ Absolutely

Right now it’s a great engineering project searching for its narrow, undeniable use-case.

If you want, I can:

• rewrite the README to be brutally clear
• define a 30-day MVP cut
• or help you design the exact “first wow” interaction

Just tell me where you want to take it.

[azehady]

Perplexity:

Honest Review: AIScienceStudio/ScienceStudio

The Bottom Line:
This project appears to be a "wrapper" or "UI-layer" tool trying to ride the massive hype wave of late-2025 AI coding agents (specifically Google's "Antigravity" and the established "Cursor").

While the pitch—"Cursor for Science"—is compelling, the project itself shows signs of being an early-stage or niche implementation rather than a fundamental breakthrough. It is not the famous "The AI Scientist" research agent by SakanaAI, nor is it an official product from the makers of Cursor or Google.

If you are looking for a magic tool to write your papers for you, this is likely not it. It is more likely a specialized text editor (possibly a VS Code fork or Electron app) that integrates LLM prompts into a writing interface.

---

1. The "Hype" Breakdown

The project’s description—"Cursor/Antigravity for Science... MS Word replacement"—is heavily loaded with buzzwords. Here is what that actually signals:

• "Cursor for Science": This implies it offers "context-aware" autocomplete for scientific writing. In reality, you can already achieve 90% of this by simply using Cursor (the actual code editor) with a Markdown/LaTeX file and a good system prompt. You don't necessarily need a separate "Science Studio" app for this.

• "Antigravity": This is a direct keyword grab from Google Antigravity, the agentic IDE that has been trending (in this 2025 timeline). By using this name, the project is trying to appear "next-gen" and agentic. Unless they have built a proprietary agentic loop that autonomously reads your citations and runs experiments (like SakanaAI's research), this is just marketing fluff.

• "MS Word Replacement": This is the biggest red flag. "Replacing Word" is the graveyard of a thousand startups. Scientists use Word because of collaborators and track changes, not because they love the interface. Unless this tool handles .docx round-tripping perfectly (which is incredibly hard), it cannot replace Word.

2. Reality Check: Features vs. Implementation

Without being able to audit the private codebase, we can infer its likely nature from the "science editor" ecosystem:

Feature Claim | Likely Reality -- | -- "Efficient Editor" | Likely a Markdown or LaTeX editor with a split-pane preview. This is standard tech (similar to Obsidian, VS Code, or Zettlr). "AI Superpowers" | It likely wraps OpenAI/Claude/Gemini APIs. It probably helps you expand bullet points into paragraphs or rephrase abstracts. "Research Focused" | It might have built-in prompts for "Summarize this PDF" or "Generate BibTeX," which is useful but also available in tools like ScienceOS or Elicit.

3. The Competition is Better

You are likely better off using established tools that this project is trying to mimic:

• For "Cursor for Science": Just use Cursor. Open your LaTeX/Markdown folder in Cursor, add your PDFs to the context window, and you have the exact same experience with a world-class editor team behind it.

• For "Automated Science": Look at SakanaAI's "The AI Scientist" (the actual research paper agent) if you want to see AI running experiments.

• For Writing Papers: Overleaf (with Copilot/Grammarly) or Obsidian (with AI plugins) offers a much more stable environment than a niche GitHub project.

Final Verdict

• Innovativeness: Low. It applies the "AI Code Editor" UX to text.

• Utility: Moderate. If you hate LaTeX and Word, it might offer a nice middle ground, but don't expect it to "do the science" for you.

• Recommendation: Skip it unless you are a "tool hopper" who enjoys testing beta software. If you want to get work done, configure Cursor or Obsidian to do exactly what this project promises.

1. https://github.com/AIScienceStudio/ScienceStudio
2. https://www.reddit.com/r/github/comments/1bzqy6e/ai_app_that_explain_any_given_github_gitlab/
3. https://www.geeksforgeeks.org/blogs/visual-studio-vs-visual-studio-code/
4. https://www.reddit.com/r/MachineLearning/comments/1eqwfo0/r_the_ai_scientist_towards_fully_automated/
5. https://xcorr.net/2013/04/17/evaluating-ides-for-scientific-python/
6. https://ai4s.lab.westlake.edu.cn
7. https://ca.trustpilot.com/review/sciencestudio.co.uk?page=2
8. https://www.youtube.com/watch?v=zulGMYg0v6U
9. https://www.reddit.com/r/JEE/comments/1ffc51p/review_science_ai_tutor/
10. https://www.datacamp.com/tutorial/data-science-python-ide
11. https://www.scienceos.ai
12. https://github.com/NASA-IMPACT/AI-Scientist-lit-review
13. https://codeop.tech/visual-studio-vs-visual-studio-code-whats-the-difference/
14. https://www.reddit.com/r/AIAssisted/comments/1j3enww/i_tested_5_best_ai_tools_for_researchheres_my/
15. https://www.reddit.com/r/datascience/comments/oh2gkp/ide_for_data_scientists/
16. https://www.activelearningsciences.com
17. https://github.com/SakanaAI/AI-Scientist
18. https://code.visualstudio.com/docs/editing/intellisense
19. https://www.reddit.com/r/PhD/comments/1j1egyx/best_ai_models_or_tool_to_research/
20. https://b2bsalescafe.wordpress.com/wp-content/uploads/2021/11/gartner-magic-quadrant-for-data-science-and-ml-platforms-march-2021.pdf
21. https://www.rundellassociates.com/projects/science-studio
22. https://skywork.ai/blog/antigravity-vs-cursor/
23. https://github.com/orgs/twitter-research/followers
24. https://www.csescienceeditor.org/article/the-scientific-editor-an-advocate-for-transparent-research/
25. https://sciencestory.ai
26. https://antigravityai.directory/learn/antigravity-vs-cursor
27. https://www.reddit.com/r/Btechtards/comments/1loi0a6/cs_geeks_of_twitter/
28. https://gist.github.com/stared/9130888
29. https://www.facebook.com/groups/BiologyMCQs/posts/24205887132377028/
30. https://www.youtube.com/watch?v=DBsrHm4JwuA
31. https://www.reddit.com/r/Bard/comments/1dzvh4l/why_would_i_choose_the_gemini_website_over_ai/
32. https://www.reddit.com/r/AskScienceDiscussion/comments/wmmqh2/anyone_know_of_any_good_science_instagram_or/
33. https://www.pbs.org/video/complete-guide-to-editing-nova-science-studio-tutorials-jsff/
34. https://www.facebook.com/groups/ScienceTechnologyAndSocietyDiscussionCorner/posts/10158004028440008/
35. https://apidog.com/blog/google-antigravity-vs-cursor/
36. https://www.reddit.com/r/Acestudioai/
37. https://instalker.org/sciencepicss
38. https://apps.microsoft.com/detail/9nhds405s95n?hl=en-US
39. https://hevodata.com/learn/building-a-data-science-tech-stack/
40. https://www.youtube.com/watch?v=HrJ3YcUSp7E
41. https://www.scribd.com/document/852178955/2504-08066v1
42. https://www.reddit.com/r/datascience/comments/zw3gya/what_tech_stack_does_everyone_use_here/
43. https://github.com/SakanaAI/AI-Scientist-v2
44. https://arxiv.org/abs/2504.08066
45. https://studioscience.com/insights
46. https://github.com/AISCIENCES
47. https://github.com/shi3z/AI-Scientist-lowcost
48. https://www.youtube.com/watch?v=21_k2St8bBI&vl=it
49. https://github.com/SakanaAI
50. https://www.scribd.com/document/759150595/2408-06292v1
51. https://www.science-inc.com/studio.html
52. https://www.reddit.com/r/github/comments/14qbi2e/aipowered_github_profile_readme_generator_analyze/
53. https://www.facebook.com/groups/utdnsa/posts/10157246210457025/
54. https://studioscience.com
55. https://profilinator.rishav.dev
56. https://github.com/sakanaai/ai-scientist
57. https://www.youtube.com/watch?v=E-xZnXRfQGI
58. https://github-profile-maker.vercel.app

### **Honest Review: AIScienceStudio/ScienceStudio**

The Bottom Line:
This project appears to be a "wrapper" or "UI-layer" tool trying to ride the massive hype wave of late-2025 AI coding agents (specifically Google's "Antigravity" and the established "Cursor").

While the pitch—"Cursor for Science"—is compelling, the project itself shows signs of being an early-stage or niche implementation rather than a fundamental breakthrough. It is not the famous "The AI Scientist" research agent by SakanaAI, nor is it an official product from the makers of Cursor or Google.

If you are looking for a magic tool to write your papers for you, this is likely not it. It is more likely a specialized text editor (possibly a VS Code fork or Electron app) that integrates LLM prompts into a writing interface.

---

1. The "Hype" Breakdown

The project’s description—"Cursor/Antigravity for Science... MS Word replacement"—is heavily loaded with buzzwords. Here is what that actually signals:

• "Cursor for Science": This implies it offers "context-aware" autocomplete for scientific writing. In reality, you can already achieve 90% of this by simply using Cursor (the actual code editor) with a Markdown/LaTeX file and a good system prompt. You don't necessarily need a separate "Science Studio" app for this.
• "Antigravity": This is a direct keyword grab from Google Antigravity, the agentic IDE that has been trending (in this 2025 timeline). By using this name, the project is trying to appear "next-gen" and agentic. Unless they have built a proprietary agentic loop that autonomously reads your citations and runs experiments (like SakanaAI's research), this is just marketing fluff.
• "MS Word Replacement": This is the biggest red flag. "Replacing Word" is the graveyard of a thousand startups. Scientists use Word because of collaborators and track changes, not because they love the interface. Unless this tool handles .docx round-tripping perfectly (which is incredibly hard), it cannot replace Word.

2. Reality Check: Features vs. Implementation

Without being able to audit the private codebase, we can infer its likely nature from the "science editor" ecosystem:

Feature Claim	Likely Reality
"Efficient Editor"	Likely a Markdown or LaTeX editor with a split-pane preview. This is standard tech (similar to Obsidian, VS Code, or Zettlr).
"AI Superpowers"	It likely wraps OpenAI/Claude/Gemini APIs. It probably helps you expand bullet points into paragraphs or rephrase abstracts.
"Research Focused"	It might have built-in prompts for "Summarize this PDF" or "Generate BibTeX," which is useful but also available in tools like ScienceOS or Elicit.

3. The Competition is Better

You are likely better off using established tools that this project is trying to mimic:

• For "Cursor for Science": Just use Cursor. Open your LaTeX/Markdown folder in Cursor, add your PDFs to the context window, and you have the exact same experience with a world-class editor team behind it.
• For "Automated Science": Look at SakanaAI's "The AI Scientist" (the actual research paper agent) if you want to see AI running experiments.
• For Writing Papers: Overleaf (with Copilot/Grammarly) or Obsidian (with AI plugins) offers a much more stable environment than a niche GitHub project.

Final Verdict

• Innovativeness: Low. It applies the "AI Code Editor" UX to text.
• Utility: Moderate. If you hate LaTeX and Word, it might offer a nice middle ground, but don't expect it to "do the science" for you.
• Recommendation: Skip it unless you are a "tool hopper" who enjoys testing beta software. If you want to get work done, configure Cursor or Obsidian to do exactly what this project promises.

[azehady]

Qwen:

Honestly—and without hype—the ScienceStudio project is ambitious and well-architected in principle, but still early, unproven, and facing significant execution risk. Here’s a sober breakdown:

---

✅ Strengths / Valid Insights

• Real user pain point: Many researchers do juggle Word and LaTeX, local files, PDFs, citations, and AI assistants across disjointed tools. A unified, local-first IDE is a coherent vision.
• Smart architectural choices: Using the emerging MCP protocol to decouple AI agents (Claude, GPT, etc.) from domain tools (PDF, citation, library) is genuinely forward-looking—not just another wrapper.
• Local-first + open source + MIT license is a strong ethical and practical differentiator, especially in academia where data sensitivity and reproducibility matter.
• The focus on agent-agnosticism (Claude Code or OpenCode) avoids vendor lock-in—a rare and thoughtful stance.

---

⚠️ Risks / Red Flags

• Very early stage: As of now, there is no public GitHub activity metrics suggesting traction—no visible star count, recent commits, or community engagement in the search results . That doesn’t mean it’s inactive, but it does mean it hasn’t yet broken through discoverability or adoption thresholds.
• High integration complexity: Combining OnlyOffice (Word), LaTeX + PDF preview, vector DBs, Semantic Scholar API, and multi-agent AI orchestration in a smooth UI is extremely hard. History shows most academic tools fail at polish, not vision (e.g., Zotero plugins, Overleaf integrations).
• Niche-but-split audience: Targeting both Word-heavy (bio/psych) and LaTeX-heavy (CS/math) users means you need two excellent editing experiences—not one “good enough” one. Most projects underestimate the UX depth required for either.
• No clear validation of workflow assumptions: Claims like “~95% of researchers use Word or LaTeX” sound plausible, but usage ≠ willingness to switch. MS Word + Zotero + ChatGPT is already a dominant stack. Why adopt a new IDE?

---

🤔 Biggest Unknown

Is this aiming to be:

• A researcher-facing app (like a supercharged Zotero + Obsidian + VS Code hybrid)?
• Or an infrastructure layer for AI research agents (a toolkit for building research agents)?

Right now, it straddles both—and that’s dangerous. If usage stays confined to technically adept PhDs comfortable with conda and npm, growth will be limited. If it tries to be plug-and-play for biologists, the installation and stability bar is much higher.

---

Final take:

Promising blueprint, not yet a product.
It’s the kind of project that should exist—and if executed well, could become foundational. But as it stands, it’s a scaffold, not a house. Success hinges entirely on UX polish, reliability, and onboarding simplicity—the hardest parts, and the least visible in the repo today.

Would I watch it? Yes.
Would I bet my thesis workflow on it today? Not yet.

Let me know if you'd like a gap analysis vs. alternatives (e.g., Zotero + Obsidian + Manuscripts, or Curvenote, or even Word+Zotero+Copilot).

[azehady]

Idea Evaluation

The core concept of ScienceStudio—building a specialized IDE for researchers that merges document editing (Word and LaTeX) with inline AI assistance, all while keeping everything local-first—is practical and addresses real pain points in academic workflows. Scientists often juggle writing tools like Microsoft Word for collaboration, LaTeX for precision in fields like physics or math, and separate apps for citations (e.g., Zotero) or literature searches. Integrating these into a single VS Code-based environment with AI prompts for tasks like refining text, adding sources, or verifying claims could streamline things, especially for users who value privacy and don't want data sent to cloud services. The pivot to agent-agnostic AI (Claude Code by default, with OpenCode for alternatives like GPT-4 or LLaMA) adds flexibility, allowing users to swap models without overhauling the setup. Features like vector search over a personal paper library and Semantic Scholar integration for citations fill a niche for offline-ish research support.

However, the idea feels overly ambitious for its current stage. It's positioned as a "Cursor/Antigravity for Science" (referencing AI coding tools), but academic writing involves more than code-like autocompletion—things like collaborative editing, version control beyond Git, or handling complex figures/tables aren't fully addressed yet. The README mentions a "Focus Mode" to simplify the VS Code UI, which is smart for non-dev users, but it's not implemented, leaving it as a developer tool rather than a polished editor. Market-wise, it competes with established options like Overleaf (online LaTeX), Notion/Obsidian for note-taking with plugins, or even Word add-ons, and the competitive analysis in the repo acknowledges this but doesn't convincingly differentiate beyond locality. With zero traction (no stars/forks/releases), it's unclear if the idea resonates; it might appeal to a small group of tech-savvy academics, but broader adoption would require proving it saves time over fragmented tools. Overall, solid foundation for efficiency in research writing, but it risks being another unfinished prototype unless it evolves to handle real-world messiness like grant proposals or multi-author edits.

Tech Stack Evaluation

The stack is modular and leverages mature open-source components, which is a strength for extensibility. The frontend is a VS Code extension in TypeScript, using Monaco for LaTeX editing (reliable for syntax highlighting) and OnlyOffice WebView for .docx files, which enables Word-like functionality without leaving VS Code—though OnlyOffice isn't as feature-complete as native Word, especially for advanced formatting. Backend relies on Python 3.12 MCP (Microservice-like) servers: pdf-mcp for extracting sections from PDFs, library-mcp with ChromaDB for vector-based searching of local papers, citation-mcp integrating Semantic Scholar API for BibTeX lookups, and docx-mcp for manipulating Word files. This setup keeps things local (no cloud dependency for core ops), with Docker Compose and Nginx for potential scaling, but it's all run via conda environments and pip installs, making it accessible for Python users.

AI integration is the highlight: agent-agnostic with Claude Code (using Claude 3.5/4 models) as default and OpenCode supporting 75+ models (e.g., Gemini, LLaMA). Inline commands via Cmd+K trigger these, which is intuitive for VS Code fans. Dependencies are standard (numpy/scipy for potential data tasks, though not core here), but the Semantic Scholar API requires internet, slightly undermining the "local-first" claim for citations.

On the downside, the stack's complexity hinders usability—the installation involves cloning, npm compiles, multiple conda/pip setups, config file tweaks for AI agents, and running in VS Code dev mode. This is fine for developers but a barrier for typical researchers. With only 18 commits (recent ones fixing basics like cursor offsets and adding LaTeX/OnlyOffice), it's immature; no tests, CI/CD, or error handling mentioned, risking bugs in production. The recent pivot to Claude Code shows adaptability, but it also highlights instability in the architecture. Scalability could be an issue with ChromaDB on large libraries, and relying on external AI backends means users need API keys or local models, adding hidden costs. In summary, the tech choices are pragmatic for a prototype—leveraging VS Code's ecosystem and Python's AI libraries—but the fragmented setup and lack of polish make it feel more like a proof-of-concept than a robust tool. It has potential for customization, but needs simplification and more development to be viable.

[azehady]

#Claude:

Alright, honest take:
The Good
The problem space is real — academic writing tooling is genuinely painful. The architecture decision to build MCP servers rather than another AI wrapper is smart. It means the tools work with Claude Code, OpenCode, or whatever comes next. That's good forward-thinking.
Supporting both Word AND LaTeX is a genuine differentiator on paper. Most tools pick one camp.
The Concerns

It's basically just docs right now. 18 commits, pre-alpha, the roadmap says OnlyOffice integration and editors are "Phase 2" — meaning the core product doesn't exist yet. This is an idea with architecture diagrams, not a working tool.
"Cursor for X" is saturated. Everyone is pitching this now. The differentiation needs to be in execution, not framing.
Massive surface area. They're attempting: OnlyOffice integration, LaTeX editor, PDF viewer, 4 MCP servers, VS Code extension, "Focus Mode" to hide VS Code complexity. That's a lot for what looks like a small team (or solo dev). Each of those is a serious engineering lift.
The comparison table is slightly misleading. Overleaf has AI features now. The "local-first" claim is also fuzzy — Claude Code still sends your content to Anthropic's API, so your writing isn't truly staying local unless you're using fully local LLMs.
Missing real research workflow pain. The features (refine, expand, add citations) are generic. The actual pain points — Zotero/Mendeley integration, collaboration, journal-specific formatting, track changes, reference manager sync — aren't addressed in the roadmap.

Bottom line: Interesting idea, reasonable architecture, but currently vaporware. 0 stars, 0 forks, no community signal. I'd want to see a working MVP before taking it seriously. The execution risk is high given the scope.

[azehady]

Honestly? The README is much better than a “random OSS repo README” — it clearly explains the researcher workflow pain (many PDFs → collect excerpts → synthesize into a section → keep citations grounded) and it avoids the usual AI-hype traps.

But it still reads more like a concept manifesto than something a developer/researcher can try, trust, and contribute to.

What’s strong now

• Problem framing is real: “researchers don’t write from one source,” “citation jumps break focus,” “section-level scratchpad/memory.” That’s legit and relatable.
• Grounding stance (“AI assists synthesis, not fabricate”) is a good differentiator if you can enforce it.
• Format pragmatism (Word + LaTeX) is smart: you’re meeting disciplines where they are, instead of forcing everyone into a new editor religion.
• High-level architecture diagram helps the mental model.

Where it still feels weak / risky

• The “Word + LaTeX + AI” promise is enormous, and the README doesn’t yet convince me you have a crisp “first lovable” wedge.

  • Right now it can sound like: PDF reader + citation navigator + notes system + docx editor + tex editor + AI agent framework + local search + citation metadata… that’s a lot.

• Differentiation is implied, not proven.

  • You say “ideation layer on top of Word and LaTeX,” but readers will immediately compare to: Zotero + Obsidian/Notion + Overleaf + Word + (insert AI assistant).
  • The README should make the “why this is uniquely better” feel inevitable: the tight loop (select → attach to section memory → write with inline evidence → verify citations) in one place, minimal context switching.

• Credibility gap: “Pre-alpha” is honest, but then readers want something concrete:

  • 2–3 screenshots or a short GIF
  • a “What you can do in 3 minutes” quickstart
  • a “What’s not built yet” list (you have some of this, but it’s still abstract)

• Agent-agnostic + MCP + ‘Claude Code default’ is cool for builders, but for many users it’s cognitive overhead.

  • You might be mixing product messaging and implementation messaging too early.

My bottom-line take

If you execute even one killer workflow end-to-end, this could become a serious “researcher daily driver” tool:

The killer wedge is not “a Word replacement.”
It’s: “evidence-first writing with section memory and citation preview that keeps you in flow.”

If ScienceStudio becomes the best place to:

1. read PDFs without losing context,
2. capture excerpts into section buckets, and
3. draft paragraphs that always cite back to those excerpts,

…then the rest (docx/tex polish, fancy editor stuff) can come later.

What I’d do next (product-wise)

• Pick a single flagship loop and make it undeniable:

  • PDF → highlight → send to “Related Work” memory → generate a 2-paragraph synthesis with inline citations → click/hover citation shows the exact source snippet.

• Make the README “tryable”:

  • Quickstart + demo + “current capabilities” checklist + “near-term roadmap” with 3 milestones.

• Be careful with “MS Word replacement” language:

  • Your own README currently says it’s not a replacement (which I think is correct).
  • I’d position it as “an ideation + evidence layer that works with Word/LaTeX.”

If you want, paste the issue criticisms (or link the specific parts you want addressed) and I’ll tell you which criticisms are valid vs. “AI reviewer noise,” and what concrete changes would address the valid ones.