Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/stepkar2004/init-configurator/workflownpx skills add Stepkar2004/init-configurator --skill workflowgit clone --depth 1 https://github.com/Stepkar2004/init-configuratorWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00137 | $0.00874 |
| Opus 5 | $0.00068 | $0.00437 |
| Sonnet 5 | $0.00027 | $0.00175 |
| Haiku 4.5 | $0.00014 | $0.00087 |
Grade A, and why
workflow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 52 lines — stays where its author put it; the contents beside it link to each section on GitHub.
workflow — the loop every implementation session runs
One skill fires for all SWE work; the less-common parts load lazily from
references/when their trigger row matches. Do not rely on separate sibling skills auto-triggering for scale or rot-check — this file is their front door.
The loop
- Orient. Read
docs/state/now.md, then the active plan (docs/plans/when the repo keeps phase plans, else the current chunk indocs/state/roadmap.md). Know the chunk's goal and acceptance criteria before touching code. If no chunk is defined, defining one IS the first task. - Plan the chunk. Smallest end-to-end slice; name the files to touch and the tests that will prove it. If scope grows mid-chunk beyond the plan, stop — re-plan or split; never "just keep going".
- Implement. Follow the constitution (CLAUDE.md) and the architecture rules in the active plan — they are constraints, not suggestions.
- Verify — the forgettable steps, in order:
- New behavior ⇒ new test; changed behavior ⇒ changed test. Same chunk, no IOUs.
- Run the repo's gates:
project.yamldeclares them as tasks; the constitution (CLAUDE.md) and the pre-commit / CI configs are the full set. - User-visible behavior ⇒ actually run it — a green unit test is not a seen behavior.
- Document in the same chunk. Update whatever the change made stale: README, the
plan doc, an ADR for any new decision (
docs/decisions/), docstrings. The test: "would a fresh session mis-learn anything if it read the docs right now?" - Commit at the chunk boundary. Gates green →
docs/state/now.md+log.mdupdated → commit. NEVER push. The user pushes, or explicitly says push — this repo is public; an unpushed mistake is free, a pushed one is not. - Reflect — do not skip, do not defer. Ask it literally: did a lesson land this chunk
(a root cause found, a tool swapped, a convention decided, a default overridden, a
mistake repeated)? If yes, run the evolve procedure NOW
(
skill-manager/references/evolve.md) before the session ends — a lesson you plan to record "later" is a lesson lost, and re-teaching it next session is the tax. Task matched no skill? → one line indocs/state/miss-log.md, keep working.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 52 lines · 137 tokens per session scan A 97cdfa114418
workflow is a skill published in the GitHub repository Stepkar2004/init-configurator (1 stars, last pushed 1mo ago), licensed MIT. It adds 137 tokens to every session and 874 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
agent-code-analyzer
Agent skill for code-analyzer - invoke with $agent-code-analyzer.
foundry-config-setup
Resolve missing setup caused by a hardcoded Foundry project endpoint or model in a sample. Use when a sample fails because it uses a placeholder/hardcoded projectendpoint (for example "https://your-project.services.ai.azure.com") or a hardcoded model instead of reading them from the environment.
evolve
Start or monitor an evolutionary development loop.
agent-memory
../../../engineering/agent-memory/skills/agent-memory/SKILL.md.
agile-product-owner
../../../product-team/agile-product-owner/skills/agile-product-owner/SKILL.md.
dogfood
Systematically explore and test a mobile app on iOS/Android with agent-device to find bugs, UX issues, and other problems. Use when asked to dogfood, QA, exploratory test, find issues, bug hunt, or test this app on mobile.