The term went viral on X in 48 hours, with three competing meanings and one fabricated study. Under the noise: a real discipline with benchmark numbers, one gap nobody has claimed.
Had a look. Named handles like auth.login beat "that thing from the six-month-old chat", same problem I attack with wikilinks in the vault. Curious how you keep the .rq files from drifting once the code moves on. That's where every requirements doc I've seen dies.
- Yes, absolutely it has to be managed to maintain a high quality project!
- I suggest thinking of the rq files as code & the source of truth, rather than a doc - in my last few projects, nothing even slightly material goes through my agent without being specified in rq. Nothing material gets written in code, without an RQ-comment reference back to the idea it is serving.
- Each idea is tied to the implementation; and to tests!. I also utilise a meta-test, that **requires** all tests to be testing against a requirement.
- It is (should be) tightly integrated with the code base - if a requirement isn't relevant to the implementation you're working on it won't be "called" or surfaced.
- Ideas can be marked as deprecated with pointers to updated versions (if for some reason you want to capture legacy system description, instead of replacing the old implementation outright.)
- If a removed idea leave's behind orphans than the reqlan indexer flags missing references - almost like a typed language compile check.
Really clear breakdown, graph engineering concepts finally make sense to me now.
Thanks Aniket!
Another tool to consider here is reqlan - worth a look
Had a look. Named handles like auth.login beat "that thing from the six-month-old chat", same problem I attack with wikilinks in the vault. Curious how you keep the .rq files from drifting once the code moves on. That's where every requirements doc I've seen dies.
Thanks Eugeniu, appreciate that.
A few thoughts:
- Yes, absolutely it has to be managed to maintain a high quality project!
- I suggest thinking of the rq files as code & the source of truth, rather than a doc - in my last few projects, nothing even slightly material goes through my agent without being specified in rq. Nothing material gets written in code, without an RQ-comment reference back to the idea it is serving.
- Each idea is tied to the implementation; and to tests!. I also utilise a meta-test, that **requires** all tests to be testing against a requirement.
- It is (should be) tightly integrated with the code base - if a requirement isn't relevant to the implementation you're working on it won't be "called" or surfaced.
- Ideas can be marked as deprecated with pointers to updated versions (if for some reason you want to capture legacy system description, instead of replacing the old implementation outright.)
- If a removed idea leave's behind orphans than the reqlan indexer flags missing references - almost like a typed language compile check.