[
https://issues.apache.org/jira/browse/SOLR-18076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18053031#comment-18053031
]
Jan Høydahl edited comment on SOLR-18076 at 1/20/26 12:33 PM:
--------------------------------------------------------------
See
[https://vibe-coding-manifesto.com/#project-automation-for-the-vibe-codingreview-workflow]
for description and example of such a file. The manifesto suggests it to be
somewhat shorter than and can work in tandem with tool-specific prompt files.
Here are some examples of what I believe would make up good rules for Solr:
* Follow Apache Software Foundation licensing rules, avoid adding a dependency
with a banned license
* Use the project's custom EnvUtils to read system properties. It auto
converts env.var SOLR_FOO_BAR to system property solr.foo.bar
* We use gradle version-catalog toml file to encode dependency versions, never
add versions directly to build.gradle files
* We use the "cutterslade-analyze" plugin which requires explicit recording of
all dependencies in a build.gradle file
* Always run "gradlew tidy" after editing files
* Always run "gradlew updateLicenses resolveAndLockAll --write-locks" after
adding or changing a dependency. See dev-docs/gradle-help/dependencies.txt for
more info
* Always run "gradlew check -x test" before delcaring a feature done
* Respect our .editorconfig
* Always add the Apache License to new source files
* When adding new unit tests, avoid using XXX and use TestRule XXX instead
* For major or breaking changes, add a prominent note in reference guide
major-changes-in-solr-X.adoc
* Always consider whether a reference-guide page needs updating due to the
new/changed features. Target audience is end user
* For changes to build system and other developer-focused changes, consider
updating or adding docs in dev-docs/ folder
* Keep all documentation including javadoc concise
* We use logchange as changelog tool. Add a new file
changelog/unreleased/SOLR-XXXX-describe-your-feature.yml for each change, see
dev-docs/changelog.adoc
* See dev-docs/gradle-help/tests.txt for hints on running tests
etc...
was (Author: janhoy):
See
[https://vibe-coding-manifesto.com/#project-automation-for-the-vibe-codingreview-workflow]
for description and example of such a file. The manifesto suggests it to be
somewhat shorter than and can work in tandem with tool-specific prompt files.
Here are some examples of what I believe would make up good rules for Solr:
* Follow Apache Software Foundation licensing rules, avoid adding a dependency
with a banned license
* Use the project's custom EnvUtils to read system properties. It auto
converts env.var SOLR_FOO_BAR to system property solr.foo.bar
* We use gradle version-catalog toml file to encode dependency versions, never
add versions directly to build.gradle files
* We use the "cutterslade-analyze" plugin which requires explicit recording of
all dependencies in a build.gradle file
* Always run "gradlew tidy" after editing files
* Always run "gradlew updateLicenses resolveAndLockAll --write-locks" after
adding or changing a dependency
* Always run "gradlew check -x test" before delcaring a feature done
* Respect our .editorconfig
* Always add the Apache License to new source files
* When adding new unit tests, avoid using XXX and use TestRule XXX instead
* For major or breaking changes, add a prominent note in reference guide
major-changes-in-solr-X.adoc
* Always consider whether a reference-guide page needs updating due to the
new/changed features. Target audience is end user
* For changes to build system and other developer-focused changes, consider
updating or adding docs in dev-docs/ folder
* Keep all documentation including javadoc concise
* We use logchange as changelog tool. Add a new file
changelog/unreleased/SOLR-XXXX-describe-your-feature.yml for each change
etc...
> Add a PROMPTING.md or similar for AI agents
> -------------------------------------------
>
> Key: SOLR-18076
> URL: https://issues.apache.org/jira/browse/SOLR-18076
> Project: Solr
> Issue Type: Wish
> Reporter: Jan Høydahl
> Priority: Major
>
> I came across
> [https://vibe-coding-manifesto.com|https://vibe-coding-manifesto.com/] which
> outlines several best practices for AI contributions to a project. We encode
> some of these already in
> [https://github.com/apache/solr/pull/3946|https://github.com/apache/solr/pull/3946.].
> But there is a recommendation for a {{PROMPTING.md}} file in the git repo to
> help AI agents follow project guidelines and preferences.
> This Jira is to discuss whether we should add such a file and what it should
> contain. Until there is a formal standard for such files, it seems as
> {{PROMPTING.md}} is the best choice.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
