-
-
Notifications
You must be signed in to change notification settings - Fork 15
Rewrite AGENTS.md with architecture guide and add task docs for agents #364
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: master
Are you sure you want to change the base?
Conversation
Replace the rough-draft AGENTS.md with a comprehensive guide covering critical rules, the code generation pipeline, model schema, persistence infrastructure, and data migration system. Add separate step-by-step task documents in docs/agents/ for common operations: adding properties, writing migrations, adding classes, adding virtual properties, and writing tests. Co-authored-by: Cursor <cursoragent@cursor.com>
|
So, this can be compiled in any of the 3 frameworks? What version of mono? Why 3? One sentence would be helpful here to understand. |
|
Can this be enforced? Can the write commands only be accessible through these two commands? |
|
Why would Windows Forms be in here at all? Why reference it if it is not in the repo? Does this need one more sentence or clause of explanation? |
|
Is this something specific to this repo? Why is it best recorded here? |
|
Does this section add value? We probably need the test script called out (if there is one). Or make a testing.instructions.md file. |
|
Can we fix this programmatically? When we start a build (and need it), can we ensure that we are not in a shallow clone in a quick way? A fix is better than a known issue... |
|
This should probably be in a comment in a project file rather than here. These should just be ignored programmatically with a rationale (if needed). |
|
Can one more sentence be added as to why this architecture was chosen? It is unobvious to me. Is there an article that explains this paradigm? Do newer versions of DotNet make this irrelevant, but we want to still support mono? Is this a good long term strategy? If you feel we need a few paragraphs to explain, can you reference a document or wiki, etc? |
|
Is it best practice to put these here? Should they be grouped with the actual relevant data? |
|
Are these files generated from a user guide that was fed into Claude? How have they been validated? I don't know enough to know if they are right. |
|
Is this a duplication of data migration? You can ask Claude "Check for duplicated code here" "Refactor to have an appropriate amount of context for a broad scope of work". |
|
Do these show up in VSCode Copilot extension? If we want new agents, they should show up for GitHub and for claude. We should follow "https://docs.github.com/en/copilot/reference/custom-agents-configuration". These are custom agents (specific general tasks that need to follow a workflow and have certain things they can an cannot do. They may also need a bit of reformatting (head matter, etc.). |
|
You may also want a impact-assessment subagent (or similar). Sending off sub-agents to research the codebase and then come back is often effective. YOu can create a custom agents and then call it out in other agents to use as appropriate. |
|
This sounds very formal. Will this become the formal documentation or is it written somewhere else? Can we reference it or can this become it? |
|
Writing tests are better as skills. Skills are reusable. We should also have a debugging skill (with specific debugging paradigms for this repo). You can have a custom agents be for writing tests, but I would put most of the logic in a skill. Migrations should also be a skill - it's kind of cross cutting concerns. Does the distinction make sense? https://github.com/orgs/community/discussions/183962 |
johnml1135
left a comment
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.
@johnml1135 reviewed 6 files and all commit messages.
Reviewable status: all files reviewed, 15 unresolved discussions (waiting on @jasonleenaylor).
jasonleenaylor
left a comment
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.
@jasonleenaylor made 7 comments.
Reviewable status: all files reviewed, 15 unresolved discussions (waiting on @johnml1135).
AGENTS.md line 21 at r1 (raw file):
Previously, johnml1135 (John Lambert) wrote…
Can this be enforced? Can the write commands only be accessible through these two commands?
It is enforced actually, this is just making sure the agent understands that. Actually there is better guidance I can give here. The silently fail is not accurate.
AGENTS.md line 23 at r1 (raw file):
Previously, johnml1135 (John Lambert) wrote…
Why would Windows Forms be in here at all? Why reference it if it is not in the repo? Does this need one more sentence or clause of explanation?
We specifically guard against developers who tend to add things like message boxes or other things from System.Windows.Forms (there is a build target that guards against it). The AI picked up on that, which seems fine.
AGENTS.md line 48 at r1 (raw file):
Previously, johnml1135 (John Lambert) wrote…
Can we fix this programmatically? When we start a build (and need it), can we ensure that we are not in a shallow clone in a quick way? A fix is better than a known issue...
It is a known GitVersion issue I believe, not an issue of ours.
AGENTS.md line 61 at r1 (raw file):
Previously, johnml1135 (John Lambert) wrote…
Can one more sentence be added as to why this architecture was chosen? It is unobvious to me. Is there an article that explains this paradigm? Do newer versions of DotNet make this irrelevant, but we want to still support mono? Is this a good long term strategy? If you feel we need a few paragraphs to explain, can you reference a document or wiki, etc?
If you are referring to the class id, field id constants that was to provide fast reflection and support data migration capabilities which didn't require instantiating C# classes. It has nothing to do with mono.
This markdown is specific to the agents, so I don't know that adding paragraphs to explain it is valuable.
AGENTS.md line 173 at r1 (raw file):
Previously, johnml1135 (John Lambert) wrote…
Is it best practice to put these here? Should they be grouped with the actual relevant data?
I'm not sure if this is best practice. this is what I got when I asked it to keep the context which an agent starts with as small as reasonable but to have instructions for specific common tasks with best practices. I was wondering about this and thinking they should really be 'skills' that live somewhere. I'm not sure on the best practice if there is one for vendor unlocked skills files.
docs/agents/adding-a-property.md line 2 at r1 (raw file):
Previously, johnml1135 (John Lambert) wrote…
Are these files generated from a user guide that was fed into Claude? How have they been validated? I don't know enough to know if they are right.
Yes, these files came from a combination of a model description pdf and specific code file guidance that I gave. I've mostly validated them but I was actually executing a test model change to validate some of this.
docs/agents/writing-a-data-migration.md line 3 at r1 (raw file):
Previously, johnml1135 (John Lambert) wrote…
This sounds very formal. Will this become the formal documentation or is it written somewhere else? Can we reference it or can this become it?
This is a description of how the datamigration code works and it is giving the agent instructions on how to successfully add one (I'm currently testing if these instructions actually result in successful agent action)
Replace the rough-draft AGENTS.md with a comprehensive guide covering critical rules, the code generation pipeline, model schema, persistence infrastructure, and data migration system. Add separate step-by-step task documents in docs/agents/ for common operations: adding properties, writing migrations, adding classes, adding virtual properties, and writing tests. Co-authored-by: Cursor <cursoragent@cursor.com>
* Move migration details to skill * Improve handling of icu tests to remove the need for bootstrapping by agents * Remove the obsolete build commands Co-authored-by: Cursor <cursoragent@cursor.com>
Replace the rough-draft AGENTS.md with a comprehensive guide covering critical rules, the code generation pipeline, model schema, persistence infrastructure, and data migration system. Add separate step-by-step task documents in docs/agents/ for common operations: adding properties, writing migrations, adding classes, adding virtual properties, and writing tests.
This change is