Turn an idea, an operating story, or a requirement into something you can inspect: a connected model, a readable diagram, and checks that show what passes, fails, or remains unknown. Ask in plain language. The assistant handles model files and commands; you decide what the system should do.
Start here: open this repository in Codex and copy a request below. The three skills help with a system concept, a concept of operations (who uses and supports it), or a particular operational scenario. This is an alpha with defined capabilities and limits.
The examples below use two fictional services: a sample-handoff station and a community tool library. Their people, equipment, limits, and observations are demonstration choices. Each preview links to a full-size SVG, with editable model and evidence links in its guide. On small screens, open the full-size view to read the detail.
Use the system-concept skill with this repository's water-sampling station example.
Show the main functions in plain language, then let me explore the detailed breakdown.
Keep the current model meaning and show unresolved choices.
This overview shows the main responsibilities. The full function tree adds eight detailed functions; the branches show decomposition, not execution order. Edit the model.
Use the operational-scenarios skill with the water-sampling station example.
Walk me through the nominal handoff. Show who sends what, in what order,
and link the picture to the selected scenario.
Read the exchanges in order to see how a receipt and custody record connect the handoffs. This is a documentary scenario reading. Full view and sources.
Use the operational-scenarios skill with the water-sampling station example.
Show the missing-label hold and recovery. Make the unresolved identity visible
and preserve the distinction between a receipt and permission to release.
The held receipt records the problem. Identity correction and release authority remain distinct. Full view and sources.
Use the CONOPS skill with the water-sampling station example.
Show the declared responsibilities
and make the scope of each assignment easy to inspect.
These assignments explain the example's intended responsibilities. They are documentary allocations, with source links for review. Full view and sources.
Use the system-concept skill with this repository's water-sampling station example.
Show how the declared needs, requirements and use cases connect.
Keep the relationship types visible so I can inspect what each link means.
Follow an identified relationship back to its model elements. A declared link records a connection for review; it does not establish that a need has been met. Full view and sources.
Use the operational-scenarios skill with the water-sampling example.
Check its supplied pass and late event traces against the correlated receipt deadline.
Show the on-time boundary, the late response and which request each receipt answers.
The event monitor matches receipts to request IDs, including responses that arrive out of order. The result applies to these supplied synthetic traces. Full view, evidence and reports.
Use the operational-scenarios skill with the water-sampling example.
Compare the supplied receipt-time observations of four and five seconds
against the declared quantity limit. Show which requirement changes result.
Four seconds meets the declared bound. Five seconds fails that clause while the separate receipt deadlines still pass. These are supplied observations. Full view, evidence and reports.
Use the operational-scenarios skill with the water-sampling example.
Explain its deliberate blocked-handoff test using the separate finite model.
Show the disabled step, the reported finding and the condition that caused it.
This deliberately altered finite model demonstrates a diagnostic. It is separate from the native SysML scenario and from observed station behavior. Full view, model and report.
Use the system-concept skill with this repository's community tool-library example.
Compare the paper and laptop alternatives, keep the selection open,
and explain the conditional capacity calculation alongside its unknowns.
The illustrative assumptions consume 30 work-minutes in a 30-minute window. The alternatives' evidence gaps remain visible; the arithmetic does not predict actual waiting time. Full view, concept and calculation.
Open the preview gallery and editable sources, the connected station walkthrough, or the capability matrix. For your own material, ask a skill to investigate a focused question and keep unresolved evidence visible. Keep private sources out of Git.
Open setup commands, supported semantics, existing examples, and implementation details
Small, independently invocable skills that help a systems engineer develop a system concept, a concept of operations (CONOPS), or an operational scenario. The engineer directs consequential decisions; the assistant helps investigate, draft, run checks, and revise.
Status: alpha. The three skills now default to authoring SysML v2 textual models for new recorded work. A pinned upstream pilot parser validates those models. A bounded controlled-text profile checks selected sampled Boolean/quantity requirements and correlated event deadlines against supplied evidence. A separate bounded generator now exports synthetic pass/fail trace pairs that demonstrate a referenced property's effect on one sampled requirement when it can find such a pair. Existing version-1 JSON helpers and the opt-in finite verifier remain available. General SysML behavior computation, temporal realizability, formal FLIP coverage, hosted Jev integration, and protected acceptance are not implemented. The project source is offered under the MIT license; the separately downloaded pilot parser has its own license. Publication details are tracked in the release handoff.
| Skill | Useful work unit |
|---|---|
develop-system-concept |
Frame a problem, identify functions, explore alternatives, and assess evidence for a concept decision. |
develop-conops |
Connect stakeholder needs, boundaries, scenarios, responsibilities, and evaluation plans. |
develop-operational-scenarios |
Develop or investigate one scenario or a selected set. |
A complete document is optional. Missing information can remain an explicit unknown. The skills use a system-wide SysML model and selected views rather than requiring the entire model in every model context. The SysML-first profile defines the supported parser and checker boundary.
The water-sampling station walkthrough follows a fictional sample from intake to recorded receipt, through a missing-label hold and recovery, and into maintenance lockout. It brings together editable source, readable views, typed traces and actual program outcomes. Its thresholds and evidence are demonstration choices, not a design approved for real equipment.
| Start with | Explore or edit | What you can check |
|---|---|---|
| Concept and operating model | Parts, concerns, functions, operational cases and declared requirements | Native syntax/reference validation and each requested drafting shape |
| Readable artifact browser · gallery guide | Scoped overview, full function tree, nominal/recovery/maintenance exchanges and model links | Selected native bindings and documentary view structure; inspect detailed diagrams at readable scale |
| Synthetic observation trace · required clause scope | Sampled recording, exact duration bounds and correlated receipts | Named finite-window monitor results, late/missing/incomplete controls and clause-local synthetic influence tests |
| Finite execution model · independent scope | Explicit guards, effects, typed data availability, external waits and completion | Finite consistency, reachable failures and declared completion paths; this is separately authored, not an executable SysML conversion |
| Meaning and scope mapping · method and official definitions | Responsibility, source/view identities, assumptions and omitted semantics | Typed correspondence and trace structure; links alone do not prove satisfaction or physical feasibility |
Run the case from a complete checkout after installing the pinned parser:
python3 examples/engineering-gallery/water-sampling/build.py --output work/water-sampling
python3 examples/engineering-gallery/water-sampling/build.py --checkUse a new output directory for each generation. The check reruns supported computations and compares the committed artifacts with their source bindings. Expected failures remain visible: a late receipt fails, an unfinished observation remains unknown, and deleted or unclassified finite-review obligations cannot disappear from a supplied external scope. See the case guide for exact inputs, outcomes and limits. The existing tool-library example adds a legacy concept comparison and conditional capacity calculation without claiming observed performance.
The completion and verification matrix maps the architecture to implemented checks, executable examples and deferred capabilities. The current finite verifier also accepts an optional independent inventory:
python3 scripts/verify.py examples/engineering-gallery/water-sampling/finite-scenarios.json \
--manifest examples/engineering-gallery/water-sampling/finite-scope.json --review --json --detailScenario analyses now run even when requirement applicability is unsupported; a definite dead-end failure survives an exploration cap alongside the incomplete result. Reports identify the scenarios actually analyzed. A focused review still checks global declarations, requirement consistency, traces and the supplied scope. Manifest-free legacy invocations remain available, with no independent inventory guarantee.
Native parsing, supplied-trace monitoring, finite state exploration, documentary allocations and engineering acceptance are separate claims. Native expression execution, unrestricted scenario compilation, realizability, full SysML conformance and protected acceptance remain outside this alpha. No global plugin installation or native-editor roundtrip is implied by the gallery.
When people interact with a proposed system or interpret an operational handoff, inspect relevant professional/UI precedents and use editable connected low-fidelity wireframes to expose consequential fields, options, defaults, actions, states and recovery. Keep source/model/requirement mappings adjacent and iterate with user feedback before substantial expansion, polish or implementation. The interaction-walkthrough workflow defines coverage, research provenance and review boundaries; current alpha limits remain separate from target product needs.
Python 3.10 or newer; the version-1 helpers use only the standard library. SysML validation additionally requires Java 21+, javac 21+, and the pinned pilot parser installed into the ignored project cache. Run from this directory:
python3 scripts/check.py
python3 scripts/install_sysml_parser.py
python3 scripts/check.py --require-sysml
python3 scripts/sysml.py examples/sysml/concept.sysml --syntax-only
python3 scripts/sysml.py examples/sysml/conops.sysml --syntax-only
python3 scripts/sysml.py examples/sysml/scenario.sysml --syntax-only
python3 scripts/sysml.py examples/sysml/ack.sysml --manifest examples/sysml/ack-manifest.json --evidence examples/sysml/ack-evidence.json --review
python3 scripts/sysml_testgen.py examples/sysml/ack.sysml --manifest examples/sysml/ack-manifest.json --output .tmp/ack-synthetic-tests.json
python3 scripts/sysml.py examples/sysml/correlated-events.sysml --manifest examples/sysml/correlated-events-manifest.json --evidence examples/sysml/correlated-events-evidence.json --review
python3 scripts/sysml.py examples/sysml/quantity.sysml --manifest examples/sysml/quantity-manifest.json --evidence examples/sysml/quantity-evidence.json --review
python3 scripts/sysml.py examples/sysml/composed-parts.sysml examples/sysml/composed-requirement.sysml --manifest examples/sysml/composed-manifest.json --evidence examples/sysml/composed-evidence.json --review
python3 scripts/sysml_view.py examples/sysml/ack.sysml --id R_ACK
python3 scripts/sysml_diff.py --before examples/sysml/ack.sysml --after examples/sysml/quantity.sysml
python3 skills/develop-conops/scripts/conops.py check examples/workshop/conops.json --review
python3 skills/develop-operational-scenarios/scripts/conops.py view examples/workshop/conops.json S1
python3 skills/develop-system-concept/scripts/concept.py --help
python3 scripts/verify.py examples/verifier/valid.json --review
python3 scripts/verify.py examples/verifier/valid.json --scenario S1 --review --json --detailOn systems where Python is named python, substitute that executable. Each skill's references/sysml.md describes new model output; references/record.md preserves its legacy JSON contract. The SysML integration tests run when the pinned parser is installed; otherwise they report a skip. The --require-sysml check and CI fail if the pinned parser is missing or stale.
The workshop example is synthetic. Passing its checks establishes only the conditions that the helper actually checks. Textual feasibility assessments, source truth, stakeholder acceptance, and implemented-system behavior are not independently verified.
The synthetic tool-library example includes a system-concept record, a human view, and a small reproducible calculation. It illustrates explicit unknowns and engineer decisions without creating a full CONOPS.
The version-2 contract and synthetic fixture specify the finite semantics. Use --scenario S1 --view to retrieve a context slice, while running checks against the full model. The FHWA slice is an unaccepted formalization proposal. FRET reuse, context measurement, and the separate protected-runner boundary record limits and next work.
The optional engineering view-quality checks
validate declared function roots/levels/parent links and ordered participant
exchanges, with task-specific counts, coverage, timing, and justified exceptions.
The skills assess action meaning and engineering adequacy with the engineer;
structural acceptance does not establish either. Existing unannotated models
retain their current checks. Try the neutral fixture with
python3 scripts/sysml.py examples/sysml/views/sample-handling.sysml --syntax-only --view-profile examples/sysml/views/task-profile.json.
The repository registers its three skills through symlinks under .agents/skills/, which Codex discovers when you open this project. They remain independently invocable and are scoped to this repository. Start a new project conversation if the skill selector has not refreshed. Codex skill discovery documents repository scope and symlink support.
Each skill's scripts/cse.py launcher finds the shared parser/engine from its real location, so checks work from subdirectories as well as the repository root. The repository also includes a plugin manifest at .codex-plugin/plugin.json; installation through a public marketplace remains untested. Copying a skill folder alone preserves its version-1 helper, but does not install the shared SysML engine. Avoid duplicate installations.
Example requests:
- “Use the system-concept and CONOPS skills on the material below. Keep my raw materials out of Git.” In this repository, the assistant uses both skills on one model, runs both draft-shape checks, and inspects supported sampled requirements with synthetic test pairs. It reads raw source in place and keeps the source and user-specific model in ignored private workspace paths; the engineer supplies material and reviews consequential interpretations, not commands or SysML syntax.
- “Use develop-system-concept to help compare these two approaches. Keep the current constraints and show unresolved evidence.”
- “Use develop-conops to investigate who operates and maintains this service.”
- “Use develop-operational-scenarios to develop the communications-loss scenario only.”
For your first combined concept/scenario trial, use “Use the system-concept and operational-scenarios skills on the material below. Keep my raw materials out of Git.” The assistant creates one shared model, returns readable concept and scenario views, runs both relevant draft checks, and reports supported computations separately from unresolved content. User-specific work stays in ignored work/. No command or SysML knowledge is required from the engineer. See the end-user test guide, pre-test review, and synthetic shared example.
Start with the first-version brief, the model and verification design, and the implementation prompt. The brief separates agreed objectives from implementation defaults and defines evidence required for completion.
The SysML-first plan and implemented alpha profile describe the current migration and its limits. The public-source evaluation shows FHWA and NASA candidate slices with synthetic traces. The controlled language profile parses a narrow FRET-inspired subset and checks supplied sampled behavior using explicit clock and unit semantics. Variable-influence tests are a bounded precursor to formal FLIP generation. The parsed context view and structural diff support review, but general state/mode computation, FRET-backed test generation, and richer generated views remain future work.
The project uses deterministic program results for computable claims. Broader validation still requires evidence and engineering judgment. JSON is a transport format, not a token-efficiency claim; measure context and repair costs before making such claims.
See public references and contribution guidance. External publications and tools remain under their own terms; none is bundled here.
An opt-in checked documentary function-tree renderer adds palette03, embedded Inter/Space Grotesk fonts and explicit provisional body variants. See visual presentation for generation, editable sources, checks and limits. Existing checking defaults remain unchanged.