Get Engineering Done (GED)
Get Engineering Done is a command-workflow scaffold for engineering programs that need more structure than a one-off chat or notebook. It is engineering-specific from the start.
GED provides a complete engineering workflow command surface and capability set. It targets capability completeness: every capability an engineering program needs to go from objective to reviewable, verified package has an explicit home in GED.
GED turns an engineering objective into a reviewable workflow:
formulate -> architect -> plan -> execute -> verify -> package
The first goal is not to fake a solver or a green result. The first goal is to make an engineering project reviewable: requirements, interfaces, discipline models, solver evidence, verification verdicts, provenance, and acceptance criteria all have explicit homes.
Quick Start
Install the runtime command surface (Claude Code, Codex, Gemini CLI, OpenCode) straight from npm — no checkout required:
npx -y get-engineering-done --claude --local
Use --codex, --gemini, --opencode, or --all for the other supported
runtimes, and --global to write into the user-level config dir. The installer
writes model-visible GED command files into the selected runtime config target.
(From a source checkout, the equivalent is node bin/install.js --claude --local.)
Install the Python CLI from PyPI:
python -m pip install get-engineering-done
ged --help
No account or API key is required for the core workflow — scaffolding, validation, the goal gate, and numerical verification all run offline. A
VVUQ_API_KEYis optional and only enables the VVUQ knowledge-graph reuse and server-side claim verification.
Create a draft engineering project:
ged new-project \
--root /path/to/project \
--objective "Produce a coupled coherent PIC transceiver model" \
--domain "photonic transceiver engineering"
Validate the scaffold:
ged validate --root /path/to/project
Strict validation is intentionally harder. A new scaffold is a draft; it does not pass strict validation until phase artifacts are present, nonempty, format-checked, marked available in the phase manifest, and paired with matching hash/provenance metadata. Strict validation does not prove engineering truth; it checks that a package is reviewable and not an obvious placeholder.
ged validate --root /path/to/project --strict
Runtime Commands
GED is designed to expose the same command loop across AI runtimes:
| Runtime | Help | New project |
|---|---|---|
| Codex | $ged-help |
$ged-new-project |
| Claude Code | /ged:help |
/ged:new-project |
| Gemini CLI | /ged:help |
/ged:new-project |
| OpenCode | /ged-help |
/ged-new-project |
The local CLI can print the full command map:
ged command-map --runtime codex
Capability completeness
GED tracks its engineering capability set as an executable requirement:
ged capabilities
This command returns non-zero until every required engineering capability is present. See docs/capability-requirement.md.
Serving the verified design loop ([serve] extra)
GED can serve its verified photonics design loop over HTTP — POST /design
returns only gate-verified designs (value computed by a cited recipe, checked
against the recipe's literature anchor, evidence pack run through the
unchanged strict gate per request). Unverifiable requests are refused as
machine-readable data, never served.
pip install "get-engineering-done[serve]" # adds FastAPI
python -c "import uvicorn; from ged.serve import create_app; uvicorn.run(create_app())"
curl -s localhost:8000/design -X POST -H 'content-type: application/json' \
-d '{"device": "ring", "params": {"FSR": 2.0e12}}'
(uvicorn or any ASGI server is yours to choose — the extra deliberately
ships only fastapi.) The pure core (ged.serve.design_response) works
without the extra installed.
MCP server ([mcp] extra)
ged-mcp exposes GED's verdicts — circuit verification, recipe-cited device
solves, and the strict validation gate — to any MCP client. It speaks stdio by
default, so an existing client config that launches a bare ged-mcp keeps
working:
uvx --from "get-engineering-done[mcp]" ged-mcp # stdio (Claude Desktop/Code, Cursor, ...)
ged-mcp --transport streamable-http --host 0.0.0.0 --port 8000 \
--allowed-host ged-mcp.<namespace>.svc.cluster.local # Streamable HTTP, endpoint /mcp
Over HTTP (for clients that cannot spawn a process, such as Open WebUI),
--host defaults to 127.0.0.1; binding every interface is an explicit
choice, and it must name the Host header(s) clients send with
--allowed-host (repeatable). DNS-rebinding protection then answers those
names and loopback and refuses every other Host with 421; a non-loopback bind
without an allowlist refuses to start (exit 2). Behind a reverse proxy that
already controls Host, --allow-any-host turns the check off explicitly.
Host matching is exact and case-sensitive, so pass names the way clients send
them (lowercase for Kubernetes service names). Needs mcp>=1.21.1.
ged_validate_project is off over HTTP unless you pass
--enable-validate-project, because it reads a caller-supplied path on the
machine running the server — over stdio the caller is the local user, over
HTTP it is whoever can reach the port; combining it with --allow-any-host
on a non-loopback bind is refused (exit 2). Over stdio it is always on.
Template Curation (STEM)
GED can curate STEM-ready templates for agent use and emit Neo4j-shared ingest artifacts:
# --workspace-root defaults to the current working directory; --output-root
# defaults to ./artifacts/template-curation
ged curate-templates
Or with explicit paths:
ged curate-templates \
--workspace-root /path/to/workspace \
--output-root /path/to/output
Install a 30-minute launchd schedule (macOS):
ged install-curation-schedule \
--workspace-root /path/to/workspace \
--output-root /path/to/output \
--interval-minutes 30
The plist defaults to
~/Library/LaunchAgents/com.englund-garage.ged.template-curator.plist;
override with --plist-path if you prefer a different location.
Project Shape
GED creates:
GED/
PROJECT.md
REQUIREMENTS.md
ROADMAP.md
STATE.md
phases/
phase-01/
PLAN.md
VERIFY.md
outputs/
README.md
artifact_manifest.json
The manifest starts with planned artifacts only. Real engineering outputs must be added by the owning project before the phase can move from draft to green.
Engineering Bias
GED is for engineering programs where success depends on interfaces, tolerances, physical constraints, cost or manufacturability, simulation evidence, tests, and reviewable provenance. For the initial coherent PIC transceiver use case, GED is designed to sit above general optimization frameworks (e.g. OpenMDAO) and to integrate discipline backends — its marimo panel helpers embed the output of Tidy3D, gdsfactory, and femwell when those libraries are installed — alongside VVUQ claim checks, Neo4j provenance, and work-contract acceptance gates.
Trademarks
GED is an independent, open-source project and is not affiliated with,
endorsed by, or sponsored by any of the third-party tools it integrates with or
references. All product, project, and company names used in this software and
its documentation — including Tidy3D, gdsfactory, femwell, OpenMDAO, and any
others — are the trademarks or registered trademarks of their respective
owners. References to these names are nominative: they identify the external
tools GED integrates with or sits above. See the NOTICE file for details.
Development
python3.11 -m pytest -q
Metadata
Release files for get-engineering-done 0.1.14
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| get_engineering_done-0.1.14.tar.gz | 300.2 kB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| get_engineering_done-0.1.14-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 644.5 kB
Release files / get_engineering_done-0.1.14.tar.gz
| Download URL | get_engineering_done-0.1.14.tar.gz |
|---|---|
| Size | 300.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c08aa18e2d5f30962a01cea4f009320c1dafb223c114b13dd22b3f2397ef56a3
|
|
BLAKE2b-256 checksum How to use checksums |
13fa6ffc9052925cca15fe2203af0800db351d262d4d7e52c9a42e3f7a8b8515
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 8, 2026.
Transparency logRelease files / get_engineering_done-0.1.14-py3-none-any.whl
| Download URL | get_engineering_done-0.1.14-py3-none-any.whl |
|---|---|
| Size | 344.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
80c7bba53b2e9931b2e921792d9a691f309820e8738fba1bc64f791359fbac08
|
|
BLAKE2b-256 checksum How to use checksums |
5cacf8769ab5960e6b2d9552fd04a1a31c3ddd45fa0d7cd980b23f728dfa3471
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 8, 2026.
Transparency logSecurity for get-engineering-done 0.1.14
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for get_engineering_done-0.1.14.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 8, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.