agentleFS
veraetogrex-portfolioveraetogrex-portfolio/solo-sdd/AGENTS.md

solo-sdd

AGENTS.md0 starsChanged yesterdayMITView on GitHub

Own spec-driven development process for one person or a team, with any coding agent, independent of other spec tools: the algorithm, skills, global agent rules, Claude Code hooks and project templates. The repository is the source of truth; sync.py push puts the files in place. Mode: prod. Prod here is the agent folders on this computer (~/.claude, ~/.codex, ~/.agents, ~/.local/bin): after sync.py push an edit takes effect in all sessions at once.

  • Installs packages

The file

We split this AGENTS.md into the rules it gives an agent

5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    No clarifying questions: a reasoned decision, recorded in the report.

    line 19
  2. Very specific:

    After tasks.md is closed, an independent live test before reporting readiness.

    line 21
  3. Very specific:

    All repository text is in English, with no Cyrillic letter (tests/test_repo_language.py).

    line 74
  4. Very specific:

    Before "done": the Tests row, the lint from the table without output, python3 -m solo_sdd validate --all, python3 sync.py status without …

    line 78
  5. Distinctive:

    Before a test of a removed requirement is deleted, its checks for kept requirements move into a kept test.

    line 110

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

solo-sdd

Purpose and mode

Own spec-driven development process for one person or a team, with any coding agent, independent of other spec tools: the algorithm, skills, global agent rules, Claude Code hooks and project templates. The repository is the source of truth; sync.py push puts the files in place. Mode: prod. Prod here is the agent folders on this computer (~/.claude, ~/.codex, ~/.agents, ~/.local/bin): after sync.py push an edit takes effect in all sessions at once.

Sources of truth

  • Behaviour contract: solo-sdd/specs/; active work: solo-sdd/changes/; the project intent: solo-sdd/project.md.
  • Algorithm: ALGORITHM.md; the lessons the rules grew from: LESSONS.md; the full text of each ## Lessons line is in its section Lessons of this repository under the same id, and a refinement edits both.
  • README.md: what lies where and how it is deployed. targets.json: the deployment map.
  • Files copied into agent folders are not a source: an edit in place is pulled with sync.py pull.
  • solo-sdd/specs/ and the open changes of solo-sdd/changes/ are kept in git. The change archive solo-sdd/changes/archive/ and docs/waiting.md are not in git, they live only in the working folder: the archive is not published.

Working with specs

  • One change per session, up to the archive.
  • No clarifying questions: a reasoned decision, recorded in the report.
  • Work outside the current spec becomes a new change.
  • After tasks.md is closed, an independent live test before reporting readiness.

Commands

WhatCommand
InstallPython 3 from the system; for tests and lint, python3 -m pip install --user hypothesis pyflakes==3.4.0
Testspython3 tests/run.py --jobs 5 --tier slow before delivery; a round: python3 tests/run.py --jobs 5 --tier fast, then python3 tests/run.py --jobs 5 --affected <path>...; before a release tag: python3 tests/run.py --jobs 5 --tier release
Tests (one)python3 tests/<file>.py; one test: python3 -m unittest <module>.<Class>.<test> from tests/
Lintpython3 -m pyflakes solo_sdd global scripts sync.py
CLIpython3 -m solo_sdd --version
What is deployed and where it differspython3 sync.py status
Deploymentpython3 sync.py push
Specspython3 -m solo_sdd validate --all

Project map

PathRole
skills/<name>/SKILL.mdAlgorithm skills and manual commands; deployed by targets.json
solo_sdd/Package and the solo-sdd command; deployment logic in layout.py, sync.py is a wrapper; the solo-sdd/ tree rules and validate in process_format.py; import openspec in import_openspec.py; init in init.py
pyproject.tomlPackage description
package.json, bin/solo-sdd.jsnpm package: a wrapper that runs python -m solo_sdd
global/AGENTS.mdGlobal rules of both agents
global/work_hooks.py, global/model-policy.jsonClaude Code workflow hooks and the model policy
global/work_hooks_settings.pyOne-off connection of the hooks in ~/.claude/settings.json
global/process-guard.pyHook that forbids stopping processes directly
global/sdd_dispatch.pyStatus acceptance and local mode merge for spec-dispatch
global/sdd_eval.pyChange replay and comparison of dispatcher configurations
tests/eval/Sets, configurations, prices, fixtures
templates/Templates for new projects
examples/demo/Demo project with its solo-sdd/ tree and WALKTHROUGH.md; kept valid by tests/test_demo.py
integrations/antislop/Bundled integration antislop: pinned copy of the anti-slop rules for ui-check and copy-check with its integration description; deployed by targets.json, updated only by replacing the copy
integrations/security-audit/Bundled integration security-audit: pinned copy of cloudflare/security-audit-skill for the security pass of spec-audit with its integration description; deployed by targets.json, updated only by replacing the copy
solo-sdd/Specs, changes and the archive of this repository; the archive lives only in the working folder
scripts/publish-first.shFirst publication: a new main without history and without solo-sdd/, one-off
scripts/pre-push-guard.shpre-push hook the publication step of docs/release.md installs: refuses a pushed commit that shares history with history-local or history-private, and a ref not to a commit
scripts/release_check.pyRelease check: tag against versions, sdist, wheel from the sdist and npm tarball into dist/, packed files against git ls-files, --version smoke, the CHANGELOG.md section; --notes <tag> prints that section
CHANGELOG.mdThe changes each version archived; its section of the current version is the GitHub release text
.github/workflows/release.ymlRelease on a pushed tag v<version>: tests, release check, PyPI and npm through trusted publishing, GitHub release
docs/release.mdOne-time registry setup and the release steps
.github/workflows/test.ymlCI: lint, tests/run.py and solo-sdd validate --all; the slow tier on Ubuntu for a push or PR, the release tier on macOS for a v* tag and on both for a manual run; a newer run of a ref cancels the older one
tests/Tests and probes; tests/run.py runs every tests/test_*.py in parallel, failed first (--failed, named files, --affected <path> by tests/affected.json); tests/stands/ holds live scenario stands

Working copy

  • Paths: docs/waiting.md, docs/debug-profile.md, docs/rules-audit.md, docs/process-safety-verification.md, global/claude-gui.py, global/claude-process-safety-settings.json, global/claude-safe.py, tests/eval/sets/, tests/probe_claude_development.py, tests/probe_claude_process_safety.py, tests/test_claude_gui.py, tests/test_claude_safe.py

Boundaries and invariants

  • Edits only here, then sync.py push. Files in agent folders are not edited by hand.
  • sync.py push does not overwrite a copy edited in place (drift); before overwriting it saves the previous text to ~/.local/share/solo-sdd/backup/.
  • Hooks are fail-open: an internal error lets the action through and is written to ~/.claude/hook-state/errors.log.
  • All repository text is in English, with no Cyrillic letter (tests/test_repo_language.py).

Checks

Before "done": the Tests row, the lint from the table without output, python3 -m solo_sdd validate --all, python3 sync.py status without unexpected drift, the change's live scenario.

Delivery

  • Mode: pr
  • Merge: squash
  • PR title: the change name
  • Deploy: no; deployment to agent folders is done separately (sync.py push).
  • CI: an agent merges a PR through sdd-pr.py merge only when sdd-pr.py wait <url> gives CI: green. On CI: red, CI: infra or CI: codeql the agent fixes, reruns and waits again as /ship (under the dispatcher, spec-dispatch) says; a PR that is still not green waits for the owner: an agent never merges around a red or missing check (docs/release.md).

Security

  • Paid model calls in tests: only the cheapest (global/model-policy.json).
  • sync.py push changes the agents' working folders on this computer: this is a prod action, check sync.py status after it.
  • There are no secrets in the repository and there must be none.

Lessons

  • A stand runs exactly what it means to test: real inputs through the host, a base commit pinned by hash and read apart from the working folder, reads on a condition, every imported module copied. (full text)
  • Environment detection looks only inside the passed home and PATH, and a test fixture pins every git and interpreter default it relies on. (full text)
  • A claim about a tool's behaviour, a record of edited files or of affected tests is written only after checking it here against the tool or the source. (full text)
  • An unnamed "our product" means solo-sdd itself; the owner's other products are neither the subject nor a source of facts unless named. (full text)
  • A reader of a format reads it by that program's own rules, refuses broken input before its first side effect, and never skips a line or entry silently. (full text)
  • A session capability the agents depend on is probed once before launch; its absence stops the launch only when the project declares the need. (full text)
  • A check of printed output or a document matches by prefix and by whole item with whitespace collapsed, never by position or physical line. (full text)
  • A stand that grades a judgement call expects one answer only where every correct reading gives it. (full text)
  • A deployment gate is worded for the whole repository, a publication target handed to a new name is guarded in every clone, and a deploying command is never run to learn its options. (full text)
  • A cleanup removes only what the current map and its own sources name, keeps and names everything else, and takes a source as gone only when it is missing. (full text)
  • A value that falls back to a default is reported with its source, every reader takes a setting from one shared definition, and an inferred choice is stored once made. (full text)
  • A bulk wording replacement keeps quoted program output verbatim and is reread line by line. (full text)
  • A script that moves or rewrites a branch decides from the commits themselves, never from a setting. (full text)
  • An input check covers the edge forms of its input (digits, a closed stdin, line endings, links, escaping, non-blocking reads) at one point every reader passes. (full text)
  • Before a test of a removed requirement is deleted, its checks for kept requirements move into a kept test. (full text)
  • A new outcome, exemption or ban of a step is written where the rule it changes is read, and checked against every rule that requires what it bans. (full text)
  • A scenario of a new behaviour names what only the new code produces, and a plan for a feature covers its life around the request. (full text)
  • A gate a person's marks open takes the confirmation from a record the agent cannot produce, and evidence the agent writes is matched against a source written before the work. (full text)
  • A guard that exempts part of a shell command reads it by the shell's and each program's grammar, refuses what it cannot read, and is replayed against the forms decided before. (full text)
  • A path that becomes git-ignored is checked through every merge, reset, abort and mirror step for a deletion of its copy, and a temporary index copy keeps the index's time. (full text)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.