Nasa skill

NASA Lab Skill

Use this for NYCU Network Administration / System Administration homework where official-spec compliance, durable state, and safe handoff matter.

Core Controls

State the active controls before changing anything:

• mode=read: inspect official specs, state files, and real system state. Update tracking files only when the user asks to align them or approves those writes. If the user forbids changes, do not update tracking files. Do not change real services, VMs, cluster resources, deliverables, or assignment artifacts.
• mode=execute: implement a bounded assignment objective such as finish E1-E4, complete HW2-1, or prepare HW2-1 for Online Judge verification.
• mode=fix: repair all currently visible Online Judge or error failures in the supplied output with scoped changes.
• confirm=ask (default): explain the next meaningful step before writes/service/network/playbook changes.
• confirm=proceed: continue without step-by-step confirmation only when the user gives a bounded objective. Vague requests like "auto", "help me do it", or "fix until good" are not enough by themselves.

If the user explicitly says not to modify anything, perform no writes at all, including tracking-file updates. Use mode=read, report any proposed correction in chat, and wait for permission before writing it.

Mode Selection

User situation	Active mode
asks for current status, follow-up, inspection, or says not to change anything	mode=read
asks to build, complete, or reach a bounded assignment endpoint	mode=execute
provides Online Judge or error output, or asks to repair visible failures	mode=fix
asks "auto", "help me do it", or "fix until good" without an endpoint	ask for a bounded objective first

HARD RULES

These rules exist because NA/SA work changes live systems, and short-context agents drift between turns.

1. Read the relevant local state/spec files and current evidence before concluding.
2. For assignment requirements, use this priority: official PDF, course portal, Online Judge text, or official starter repository; then user-pasted official text; then a user-maintained SPEC based on official material; then AI/OCR SPEC files; then chat memory or assumptions.
3. Tracking files do not define assignment requirements. For current operational state, direct evidence outranks tracking files, and tracking files outrank chat memory.
4. If official sources cannot be read, ask for pasted official text or a user-maintained SPEC; do not invent requirements.
5. Follow current course, instructor, and institution AI-use and academic-integrity rules when available. If referenced rules cannot be read, ask the user instead of assuming permission.
6. Before applying changes, confirm scope unless confirm=proceed has a bounded objective.
7. Every logically complete execute or fix change group needs an implementation check to confirm the intended change actually landed.
8. Every logically complete execute or fix change group also needs outcome verification, either local, Online Judge, or user-delegated.
9. Online Judge/user delegation may satisfy outcome verification, but not the implementation check.
10. Report implementation checks and outcome verification in chat.
11. Changes should survive reboot or re-apply unless the spec explicitly asks for runtime-only state; prefer durable config, manifests, units, playbooks, or repository files over one-off commands.
12. Do not use shortcuts that merely pass the visible check while violating the spec, hurting reproducibility, or risking later requirements.
13. Before high-risk VM/network/storage/cluster/service changes, remind the user to take a snapshot or backup when rollback would be expensive.
14. After each logically complete execute or fix change group, update STATE, append TRANSITIONS, and update DECISIONS only when a decision, trap, workaround, tradeoff, or architecture assumption changed. If DECISIONS does not need an update, leave it unchanged and note that in TRANSITIONS.
15. If state files conflict with actual state, stop broad changes and perform read-only checks. Record a state_drift correction before continuing, unless the user forbids writes; in that case, report the proposed correction in chat and do not continue into changes.

Required Files

Maintain assignment-scoped files when the work spans more than one short turn or needs handoff:

• <COURSE>_<ASSIGNMENT>_STATE.md
• <COURSE>_<ASSIGNMENT>_TRANSITIONS.md
• <COURSE>_<ASSIGNMENT>_DECISIONS.md

Use existing course/project naming if files already exist. For new assignments, prefer the bundled initializer instead of recreating templates by hand. Resolve the script relative to this SKILL.md; do not hardcode the install path.

# from the nasa skill directory
python3 scripts/init_nasa_state.py NA_HW2 --root HW2 --operator Codex

# from elsewhere, after resolving the skill directory
python3 <nasa-skill-dir>/scripts/init_nasa_state.py NA_HW2 --root HW2 --operator Codex

File Roles

• STATE: current objective, bounded endpoint, runtime facts, requirement/pass/fail matrix, latest evidence refs, and next action. Current truth beats brevity.
• TRANSITIONS: append-only operational events, checks, verification, delegated verification, and state-drift corrections.
• DECISIONS: architecture/rationale, traps, workarounds, tradeoffs, and references to transition IDs.

Large requirement text belongs in official PDFs or assignment SPEC/REQUIREMENTS files. If an AI/OCR SPEC is used, mark it as a working transcription and keep official sources authoritative.

The three tracking files describe current work and operational state. They never outrank official requirement sources.

Mode Workflows

mode=read

1. Read SKILL.md, assignment STATE, recent TRANSITIONS, relevant DECISIONS, and official/user-provided spec sources.
2. Inspect current system state only with read-only commands unless the user explicitly asks otherwise.
3. Update tracking files only when the user requested alignment or approved the write. If the user forbids changes, report observed facts, uncertainty, or state drift in chat only.
4. End with current objective, known facts, uncertainty, and the next recommended bounded action.

mode=execute

1. Confirm the bounded objective and source-of-truth requirements.
2. Split work by assignment requirement/check (E1..En) or the project's existing structure.
3. For each requirement: plan, apply one logically complete durable change group, run the implementation check, choose outcome verification, then process STATE, TRANSITIONS, and DECISIONS.
4. Stop on blockers, safety ambiguity, missing official requirements, or verification failure that needs user or Online Judge input.

mode=fix

1. Read the exact newest Online Judge or error output first.
2. Identify all currently visible failures; avoid rewriting unrelated passing areas.
3. Fix scoped root causes, not symptoms.
4. Run the implementation check, then choose local, Online Judge, or user outcome verification for the touched requirement.
5. Update STATE, append TRANSITIONS, and update DECISIONS only when needed. If it remains unchanged, note that in TRANSITIONS.

Examples

• User: "follow up目前進度，不要改" -> mode=read, read state and actual evidence, report next bounded action.
• User: "完成 HW2-1，並準備給 Online Judge 驗證" -> mode=execute confirm=proceed, because the endpoint is bounded.
• User: "這是 Online Judge 回饋，幫我修" -> mode=fix, read the exact Online Judge output and repair visible failures.
• User: "幫我做 / auto / 修到好" -> ask for the bounded endpoint before using confirm=proceed.

Common Mistakes / Red Flags

Rationalization	Why it is wrong	Required response
"I can start executing; the user wants help."	NA/SA changes can affect live services and prior state may have drifted.	Read STATE, recent TRANSITIONS, and the official/user-provided spec first.
"The OCR/SPEC says this, so it must be the requirement."	AI/OCR SPEC is only a working transcription.	Prefer official PDF, portal, or Online Judge text; mark uncertainty when official text is unavailable.
"This is only read mode, but I will quickly patch it."	mode=read must not change runtime systems or deliverables, and an explicit no-change request forbids tracking-file writes too.	Report findings in chat; update tracking files only when the user requested alignment or approved the write.
"Online Judge will verify it, so I do not need to check anything."	Online Judge can verify outcome, not whether the intended change actually landed.	Run an implementation check before delegating outcome verification.
"The runtime command works, so it is done."	Many lab fixes disappear after reboot, service restart, rebuild, or re-apply.	Put the change in durable config or mark it as temporary in state files.
"This shortcut gets Online Judge green."	A shortcut can violate the spec or break later requirements.	Prefer the spec-aligned fix; record workaround risks in DECISIONS or TRANSITIONS.
"I can reproduce the Online Judge locally."	Rebuilding Online Judge behavior can waste tokens and still miss the real external check.	Use real Online Judge feedback when available and relevant; local checks should be targeted or safety-related.
"The service changed; I will update state later."	Handoff depends on durable files, not chat memory.	Process STATE, TRANSITIONS, and DECISIONS after each logically complete execute/fix change group.
"This command history belongs in DECISIONS."	DECISIONS is for rationale, traps, and tradeoffs, not logs.	Put operational evidence in TRANSITIONS; keep DECISIONS concise.

Handoff / Resume

On compaction, model switch, "接手", "跟上目前狀態", or similar:

1. Re-read this file.
2. Read *_STATE.md current objective/status/evidence refs.
3. Read the tail of *_TRANSITIONS.md.
4. Read recent traps/decisions from *_DECISIONS.md if relevant.
5. Read the newest user, Online Judge, or error output.
6. Determine mode=read|execute|fix.
7. Continue from durable files and actual system state, not chat memory alone.
8. Before changing anything, state the current objective and next action.

IDs And Timestamps

• Transition IDs: T0001, T0002, ...
• Timestamp: ISO-8601 with timezone.
• Include updated_by and evidence_ref (T####) where relevant.

Response Budget

Keep conversational prose concise. Put durable details in state files, but never hide blockers, partial failures, or skipped/delegated verification.

Git-Aware, Git-Optional

If git repo exists:

• check git status --short before/after meaningful changes
• prefer small milestone commits when the user asks for commits

If no git repo exists:

• continue with state files as source of truth
• do not block work

References (load only when needed)

• references/bootstrap-from-zero.md: new assignment setup.
• references/workflow.md: detailed read/execute/fix flow.
• references/verification.md: implementation checks, Online Judge/user delegation, and subsystem examples.
• references/state-files.md: state file structure and transition format.
• references/recovery.md: compaction, handoff, state drift, and recovery.
• references/test-scenarios.md: lightweight forward-test scenarios for this skill.