Add agentic workflows context files#3387
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/kind/cleanup |
82e0bf0 to
c44001f
Compare
vdemeester
left a comment
There was a problem hiding this comment.
Few questions, otherwise looks good. The 'AGENTS.md` is a bit bigger than 60 lines but I feel it is needed 👼🏼
| `knative.dev/pkg/apis` (`condSet.Manage(status).MarkTrue/MarkFalse`). Do not use | ||
| `controller-runtime` — it is not in this project. | ||
|
|
||
| **API layout** — all CRD types live in `pkg/apis/operator/v1alpha1/`. Each component |
There was a problem hiding this comment.
Do we want to specify the version here ? (aka pkg/apis/operator/ should be good enough, isn't it ?)
|
|
||
| --- | ||
|
|
||
| ## PR Conventions |
There was a problem hiding this comment.
We should have an entry stating that pull request have to follow the pull request template.
|
|
||
| For complete detection logic, see `references/footer-detection.md`. | ||
|
|
||
| ### Assisted-by |
There was a problem hiding this comment.
Naive question, Assisted-by or Co-authored ?
There was a problem hiding this comment.
“Co-authored” seems to better reflect what actually happen.
There was a problem hiding this comment.
This is subjective, but I lean towards Assisted-By. To me, authorship implies ownership and accountability. This is a broader discussion in the Open Source community though, e.g. in this VSCode issue, and was a recent point of discussion by the Linux kernel maintainers as well (who adopted "Assisted-by" in their contribution guidelines)
There was a problem hiding this comment.
Yeah I saw that as well, I may lean toward Assisted-by for most cases I guess, we can / should accept both though.. Maybe it depends on the involvement of the agent in the commit 😅
There was a problem hiding this comment.
looks like a chicken egg debate :) but yes lets use Assisted-By across all projects
There was a problem hiding this comment.
A bit late to the discussion, sharing my thoughts nevertheless.
While I personally prefer Assisted-by as it more accurately describes the relationship, Co-authored-by has the practical advantage that GitHub natively recognizes it and surfaces it directly in the UI, making it immediately visible whether AI was involved - this built-in visibility is a meaningful benefit over what is treated as plain text.
Commit 67cfa52 - co-authored-by

Commit 32820cb - asssited-by

There was a problem hiding this comment.
Interesting. From what I see, it only shows it on the commit and not on the PR, which is less visible IMO, at least the way I interact with PRs.
Anyway, I like Assisted-by: more.
| @@ -0,0 +1,554 @@ | |||
| # Author Detection and Footer Generation | |||
|
|
|||
| Complete guide for detecting author information and generating required commit footers. | |||
There was a problem hiding this comment.
nit: these are called trailer(s) in the git realm (there is even git-interpret-trailers command to interact with it)
aThorp96
left a comment
There was a problem hiding this comment.
The suggestion for the (I assume, copy paste) error highlights an important point: AGENTS.md might be repository specific but commit types, trailers, release notes format, etc, are all pretty much standard across all of Tekton. If a 2k lines of skills has to be included in every repository it could result in maintenance issues as style guides change or skills need to be refined. Can the skill reference a shared skill in the plumbing more central repo? I think plumbing because it's vendored in every(?) repo, so an agent doesn't need to remotely fetch the skill reference/context.
| @@ -0,0 +1,269 @@ | |||
| # Commit Types Reference | |||
|
|
|||
| Complete reference for conventional commit types used in the Pipelines-as-Code project. | |||
There was a problem hiding this comment.
| Complete reference for conventional commit types used in the Pipelines-as-Code project. | |
| Complete reference for conventional commit types used in the Tekton Operator project. |
There was a problem hiding this comment.
Yes indeed, this skill is copy paste from pac, i wanted to have an uniformed shared skill for commit and release note, and +1 to have a shared thing
|
@vdemeester @anithapriyanatarajan can you have another look here please ? |
| ```markdown | ||
| * **Bold title:** One-sentence description of the change. | ||
| * Link: <PR_OR_COMMIT_URL> | ||
| * Jira: [SRVKP-XXXX](https://issues.redhat.com/browse/SRVKP-XXXX) |
There was a problem hiding this comment.
+1 to remove the Jira references. I assume it's coming from PaC from the time it was downstream only. Non Red Hat contributions won't have srvkp issue anyway. Dependabot PRs as well.
|
enarha
left a comment
There was a problem hiding this comment.
We use symlinks, CLAUDE.md -> AGENTS.md and that works on Linux and Mac and GitHub properly renders it, but it won't work on Windows. A simple workaround is to document for Windows users to use core.symlinks=true e.g. git clone -c core.symlinks=true https://github.com/tektoncd/operator.git.
Another thing is the vendor neutral locations. We have CLAUDE.md pointing to AGENTS.md which is fine. For the skills though we have .agents/skills pointing to .claude/skills instead the other way around. Not crucial, but it's an easy fix.
|
|
||
| - Fixing crashes or errors | ||
| - Resolving incorrect behavior | ||
| - Patching security vulnerabilities |
There was a problem hiding this comment.
No strictly a bug fix. As discussed at one of the upstream calls, we agreed to introduce few new labels, we can have one for security fixes. IMO we better drop this now than forget about it and create ambiguity when we introduce a proper security specific label.
| **Examples**: | ||
|
|
||
| - `fix(controller): resolve pipeline race condition` | ||
| - `fix(SRVKP-456): correct webhook payload parsing` |
There was a problem hiding this comment.
As discussed further down, if agreed, we should avoid SRVKP references. It could be nice if we can include GitHub specific format and point to GitHub issues, so they are automatically closed when the PR is merged.
| - `refactor(SRVKP-234): reorganize package structure` | ||
|
|
||
| **When to use**: | ||
|
|
There was a problem hiding this comment.
We might add an extra line about not changing existing behavior.
|
|
||
| - Makefile changes | ||
| - Docker/container build changes | ||
| - Dependency management (major) |
There was a problem hiding this comment.
This sounds vague to me. Instead we might focus on golang version and tooling e.g. updating go version in go.mod.
|
|
||
| **When to use**: | ||
|
|
||
| - GitHub Actions updates |
There was a problem hiding this comment.
Isn't it more straightforward if we say changes of .github/workflows/ directory?
We might also include as a separate entry changes of the .tekton directory.
- Makefile: reinstall golangci-lint when local version diverges from ci.yaml (v2.7.2) - Makefile: add PKG variable to lint-go for single-package lint - Remove unused resourceKind constants in tektonchain, tektonpipeline, and tektontrigger reconcilers Signed-off-by: Jawed khelil <jkhelil@redhat.com> Assisted-by: Claude Sonnet 4.6 (via Cursor)
- AGENTS.md: agent-oriented context for build, test, conventions, and architecture - .agents/skills/: commit-message and release-notes skills - .claude/skills -> .agents/skills, CLAUDE.md -> AGENTS.md - .gitlint: dependabot exclusion Signed-off-by: Jawed khelil <jkhelil@redhat.com> Assisted-by: Claude Sonnet 4.6 (via Cursor)
|
/retest |

Changes
Prepare the Tekton Operator repository for agentic workflows as part of SRVKP-11820.
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
make test lintbefore submitting a PRSee the contribution guide for more details.
Release Notes