Comparison
Apothem vs raw GitHub Copilot config
Hand-maintaining GitHub Copilot's copilot-instructions.md versus rendering it from Apothem's shared profile.
GitHub Copilot reads its instructions from .github/copilot-instructions.md.
Apothem's github-copilot adapter renders that file from the shared profile. This
page contrasts hand-maintaining that config against managing it with Apothem.
Effort comparison
| Task | Raw hand-config | Apothem-managed |
|---|---|---|
| Author instructions | Hand-edit .github/copilot-instructions.md | Rendered: shared rules embedded into the file |
| Keep instructions aligned with other harnesses | Manual, per tool | Automatic on apothem update |
| Install / remove the config | Write and delete the file by hand | apothem install / apothem uninstall |
| Share reusable skills and commands | Hand-copy each skill folder into ~/.agents/skills/ and keep the copies current | Written to ~/.agents/skills/ by the adapter, one copy for every project, and refreshed on apothem update |
| Verify the config is correct | Manual inspection | apothem verify --harness github-copilot --project <path> |
What Apothem manages
The github-copilot adapter embeds the shared rules into
.github/copilot-instructions.md. Copilot documents hooks in
.github/hooks/*.json, which the adapter does not write, so guardrail intent is
carried entirely in the rendered instructions. Every change to the shared rules
re-renders the file on the next apothem update.
Migration path
- Run
apothem profile initto create the shared profile if you have not yet. - Move the content of your existing
.github/copilot-instructions.mdinto the shared corpus. - Run
apothem install --harness github-copilot --project <path>to render the instructions file. - Run
apothem verify --harness github-copilot --project <path>to confirm the config landed. - Use
apothem update --harness github-copilot --project <path>for every later change.