jon-devlapaz Agentic Systems Engineering
Purpose
Use this router skill to select the smallest useful systems-engineering playbook for agentic software development work. The router reduces ambiguity between overlapping public skills by exposing one activation point and then loading one or more internal playbooks by intent.
When To Use
- The request mixes user need, requirements, tests, design choices, integration risk, or acceptance evidence.
- The task needs a durable artifact such as a ConOps brief, requirements matrix, interface contract, integration plan, verification matrix, validation plan, decision record, or checkpoint note.
- The user asks for systems-engineering discipline, NASA-SE inspired workflow, source-grounded planning, behavioral validation, or release readiness.
- The user asks to assess a repo, score codebase health, run a NASA-SE-aligned audit, or identify robustness gaps.
- A task has enough ambiguity or risk that categories must be separated before coding.
When Not To Use
- Trivial code edits, simple syntax fixes, formatting-only changes, or ordinary dependency updates.
- Tasks with no systems-engineering artifact needed.
- Pure factual lookup, extraction maintenance, source PDF processing, or requests to rerun extraction.
- Cases where the user explicitly asks for one legacy repo-scoped skill such as
requirements-distillerorverification-planner. - Cases where the right action is a direct command or a local repo inspection with no planning artifact.
Routing Table
| User intent | Load internal playbook |
|---|---|
| unclear intent, operational scenario, actors, nominal/off-nominal flow | playbooks/conops.md |
| user goal to obligations, vague feature to testable statements | playbooks/requirements-distillation.md |
| requirements review, ambiguity, contradiction, unverifiable wording | playbooks/requirements-audit.md |
| module/API/tool boundary, external dependency, schema or protocol boundary | playbooks/interface-contracts.md |
| multi-component assembly, generated artifact sequence, merge ordering | playbooks/integration-planning.md |
| proof against stated requirements, test/inspection/analysis/demo matrix | playbooks/verification-planning.md |
| proof against intended use, user workflow, ConOps fit, operational need | playbooks/validation-planning.md |
| option choice, architecture/tool tradeoff, criteria, rationale | playbooks/decision-analysis.md |
| checkpoint, drift, failure, readiness, closeout, residual risk | playbooks/technical-assessment.md |
| codebase health, NASA-SE audit, robustness review, evidence scoring, release-readiness assessment | playbooks/codebase-assessment.md |
Sequencing Rules
- If intent is unclear, start with
playbooks/conops.mdbefore requirements. - If turning user intent into obligations, load
playbooks/requirements-distillation.md; audit high-risk output withplaybooks/requirements-audit.md. - If a boundary crosses modules, APIs, tools, files, schemas, or generated artifacts, load
playbooks/interface-contracts.mdbefore integration planning. - If multiple components must become one working result, load
playbooks/integration-planning.mdand name checkpoints. - If proving compliance with specified requirements, load
playbooks/verification-planning.md. - If proving fit for intended use, user workflow, or ConOps, load
playbooks/validation-planning.md. - If choosing among options, load
playbooks/decision-analysis.mdbefore selecting. - If evidence, drift, residual risk, or closeout is the issue, load
playbooks/technical-assessment.md. - If scoring a repo or judging engineering maturity, load
playbooks/codebase-assessment.mdfirst, then route findings to remediation playbooks. - When multiple playbooks apply, sequence them explicitly instead of blending terms.
Required Distinctions
- Goals and objectives are not requirements. Keep desired outcomes separate until a specific, necessary, testable obligation exists.
- Requirements are not implementation choices. Treat architecture, libraries, UI patterns, data models, and tools as design choices unless the user or source makes them constraints.
- Verification proves compliance with specified requirements using test, inspection, analysis, or demonstration evidence.
- Validation checks intended use, user workflow, operational need, or ConOps fit. Verification passing does not prove validation.
- Source grounding is workflow context, not proof of agent performance.
Source-Grounding Caveat
The NASA Systems Engineering Handbook references in references/ explain why these workflow categories exist. They do not prove that a generated answer is useful, correct, or behaviorally better. Behavioral effectiveness must be judged with eval outputs, reviewer notes, and practical task results.
Playbook Loading
After choosing a route, read only the matching internal playbook and any directly referenced note needed for the answer. Prefer concise artifacts over broad process narration.
Bundled Direct Skills
This plugin also exposes the eight canonical direct skills under skills/ (for example requirements-distiller, verification-planner). Use a direct skill when the user names it explicitly or when the task needs only one workflow without router sequencing. Use this router when intent is mixed, ambiguous, or spans multiple categories. Canonical copies remain under .agents/skills/; plugin entries link to those paths via scripts/sync_harness_skills.sh.
Output Discipline
- State the selected playbook and why it was selected.
- When one internal playbook is selected, produce every mandatory section in that playbook's Output (do not emit a shortened artifact).
- Produce the requested artifact, not generic systems-engineering prose.
- Preserve category labels: goal, objective, requirement, constraint, assumption, implementation choice, verification evidence, validation evidence.
- Call out unsupported claims and missing evidence.
- Score assessments only from inspectable target-repo evidence.
- Keep NASA citations as source context and avoid claiming that citations prove agent behavior.