redhat-et / redhat-et/docsclaw
Specialized Dockerfiles for agent flavors (docs, media, data, presentations, content)
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 2
- Forks
- 1
- Avg merge
- 6h 9m
- Merged PRs (30d)
- 1
Description
Summary
Create multiple Dockerfiles that bundle domain-specific CLI tools into the DocsClaw image for different business use cases.
Motivation
The base DocsClaw binary is 5 MiB, but agents need external tools for real work. Rather than one bloated image, provide purpose-built flavors that include only the tools relevant to each domain.
Proposed flavors
| Flavor | Use case | Key tools |
|---|---|---|
| docs | Document conversion, review, summarization | pandoc, libreoffice-headless, poppler-utils (pdftotext), wkhtmltopdf |
| media | Image acquisition, processing, description | imagemagick, ffmpeg, exiftool, curl/wget |
| presentations | Slide deck creation and rendering | marp-cli, mermaid-cli, chromium-headless |
| data | Report generation, CSV/Excel processing | gnuplot, csvkit, python3+openpyxl, jq |
| content | Blog posts, newsletters, polished Markdown | markdownlint-cli, vale (prose linter) |
These are tool-focused, not role-focused. The agent's personality and role come from the ConfigMap; the Dockerfile determines what tools are available.
Design considerations
- All flavors should use a common base image (UBI minimal or UBI micro)
- Multi-stage builds to keep image size reasonable
- Each flavor gets its own Dockerfile:
Dockerfile.docs,Dockerfile.media, etc. - CI should build and push all flavors to
quay.io/redhat-et/docsclaw:<flavor> - Consider whether some flavors should bundle MCP servers (e.g., Playwright for media)
Non-goals
- Developer-focused images (code review, linting) — developers use personal agents
- "Kitchen sink" image with everything — defeats the purpose
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the proposed Dockerfile.docs, Dockerfile.media, Dockerfile.presentations, Dockerfile.data, and Dockerfile.content entry points, along with the existing CI configuration. Review the common-base and multi-stage requirements, then verify that CI builds and pushes each flavor to the specified quay.io/redhat-et/docsclaw: tags.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, python
- Domain
- build-system, ci-cd, devops
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100