I picked the name in the context of a .NET global tool, and Fuse was available on NuGet. I looked into the project you mean: FUSE is the Linux Filesystem in Userspace layer, and SSHFS is one filesystem built on it. Their commands are sshfs and fusermount, so there should not be an actual CLI or NuGet conflict. The real issue is name and search confusion, which is fair, so I will make "Fuse for .NET" more obvious when I mention it outside NuGet.
I would say since your focus is on structural or programmatic detection, and not LLM heuristics, the problem depends on language a lot.
In Rust or Go there’s super clear test markers or filenames.
In Javascript it would have to detect the framework in use then detect test files and tests embedded in program files.
And so forth.
Are you doing any call sequencing heuristics? Like if the same 5 calls (with different args) appear in the same order in multiple places (even in test files) that might be a strong signal for deduplication. Or even if the same 5 calls are in the same order with a couple different interleaved calls - the fuzziness of the heuristic might be something tunable to a language, or particular codebase, or framework, etc.
Fair. The differentiator is the Rust single binary +
petgraph knowledge graph. No Python runtime, no cloud,
survives restarts. Built it because nothing local fit
that profile.
how to capture, what to capture, when to capture it.. where to put it.. how to make it 'useful'.. how to reinject it or make it accessible
the harness makers may well come up with better means than flat files, but there are loads of folks out there working across different harnesses and in teams, and there's very little that works in that respect.
Cheers — quite a bit more work going into that presently and extensive testing to back it up. Early finding: auto-extracted memory is no better than a hand-written doc. Human curation is the lever. Numbers at the top of the mori README.
BM25 is in my other project vecdb. mnemo's retrieval is
graph-first — entity deduplication, multi-hop traversal,
session-scoped scoring. Different tradeoff, not an oversight.
Look at the juxt/allium plugin. It’s a more mature version of what you’re attempting.
Also big requirements/tasks files will rot your context opening up hallucinations and drift. So I’d guess your starting point isn’t useful for larger codebases.
Wondering if this is attempting what github.com/gsd-build/get-shit-done has done: plan your milestones, discuss them, execute them, review them. It can also review the plans by another agent before execution... Everything documented and checked in.
To be honest, I did not know what GSD was before publishing this skill (nerviousness).
I did some research after reading your and a discord comment i received and i agree that GSD is doing something more complete — full execution orchestration with context rotation. This skill is intentionally the spec layer only: interview → requirements.md + design.md + tasks.md + AI
config files as I believe this is a more manageable as well as a core part of SDD to be tackled.
I intend it to be composable with GSD rather than a replacement for it. After all even while using GSD one still needs a spec before execution begins and that is the gap I now want to fill.
Also thank you so much for your input, it is always good to have some proper references for a project in it's early stages to avoid redundancy.
Cool, thanks for the reply. GSD is great for new projects but it burns through tokes at quite the rate. Esp. in quality mode. Something more lightweight would sometimes also be welcome. Though there is /gsd-fast and /gsd-quick that partially fill that gap.. I'll definitely check yours out, thanks for publishing
To be fair allium is genuinely impressive, I checked it out and the custom language approach and autonomous tend/weed agents are more sophisticated than what I'm doing with this skill. The tradeoff I made deliberately was to use standard markdown files that any AI tool can read without installing anything.
Allium's .allium format requires the skill to be installed to be useful;
The requirements.md should work in any editor, any agent, any CI pipeline.
Also, context rot on large specs is a real limitation. I added a
lightweight CONTEXT.md journal but nothing close to proper context
rotation. That's filed for v2.0.
I'd also like to thank you so much for taking your time to revise this show HN and express that I appreciate your feedback.
That is a limited argument because sometimes the harness can run itself in the cloud, not on the client side. Something then has to maintain the communication between the harness and the client.
Man there is a LOT of people who have no idea how these GPT-LLM services actually work, despite there being large amount of documentation on the APIs and whitepapers and so forth.
reply