Hello HN,I'm Ali, building Decispher.The problem we're working on is that coding agents repeatedly rediscover context that already exists inside an engineering organization.A developer working on a feature can combine information from previous PRs, Jira tickets, Slack discussions, ownership boundaries, architectural decisions and their own experience. Coding agents usually start with a prompt...
Hello HN, If you integrate your agents with decispher you can transfer context from one agent to another agents in 2 ways -:1) If you are working on git branch then branchstory feature keeps on recording your session activity like user prompts -> agent's reasoning -> agent's action -> edited files. These recordings can be played by other agent/human taking up task next. Agents can...
Hi HN, You can now integrate your grok agent (just like claude code, codex, cursor) with Decispher to transfer your team's architectural decisions directly and dynamically on demand.You can also record your AI coding session with decispher (User's prompt -> agent reasoning -> agent's action and more).npx decispher@latest init --agents grokPS -: We are looking for design partners and if...
I was working in a team of 10 people on a project. We kept running into inconsistency across the codebase because everyone prompted differently and got different results. We tried maintaining a skills.md file to fix it, but it wasn’t great.So I built Decispher (decispher.com). Its main goal is to automatically capture engineering context from across different platforms and feed it to AI agents....
One feature i would like to talk about: Branch Story (VS Code extension + npm). It captures the reasoning, diffs, and terminal output as work happens, then surfaces it at PR review time, so a reviewer knows why the code is the way it is instead of just reading a diff and hoping it's fine.
There's also "why is this line here": right-click any line in the editor, get the decision behind it.
Hello HN,I created Decispher (decispher.com) to enable human developers and AI agents working alongside each other to share their context.It has some pretty cool features, like Branch Story (explains why a branch's code looks the way it does) and Session Context Transfer (an MCP tool that can copy context from one chat, agent, or machine to another).You can also capture context from engineering...
Hello, I waned to ask if i can use AI voiceover and animated cartoon to tell a story about my YC product demo. Will it have negative impact?
The tool is simple. You write your architectural decisions in a Markdown file what was decided, why, what was rejected. Decision Guardian maps those decisions to file glob patterns. When a PR touches a matched file, it posts a comment explaining the relevant decision.No database. No signup. Two lines of GitHub Actions YAML.v1.2.0 fixes several rule-engine bugs that surfaced from real...
Decision Guardian Prevent institutional amnesia by surfacing past architectural decisions directly# Install globallynpm install -g decision-guardian# Or use directly without installationnpx decision-guardian --help# Check staged changesdecision-guardian check .decispher/decisions.md# Check against a branchdecision-guardian check .decispher/decisions.md --branch main# Auto-discover all decision...
Hey HN,I built Decision Guardian — an open-source GitHub Action and CLI that automatically surfaces architectural decisions as PR comments when code touches protected files. The problem it solves:Spotify published a great post in 2020 about when to write Architecture Decision Records. I followed the advice. My team wrote ADRs. They sat in docs/adr/. Nobody read them before opening a...
Hey HN, I’m Ali.I built Decision Guardian to solve a problem I call "institutional amnesia." Senior engineers build complex systems (like highly-tuned DB connection pools or sensitive auth middleware) and document the "why" in wikis or ADRs. But inevitably, a new developer modifies that code without reading the docs, and things break. While tools like CODEOWNERS are great for telling you who...
Hey everyone,If you work on a scaling codebase, you know the struggle of keeping architectural context alive. Senior engineers make important decisions about how the code should be structured, but new hires often don't know that context exists and end up accidentally breaking critical systems.To fix this, I built Decision Guardian. It is an open-source tool (running as a GitHub Action or local...
Most teams have files where the "why" matters as much as the "what." A config value tuned against prod load. A dependency pinned for a CVE reason. A route that's hardcoded in an external system nobody remembers.The context exists somewhere — a postmortem doc, a Slack thread, someone's memory. It's just never at the moment a new engineer opens a PR touching that file.Decision Guardian reads a...
I stumbled across this tool recently and thought it was worth sharing for anyone managing large codebases or monorepos.The Problem: We write ADRs (Architectural Decision Records), put them in a folder, and then ignore them. New engineers break architectural rules because they don't know the history.The Solution: Decision Guardian runs in CI. You define rules (ADRs) linked to file patterns.What...
Re: noise — I agree, that’s the main failure mode for any PR bot.
A few things I did to keep signal high:
Only trigger on explicit file patterns (no fuzzy matching by default)
Idempotent comments — it updates instead of spamming new ones
If multiple decisions match, it groups them into a single comment
Severity levels (info / warning / critical) so teams can tune strictness
Optional “fail critical” mode so it never blocks PRs unless configured
The goal is that it behaves more like a linter than a chatbot — predictable and quiet unless something clearly matches.
If it ever becomes background noise, it’s failed
This is still just markdown in the repo. The Action doesn’t replace ADRs, it just surfaces the relevant ones automatically in PRs so reviewers don’t have to remember to look for them.
In teams where people consistently check ADRs, this probably isn’t useful.
In teams where the ADR exists but nobody remembers it during review, this helps reduce that friction.
And yeah — the Mongo example was dramatized. The real version was just re-explaining a past decision in a design doc. Not catastrophic, just wasted cycles.
Appreciate the sanity check.
Hi HN, I built this to solve a problem I kept running into on my team.The problem: A senior engineer made a deliberate choice—Postgres over MongoDB for billing because we needed ACID compliance. They documented the reasoning in a Slack thread. 8 months later they left. A new developer opened a PR to migrate to MongoDB. No one remembered why Postgres was chosen. We spent 3 months re-evaluating a...
https://decision-guardian.decispher.com/
I built Decision Guardian after watching teams repeatedly debate decisions that were already settled.At my last job, we chose Postgres over MongoDB for ACID compliance. 18 months later, a new engineer opened a PR to switch to MongoDB. The team spent 3 months re-evaluating before someone remembered.Decision Guardian prevents this: - Document decisions in markdown (why you chose X over Y) -...