4 ms·

On another note, this rang true to me: > Basically knowledge packs should be specified in each npm package.json or similar. Our YAML-based file format for ass

On another note, this rang true to me: > Basically knowledge packs should be specified in each npm package.json or similar. Our YAML-based file format for assistants (https://docs.continue.dev/reference https://docs.continue.dev/reference) is hoping to do just this by allowing you "import knowledge packs". Does it need to be decoupled from package.json, etc.? One of the most interesting reasons we decided not to go that route was it can be cumbersome for all of your many dependencies to taken into account at once. Another is the question of how the ecosystem will evolve. I definitely think that each package author should take the time to encode the rules and best practices of using their library, however it might be difficult for community to help out if this is gated by getting in a pull request. At the same time, one of the soon-to-be-released features we are working on is the ability to auto-generate or suggest rules (based on package.json, etc.).

bhouston 2y ago
> Does it need to be decoupled from package.json, etc.? Knowledge packs should be decoupled from package.json just as eslint rules or commit-lint rules are. You can include them in package.json or in separate files. But including pointers to the main files in a package.json helps with discovery. All packages across all languages should support AI friendly knowledge packages so a level of decoupling is required. EDIT: After thinking about it I think README.md should just be written with Agentic Coders in mind. I wrote up my thoughts on that here: https://benhouston3d.com/blog/crafting-readmes-for-ai https://benhouston3d.com/blog/crafting-readmes-for-ai
mentalgear 2y ago
how are "knowledge packs" different than just the package's README ? (if present and well written, it should be as usable to devs as to an LLM, if not, maybe consider letting the LLM write it's own "Readme" for a package on the hub be scanning source/types of the package)
- sestinj 2y ago
  I'd say rules are quite similar to a README, just tailored to LLMs, which often benefit from slightly different information than a human would. One way to think about the difference is that we as developers have the chance to build up memory/context over time, whereas LLMs are "memoryless" so you want to efficiently load all of the necessary high-level understanding. > consider letting the LLM write it's own "Readme" for a package on the hub be scanning source/types of the package This is something we're looking to ship soon
- bhouston 2y ago
  I agree with you on the READMEs. In response to his suggestion that I write a blog post on the idea of knowledge packages, I just spend the last 30 minutes aligning on your suggestion by coincidence. Written up here: https://benhouston3d.com/blog/crafting-readmes-for-ai https://benhouston3d.com/blog/crafting-readmes-for-ai
  - sestinj 2y ago
    wow that was fast—some gems in there

bhouston 2y ago

> Does it need to be decoupled from package.json, etc.? Knowledge packs should be decoupled from package.json just as eslint rules or commit-lint rules are. You can include them in package.json or in separate files. But including pointers to the main files in a package.json helps with discovery. All packages across all languages should support AI friendly knowledge packages so a level of decoupling is required. EDIT: After thinking about it I think README.md should just be written with Agentic Coders in mind. I wrote up my thoughts on that here: https://benhouston3d.com/blog/crafting-readmes-for-ai https://benhouston3d.com/blog/crafting-readmes-for-ai

mentalgear 2y ago

how are "knowledge packs" different than just the package's README ? (if present and well written, it should be as usable to devs as to an LLM, if not, maybe consider letting the LLM write it's own "Readme" for a package on the hub be scanning source/types of the package)

sestinj 2y ago
I'd say rules are quite similar to a README, just tailored to LLMs, which often benefit from slightly different information than a human would. One way to think about the difference is that we as developers have the chance to build up memory/context over time, whereas LLMs are "memoryless" so you want to efficiently load all of the necessary high-level understanding. > consider letting the LLM write it's own "Readme" for a package on the hub be scanning source/types of the package This is something we're looking to ship soon
bhouston 2y ago
I agree with you on the READMEs. In response to his suggestion that I write a blog post on the idea of knowledge packages, I just spend the last 30 minutes aligning on your suggestion by coincidence. Written up here: https://benhouston3d.com/blog/crafting-readmes-for-ai https://benhouston3d.com/blog/crafting-readmes-for-ai
- sestinj 2y ago
  wow that was fast—some gems in there