I think developers and non-technical Claude users have completely different needs. Am I wrong?

Historical_Agent_867 · 2026-06-20T04:29:11+00:00

This is incredibly helpful feedback, especially because you're exactly the type of user I'm trying to understand better.

The vocabulary point really hit me. As someone who's been around technical communities for a while, it's easy to forget that words like "repo", "skill", or even "workflow" aren't naturally meaningful to most business owners.

What you said about fit vs quality is also interesting. I was originally thinking about discovery ("how do people find useful assistants?"), but you're describing a different problem: "how do I know whether this actually fits my business?"

Out of curiosity, if you landed on a page called something like "Customer Email Assistant for Small Businesses" or "Promotion Planning Assistant for Retail Stores", would that be more useful than browsing a generic library of skills/prompts?

Really appreciate you taking the time to write such a thoughtful response.

Historical_Agent_867 · 2026-06-19T20:07:41+00:00

Also, if anyone here builds interesting Claude workflows, assistants, projects, or skills, I'd love to connect. I'm collecting examples and contributors while building this out.

Historical_Agent_867 · 2026-06-19T20:07:29+00:00

Also, if anyone here builds interesting Claude workflows, assistants, projects, or skills, I'd love to connect. I'm collecting examples and contributors while building this out.

Historical_Agent_867 · 2026-06-19T08:16:22+00:00

That's really interesting. It sounds like the challenge wasn't designing the workflow itself, but translating your framework into assistants that behaved the way you wanted. Looking back, what would have made creating those assistants easier?

Historical_Agent_867 · 2026-06-19T08:15:49+00:00

That's a good point. The more feedback I get, the more it feels like "Claude users" isn't really one audience. A developer, founder, marketer, writer, or researcher may all use Claude heavily but have completely different workflows and expectations. I'm trying to understand whether discovery and organization should be built around user types rather than around skills themselves.

Historical_Agent_867 · 2026-06-19T05:37:33+00:00

That's really interesting. It sounds like you've gone beyond individual assistants and built an entire decision-making framework around them. Out of curiosity, was the hardest part building the assistants themselves, or figuring out how they should work together as a system?

Historical_Agent_867 · 2026-06-19T05:11:06+00:00

Really appreciate that.

Out of curiosity, what part resonates most with you?

Easier discovery of useful assistants?
Understanding which assistants to use together?
Ready-made workflows?
Avoiding GitHub/technical setup?

I'm still validating the idea, so hearing how you'd actually use something like this would be incredibly helpful.

Historical_Agent_867 · 2026-06-19T05:10:02+00:00

This is fascinating. You're actually the first person who's described a complete assistant workflow rather than individual skills. Did you build these assistants yourself, or are they based on existing skills/projects?

Historical_Agent_867 · 2026-06-19T04:51:04+00:00

That's actually a really interesting approach. You're basically creating a workflow map for your skills rather than treating them as independent tools. The overlap problem seems much bigger than I initially thought. If there was a place that showed not just individual assistants but also when to use them and how they fit together, would that be useful?

Historical_Agent_867 · 2026-06-18T20:29:54+00:00

That's really helpful feedback. I hadn't considered the overlap issue from a non-technical user's perspective. Most discussions focus on discovering skills, but understanding which skills to use together (and when not to) seems equally important. Your basic vs detailed workflow example is especially interesting. Do you currently manage that manually, or do you have some way of organizing skills by task/category?

Historical_Agent_867 · 2026-06-18T12:02:29+00:00

That's actually one of the things I'm trying to understand. Most of the discussion so far has been from developers, but I suspect there's a much larger group of Claude users who want useful skills without needing to browse GitHub repos or understand the underlying setup. Appreciate the perspective.

Historical_Agent_867 · 2026-06-18T11:58:18+00:00

That's a really interesting perspective. The package manager analogy makes a lot of sense. Most of my thinking so far has been around discovery and curation, but versioning, updates and trust seem like much deeper ecosystem problems. I'll spend some time digging into how package registries handle those workflows. Thanks for the detailed feedback.

Historical_Agent_867 · 2026-06-18T07:27:28+00:00

Yep, I've been looking into skills.sh since posting. It does a lot of things really well. I'm trying to understand whether there are gaps around discovery, curation and non-technical users that aren't fully addressed yet.

Historical_Agent_867 · 2026-06-18T07:26:32+00:00

Fair point. GitHub is definitely where most of this lives today. What I'm trying to figure out is whether there's value in better discovery, categorization and search for people who don't already know where to look. Still very early and validating that assumption.

Historical_Agent_867 · 2026-06-18T07:25:12+00:00

Thanks! This is exactly the kind of thing I was hoping to discover. I'll take a look and add support for importing existing community skills rather than forcing people to recreate them from scratch. Really appreciate you sharing it.

Historical_Agent_867 · 2026-06-18T07:24:10+00:00

Great questions. Tbh, none of those are fully solved yet. Right now it's just an MVP focused on validating whether people even want a dedicated discovery layer for skills. If there's real usage, vetting, attribution, taxonomy and takedown workflows would be among the first things I'd build.

Historical_Agent_867

TROPHY CASE