Written project knowledge reduces repeated explanations to agents
Boris as quoted by Theo argues that teams should write instructions, review guidance, skills, and documentation for their codebases. His aim is productive agent work without additional project context supplied by the person making the request. Theo endorses the core idea that moving domain knowledge into the repository helps the next contributor's agent.
Test whether project files explain enough to newcomers
Give a fresh agent or new hire only the repository and see where the missing project explanation blocks progress. When the repository could have supplied that explanation, put it in the instruction or documentation layer. Keep review standards in a review file so the next review has access to those expectations too.
First tasks reveal explanations missing from project files
This is useful in shared codebases where a newcomer's first request still depends on explanations from existing contributors. That first attempt can expose knowledge that remains in prompts instead of being available in the repository. If the repository already supplies the needed context, this test does not call for adding more explanation merely to expand it.
Better documentation does not guarantee equal newcomer performance
Boris's equal-effectiveness claim for non-engineers is disputed by Theo and should not become a promise about newcomer performance. Theo's examples of public preferences and book-based tone tuning are illustrations, rather than generally recommended prompting techniques. Use repository-only onboarding to locate missing knowledge without assuming that name-dropping or borrowed book context will solve it.