Implementation Review Prompt

Act as a practical electrical engineer, CAD-tool integrator, and standards implementer who is attempting to actually use this specification in a real workflow.

Your job is not to praise it. Your job is to analyze it like an engineer who must:
1. build an exporter against it,
2. validate outputs,
3. use the exported data for downstream analysis,
4. explain where the spec is clear, ambiguous, burdensome, inconsistent, or incomplete.

I will provide a draft specification excerpt. Analyze it from the perspective of real implementation and engineering use.

What I want from you:
- Read it as if you are trying to implement a compliant exporter.
- Read it as if you are trying to consume the exported output in an engineering analysis pipeline.
- Identify friction points, ambiguity, hidden assumptions, contradictions, and over-specification.
- Distinguish between:
  - things that are good and usable,
  - things that are underspecified,
  - things that are too rigid,
  - things that are likely to break interoperability,
  - things that look fine on paper but would be annoying in practice.
- Point out where the standard appears to mix:
  - core transport requirements,
  - tool-specific behavior,
  - analysis-module semantics,
  - implementation guidance,
  - and policy/process language.
- Evaluate whether the effort-tier idea is actually useful and operationally meaningful.
- Evaluate whether the JSON and Markdown profiles feel coherent and realistically implementable.
- Evaluate whether the EPSA/FMEA/WCCA extension approach is clean or messy.
- Evaluate whether the EAGLE-specific and Altium-specific language belongs in the main standard body.
- Identify exactly what would make an implementer hesitate, misread, or produce incompatible outputs.
- Suggest concrete improvements.

Required output format:

## 1. Engineer's first impression
Give your blunt first impression as someone trying to use this spec.

## 2. What this spec is trying to do
Summarize the apparent intent in practical engineering terms.

## 3. What is strong
List the parts that seem genuinely solid, useful, and implementable.

## 4. What is confusing or ambiguous
List specific ambiguities, each with:
- section/topic
- what is unclear
- why it matters in implementation
- how to fix it

## 5. What feels overengineered
Identify sections or rules that feel too heavy for version 1.0.

## 6. What is missing
Identify important missing artifacts, definitions, schemas, examples, edge-case rules, or conformance guidance.

## 7. Interoperability risks
Call out anything likely to cause different exporters to produce incompatible results.

## 8. Practical implementation pain points
Describe what would be annoying for:
- an EAGLE exporter author,
- an Altium exporter author,
- a JSON consumer,
- a Markdown consumer,
- an analysis-engine developer.

## 9. Separation-of-concerns critique
Explain where the document mixes standard, policy, implementation guidance, and analysis framework too tightly.

## 10. Recommended rewrite priorities
Give the top 10 changes you would make before calling this standard ready for broader adoption.

## 11. Bottom line
Answer plainly:
- Would you trust this enough to implement against today?
- Would you trust another team's exporter to interoperate with yours?
- What level of maturity does this spec currently feel like?

Important instructions:
- Be direct.
- Be specific.
- Quote short phrases from the spec when useful.
- Do not rewrite the whole standard.
- Do not be polite at the expense of accuracy.
- Think like an engineer trying to avoid rework.
- Prefer implementation realism over standards-style optimism.

Here is the specification excerpt to analyze:

[PASTE SPEC HERE]