Skip to content

Conversation

@mtrmac
Copy link
Contributor

@mtrmac mtrmac commented Feb 6, 2026

So far, this seems to work at least in reducing the redundant comments.

@github-actions github-actions bot added the image Related to "image" package label Feb 6, 2026
@packit-as-a-service
Copy link

Packit jobs failed. @containers/packit-build please check.

1 similar comment
@packit-as-a-service
Copy link

Packit jobs failed. @containers/packit-build please check.

@@ -0,0 +1,78 @@
# Commitments
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it actually work to have AGENTS.md in a subdirectory like this? I don't think tools will read it unless invoked from that subdirectory which is likely unusual.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least https://cursor.com/docs/context/rules#agentsmd suggests that works. I don‘t know how to tell for sure. (Asking the agent without any task reveals that it found the image/AGENTS.md file.)

Anecdotally, I have seen agent edits that suggest that these instructions were followed in content outside the image directory; I’m not sure.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK I see, I was unaware of this. I spent some tokens on this:

Looking at the OpenCode source code:
OpenCode behavior (from instruction.ts)
1. System prompt loading (systemPaths() lines 70-111): Only loads AGENTS.md by walking up from the working directory to the worktree root using Filesystem.findUp(). It does not descend into subdirectories at startup.
2. On-demand subdirectory loading (resolve() lines 166-190): When the Read tool reads a file, it walks up from that file's directory to the project root, loading any AGENTS.md files it finds that weren't already loaded.

I wasn't aware of this. That said...I guess you're also trying to say that you work on only the image/ subdirectory and aren't trying to imply style/coding constraints for the rest of the repository...which I can understand, but OTOH seems to conflict with the monorepo goal?

None of this seems controversial and so it'd make sense to move it up a level anyways right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For historical reasons I feel sort of authoritative for coding style in image. It’s weaker for storage where I don’t have the history. And I have historically done very little in common so I want to be much more cautious about imposing my aesthetic choices there. (E.g. libartifact is, I understand, intentionally using more verbose comments.)

That said, it’s an RFC. If others like it, I’m not opposed to making this top-level.


# Prioritize human attention

Avoid repetitive code. As a rule of thumb, 3 repetitions of
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of this looks good, however...I think some of it is better broken out into a separate STYLE.md - where it's also applicable for humans too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improving all of that would be nice, but it’s a “someday-maybe” task, while changing what agents do for my work, and for work that I have to review (e.g. the above is very frequently violated in AI-written tests), is comparatively much more urgent.

So far, this seems to work, at least in reducing the redundant
comments.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

image Related to "image" package

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants