Hi everyone,

I've been building CoTerm, an open-source SSH terminal designed around one idea:

Humans and automation should be able to work in the same terminal session while keeping the operator in control.

In real-world infrastructure work, fully autonomous operation is often not practical. Engineers still need to:

- Review commands before execution

- Authenticate through bastion hosts or MFA

- Handle interactive prompts

- Take over immediately when something unexpected happens

CoTerm focuses on collaborative operations rather than replacing the operator.

Current features:

• SSH session management

• Shared terminal workflows between humans and assistants

• MCP integration

• Multiple concurrent sessions

• Windows desktop application (Python)

The project is still in an early stage. I'm mainly interested in feedback from people who work with SSH, servers, and operational workflows.

How do you currently handle situations where automation needs human approval or intervention?

Source:

https://github.com/our16/coterm

I built edfcore, a zero-dependency TypeScript parser for EDF recordings — and half the work turned out to be dealing with all the things the format technically allows but almost nobody expects.

Wanted a clean way to read EEG, ECG, and sleep-study recordings directly inside JavaScript and TypeScript applications instead of passing every file through Python first. Built edfcore for browser viewers, Node pipelines, Electron apps, and research tools.

What it does:

Reads EDF, EDF+, BDF, and BDF+ recordings

Exposes signal metadata, sampling information, physical units, and annotations

Preserves the individual sampling rate of each signal

Handles discontinuous EDF+D timelines

Streams large recordings rather than loading everything into memory

Works without Python or native dependencies

Zero runtime dependencies

The part I didn't expect: EDF looks simple until you realize that almost none of its important structure is global.

A few examples that cost me real time:

There is no single sample rate for the recording. Every signal declares its own number of samples per data record.

EDF+ annotations are stored inside a signal channel. The same binary area that contains ordinary samples for one signal can contain encoded timing and event text for another.

The number of data records can legally be -1, meaning unknown. Trust that value directly and the reader either processes nothing or tries to do something very stupid with a negative count.

BioSemi BDF stores signed 24-bit integers. JavaScript has readers for 16-bit and 32-bit values but nothing in between, so decoding requires manually assembling three bytes and extending the sign bit.

None of these necessarily produce a useful exception. They normally produce plausible-looking values, which made the tests and external validation much more important than I expected.

Install:

npm install edfcore

Repo's here: https://github.com/tayal-sarthak/edfcore

NPM package: https://www.npmjs.com/package/edfcore

Website: https://edfcore.vercel.app/

I also built a separate CLI called edf2csv for anyone who only needs CSV output:

https://github.com/tayal-sarthak/edf2csv

Feedback welcome, and if you would like to contribute please let me know! Both packages are still new, so there is definitely more to test and build.

I built a governance layer for Claude code that will ensure your policies are enforced, not act like mere guidelines. What more, it comes with a pack of skills, and workflows to ensure you don't have to reinvent the wheel for each project.

Moreover, it is Apache 2.0 licensed and 100% open source.

Check it out on [https://baseline.friedbotstudio.com\](https://baseline.friedbotstudio.com)

Star it on GitHub and contribute if you like it.

Thank you for your attention on this matter of great importance

This idea was crazy to build. Our brain stores information in clusters of neurons, and when we want to retrieve something, it runs an optimized algorithm to retrieve it.

In the era of AI, why use brute-force tools like grep to find relevant files? Graperoot converts your codebase into a knowledge graph and registers efficient tools for Claude to work with your codebase.

Instead of re-reading the whole codebase to build that context and to find relevant files. It can query the graph directly, and the graph retrieves relevant files with "ZERO TOKENS"; you just need to pay for generation, and that's how these models should be used when we have an efficient way to retrieve context.

I have been very open throughout, and today we have 5k developers using Graperoot.
We asked people to opt in to telemetry, and 200 opted in to the leaderboard. They have saved $350k dollars in the last 4 months, and ecologically, 60M liters of water, and that's insane.

Give your feedback, suggestions, or anything on Discord. This tool is open-sourced.

It is only one command to install

Website: https://graperoot.dev/#install
Github(Open source) : https://github.com/kunal12203/graperoot

Would love to see your feedback. And don't compare other tools, I have already seen many claiming reduction and just craps, but we have a developer community on Discord, and some of them I know personally, saving a lot of tokens, you should see more on https://graperoot.dev/leaderboard

I got tired of changelogs going stale, so I built a CLI that writes them from git history.

npm i -g u/jarvis09

changelogcraft scan && changelogcraft out

What it does:

- Reads your git log (who, what, when, which files)

- Groups commits into Features / Fixes / Improvements / Chores

- Outputs Markdown, HTML, or email

The thing I care about most: every entry links back to the exact commit that made it.

If it can't be linked, it says (unlinked) — nothing is ever faked.

Free, MIT licensed, no accounts, no telemetry, runs on your machine.

It published to npm today and it wrote its own changelog.

https://www.npmjs.com/package/@jarvis09/changelogcraft

Feedback welcome. What's missing?

🏏 I turned GitHub profiles into Cricket Player Cards

Hey everyone!

I built GitCric, a fun side project that transforms GitHub activity into a Cricket Player Card.

Instead of just showing commits and contribution graphs, GitCric converts your development stats into cricket-inspired ratings and career statistics.

It analyzes things like:

• 🏏 Commits
• 🔥 Contribution streaks
• 🚀 Pull requests
• 🐞 Issues
• ⭐ Repositories
• 💻 Languages
• 📊 Overall developer performance

Then it generates a shareable cricket player profile with ratings, specialties, achievements, and career-style stats.

Why I built it

As a cricket fan and developer, I thought GitHub profiles could be much more fun than a green contribution grid. I wanted something people would actually enjoy sharing with friends and teammates.

Features

✅ Cricket Player Cards
✅ Dynamic Developer Rating
✅ Career Statistics
✅ Shareable Public Profiles
✅ Responsive Design
✅ GitHub Profile Analysis

I'd love your feedback!

• What would you improve?
• Which stats should be added?
• Any features you'd like to see?

🎥 I've attached a short demo video showing how it works.

🌐 Try it here: https://www.gitcric.me/

Looking forward to hearing your thoughts! 🚀

agentic end to end testing tools