Agentic review and linting#798
Conversation
ocampana-videotec
requested review from
HansBusch,
kieran242,
mfournier-genetec,
sujithhanwha,
venki5685 and
willysagefalk
|
Maybe a structure like this? Easier to maintain and reuse in different workflows like
.ai/ skills/ |
|
are we tried this on current ONVIF 26.06 RC2 spec documents to see how it really performs as experimental? |
|
I would further echo and support the query @venki5685 has made. For my own opinion I am very in favour of this functionality as similar Github hooks are in place on all of our dev products within my own organization and it really improves quality. |
|
Hello, I just implemented a proposal based on Willy's feedback:
|
kieran242
left a comment
kieran242
left a comment
There was a problem hiding this comment.
I have reviewed all the MD files and for the most part I agree with the content within.
I am however concerned that instead of flagging issues to a user via Git Review comment or suggestion that AI has been given the automatic privilege to update and change content . See my review comment below regarding "Shall" being converted to "SHALL" below.
Can you please confirm my query? and clarify for this PR the intended AI privileges that are being afforded to these tools?
|
|
||
| ### 1. Case Alignment & Syntax Audits | ||
| - You SHALL scan all modified prose clauses for requirement keywords (`shall`, `shall not`, `should`, `should not`, `recommended`, `may`). | ||
| - If any requirement keyword is found in lowercase or mixed-case within a normative requirement context, you SHALL convert it to strict **UPPERCASE** (e.g., changing "the device shall" to "the device SHALL"). |
There was a problem hiding this comment.
This reads, as do some other parts of the MD files, in this PR that you are stating that this AI set of tools can automatically change and update the content of the ONVIF standards and not flag a review comment!! instead for PR's.
There was a problem hiding this comment.
in the last push, the feedback does not operate on source but generates a table, as you can see in the following comment
|
So, I gave the prompt
int this branch, where I basically only have the draft of the draft of
there are still some enhancements to be done, because for example always having development as reference branch is not the best solution. But at least, this gives the idea |
Capitalization of SHALL and similar words has been removed because it was wrong. |
|
Maybe having a set of fix skills that creates PRs ? Review skills = find everything. E.g. fix/ |
| ### Pass 2: DocBook 5 Structural Alignment & Paragraph Enforcement | ||
| Before calculating indentation depths, evaluate the semantic structure of the document: | ||
| 1. **DocBook 5 Schema Verification:** If `STRICT_DOCBOOK` is true, evaluate the document against DocBook 5 structural hierarchies. Identify any broken structural syntax or out-of-order parent/child element relationships. | ||
| 2. **Paragraph Enforcement:** Scan for text blocks, tables, or itemized lists missing container elements. If an exposed or raw text node falls within or immediately adjacent to a modified line tracked in Pass 1, explicitly wrap it in properly closed `<para>...</para>` tags to ensure schema compliance. |
There was a problem hiding this comment.
This will auto-inserts tags, but system-guidelines.md 4 prohibits content generation
| - If a modified clause introduces a requirement that cannot be programmatically verified by the ONVIF Device or Client Test Tools, flag it as an "untestable requirement assertion" so the committee can adjust the wording. | ||
|
|
||
| ### 3. Data Tracking Requirement | ||
| - When a structural schema validation error occurs or a missing `<para>` tag is injected, you SHALL record the exact `File` and the specific `Line` number where the structural modification took place. |
There was a problem hiding this comment.
I feel this belongs in the lint skills
| ## Instructions | ||
|
|
||
| ### 1. ONVIF Structural Contract Audits | ||
| - Verify that all newly introduced or modified namespaces strictly adhere to official ONVIF naming conventions and URL structures. |
There was a problem hiding this comment.
I think it could be worth to add an inline definition of the pattern (e.g. http://www.onvif.org/ver{NN}/{service}/) or reference a file in the repo
5 participants
This PR establishes a repository-wide, tool-agnostic AI guidelines framework. As different contributors use different AI assistants (GitHub Copilot, OpenAI, Claude, Gemini, or Cursor), this setup ensures that all models adhere to the exact same repository rules, code conventions, and formatting constraints without duplication.
We are using a "Hub-and-Spoke" configuration layout:
I think the main focus should be in reviewing the skill more than the configuration. For me, this could replace PR #726