# 0hmx - Why don’t agents have an easy way to rep... Channel: #contributor Source: https://discord.com/channels/1233487248129921135/1528705719946449066 Started: 2026-07-20T10:10:46.285000+00:00 Last activity: 2026-07-21T18:04:20.029000+00:00 ## 0hmx — 2026-07-20T10:10:45.614000+00:00 Why don’t agents have an easy way to report missing features or bugs? Right now, they have to locate the correct GitHub repository themselves, which feels like a terrible experience. We need an API that an agent can call with the reproduction TSX files, a description of what it was trying to do, and where it got stuck. We can then automatically classify it as an autorouter bug, a missing feature, or something else. The API should: 1. Create a GitHub issue so our open-source contributors can investigate it. 2. Create a channel in our primary workspace discord/slack and post the GitHub issue link there so we can discuss it. we are missing out on auto research and finding of bugs Attachment: image.png — https://community.tscircuit.com/media/1528705719669362688 ## 0hmx — 2026-07-20T10:11:56.167000+00:00 [attachment] Attachment: image.png — https://community.tscircuit.com/media/1528706015443419146 ## ! Rushabh | Linux Shill — 2026-07-20T10:40:25.441000+00:00 this sounds cool ## Seve — 2026-07-20T13:51:50.057000+00:00 Why not make tscircuit/tscircuit have all our issues- im a bit skeptical of not getting totally spammed like we do on repos with bounties tho ## astrimid — 2026-07-21T14:16:22.215000+00:00 If I understand correctly, you would still need someone to decide whether it's a confusion regarding API or a genuine missing feature/bug. From my short experience, the bottleneck is not crafting a reproduction example. It's finding documentation on how it's intended to work to judge whether it's a bug, missing feature, edge case. For that I believe we need a database of real device reference schematics, not toy examples. Is there anything like that, where you can point AI to reference example of PCB you're doing, be it a developement board or mass produced PCB? ## astrimid — 2026-07-21T14:29:21.365000+00:00 Even a database/templates of common circuits, like LDO, charge controllers, buck-boost regulators would probably help LLM-driven design more productive. As I understand https://common.tscircuit.com/ is whee they're supposed to live. Currently, I only see raspberry pi with usb-c. Could benefit from more complex multipage schematics and annotated with code example. ## astrimid — 2026-07-21T14:35:18.642000+00:00 If that common circuitl organization system exists, we could try using LLM to populate that. One way to categorize is by "passive" vs "programmable" components/circuits. Another way is by "physical" implementation vs "logical" function. ## Seve — 2026-07-21T14:37:02.897000+00:00 There is the “sparkfun boards” repo, the common repo we will mostly reserve for physically validated boards (something we know for sure works) until we are confident in ai https://github.com/tscircuit/sparkfun-boards ## Seve — 2026-07-21T14:37:53.319000+00:00 For ai generated circuits, i think anyone can push them to our registry via “tscircuit push”, we will also do this for designs that may not be physically validated ## astrimid — 2026-07-21T14:46:35.125000+00:00 I'm thinking some repo for showcasing functional chips. For example reproducing texas instruments evaluation boards documentation: https://www.ti.com/lit/ug/slvu086/slvu086.pdf It has bill of materials, schematics and PCB layout, so seems to be perfect for creating tscircuit representations which could be backfed to train LLMs or creating skills.md Sparkfun appears to be a manufacturer? So does it mean a separate git repository per manufacturer? ## Seve — 2026-07-21T14:49:52.256000+00:00 For official repos yep ## Seve — 2026-07-21T14:50:01.687000+00:00 There is a tscircuit/ti repo as well ## astrimid — 2026-07-21T15:04:25.247000+00:00 Ah, so it already exists and works. I was confused by editor syntax error: `Cannot find module '@tsci/tscircuit.ti' or its corresponding type declarations.` thinking I'd need to clone the repo locally and run the local copy. So there are official repos, maintained by tscircuit and community-implemented repos? And I could potentially create my own library LLM could feed on? ## Seve — 2026-07-21T15:06:00.550000+00:00 Yep!!! The official repos are pretty new so we’ll look into that issue cc <@809856037376491570> ## astrimid — 2026-07-21T15:41:23.067000+00:00 Ok. Looking back at original thread, this seems to be a human-driven reporting without creating/navigating discord/github accounts/channels/repos, not fully automated feature/bug discovery. For this particular missing feature (impedance or diff pair gap), we have two facets: logical requirement (impedance) and PCB implementation (constraint on physical distance between traces, width, pcb layer thickness, etc). One could be represented as annotation on schemetics, another needs to be encoded as manually calculated and specified constraints for automatic routing. So one design intent needs multiple specifications: physical and logical/electrical constraints. Hence my previous note about canonical hierarchical listing of features independent of EDA implementation, so that AI could transplant and map knowledge. ## Seve — 2026-07-21T15:55:37.380000+00:00 Yea there are multiple domains that specifications map to, eg a usb port itself implies a differential pair. It also implies a cutout aperture for an enclosure, the need for power etc ## astrimid — 2026-07-21T16:05:40.339000+00:00 So for automatic AI design it needs to: fetch the design intent from database, like electrical requirement for USB signals, solve the physycal constraint given electrical requirements and then try to implement it in tscircuit using ``-like workaround with annotations while submitting a request for intent design syntax sugar (to compress it into fewer tokens/code). ## Seve — 2026-07-21T16:20:01.190000+00:00 yea the TSX is mostly a way to reduce the amount of context required- this is also true of any higher level language ## astrimid — 2026-07-21T17:02:38.702000+00:00 As I understand, currently there's no high level "design intent" specification that encodes constraint domains (e.g. standard imposed characteristics). The closest thing is SPICE model, but the inverse of simulation is needed for constraints. So each standard/design intent requires multi-domain specification. As you noted, tscircuit tries to build a single cross-domain model, to minimize redundant specification, but there's no way to capture intent explicitly as there are many cross-domain views. For example, `` is logical view of ``, footprint and pin/pads locations is physical implementation of ``. So logical intent and physical constraint are interdependent as there's no source of truth. To overcome that, one could think of design intent annotation: ``` ``` But this probably deserves a separate thread. ## Seve — 2026-07-21T17:10:35.746000+00:00 an intent element is too generic- is an example of capturing an intent. And there's which is a manual way of specifying pairs, then there's which is more automatic ## Seve — 2026-07-21T17:11:17.289000+00:00 your language proposal above is over-abstracting which reduces the effectiveness of types, and the compaction of intent ## Seve — 2026-07-21T17:11:31.765000+00:00 it's the right idea to think in terms of intent however ## astrimid — 2026-07-21T17:29:15.422000+00:00 Yeah, I'm thinking of this ` Codified Intent -> tscricuit implementation -> circuitjson implementation. This could also help LLM to reason about version changes, as tscircuit evolves and defines more elements. ## Seve — 2026-07-21T17:52:10.050000+00:00 i guess, but it's actually less structured to have more generic names- ## Rishabh — 2026-07-21T18:00:55.520000+00:00 Is the package install not working for you? Attachment: image.png — https://community.tscircuit.com/media/1529186428884357291 ## astrimid — 2026-07-21T18:04:20.029000+00:00 Can't reproduce anymore, it was on https://tscircuit.com/editor