Spawn — a framework for developing AIDD methodologies

Anton Novgorodtsev — Wed, 10 Jun 2026 11:10:51 +0000

Hi everyone! I built a tool for developing AIDD and named it Spawn. It's a Python utility that helps you coherently use multiple AIDD methodologies in a single repository — without manually syncing rules, skills, and MCP configs between them.

Below is a short introduction, followed by how Spawn works, how to use it from a client's perspective, how to develop extensions, and a few examples.

Who might be interested

Development team leads — to develop team rules and processes related to AI-assisted development and beyond.
Individual developers — to use a ready-made SDD framework or build your own purely "for yourself".
Potentially — developers of full-cycle AIDD development software.
DevOps engineers, infrastructure specialists, and technical writers — provided that scripts, configurations, or documents are stored in repositories.

Key ideas

Spawn lets you use multiple AIDD methodologies (or rule sets) coherently. It automatically propagates global mandatory rules or process descriptions between the artifacts of installed extensions within a single repository — the agent always has cross-references.
An extension in Spawn terms is an AIDD methodology that can be installed into a repository. For the utility, it's a set of documents, instructions, scripts, skills, and MCP configurations.
An extension can also be a set of team rules, project scaffold files, or a set of automations — something that can't yet be called a methodology, but that you already want to reuse.
Spawn lets you install IDE-specific artifacts (MCP, skills, agent-ignore and git-ignore lists) for the selected supported IDEs, while the extension developer doesn't have to "tailor" each such artifact to a specific IDE — Spawn does it for you. The utility works with universal, IDE-independent configurations that are later "rendered" for the IDEs the team uses.
It's possible to create cross-platform MCPs; Spawn will launch the right one for the current OS via an MCP proxy on its own — this is important for teams whose members work on different operating systems.
After spawn init, a ./spawn directory appears in the repository — it stores the metadata of installed extensions, local configurations, and navigation. This folder must be committed to the repository; don't add it to .gitignore.

Installation and quick start

Installing the Spawn CLI

Python 3.10+ is required. The recommended way is via uv:

uv tool install spawn-cli && spawn --help

Initializing a repository

spawn init

Adding an IDE

spawn ide add cursor
# you can add several at once:
spawn ide add cursor codex

To see all supported IDEs and what each of them can render:

spawn ide list-supported-ides

At the time of publication, the following are supported: cursor, codex, claude-code, windsurf, github-copilot, gemini-cli.

Installing your first extension

spawn extension add https://github.com/noant/spawn-ext-spectask.git

Terminology

Extension — the content of a specific AIDD methodology, containing an extension config file, a set of IDE-independent skill and MCP files, instruction files, scripts, etc. An extension can be installed from a Git repository, a zip archive, or a local folder.

IDE agent entry point — a file that the IDE reads before executing any command. For example, in Cursor this is AGENTS.md.

Hint — a short reminder string that is inserted directly into skills and the agent entry point. The agent sees it immediately in the context — without reading an additional file. For example: the response language (RU/EN), tone, project specifics. A hint can be global (it lands in all skills of all extensions and in the managed block of the agent entry point — e.g. AGENTS.md) or local (only in the skills of the current extension).

Instruction file — an AI-readable file describing a process, rule, or convention. Unlike a hint, the agent reads it deliberately — after seeing a reference in the navigation or a skill. There are two read modes: required-read — the reference is always present in skills and the agent entry point, and the agent must read it on every invocation; contextual-read — the reference is present in navigation, but the agent reads it as needed, only when the task is relevant to its content. The scope is set via globalRead/localRead: a global file lands in all skills of all extensions, a local one — only in the skills of its own extension.

Global navigation file — a file containing all references to the needed instruction files (not skills) with a short description, scope, and an indication of whether reading is required or contextual (situational). The global navigation file also contains hints and references to local rule files.

Local rules — instruction files and hints that can be added to a repository without installing an extension. This can be useful when you understand that the rules won't become universal. If needed, such rules can always be packaged into an extension and reused in other projects.

Extension file mode — defines the file's behavior when the extension is updated. Static — the file is overwritten from the source on every update; used for instructions that should always match the latest version of the extension. Artifact — the file is created once on installation and after that belongs to the project; it is not overwritten on updates; used for configurations and data that the project adapts for itself.

Working with extensions

Managing installed extensions

# in the examples below, spectask is the name of an installed extension
spawn extension list                    # list installed extensions
spawn extension update spectask         # update the extension from its source
spawn extension reinstall spectask      # full reinstall (in case of corruption)
spawn extension remove spectask         # remove the extension
spawn extension healthcheck spectask    # check the extension's state

Extension builds

Installing several extensions (so-called "extension builds"):

spawn build install https://github.com/org/team-methodology.git --branch main
# or from a local directory that has extensions.yaml in its root:
spawn build install .

Local rules and refresh

Adding rules without installing extensions:

# create a rules file in spawn/rules/ and run refresh:
spawn refresh

After editing files in spawn/rules/ or hints in spawn/navigation.yaml, you need to run refresh so that skills and IDE entry points are updated. There are two options:

spawn refresh — a full recompute: updates navigation.yaml, regenerates skills and agent entry points. Use it after any changes. It runs automatically when an extension is installed or an IDE is added.
spawn rules refresh — only syncs files from spawn/rules/ into navigation.yaml, without regenerating skills and entry points. Suitable when you need to quickly update navigation without touching IDE artifacts.

Important: Spawn only edits files that it installed itself. It doesn't touch third-party skills and rules outside those paths during refresh or extension updates.

What happens during `spawn extension add`

When you run spawn extension add <url>, Spawn:

Clones the extension's source repository (or unpacks a ZIP / copies from a local folder) into a temporary directory.
Reads the extension's extsrc/config.yaml — identifies the stable name, version, and the list of files, skills, MCP servers, and ignore rules.
Copies files from extsrc/files/ into the target repository according to the declared paths. Files with static mode will be overwritten on updates; files with artifact mode are created once and then belong to the project.
Registers skills: sources from extsrc/skills/ are rendered with the active IDEs in mind — references to mandatory instruction files, hints, and the global navigation are embedded into each skill.
Connects MCP servers from extsrc/mcp/{windows,linux,macos}.json: for each registered IDE an IDE-specific config is generated, while cross-platform servers are automatically wrapped in an MCP proxy.
Runs lifecycle scripts from setup/ (e.g. after-install) — installing dependencies, initializing artifacts, etc.
Updates spawn/navigation.yaml: adds the extension's ext: block with its mandatory and contextual reads, global hints, and references to instruction files.
Generates IDE agent entry points (e.g. AGENTS.md for Cursor): merges the navigation of all installed extensions and local rules into a single coherent file.
Updates .gitignore and agent-ignore according to the patterns declared in the extension's config.yaml.

Metadata about the installed extension is saved in spawn/.extend/<name>/ — this allows spawn extension update / reinstall / remove to work correctly, and spawn extension healthcheck to diagnose discrepancies between what's declared in config.yaml and what's actually present in the repository.

Examples of ready-made extensions

Below are two extensions I use myself: the Spectask SDD methodology and the integration with the local semantic memory MemPalace.

Spectask — an SDD extension

This extension lets you:

Keep task specifications in the repository
Decompose tasks
Independently build a parallelization scheme for executing subtasks
Execute subtasks with different subagents
Create tasks from Jira tickets
Keep architecture files up to date.

Installing the extension:

spawn extension add https://github.com/noant/spawn-ext-spectask.git

How to create a task from a Jira ticket (invoking a skill, example for Cursor):

/spectask-from-jira import PROJ-123

How to create a task without a Jira ticket (invoking a skill, example for Cursor):

/spectask-create add authorization via OAuth

The task goes through the process flow with the following steps:

[1] spec created → [2] self spec review → [3] spec review (user) → [4] code implemented → [5] self code review → [6] code review (user) → [7] design documents updated

Steps 1, 2, 4, 5, 7 are performed by the agent; steps 3 and 6 — by the user (confirmation). Step 4 launches a separate subagent for each subtask.

All skills with descriptions:

Skill	Purpose
`spectask-create`	Create a task specification — Steps 1–2 (without implementation)
`spectask-spec-review-passed`	Step 3: confirm the specification and move on to implementation
`spectask-execute`	Steps 4–5: implement the task and perform a self code review
`spectask-code-review-passed`	Step 6: confirm the code, trigger the architecture documents update (Step 7)
`spectask-design`	Register architecture files in `spec/design.yaml` or create `spec/design/*.md`
`spectask-seed-create`	Capture a rough idea as `spec/seeds/{X}-{slug}.md` without creating a full task
`spectask-from-jira`	Import a Jira ticket into the task folder via MCP or CLI

Seeds

Before creating a full-fledged task, you can quickly capture an idea as a seed file in spec/seeds/. This is an informal note without the full flow — useful when you have an idea but implementation is still far off. When ready, a seed is easily promoted into a full-fledged task via spectask-create, and after the task is closed the seed is renamed with the _DONE_ prefix.

Jira integration

The extension ships with an MCP server spectask-mcp, which is installed automatically when the extension is installed. It lets the spectask-from-jira skill fetch data directly from Jira by the ticket key.

Configuration is done through an interactive setup during extension installation (it runs automatically if stdin is a TTY). If needed, it can be invoked again manually:

spectask-mcp interactive --setup

The configuration (URL, token, optional SOCKS5 proxy) is saved in spec/.config/config.yaml — this file is automatically added to .gitignore and agent-ignore so that secrets don't end up in the repository.

The methodology is described in the extension repository's main file main.md — that's also where the full process and rules live. The Spawn CLI was developed using this methodology.

Extension repository: github.com/noant/spawn-ext-spectask.

MemPalace

This extension lets you install MemPalace (a local semantic memory — a "memory palace") from the original package into the current repository, and also provides on top of it a cross-platform MCP (required for MemPalace to function), a set of skills, and scripts for configuring mempalace. For more about MemPalace itself, see the project's official site.

Installing the extension:

spawn extension add https://github.com/noant/spawn-ext-mempalace.git

Configuring the memory palace (invoking a skill):

/mempalace-configure-palace

(example for Cursor)

After installation, the extension automatically:

installs the mempalace package via pip (or, if it's missing, via uv pip), unless MEMPALACE_EXTENSION_SKIP_PIP is set
initializes a palace in <repo>/.mempalace/palace (via mempalace init .); overridden by the MEMPALACE_EXTENSION_GLOBAL_PALACE flag or the MEMPALACE_PALACE_PATH variable
connects two MCP servers: mempalace-mcp (the official MemPalace tools) and mempalace-mine-mcp (a bridge for indexing and updating the wake-up context)

How it works

The semantic memory is stored in .mempalace/palace (ChromaDB by default; the backend is pluggable). After substantial edits in the repository, the agent calls mempalace_mine — this reindexes files and updates .mempalace/wakeup.md. This file is declared as required-read in spawn/navigation.yaml, so the agent loads the current context from the palace at the start of each session — without re-explaining the project structure.

Skills:

Skill	Purpose
`mempalace-configure-palace`	Configure the palace: global config, `mempalace.yaml`, `palace_path`, identity
`mempalace-search`	Semantic search via the MemPalace MCP or CLI with a fallback to workspace search
`mempalace-diagnose-palace`	Diagnose the installation, palace path alignment, MCP, and the wake-up context

After that, on any substantial change to the project, the agent will itself suggest reindexing the files in the palace.

Extension repository: github.com/noant/spawn-ext-mempalace.
Original MemPalace repository: github.com/MemPalace/mempalace.

How to create your own extension

Two paths: CLI scaffold and spawn-ext-creator

Quick start via CLI — creates a minimal scaffold (extsrc/ with config.yaml, empty skills/, files/, setup/) without any additional extensions:

spawn extension init --name my-extension

A full-fledged scaffold via spawn-ext-creator — an extension that adds skills for the agent: it will walk you through declaring config.yaml, skills, and MCP, through verification, and other steps. Suitable when the extension is expected to be non-trivial.

Installing the spawn-ext-creator extension:

spawn extension add https://github.com/noant/spawn-ext-creator.git

spawn-ext-creator skills

Skill	Purpose
`spawn-methodology-shape`	Design the methodology: namespaces in `extsrc/files/`, static vs artifact, global vs local reads
`spawn-ext-bootstrap`	Start from scratch: `spawn extension init`, stable `name`/`version`, safe path prefixes
`spawn-ext-config`	Maintain `config.yaml`: declare all files, folders, read flags, ignores, `setup`, `mode`
`spawn-ext-hints`	Declare `hints.global`/`hints.local` (sections in `config.yaml` for global and local hint strings)
`spawn-ext-skill-sources`	Write `extsrc/skills/*.md`, register them under `skills:`, wire up `required-read`
`spawn-ext-mcp`	Create `extsrc/mcp/*.json` for the three OSes: servers, transport, env placeholders
`spawn-ext-verify`	Run `spawn extension check . --strict` and a smoke test `spawn extension add` in a test repo
`spawn-ext-increment-version`	Bump `version` in `extsrc/config.yaml` before a release, keeping `name` stable

The recommended order when creating a new extension: spawn-methodology-shape → spawn-ext-bootstrap → spawn-ext-config → spawn-ext-skill-sources → spawn-ext-mcp (optional) → spawn-ext-verify. Before each release: spawn-ext-increment-version → spawn-ext-verify.

Recommendation: for extensions more complex than the minimal one, use spawn-ext-creator — it's faster and more reliable than assembling the structure by hand.

The `extsrc/` structure

The central file of an extension is config.yaml. The extension's file structure looks like this:

my-extension/
└── extsrc/
    ├── config.yaml       # required: schema, version, name, declaration of files and skills
    ├── files/            # files that will be copied into the target repository
    ├── skills/           # skill sources (IDE-independent)
    ├── mcp/              # (optional) MCP server declarations: windows.json, linux.json, macos.json
    ├── agent-ignore      # (optional) patterns for agent-ignore
    └── setup/            # (optional) scripts run on install/update

The only required file is extsrc/config.yaml. Everything else is optional depending on what the extension does.

Reference: an example `config.yaml` with all fields

Below is an example with a description of all fields and how they work after the extension is installed into a project:

# Config schema version — always 1
schema: 1
# Stable extension identifier (used as the folder name spawn/.extend/<name>/)
# Don't change after the first publication
name: my-extension
# Extension version (semver)
version: "1.0.0"

# Folders that belong to the project (artifact — not overwritten on extension updates)
folders:
  my-extension/data:
    mode: artifact

# Patterns for agent-ignore (the agent won't read these files)
agent-ignore:
  - my-extension/data/secrets/**

# Patterns for git-ignore
git-ignore:
  - my-extension/data/secrets/**

# Scripts run on install/update
setup:
  # Path from the extsrc/ root — extsrc/setup/install.py will live here
  after-install: setup/install.py

# Extension files
files:
  # Static file — overwritten on extension update
  my-extension/process.md:
    description: "Description of the development process."
    mode: static
    # globalRead: required — the reference lands in all skills of all extensions
    # globalRead: auto — only if the agent deems the file globally relevant
    # globalRead: no — doesn't land in the global navigation
    globalRead: auto
    # localRead: required — always read when using this extension's skills
    # localRead: auto — read as needed
    localRead: required

  # Artifact file — created on installation, then belongs to the project
  my-extension/config.yaml:
    description: "The extension's configuration for the current project."
    mode: artifact
    globalRead: no
    localRead: auto

# Extension skills (sources live in extsrc/skills/)
skills:
  my-skill.md:
    name: my-skill
    description: "Skill description — what the agent does when invoked."
    # Files the agent must read before executing the skill
    required-read:
      - my-extension/process.md

Validation and publication

Validating an extension before publication:

spawn extension check ./my-extension
spawn extension check ./my-extension --strict

Installing a ready extension into a project:

spawn extension add https://github.com/your-org/your-extension.git

A complete description of the extension model (all config.yaml fields, static vs artifact content, lifecycle scripts, etc.) is in the extension-author-guide in the repository.

Packaging local rules into an extension

If you already have local rules in spawn/rules/ and want to package them into an extension (e.g. to reuse in other projects):

spawn extension from-rules ./repo-with-spawn-rules --name my-ext --output ./out
# or from a remote repository:
spawn extension from-rules https://github.com/org/my-repo.git --name my-ext --output ./out

Contact the author

Spawn CLI source code: github.com/noant/spawn-cli — issues are welcome, let's discuss.
Direct contact: anton.novgorodcev@gmail.com

Thanks, everyone!

P.S. Below is a diagram that might help you understand how Spawn works.

DEV Community: Anton Novgorodtsev