> For the complete documentation index, see [llms.txt](https://docs.konsist.lemonappdev.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.konsist.lemonappdev.com/advanced/why-there-are-no-pre-defined-rules.md).

# Why Are There No Pre-defined Rules?

Many linters including [Detekt](https://github.com/detekt/detekt) and [ktlint](https://github.com/pinterest/ktlint) have a predefined set of rules. These rules are derived and aligned with guidelines or common practices for writing high-quality code and industry coding conventions ([Kotlin coding conventions](https://kotlinlang.org/docs/coding-conventions.html), [Android Kotlin style guide](https://developer.android.com/kotlin/style-guide), etc.).

However, there are no industry standards when it comes to application architecture. Every code base is different - different class names, different package structures, different application layers, etc. As the project grows, the code base evolves as well - it tends to have more layers, more modules, and a more complex code structure. These "rules" are hard to capture by a generic linter, because they are often specific to the given project.

Let's consider a use case - a concept defined by the [Clean Architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html). At a high level the use case definition is quite simple - "use case holds a business logic". How is the use case represented in the code base? Well... In one project this may be a class that has a name ending with `UseCase`, in another, it may be a class extending `BaseUseCase` and in another, a class annotated with `@UseCase` annotation. The logic for filtering "all project use cases" will vary from project to project.

Now let's consider the actual structure of the use case class:

* should every use case have a `UseCase` suffix in the class name?
* can the use case be extended or include another use case?
* should every use case reside in the `usecase` package?
* should the use case have a single method?
* how should this method be named?
* can this method have overloads or should it be defined as an `invoke` operator?
* should this method have a `suspend` modifier?
* …

Answers will vary from project to project. That is why Konsist favors a more flexible approach - it allows filtering members and defining custom code base assertions (tests). On top of that Konsist is utilizing Kotlin collection processing API to provide more control over filtering and asserting declarations ([Declaration](/features/declaration.md)).

{% hint style="success" %}
Some things can be standardized across different projects e.g. constructor parameter names being derived from the property name, or alphabetical order of the parameters. For now, custom tests will be a core part of Konsist, however, we are considering the addition of a small set of predefined rules in the future.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.konsist.lemonappdev.com/advanced/why-there-are-no-pre-defined-rules.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.