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/sjarmak/agent-workflows/scaffoldnpx skills add sjarmak/agent-workflows --skill scaffoldgit clone --depth 1 https://github.com/sjarmak/agent-workflowsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/sjarmak/agent-workflows/scaffold)<a href="https://agentmods.dev/skills/sjarmak/agent-workflows/scaffold"><img src="https://agentmods.dev/badge/skills/sjarmak/agent-workflows/scaffold.svg" alt="Measured on agentmods" height="20"></a>What 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.00000 | $0.01970 |
| Opus 5 | $0.00000 | $0.00985 |
| Sonnet 5 | $0.00000 | $0.00394 |
| Haiku 4.5 | $0.00000 | $0.00197 |
Grade A, and why
scaffold 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 4d ago.
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 — 202 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Build-order planning via competing sequencing strategies. Takes a chosen design (from /diverge-prototype or any architecture decision) and spawns N independent agents, each proposing a different build-order strategy. Each agent produces a sequenced implementation plan with milestones, dependencies, and risk assessment. Synthesizes into a recommended build plan.
Arguments
$ARGUMENTS — format: [N] [path/to/design.md or inline description] where N is optional (default: 4)
Parse Arguments
Extract:
- agent_count: the optional leading integer (default 4, min 2, max 6)
- design_input: a file path to a design doc/prototype/PRD, or an inline description of what needs to be built
If the design input is missing or unclear, ask the user to clarify before proceeding.
Phase 1: Understand the Design
Read the design doc, prototype, or PRD provided. Extract the following:
- Components to build — every distinct module, service, or subsystem
- Dependencies between them — what requires what
- External integrations — third-party APIs, databases, services
- Testing requirements — what needs testing and at what level
- Deployment needs — infrastructure, environments, CI/CD
Prepare a build brief that summarizes:
- What needs to be built
- What exists already (if working within an existing codebase)
- What the constraints are (technical, timeline, team)
Present the build brief to the user and confirm before proceeding. Adjust if the user gives feedback.
Phase 2: Spawn Sequencing Agents
Launch all N agents in parallel using the Agent tool. Each agent receives the build brief plus a unique sequencing strategy drawn from this pool (assign strategies 1 through N):
- "Riskiest-First" — Start with the highest-uncertainty components. Front-load risk to learn early whether the approach works. Motto: "fail fast on the hard stuff."
- "Demo-able First" — Start with the components that produce visible, testable output. Build stakeholder confidence early. Motto: "something to show every sprint."
- "Dependency-Topological" — Strict dependency order. Build foundations first, layers on top. Nothing starts until its dependencies are complete. Motto: "no stubs, no mocks, each piece works when built."
- "Vertical Slice" — Build one thin end-to-end path through the entire system first. Proves integration works before widening. Motto: "narrow and deep before wide."
- "Test Infrastructure First" — Start with test harness, CI/CD, monitoring, observability. Build the ability to verify before building things to verify. Motto: "confidence before velocity."
- "Parallel Tracks" — Identify independent work streams that can proceed simultaneously. Optimize for team throughput. Motto: "max parallelism, defined interfaces."
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.
- 4d ago First seen · 202 lines · 0 tokens per session scan A 1e07371c9b3b
scaffold is a skill published in the GitHub repository sjarmak/agent-workflows (9 stars, last pushed 1mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,970 tokens. 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
speckit.specify
Skill "speckit.specify" from caipe-io/ai-platform-engineering, covering user input, outline, quick guidelines, section requirements and for ai generation.
speckit.clarify
Skill "speckit.clarify" from caipe-io/ai-platform-engineering, covering user input and outline.
local-integration-testing
Run end-to-end integration tests with all 15 agents and supervisor in local Docker Compose dev environment. Validates agent discovery, multi-agent routing, checkpoint persistence, and cross-agent follow-up conversations.
release-docs
Generate a combined release blog post for ai-platform-engineering. Produces a single docs/releases/YYYY-MM-DD-release-X-Y-Z.md file containing release notes and the upgrade guide (migration guide) inline. Use when cutting a release, when a user asks "what changed in 0.4.x", or when upgrading their values.yaml to a new…
update-docs
Audit and update all documentation moving parts for ai-platform-engineering. Checks release blog posts, features page, agent docs, homepage version strings, Docusaurus version config, and sidebar completeness. Fixes what is stale and reports what needs manual attention. Use after cutting a release, adding a new agent…
docker-compose-first-install
Validate and repair the OSS first-install Docker Compose path. Use when editing docker-compose.yaml, docker-compose.dev.yaml, .env.example, release image tags, Compose profiles, Keycloak/OpenFGA/RAG defaults, or first-launch UI behavior for local all-in-one installs.