docs(readme): describe basic idea

README.md

@@ -1,4 +1,71 @@
 # buildr
 
-* [Docs](https://docs.buildr.icb4dc0.de/)
-* [Raise/vote for feature requests/bug tickets](https://community.buildr.icb4dc0.de/)
+* [Docs (coming soon)](https://docs.buildr.icb4dc0.de/)
+* [Raise/vote on feature requests/bug tickets](https://community.buildr.icb4dc0.de/)
+
+## Current state
+
+The project is currently under heavy development and not production ready (although the project already uses the tool itself to build, run scripts and the like).
+
+## Purpose
+
+The general idea is something between [goreleaser](https://goreleaser.com/), [taskfile](https://taskfile.dev/installation/) and [dagger](https://dagger.io/).
+
+Think of: having one tool to build all the projects your working on no matter if it's Go code, C#, Java, Python or anything else.
+
+The HCL2 based DSL allows you to define the whole build pipeline and to run it either locally or in the CI of your choice.
+You can use it to:
+- ensure local development dependencies are available
+- run steps in container images to use the tools installed there
+- define build parameters (so you don't have to keep them in mind or fall back to shell scripts)
+- more to come
+
+The basic idea of the workflow is like this:
+
+1. Install tools
+1. Run some tasks e.g. to generate code, execute tests, ...
+1. Build your optimized binary
+1. Package it e.g. as container image or as archive (coming soon)
+1. Create a GitHub/GitLab/Gitea release and upload created artifacts
+
+Every module can have dependencies to other modules and the execution will be optimized to run as much in parallel as possible.
+The CLI can be used to execute every kind of module (`buildr build`, `buildr task`, ...).
+
+## Features
+
+### Tools
+
+- `go_tool` - install tools via `go install`
+
+### Tasks
+
+- `script` - run scripts
+
+### Builds
+
+- `go_build` - build Go binaries
+
+### Packages
+
+- `container_image` - build container images (no Docker/Podman installation required)
+
+### Helpers
+
+- `vault` to encrypt required secrets and store them as part of your code
+
+### Execution
+
+- execute modules locally
+- execute modules in a container
+    - output is streamed back
+    - created files are automatically extracted
+- map input for modules
+    - allow layering of multiple directories on top of each other (just like container image layers)
+    - allow operation on a subdirectory/subset of files of the repository (works for local and container execution
+      environments)
+- redirection of created files
+    - in container execution environment a filesystem watcher tracks created/modified files, for local task execution a
+      unionfs a-like FUSE driver is used to layer directories and redirect created files to a module specific output
+      directory
+    - `out_dir` of every module is configurable and can be set to repository root if desired
+- `.buildrignore` (same semantics like .gitignore) to exclude files that should never be copied e.g. to/from containers