Arch Forum 2026-03-19¶
Participants: Backend devs, Andy, Limkevin, Kyle, and Victor
Agenda¶
- SQLFluff and uv
- A unified Majority CLI: m
- be-template and copier
- Table copy workflow (Rasmus)
- Sharing of AGENTS.md, skills, hooks, etc.
Summary¶
SQLFluff and uv¶
-
Use uv for all things Python.
uvis similar tonpmor thedotnetCLI. -
A short recap of
sqlfluff, in case someone forgot.- It's like
.editorconfigwithdotnet format, but more advanced, for.sqlfiles.
- The.sqlfluffconfig file (i.e. https://github.com/majority-dev/be-platform/blob/master/Minority/.sqlfluff).
- sqlfluff extension in VS Code
- sqlfluff CLI (uv tool install sqlfluff,sqlfluff fix ..., etc.)
A unified majority CLI: m¶
I think we should standardize on the m CLI by merging the majority-cli tool into it and removing the PowerShell scripts.
- Easier with a single tool that does all Majority-related things, with better discoverability
- No need to have PowerShell at all anymore, which is nice for non-Windows users
More to come on this topic.
be-template and copier¶
To more easily synchronize common files/folders between repos, I have experimented with a template solution.
The idea:
- A repo, be-template, that contains a template that should be applied to all backend areas.
- The template contains files that are shared between backend areas, like the CI/CD workflows.
- When such a file is updated, it's committed to
be-template. The repo requires a normal PR with approval. - When a PR is merged (and/or on a schedule, like once per week), a job runs that tries to apply the template to all backend areas and opens PRs, like Renovate does.
- Just like the Renovate PRs, if the PR is clean and green it will be auto-merged.
- To apply the changes, we adopt the tool Copier.
- The template allows parameterization (like DB name). The parameters are saved in the repo itself in a
.copier-answers.ymlfile.
Demo: creating a new repo config, running copier update, and reviewing the generated PR.
Open questions & POC thoughts:
- Do we need the clean-up.ps1 script? If it's useful, I think it's better to put it in the
mCLI. - The current template is very basic. The thought is to start small, and then expand.
- Some stuff in the current template doesn't work for all repos exactly. Those it doesn't work for need to adjust before adopting the template.
- If we think this is useful, we can add more items to the template:
- API/Service/Contract/Db/Test csproj files and some of their required files
- app-config files
- app-locales files
Meeting notes:
- Several features were requested:
- Support adding a new repo altogether
- Support for adding a new service (e.g. RegressionTest) to an existing area
- Support for / help for adding the required config tobe-deploymentsandplatform-infrastructurerepos when updating or creating a new service.
Table copy workflow (Rasmus)¶
Demo of the new table-copy GitHub workflow to copy data between tables. See bcp_table_copy.yml.
Meeting notes:
- A good and helpful feature
- More functionality would be useful:
- Option to copy secondary indexes automatically
- Option to copy only part of a table (i.e., by supplying a WHERE query)
Sharing of AGENTS.md, skills, hooks, etc.¶
How should we deal with the various LLM configs?
Some examples:
- AGENTS.md / CLAUDE.md
- Skills / Rules
- Memory
- Custom Agents / Sub-agents
- Hooks
- Tools
- Plugins
- MCPs
Questions:
- How many have any such custom files?
- How do we deal with different incompatible tools (AGENTS vs CLAUDE and similar)?
- What is repo-level vs local-computer-level?
- How can we share what we have?
Meeting notes:
- Most have some custom files
- Often we have some standard files in local workspace files
- The local workspace files can conflict with what's in the repo, often not for the best
- Files committed to the repo are often not as good as the local ones, and you are a bit hesitant to commit them.
- Separate documentation / knowledge.md file that can be attached to a session when relevant (e.g., a description of the router in mf remittance)
- Claude Code marketplace can be used to share Claude files. Right now we have something in be-devtools where you can add Claude plugins
- One thought: each repo should only have repo-specific knowledge that is not shared across all backend repos. Shared things should go into a workspace/local user place.