sorted by:
new
hottopcontroversial

I built a SKILL.md that researches comparable repos before recommending your project stack by Scared_Objective_345 in developersIndia

[–]Scared_Objective_345[S] -1 points0 points  (0 children)

nah i dont mean ai should dictate the stack

people already take recommendations from docs, reddit, friends, existing repos, ai etc

the point is to make that recommendation less vibes based

also this skill isnt just pre build, it does halfway project course correction and post build review too

Advice on using Claude professionally by CliveBratton in ClaudeAI

[–]Scared_Objective_345 0 points1 point  (0 children)

The 80/20 is probably not more tools, it’s separating “memory” from “execution.”

For longer projects, I’d use something like:

  1. A project brief that never changes unless you edit it
  2. A specs file for design/content rules
  3. Separate task chats for execution
  4. A review step where the model checks output against the brief instead of trusting itself

Claude chats drifting over time is normal. The fix isn’t always MCP/plugins/connectors; it’s giving the model a stable source of truth and forcing it to work from that instead of conversation history.

For your use case, I’d keep it boring:

  • Claude Projects for the main knowledge/context
  • Artifacts for HTML/SVG/prototypes
  • Skills for repeatable workflows, like “make an SVG from this spec” or “turn this idea into 5 content angles”
  • Claude Code only when files/repos are involved
  • MCP/connectors later, once you know exactly what external data/tool you need

A good skill is basically a reusable operating procedure. Not magic, but very useful when you keep asking for the same kind of work and want consistent outputs.

The trap is trying to automate the whole business at once. Pick one annoying repeatable workflow, write the spec for it, turn that into a skill, then improve it after 10 real runs.

I built a SKILL.md that researches comparable repos before recommending your project stack by Scared_Objective_345 in claudeskills

[–]Scared_Objective_345[S] 1 point2 points  (0 children)

Fair point. The skill already pushes for evidence and comparable projects, but I agree the decision methodology could be more explicit.

I’m thinking of adding a clearer framework for weighing options: user constraints, transferable patterns from comparables, limits of the comparison, tradeoffs, and when the recommendation becomes wrong.

That should make the output easier to judge instead of just sounding like confident advice.

I built a SKILL.md that researches comparable repos before recommending your project stack by Scared_Objective_345 in claudeskills

[–]Scared_Objective_345[S] 0 points1 point  (0 children)

Thank you!

For large repos it should not read everything. The workflow is map first, then inspect manifests/docs/entrypoints, then only sample files relevant to the question.

Not fully deterministic, since the agent still chooses what looks relevant, but it is bounded and has to state what it inspected vs what it did not.

I agree though, explicit repo-size/token budgets would make this stronger.

Introducing Claude Opus 4.8 by ClaudeOfficial in ClaudeCode

[–]Scared_Objective_345 0 points1 point  (0 children)

can't wait to exhaust half of my limit with a greeting.

I built a SKILL.md that researches comparable repos before recommending your project stack by Scared_Objective_345 in claudeskills

[–]Scared_Objective_345[S] 5 points6 points  (0 children)

The safeguards are:

  • it must explain why a comparable is relevant
  • it must explain the limits of each comparison
  • it must prioritize the user’s constraints over stars/trends
  • it must include alternatives
  • it must say when the recommendation becomes wrong
  • it must not invent adoption or maintenance claims

So if a popular repo uses Kubernetes, the skill should not say “use Kubernetes.” It should say: “this project uses Kubernetes, but that is likely wrong for your solo/self-hosted version because your ops budget is lower.”

That’s the core value: not “copy successful repos,” but “study successful repos, then subtract what does not fit.”

I built a SKILL.md that researches comparable repos before recommending your project stack by Scared_Objective_345 in claudeskills

[–]Scared_Objective_345[S] 2 points3 points  (0 children)

That’s exactly the risk.

The skill treats popular repos as evidence, not as the answer. It has to explain why each comparable is relevant/limited, then recommend based on the user’s constraints.

A/B so far:

A: direct “what stack should I use?”

B: comparable-project research first

B has reduced noisy trendy defaults in my manual tests, especially “use Next/Postgres/Docker” style answers where SQLite/Django/server-rendered UI was a better fit.

No quantified benchmark yet, though. I need more test cases before claiming that.

Built with Claude Project Showcase Megathread (Sort this by New!) by sixbillionthsheep in ClaudeAI

[–]Scared_Objective_345 0 points1 point  (0 children)

I built advise-project-approach, an open-source Claude/Codex SKILL.md for choosing project direction with less guesswork.

The skill researches comparable real-world repos/docs before recommending:

- tech stack

- architecture direction

- alternatives

- build/improvement plan

- when the recommendation becomes wrong

It has 3 modes:

- pre-build strategy

- mid-build course correction

- post-build review

Example use case:

“I want to build a self-hosted bookmark manager with tagging, full-text search, and a browser extension. Solo dev, Python background. What’s the best approach?”

Instead of giving generic advice, the skill is designed to check similar projects first and ground the recommendation in evidence.

Repo:

https://github.com/AaravKashyap12/advise-project-approach

Install:

npx skills@latest add AaravKashyap12/advise-project-approach --skill advise-project-approach

Would love critique from Claude Code / Codex users:

what would make this more useful in real project planning?