get-engineering-done 0.1.10

Get Engineering Done: structured agentic workflows for engineering programs

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_KEY is 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.

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