---
name: ntn-openspec-follow-on-kickoff
description: Use when deciding whether a future ntn-sim-core follow-on, especially OMNeT++ / INET / estnet or other external-consumer/backend realism work, should be bootstrapped with OpenSpec instead of the repo's normal SDD/todo flow. Also use when a user explicitly mentions OpenSpec, opsx workflows, or wants a separate change/spec workflow for a new track without replacing existing ntn-sim-core authority.
---

# NTN OpenSpec Follow-On Kickoff

Use this skill when the question is not "how does current `ntn-sim-core` authority work?" but rather:

1. should a **new** follow-on track use OpenSpec,
2. where should OpenSpec live,
3. how should OpenSpec coexist with the repo's existing SDD/todo/governance surfaces,
4. how should a future external-consumer/backend realism track be bootstrapped without polluting the current simulator authority chain.

This skill is a **workflow aid**, not a replacement for the active SDD set.

## Required Read Order

Read these first:
1. `agent-governance.md`
2. `sdd/README.md`
3. `sdd/ntn-sim-core-implementation-status.md`
4. `sdd/ntn-sim-core-research-positioning-note.md`
5. any active or paused downstream surface directly related to the proposed follow-on:
   - `sdd/estnet-ui-contract-outline.md`
   - `sdd/real-trace-scalability-preflight-note.md`
   - `sdd/downstream-runtime-architecture-sdd.md`
6. OpenSpec reference docs as **tool background only**, not authority:
   - `/home/u24/papers/OpenSpec/README.md`
   - `/home/u24/papers/OpenSpec/docs/getting-started.md`
   - `/home/u24/papers/OpenSpec/docs/opsx.md`
   - `/home/u24/papers/OpenSpec/docs/concepts.md`

## Core Rule

Do **not** recommend OpenSpec as a retrofit replacement for the current `ntn-sim-core/sdd/` authority stack.

OpenSpec is a good fit only when the user is opening a **new track** that benefits from:

1. separate change folders,
2. delta-spec workflow,
3. explicit proposal/design/tasks artifacts,
4. future external-consumer or cross-repo integration planning.

It is usually a poor fit when the task is:

1. maintaining the current shipped simulator baseline,
2. updating active `sdd/` authority in place,
3. minor follow-up edits inside an already-promoted `ntn-sim-core` surface,
4. using OpenSpec merely because "more process sounds better."

## Decision Workflow

1. Identify the target work:
   - current simulator maintenance,
   - new follow-on inside `ntn-sim-core`,
   - new external-consumer/backend realism track,
   - separate repo/subproject kickoff.
2. Decide whether OpenSpec should be:
   - `no` — stay on current SDD/todo flow,
   - `later` — not yet, but maybe for a future dedicated track,
   - `yes-separate-track` — use OpenSpec for the new track only.
3. If `yes-separate-track`, recommend the smallest safe placement:
   - a separate repo,
   - or a clearly bounded future subproject,
   - but not a silent takeover of the `ntn-sim-core` root governance.
4. State coexistence rules explicitly:
   - `ntn-sim-core/sdd/` remains simulator authority,
   - OpenSpec governs only the new track's change workflow,
   - frozen contracts and existing active SDDs still win for current simulator behavior.

## Recommended Output

When this skill is used, report:

1. whether OpenSpec should be used at all,
2. the exact scope that should use it,
3. where it should live,
4. what should remain under current SDD authority,
5. the minimum bootstrap plan.

## Minimum Bootstrap Plan for a Future OpenSpec Track

If the verdict is to use OpenSpec, recommend a minimal bootstrap like this:

1. create or choose a dedicated track boundary first,
2. keep current `ntn-sim-core` authority unchanged,
3. initialize OpenSpec only inside the dedicated track boundary,
4. treat `openspec/specs/` as that track's source of truth,
5. use `changes/` for proposal/design/tasks deltas,
6. keep interface points back to `ntn-sim-core` anchored to frozen contracts or explicitly promoted new adapter contracts.

## Do Not

1. Do not tell agents to run `openspec init` in `ntn-sim-core` root by default.
2. Do not let OpenSpec replace `sdd/README.md`, `implementation-status`, or the validation matrix for current simulator work.
3. Do not fork or edit OpenSpec upstream specs just to teach this repo how to use it.
4. Do not present OpenSpec as required for ordinary paper-mode / claim-mode hardening.
5. Do not use OpenSpec to bypass the repo's promotion / reopen discipline.

## Best-Fit Use Cases

OpenSpec is most likely worth using here when:

1. `OMNeT++ / INET / estnet` integration becomes an active external-consumer/backend realism track,
2. a new adapter-heavy subproject needs separate proposal/design/tasks artifacts,
3. the user wants a bounded change-management workflow for a future line that should not contaminate current simulator authority.

## Poor-Fit Use Cases

Stay on the existing SDD/todo workflow when:

1. the work is within current `MODQN`, `UI`, or `T1` completed surfaces,
2. the user is only updating notes, validation, or shipped baselines,
3. the change belongs inside active simulator authority rather than a separate track,
4. the user only wants clearer SDDs, not a new change-management system.