Best for
- Stopping dependency sprawl before it starts
- AI teams that reach for a new package by reflex
- Keeping licence and security exposure deliberate
What you give it
- The proposed addition and the problem it is meant to solve
What you get back
- A verdict first: already covered, native solution, or genuinely new
- The cost picture: maintenance, security surface, licence, lock-in
- A short written case for your yes/no when an addition is warranted
How it works
- Reads your approved-stack document and the dependency manifest.
- Checks whether existing capabilities or native features solve the need.
- Assesses the candidate: maintenance health, licence, transitive weight.
- Writes the case — problem, alternatives, costs, recommendation.
- Records approved additions into the stack document with the reason.
Example
You: The build wants to add a date-picker library.
Result: Verdict: the UI kit already in the stack ships one — covered. Two-line note on the difference that tempted the addition, and how to get it with what exists.
Limits — please read
- It advises; the yes/no on new technology stays with you.
- Health signals are read from public facts, not guarantees.
- An empty stack document means the first pass is writing one.