Primary question: Are the Markdown agent definitions and shell scripts safe enough to import into your internal AI workflow without prompt-injection or credential-leak exposure?
RepoDaily adoption score
RepoDaily rates this as 88/100 (strong) for adoption: evidence, installation path, production risk, differentiation, license clarity, and AI/agent fit are scored from the article sources and adoption notes.
4 source(s) across 3 source category/categories, plus a RepoDaily-specific evidence module when available.
6 workflow step(s), 4 next-action step(s), and 1 command/install signal(s) were detected.
Trending momentum is +1,793 stars, with maintenance/release/issue signals counted when present.
Risk is marked medium, with 5 security note(s) and 3 explicit skip condition(s).
3 opportunity lens item(s), 4 alternative(s), and 3 type-specific section(s) support differentiation.
License source or license wording is present.
4 AI/agent-related signal(s) were detected in the article text and metadata.
Project overview
msitarzewski/agency-agents packages itself as a complete AI agency: a catalog of specialized agents organized into 16 divisions, including a dedicated security division covering security architecture, AppSec, pentest, threat intelligence, and incident response. The repository is written primarily in Shell and Markdown, which means the deliverable is prompt definitions plus installation, conversion, and lint scripts rather than a compiled binary.
The project picked up 1,793 period stars and landed at trending rank 1 for 2026-07-01. The appeal is immediately readable from the structure: each agent is a Markdown file with frontmatter and prompt content, organized under labeled directories such as engineering, design, finance, gis, and security. The CONTRIBUTING.md names divisions.json as the single source of truth for the division set, validated in CI by scripts/check-divisions.sh.
From a security-tool perspective, the interesting surface is not just the security division's agents but the repository's own handling of risk. The SECURITY.md is explicit about two categories: non-executable Markdown agent files that must not store secrets, and executable shell scripts in scripts/ that contributors must review before running. That framing makes the repo a useful case study for teams building internal agent catalogs without importing prompt-injection vectors or unreviewed shell code.
Why it is trending now
- 1,793 period stars and trending rank 1 for 2026-07-01, driven by a low-friction Markdown format that lets non-engineers read and modify agent definitions.
- 16 named divisions, including security, academic, engineering, gis, spatial-computing, and specialized, give the catalog breadth without requiring users to adopt a framework.
- A documented security policy with a 48-hour acknowledgment window and a 7-day initial assessment target signals operational seriousness for a community prompt catalog.
- The convert.sh script generates per-tool output under integrations/, which positions the repo as an adapter layer between plain Markdown agents and downstream AI tools.
Problem it solves
- Markdown agent files are non-executable prompt definitions, but any agent imported into an LLM context can carry prompt-injection instructions if not reviewed.
- Shell scripts in scripts/, specifically install.sh, convert.sh, and lint-agents.sh, are executable and must be reviewed before merging, as stated in SECURITY.md.
- Contributors can propose new divisions by editing divisions.json, scripts/convert.sh, and scripts/lint-agents.sh, which expands the trusted surface area on every accepted change.
- The strategy/ and integrations/ directories are explicitly excluded from the division list, which means generated and playbook content can accumulate outside the CI-enforced catalog checks.
How it works
- Clone the repository and read SECURITY.md before running any script, since the project flags scripts/install.sh, scripts/convert.sh, and scripts/lint-agents.sh as executable and review-required.
- Inspect divisions.json to see the authoritative list of 16 divisions, then navigate to the relevant directory, such as security/ for security-architecture, AppSec, pentest, threat-intel, and incident-response agents.
- Open a Markdown agent file to review its frontmatter and prompt body; SECURITY.md states that agent files must not contain API keys, tokens, or credentials.
- Run scripts/check-divisions.sh behavior in CI by confirming that any new directory entry in divisions.json also appears in AGENT_DIRS inside scripts/convert.sh and scripts/lint-agents.sh, otherwise the build fails.
- Use scripts/convert.sh to generate per-tool output under integrations/, then import the converted agent definitions into your target AI tool after a prompt-injection review.
- Report any suspicious agent definitions or script behavior through a private GitHub Security Advisory rather than a public issue, per the policy in SECURITY.md.
Scripts and Files You Actually Need to Audit
- scripts/install.sh: executable installer flagged in SECURITY.md as requiring contributor review before running.
- scripts/convert.sh: executable converter that also carries an AGENT_DIRS list used by the divisions consistency check.
- scripts/lint-agents.sh: executable linter that carries a second AGENT_DIRS list that must match convert.sh and divisions.json.
- scripts/check-divisions.sh: CI gate that fails the build when divisions.json, convert.sh, and lint-agents.sh disagree or when a division directory has no agent file.
- divisions.json: repo-root file that defines label, icon, and color for each of the 16 divisions; treated as the single source of truth.
- strategy/: NEXUS playbooks and runbooks without agent frontmatter; explicitly not a division and excluded from division checks.
- integrations/: generated per-tool output produced by convert.sh; explicitly not a division and not part of the contributor catalog.
Adoption Checklist for a Security-Conscious Team
- Read LICENSE and confirm the MIT License attribution requirement, copyright 2025 AgentLand Contributors, is acceptable for your distribution model.
- Confirm that SECURITY.md's 48-hour acknowledgment and 7-day initial assessment timeline meets your internal SLA for vulnerability reports.
- Before importing any agent Markdown file, search its body for instructions that could redirect an LLM, exfiltrate context, or execute shell commands.
- Before running install.sh, convert.sh, or lint-agents.sh, diff the scripts against the last reviewed commit and trace every shell operation.
- Pin to a specific commit and subscribe to release or commit notifications so new agent files or script changes are reviewed before upgrade.
Maintenance Risk for Long-Term Use
The maintenance model rests on three executable scripts and one JSON file staying in sync. CONTRIBUTING.md requires that any new division be added to divisions.json, to AGENT_DIRS in scripts/convert.sh, and to AGENT_DIRS in scripts/lint-agents.sh. The check fails the build unless all three agree and the directory contains at least one agent file, which is a meaningful guardrail.
The residual risk is that strategy/ and integrations/ are not covered by the same check. strategy/ holds NEXUS playbooks and runbooks without agent frontmatter, and integrations/ holds generated per-tool output from convert.sh. Neither is a division, and CONTRIBUTING.md explicitly warns against adding them to the division lists, so prompt and configuration drift can accumulate there without the CI gate catching it.
Who should pay attention?
Good fit if
- Security teams that want a readable template for structuring internal agent catalogs with labeled divisions and frontmatter.
- AppSec and threat-intel practitioners who can review Markdown prompts for prompt-injection patterns before importing them.
- Platform teams building a CI gate modeled on check-divisions.sh for their own multi-directory prompt libraries.
Skip for now if
- Teams that cannot commit to reviewing shell scripts before each merge, since install.sh, convert.sh, and lint-agents.sh are executable and review-required.
- Environments that treat agent Markdown files as trusted by default, because SECURITY.md explicitly calls out prompt-injection reporting for suspicious definitions.
- Projects that need a compiled, sandboxed runtime rather than plain Markdown plus shell glue.
Risks and cautions
The repository is MIT-licensed Markdown and shell, but its executable scripts and external agent definitions require manual review before each import or merge.
- SECURITY.md classifies install.sh, convert.sh, and lint-agents.sh as executable scripts that contributors must review before running or merging.
- Agent Markdown files are prompt definitions imported into LLM contexts, where prompt injection is a named risk in the contributor guidance.
- The CI gate validates divisions.json, convert.sh, and lint-agents.sh consistency, but does not cover strategy/ playbooks or integrations/ generated output.
- New divisions expand the trusted AGENT_DIRS lists in two scripts, increasing the review burden as the catalog grows.
- SECURITY.md asks reporters to open a private GitHub Security Advisory rather than a public issue for vulnerabilities.
- Stated response timeline is acknowledgment within 48 hours and initial assessment within 7 days.
- Agent Markdown files are non-executable prompt definitions and must not contain API keys, tokens, or credentials.
- Contributors are instructed to report suspicious agent definitions that attempt prompt injection.
- Shell scripts in scripts/ must be reviewed before merging, and the policy lists install.sh, convert.sh, and lint-agents.sh by name.
Alternatives to compare
| Approach | When to use | Trade-off |
|---|---|---|
crewAI | When you need a Python framework with runtime orchestration instead of Markdown prompt files plus shell glue. | Open source |
LangGraph | When your security review favors graph-based agent state and typed Python interfaces over plain Markdown definitions. | Open source |
| When you want an autonomous agent runtime with community plugins, accepting the heavier review burden that comes with executable agent code. | Open source | |
Internal prompt library | When your organization already maintains reviewed Markdown prompts behind a private repository with its own lint pipeline. | Internal build |
What this trend reveals
Clone the divisions.json pattern for your own catalog
The single-source-of-truth JSON plus a CI check that enforces agreement across divisions.json, convert.sh, and lint-agents.sh is a reusable pattern for any team that maintains a labeled directory of prompts or runbooks.
Reproduce the check locally by removing a division from AGENT_DIRS in either script and confirming the build fails.
Add a prompt-injection linter to lint-agents.sh
Because the repo already runs lint-agents.sh in CI and instructs contributors to report prompt-injection attempts, there is a concrete place to add pattern-based checks for instruction redirection, shell execution, and credential exfiltration.
Prototype a grep-based rule set against existing agent Markdown files and measure how many false positives it produces before proposing it upstream.
Publish a hardened fork with signed agent files
Teams that need provenance for agent definitions can fork the catalog, keep the MIT License attribution, and add commit signing plus a manifest of reviewed agent files.
Confirm that convert.sh can consume signed manifests without changes, or document the smallest patch required.
RepoDaily verdict
Agency-Agents is a well-structured Markdown-and-shell catalog with a real security policy, a named security division, and a CI gate for catalog consistency; the deciding factor for adoption is whether your team will actually review each executable script and agent prompt before import.