Repository navigation
enhancement: drop template folder from .squad #1436
Description
The .template folder is large and I think unecessary in a repository that uses Squad.
It should not be added when running squad init.
the templates are already embedded in the CLI, and during an upgrade, you can diff the actual squad runtime files against the ones in the CLI, rather than the copied tempalte files.
If the user wants to modify templates, we can still support adding a template file as an override, but by default there is no need to have the full template folder in the repository.
Why that change matters?
The outcome of squad init is scary (so many files!) and squad upgrade needs to keep all of them in sync (huge diff)
Reacted by Leho Kraav
Activity
tamirdresher commentedon Jul 2, 2026
Hey @serbrech — great observation, the init output is definitely intimidating and squad upgrade diffs are noisy because of it.
One concern with the "embed in CLI" approach: Squad is designed to be portable and CLI-independent. The .squad/ folder + squad.agent.md governance file is self-contained — it works on Copilot CLI (with or without the squad CLI installed), VS Code, GitHub.com, and any future Copilot surface. The coordinator reads templates at runtime via file reads, not CLI commands.
If templates move exclusively into the CLI binary, you create a hard dependency on the squad CLI for coordinator functionality that currently works everywhere. Users who adopt Squad by copying the folder structure (or getting it via a PR) without installing the CLI would see failures — the coordinator tries to read .squad/templates/ceremony-reference.md etc. and gets file-not-found.
What's already happening in v0.11.0:
Brady's been extracting template content into .squad/skills/ (e.g., \coordinator-init-mode, \coordinator-response-mode, \coordinator-source-of-truth). Skills feel less scary than templates because they have clear purpose and naming. The long-term direction is: templates gradually become skills or get inlined into the governance prompt, and the template folder shrinks organically.
Possible middle ground:
The key constraint: whatever solution ships must work for users who don't have the squad CLI installed — just the .squad/\ folder and a Copilot surface.
serbrech commentedon Jul 2, 2026
In that case, what are the copies used for under .squad directly?
dat-intellis commentedon Jul 10, 2026
@tamirdresher > There's a tax here I feel needs to be taken into consideration which is token and context cost.
Moving everything into skills adds token overhead in the form of skill fontmatter overhead. Each skill accumulating further. On top of the already heavy
squad.agent.mddefinition and the heavier-than-other-harnesses system prompt (I believe around 50kb?) it stacks up. Especially for multi turn sessions.With that said, the current ongoing extraction from the agent definition into skills is a net upgrade IMO! Bonus: Skills can refresh in sessions post-compaction.
Then there's the fact that skills are probability based so there's no guarantee that the model will remember to activate it.
With a cli (or alternatively, script) based approach it becomes possible to make those guarantees and save quite a lot of recurring "instruction token tax". It becomes possible to guarantee those triggers, chains, lookups, and handoffs.
Introducing an mcp server isn't much better in terms of token cost - those tool definitions carries a lot of tax. All tool definitions carry on all sessions. GitHub recently released a blog post stating that they discovered moving away from the GitHub mcp server to the GitHub cli resulted in a measurable drop in cost. (Might be due to the amount of public material included in the model training?).
Final thought: instead of extracting into multiple squad skills you might be able to collapse it into one skill using either a progressive disclosure approach or a skill-internal scripted selection. Full disclosure, I haven't thought this idea to completion yet. :D
lkraav commentedon Jul 17, 2026
0.11.0: I'm also wondering about this. Installed workflows are getting flagged by various eslint, yaml, etc checks, and I need to modify them.
But turns out modding
.squad/templates/workflows/squad-heartbeat.ymldoes nothing to align.github/workflows/squad-heartbeat.ymlto standards.So I'm also unclear on how exactly
.squad/templates/content is useful?tamirdresher commentedon Jul 17, 2026
Thanks for filing this. Ran an evidence pass across the CLI, runtime, and shipped templates. Findings:
Safe to remove from
.squad/templates/in generated projects (they are stale init copies, not read at runtime):.squad/templates/workflows/.squad/templates/skills/Both directories are produced by
squad initfrom bundled CLI templates and never read back by the runtime. The active workflow definitions consumed at execution time live in.github/workflows/(operative CI) and the active skill definitions the coordinator loads at runtime are the ones shipped inside the CLI package and referenced by path from generated agents/config, not the copies under.squad/templates/skills/. Deleting these two subtrees from an initialized repository is safe today and only removes duplication.Must remain in
.squad/templates/(these are runtime inputs, not stale copies):.squad/templates/are read by the runtime during agent spawn, charter compilation, and template resolution. Removing them will breaksquad copilot/squad rc/agent bootstrap in initialized projects. So the cleanup has to be scoped, not a blanket.squad/templates/deletion.One real behavior gap surfaced by this investigation:
.github/workflows/*are operative on every generated project, andsquad upgradecurrently overwrites local edits to those workflow files without asking or backing them up. Even if we drop the stale template copies, users who have hand-edited their.github/workflows/still lose those edits on the next upgrade. Filing that as a separate issue so it does not get lost in this cleanup tracker.Proposal for this issue:
.squad/templates/workflows/and.squad/templates/skills/fromsquad initoutput and from existing projects (either via asquad upgradecleanup step or a one-time migration)..squad/templates/are runtime inputs vs generated/stale copies, so the next contributor does not have to redo this evidence pass. Links to those follow-ups will land in a follow-up comment.Not editing the issue body or title; leaving the framing as you filed it.
tamirdresher commentedon Jul 17, 2026
Follow-ups filed:
.github/workflows/*#1493 for the.github/workflows/*local-edit preservation gap (workflow overwrite onsquad upgrade)..squad/templates/runtime inputs vs generated/stale copies (source template) #1494 for the.squad/templates/runtime-vs-stale documentation (source.squad/templates/README.mdtemplate).Both link back here. Keeping this issue open as the tracker for the actual pruning of
.squad/templates/workflows/and.squad/templates/skills/.lkraav commentedon Jul 17, 2026
🦸 📈
Cleanuping now.