Arc Skills — 100 free AI skills for systems and hardware engineers
Choose an engineering task, see its worked example and copy the prompt into your AI assistant.
Use Arc Skills
Clean requirements, review against ECSS, derive sub-requirements, check hardware interfaces and build engineering budgets. The toolkit is MIT licensed; your AI assistant may have its own charges.
Download the ZIP and open its folder in Codex, or attach it to a ChatGPT conversation with file-analysis support. Copy this prompt:
Set up Arc Skills from:
https://github.com/ArcHelps/systems-engineering-skills
Read README.md and docs/SETUP.md. Use the repository or ZIP I provided,
or fetch the public repository if your tools support it.
Choose the supported route:
- Local MCP: install the locked dependencies, connect the server and check tool discovery.
- Conversation instructions: read the selected skill and its bundled references.
Use a dedicated arc-engineering-work folder. Preserve my existing settings
and source files, and do not upload them to other services.
Show me five relevant skills and try the included requirements example.
Tell me which route worked and any remaining setup step.Choose the route your client supports
| Where you use it | What works | What you need |
|---|---|---|
| Codex on your computer | Local MCP with the 100-skill catalogue and file tools. | Python 3.11+, uv, and a dedicated work folder. Follow the setup guide and confirm tool discovery. |
| ChatGPT web | Read attached skill instructions and use available conversation file tools. This does not install the MCP. | Attach the ZIP and source material. If ZIP reading is unavailable, paste the selected instructions and references. |
| Claude Desktop or another local MCP client | Connect the same local server using a stdio-capable client. | Install the locked environment, generate the documented configuration and restart the client if needed. Follow the client’s local-server setup instructions. |
See the inputs and outputs
| What you have | Engineering task | What you get |
|---|---|---|
| A requirements spreadsheet | Clean and map requirements | Preserved IDs and statements, field mapping and count reconciliation. |
| One requirement and the applicable ECSS edition | Review against ECSS-E-ST-10-06 | Clause-grounded findings, proposed wording and open decisions. |
| Requirements and verification activities | Build a verification matrix | Methods, acceptance criteria and separate plan/evidence gaps. |
| Electrical interface specifications | Review an electrical interface | Voltage, current, grounding, signal and fault compatibility checks. |
| Component loads and source limits | Build a power budget | Demand by operating mode, remaining allowance and unknown loads. |
| Functions and component failure behavior | Perform an FMEA | Failure modes, local/system effects, controls and open evidence. |
Illustrative engineering examples. Each page shows its input, worked output and sources.
All 100 systems engineering skills
100 of 100 skills
No matching skills. Clear the search or try another engineering task.
| Task | Category | What it delivers |
|---|---|---|
| Allocate requirements to systems and subsystems | Requirements | Propose requirement-to-system allocations with a reasoned ownership boundary. |
| Build a tender compliance matrix | Requirements | Organize bidder response obligations against tender clauses with evidence and unresolved exceptions. |
| Check whether a requirement is verifiable | Requirements | Assess whether objective evidence could decide a requirement at the stated level and configuration. |
| Clean and map a requirements spreadsheet | Requirements | Prepare a source-preserving column map and reviewed import proposal from a messy requirements spreadsheet. |
| Compare child requirements to parent requirements | Requirements | Assess whether existing children preserve, cover, or exceed a parent requirement. |
| Compare two versions of a requirements specification | Requirements | Produce a semantic change register between two controlled specification versions. |
| Define acceptance criteria for a requirement | Requirements | Turn an approved requirement into observable pass/fail criteria without inventing thresholds. |
| Derive interface requirements from an interface definition | Requirements | Turn an agreed system boundary and exchanged items into candidate interface obligations. |
| Derive sub-requirements from a parent requirement | Requirements | Propose child requirements that partition an approved parent obligation without losing or inventing intent. |
| Extract requirements from a customer document | Requirements | Extract candidate obligations from a customer document with exact source trace and ambiguity flags. |
| Identify conflicting requirements in a specification | Requirements | Find requirements whose simultaneous obligations cannot be reconciled under the same conditions. |
| Identify duplicate requirements in a specification | Requirements | Identify exact and semantic duplicates while preserving distinct conditions and source obligations. |
| Identify missing requirements from operational scenarios | Requirements | Find unsupported scenario transitions and exceptions that need requirement decisions. |
| Identify undefined terms in requirements | Requirements | Find terms whose missing or inconsistent definitions materially change interpretation or verification. |
| Import requirements and links from ReqIF | Requirements | Map ReqIF objects and relations into a reviewed local requirements proposal while preserving external IDs. |
| Resolve TBDs and TBCs in requirements | Requirements | Prepare source-backed decisions for unresolved requirement placeholders without silently choosing values. |
| Review a requirement against ECSS-E-ST-10-06 | Requirements | Review one requirement against an inspected, applicable edition of ECSS-E-ST-10-06 and return source-grounded findings. |
| Review a requirement against the INCOSE Guide for Writing Requirements | Requirements | Review one requirement against a user-accessible licensed INCOSE guide edition without inventing rules. |
| Review requirement rationale | Requirements | Assess whether rationale explains the obligation and supports future change decisions. |
| Review supplier compliance claims against evidence | Requirements | Challenge supplier claim strength against exact requirement, configuration, and supplied proof. |
| Rewrite a requirement using EARS | Requirements | Rewrite a requirement in an appropriate EARS pattern while preserving its engineering intent. |
| Trace requirements back to stakeholder needs | Requirements | Build an evidence-backed trace from technical requirements to stated stakeholder needs. |
| Allocate an end-to-end performance budget | Architecture and engineering budgets | Allocate a system performance limit across contributing stages and calculate remaining margin. |
| Allocate system functions to subsystems | Architecture and engineering budgets | Perform functional allocation: allocate stated system functions to responsible subsystems and reveal unowned or overlapping behavior. |
| Build a system mass budget | Architecture and engineering budgets | Build a mass budget from component estimates, configuration, and a stated system allowance. |
| Build a system power budget | Architecture and engineering budgets | Build a mode-specific electrical power budget from loads and source capability. |
| Check engineering margins against requirements | Architecture and engineering budgets | Calculate signed engineering margin and judge it only against stated requirements and conventions. |
| Check units and dimensions in engineering calculations | Architecture and engineering budgets | Check calculation expressions for unit consistency, conversions, and physical dimensional meaning. |
| Compare architecture alternatives in a trade study | Architecture and engineering budgets | Compare feasible architectures against stated decision criteria, assumptions, and evidence. |
| Decompose a system into subsystems | Architecture and engineering budgets | Perform functional or product decomposition: propose a System hierarchy from responsibilities and physical or logical boundaries. |
| Define a system boundary and external actors | Architecture and engineering budgets | Define a system-of-interest boundary, external actors, and crossings from a stated mission or product scope. |
| Develop operational scenarios and off-nominal scenarios | Architecture and engineering budgets | Write normal and off-nominal operational scenarios with triggers, actions, responses, and recovery paths. |
| Perform a make-or-buy technical assessment | Architecture and engineering budgets | Assess technical feasibility and integration consequences of building versus buying a component. |
| Review a functional architecture for missing functions | Architecture and engineering budgets | Find missing or weakly allocated functions by walking scenarios, requirements, and function flows. |
| Review single points of failure in an architecture | Architecture and engineering budgets | Identify architecture elements whose single failure may defeat a stated function or mission outcome. |
| Review system modes and transitions | Architecture and engineering budgets | Review operating modes, guards, transitions, and recovery for ambiguous or unreachable behavior. |
| Write a concept of operations | Architecture and engineering budgets | Draft a concept of operations (ConOps) connecting actors, goals, phases, modes, and outcomes for a defined system. |
| Compare supplier and customer interface specifications | Interfaces | Compare two parties’ interface specifications and record matches, conflicts, and missing evidence. |
| Define an interface between two systems | Interfaces | Define an engineering exchange between two Systems and propose its Interface relationship content. |
| Diagnose an integration failure from test evidence | Interfaces | Use integration logs and configuration evidence to narrow a failure and propose discriminating checks. |
| Identify missing interface requirements | Interfaces | Find interface behaviors that lack an explicit, allocated, verifiable Requirement. |
| Plan system integration order | Interfaces | Sequence subsystem integration using dependencies, test access, and fault-isolation needs. |
| Review a data interface specification | Interfaces | Review a data exchange for syntax, semantics, timing, state, and error behavior. |
| Review a mechanical interface specification | Interfaces | Review mating geometry, loads, tolerances, access, and installation assumptions across two Systems. |
| Review an electrical interface specification | Interfaces | Review an electrical interface for complete, consistent power, signal, grounding, and fault parameters. |
| Review interface timing and latency budgets | Interfaces | Review end-to-end interface latency by tracing stages, bounds, clocks, and operating conditions. |
| Write an interface control document | Interfaces | Draft an interface control document (ICD) from agreed System endpoints and controlled exchange details. |
| Assess whether test results demonstrate a requirement has been met | Verification and validation | Assess executed data against a specific requirement and approved acceptance rule. |
| Build a requirements verification matrix | Verification and validation | Build a traceable matrix from requirements to planned verification evidence. |
| Check whether a test procedure verifies a requirement | Verification and validation | Compare an existing procedure’s actions and criteria with the full requirement obligation. |
| Define entry and exit criteria for a test campaign | Verification and validation | Draft auditable readiness and completion gates for a bounded verification campaign. |
| Identify requirements without verification coverage | Verification and validation | Find baseline obligations lacking adequate planned Tests or current evidence. |
| Plan re-verification after an engineering change | Verification and validation | Choose targeted re-verification actions after a change using actual affected obligations and evidence. |
| Review a verification matrix against ECSS-E-ST-10-02 | Verification and validation | Review matrix completeness and source-grounded ECSS-E-ST-10-02 obligations for a controlled edition. |
| Review environmental qualification test coverage | Verification and validation | Check that qualification evidence spans approved environments, configurations, and requirement limits. |
| Review verification evidence configuration and applicability | Verification and validation | Decide whether existing verification evidence applies to the current requirement and product configuration. |
| Select a verification method for a requirement | Verification and validation | Choose a defensible inspection, analysis, demonstration, or test approach for one requirement. |
| Write a test procedure for a requirement | Verification and validation | Draft executable steps and records that can verify a requirement on a defined article. |
| Write a verification close-out report | Verification and validation | Synthesize verification status and open exceptions for a named baseline and article. |
| Assess whether an engineering tool needs qualification | Standards and development assurance | Assess qualification need from a tool’s intended use, output credit, and downstream error detection. |
| Check hardware assurance evidence against DO-254 objectives | Standards and development assurance | Assess airborne electronic hardware evidence against the approved DO-254/ED-80 basis and hardware DAL. |
| Check software assurance evidence against DO-178C objectives | Standards and development assurance | Map supplied software lifecycle evidence to the applicable DO-178C objectives for an approved software level. |
| Review a NASA software requirements mapping matrix | Standards and development assurance | Check applicability, tailoring, evidence, and approval in an NPR 7150.2D Appendix C mapping matrix. |
| Review a safety argument against its evidence | Standards and development assurance | Challenge the links among safety claims, assumptions, subclaims, and configuration-specific evidence. |
| Review a standards applicability and tailoring matrix | Standards and development assurance | Review the basis, scope, rationale, and approval of an engineering standards applicability matrix. |
| Review an ECSS compliance finding and its proposed closure | Standards and development assurance | Assess whether a proposed closure addresses a stated ECSS finding using current, applicable evidence. |
| Review development assurance level allocation rationale | Standards and development assurance | Review the reasoning and authority trail for functional, item, software, and hardware assurance allocations. |
| Assess common-cause failures between redundant systems | Safety | Examine shared exposures and dependencies that can defeat claimed redundancy in a defined architecture. |
| Build a fault tree for a hazardous event | Safety | Construct a traceable Boolean fault tree for one defined top event and analyze its minimal cut sets and assumptions. |
| Derive safety requirements from a hazard analysis | Safety | Turn approved hazard controls into proposed measurable safety requirements with traceable rationale. |
| Perform a failure modes and effects analysis | Safety | Analyze credible item failure modes, their local and system effects, detection, and existing controls for a configured design. |
| Perform a functional hazard assessment | Safety | Assess loss and malfunction of intended functions across operating conditions and document candidate failure conditions. |
| Perform a preliminary hazard analysis | Safety | Identify credible early lifecycle hazards and record assumptions, controls, and follow-up evidence for a defined system concept. |
| Review an FMEA for missing failure modes | Safety | Find credible omissions in an existing FMEA against actual functions, interfaces, and operating modes. |
| Review fault detection isolation and recovery logic | Safety | Review FDIR sequences against fault effects, timing, safe-state behavior, and verification evidence. |
| Review hazard mitigations and closure evidence | Safety | Check whether each claimed hazard control has applicable, current, and sufficient implementation and verification evidence. |
| Allocate a system reliability target to subsystems | Reliability and maintainability | Propose traceable subsystem reliability budgets that satisfy an approved system success target under explicit architecture assumptions. |
| Calculate system reliability from component data | Reliability and maintainability | Calculate a bounded system reliability estimate from component data and a defined success model. |
| Review a reliability block diagram | Reliability and maintainability | Check whether a reliability block diagram represents the actual success logic, dependencies, and mission scope. |
| Review maintainability requirements | Reliability and maintainability | Check maintainability requirements for measurable repair, access, support, and operating context. |
| Assess the impact of a requirement change | Configuration and change control | Trace a proposed Requirement revision to affected design, interfaces, tests, and evidence. |
| Assess the impact of an interface change | Configuration and change control | Trace a proposed Interface revision across both endpoints, requirements, integration, and evidence. |
| Build a requirement traceability matrix | Configuration and change control | Build a requirement traceability matrix (RTM) from stable IDs, recorded links, and verification evidence. |
| Check the completeness of a configuration baseline | Configuration and change control | Check whether a proposed baseline contains the intended scope, revisions, documents, and review evidence. |
| Compare two engineering baselines | Configuration and change control | Compare two exact engineering baselines and explain material model and evidence changes. |
| Identify stale evidence after a configuration change | Configuration and change control | Identify verification evidence whose tested configuration may no longer support the changed model. |
| Prepare an engineering change request | Configuration and change control | Prepare a reviewable engineering change request with rationale, exact deltas, impacts, and validation. |
| Review a deviation or waiver request | Configuration and change control | Review a proposed deviation or waiver against a specific requirement, configuration, evidence, and authority. |
| Build a technical review action closure matrix | Technical management and design reviews | Track review actions from finding to evidence-backed closure recommendation without losing original board decisions. |
| Define technical performance measures and monitoring thresholds | Technical management and design reviews | Define a small set of decision-useful TPMs with sources, trends, and project-approved action thresholds. |
| Perform a technical risk assessment | Technical management and design reviews | Identify and assess credible technical risk scenarios against project objectives and existing controls. |
| Prepare a critical design review | Technical management and design reviews | Prepare a CDR packet assessing whether detailed design and build-to data are mature for implementation and integration. |
| Prepare a preliminary design review | Technical management and design reviews | Prepare a PDR packet that tests preliminary architecture, interface choices, margins, and path to detailed design. |
| Prepare a system requirements review | Technical management and design reviews | Prepare a decision-ready SRR packet focused on requirements completeness, feasibility, and baseline readiness. |
| Prepare a test readiness review | Technical management and design reviews | Prepare a TRR packet checking test article, facility, procedures, personnel, safety, and data capture readiness. |
| Prepare an operational readiness review | Technical management and design reviews | Prepare an ORR packet assessing deployed system, support products, people, procedures, and contingency readiness. |
| Review a risk register for missing or weak risk statements | Technical management and design reviews | Find missing technical risks and rewrite vague entries as cause-event-consequence statements. |
| Review a supplier technical deliverable | Technical management and design reviews | Review a specific supplier engineering deliverable against agreed content, interfaces, evidence, and configuration. |
| Review technology readiness evidence | Technical management and design reviews | Evaluate claimed TRL or technology maturity against what was demonstrated in the relevant environment. |
| Write a risk mitigation plan | Technical management and design reviews | Plan concrete actions, triggers, and evidence to reduce a stated technical risk scenario. |
Where your engineering data goes
The local MCP reads and exports inside the work folder you choose. It has no Arc connection, customer database or outbound data client and sends no customer data to Arc. The connected assistant and its AI provider still process content used in the conversation: local parsing does not mean offline AI. ChatGPT uploads follow ChatGPT’s policies.
Choose a dedicated project folder for the local MCP. Inputs are preserved; exports create new files and refuse existing filenames.
For standards reviews, provide the applicable edition and project tailoring. Proposed edits remain separate from your source records.
Arc Skills and the Arc platform
Arc publishes this free toolkit. It runs locally and does not connect to your hosted programme. The Arc platform MCP integration is a separate connection to permission-controlled programme records. For shared engineering records, branches and team reviews, explore the Arc platform.
Catalogue and setup checked against public repository revision 6158966 on 3 October 2026. Contact Arc or report a toolkit issue.