-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Upstream model generated file and line linkification #1803
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
|
||
| export class FileLinkificationInstructions extends PromptElement<{}> { | ||
| render() { | ||
| return <Tag name='file_linkification'> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a gut feeling but this seems pretty verbose and I'm not sure how well models will follow the good/bad method written this way
| For casual greetings, acknowledgements, or other one-off conversational messages that are not delivering substantive information or structured results, respond naturally without section headers or bullet formatting.<br /> | ||
| <br /> | ||
| When referring to a filename or symbol in the user's workspace, wrap it in backticks.<br /> | ||
| <FileLinkificationInstructions /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this should break up the example
| - Don'ts: no nested bullets/hierarchies; no ANSI codes; don't cram unrelated keywords; keep keyword lists short—wrap/reformat if long; avoid naming formatting styles in answers.<br /> | ||
| - Adaptation: code explanations → precise, structured with code refs; simple tasks → lead with outcome; big changes → logical walkthrough + rationale + next actions; casual one-offs → plain sentences, no headers/bullets.<br /> | ||
| - File References: When referencing files in your response, always follow the below rules:<br /> | ||
| * Use inline code to make file paths clickable.<br /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should revisit these instructions too as they duplicate the linkfication stuff. I'd expect to have some base set of linkfication rules and then a (hopefully) small set of additional customizations for each model
| // Example: [src/file.ts](src/file.ts#L10-12) or [src/file.ts](src/file.ts) | ||
| const modelLinkRe = /\[(?<text>[^\]\n]+)\]\((?<target>[^\s)]+)\)/gu; | ||
|
|
||
| export class ModelFilePathLinkifier implements IContributedLinkifier { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's break up the existing FilePathLinkifier into the real links functionality and the inline code functionality. Maybe just delete the real links stuff from FilePathLinkifier and keep this class. I'd like to avoid the duplication though and make it so we just have one place that handles the markdown file links
Motivation
Move file path linkification upstream to the model so it emits canonical, machine‑parsable Markdown links (path), reducing reliance on heuristic fallback and enabling precise line anchors. Linkification falls back to current component if model does not handle it.
Also ensure consistent behavior across all model families (OpenAI/GPT‑5, Anthropic/Claude, etc.) while eliminating duplicated prompt text.
This is example response with line number linkification: