From Frugal
Manages per-project model overrides for frugal agents: show current mapping, assign agents to different models (haiku, sonnet, opus, fable), or reset overrides.
How this skill is triggered — by the user, by Claude, or both
Slash command
/frugal:modelsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Manage the per-project model mapping for frugal's agents. Defaults live in each
Manage the per-project model mapping for frugal's agents. Defaults live in each
agent's frontmatter (agents/*.md under the plugin root); overrides live in the
project's .claude/routing-overrides.md, which the routing policy reads first.
Overrides work because the Agent tool accepts a model parameter per spawn - no
plugin files are ever edited.
Valid agents: scout, extractor, mechanic, builder, sage.
Valid models: haiku, sonnet, opus, fable.
model: frontmatter line in
<plugin-root>/agents/*.md (plugin root is two directories up from this
skill's base directory)..claude/routing-overrides.md if it
exists.scout=sonnet builder=opusValidate every pair against the lists above. Invalid agent or model: reject with the valid options, change nothing.
Create or update the managed section in .claude/routing-overrides.md
(create the file if missing, keep any unmanaged content above it intact):
## Model overrides (managed by /frugal:models)
| Agent | Model |
|---|---|
| scout | sonnet |
When spawning a frugal agent listed above, pass its listed model as the
Agent tool's `model` parameter.
Merge with existing overrides: new pairs win, unmentioned pairs stay.
Setting an agent to its default removes its row. Empty table: remove the whole section.
Confirm with the resulting mapping table and apply it immediately to any spawns later in this session.
resetRemove the managed section. If the file is then empty, delete the file. Show the default mapping.
npx claudepluginhub thomaslangbroek/frugal --plugin frugalGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.