本文へ移動
cccskills
無料GitHub で公開

gao-tra

Knowledge base from the GAO Technology Readiness Assessment Guide (GAO-20-48G, 2020). Use for evaluating technology maturity in acquisition programs and projects: Technology Readiness Levels (TRL 1–9) and related scales (MRL, IRL), identifying Critical Technology Elements (CTEs), the five-step process for a high-quality TRA, the four characteristics of a reliable TRA (comprehensive, well-documented, credible, defensible), Technology Maturation Plans (TMPs), and using TRA results in knowledge-based, milestone decisions. Assessment/maturity oriented: it measures readiness and frames risk — it is not a full SE process model, cost-estimating, or schedule guide (see sibling packs for those).

インストール方法を見る

含まれるファイル(13)

  • SKILL.md11.4 KB
  • chapters/ch01-tra-fundamentals.md4.4 KB
  • chapters/ch02-technology-readiness-levels.md4.6 KB
  • chapters/ch03-critical-technology-elements.md4.4 KB
  • chapters/ch04-five-step-tra-process.md4.5 KB
  • chapters/ch05-four-characteristics.md4.0 KB
  • chapters/ch06-technology-maturation-plans.md4.2 KB
  • chapters/ch07-using-tras-in-decisions.md4.7 KB
  • cheatsheet.md4.4 KB
  • glossary.md2.9 KB
  • LICENSE1.6 KB
  • PACK.yaml1.2 KB
  • patterns.md4.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

<!-- argument-hint: [TRL level, readiness scale (MRL/IRL), critical technology element (CTE), TRA step, TRA characteristic, technology maturation plan (TMP), maturity decision, chapter number] -->

GAO Technology Readiness Assessment Guide (GAO-20-48G, 2020)

Source: US Government Accountability Office (GAO) — US Government work, public domain | Chapters: 7

When to use

Use this skill when you need to assess, explain, or critique the maturity and readiness of a technology before committing it to an acquisition program or project: assigning Technology Readiness Levels, identifying which technologies are critical (CTEs), planning and conducting a high-quality TRA, judging whether an existing TRA is reliable, building a Technology Maturation Plan for immature technology, or using TRA results to inform a knowledge-based milestone decision. This is GAO's cross-government best-practice companion to the agency-specific SE handbooks (NASA, DoD).

Prerequisites: none — plain Markdown; no MCP server, API key, or licence tier needed at runtime.

How to Use This Skill

  • Without arguments — load the core frameworks below for an overview of TRLs, CTEs, the five-step TRA process, and the four characteristics of a reliable TRA.
  • With a topic — ask about a TRL level, a readiness scale (MRL/IRL), identifying CTEs, a TRA step, a TRA characteristic, or building a TMP.
  • With a chapter — ask for ch02 (TRL scale), ch03 (CTEs), ch04 (five-step process), ch05 (four characteristics), ch06 (TMPs).

Supporting files: glossary.md, patterns.md, cheatsheet.md.

Core Frameworks & Mental Models

What a TRA is (and isn't)

A Technology Readiness Assessment (TRA) is a systematic, evidence-based evaluation of the maturity of critical technologies. It produces a snapshot of readiness at a point in time, expressed in Technology Readiness Levels. It is a risk-identification tool, not a pass/fail gate and not a guarantee of program success: a high TRL reduces — but does not eliminate — technology risk. A TRA informs decisions; it does not make them.

Technology Readiness Levels (TRL 1–9)

The nine-level maturity scale (originated by NASA, adopted across government):

TRLMeaningEnvironment
1Basic principles observed and reported—
2Technology concept and/or application formulated—
3Analytical/experimental proof-of-conceptLaboratory
4Component/breadboard validatedLaboratory
5Component/breadboard validatedRelevant environment
6System/subsystem model or prototype demonstratedRelevant environment
7System prototype demonstratedOperational environment
8Actual system completed and qualified through test & demonstrationOperational
9Actual system proven through successful mission operationsOperational

The decisive jumps are lab → relevant environment (TRL 4→5/6) and relevant → operational environment (TRL 6→7). Many programs over-rate TRLs by demonstrating in a less representative environment than they claim. Related scales: Manufacturing Readiness Levels (MRL) for producibility and Integration Readiness Levels (IRL) for how well elements work together — readiness is more than a single TRL number.

Critical Technology Elements (CTEs)

A technology is a CTE if it is new or novel, or used in a new or novel way, and is needed for the system to meet its operational performance requirements within cost and schedule. The TRA assesses CTEs, not every technology — so identifying CTEs correctly is the highest-leverage step: miss a CTE and the program carries unassessed risk; over-include and the TRA drowns in noise. CTE identification should be driven by the work breakdown structure and requirements, with independent review.

The Five-Step TRA Process

A high-quality TRA follows five steps:

  1. Prepare the TRA plan and select the assessment team — scope, schedule, methodology, and an independent, credible, expert team.
  2. Identify the Critical Technology Elements (CTEs) — using the WBS/requirements and the "new/novel + needed" test.
  3. Assess the CTEs' readiness — gather and evaluate evidence to assign a TRL to each CTE against defined criteria and environments.
  4. Prepare the TRA report — document the CTEs, evidence, TRLs, assumptions, and limitations.
  5. Use the TRA results — feed maturity findings into program decisions and, for immature CTEs, into a Technology Maturation Plan.

(Appendix II of the Guide provides "key questions" auditors use to judge how well a program followed these five steps.)

The Four Characteristics of a Reliable TRA

GAO judges TRA quality against four characteristics — a TRA is only as useful as it is reliable:

  • Comprehensive — all CTEs identified; readiness assessed against complete, defined criteria and the correct environment.
  • Well-documented — evidence, assumptions, methods, and TRL rationale captured so the assessment can be traced and repeated.
  • Credible — performed by qualified, independent assessors; evidence is sufficient and objective.
  • Defensible — conclusions follow from the evidence and withstand independent scrutiny and oversight.

Technology Maturation Plan (TMP)

When a CTE is immature (below the TRL needed for the upcoming decision), the program responds with a Technology Maturation Plan: the steps, resources, schedule, and level of effort to raise the CTE to the required TRL, plus alternatives/off-ramps if it cannot mature in time. The TMP turns a TRA finding into managed action.

Knowledge-Based Acquisition

The reason TRAs matter: knowledge-based acquisition holds that major investment decisions should be made only when the requisite knowledge (including technology maturity) is in hand. Demonstrating CTEs at TRL 7 (operational environment) before committing to product development is the best-practice maturity threshold; starting development with immature CTEs is a leading, well-documented cause of cost growth and schedule slip.


Chapter Index

#SectionKey content
ch01TRA FundamentalsWhat a TRA is/isn't, why technology maturity matters, the snapshot/risk-tool nature, audience (developers, PMs, oversight, auditors), relationship to acquisition decisions
ch02Technology Readiness LevelsTRL 1–9 definitions, lab/relevant/operational environments, the decisive transitions, hardware vs. software TRLs, related scales (MRL, IRL), common over-rating pitfalls
ch03Critical Technology ElementsThe CTE definition ("new/novel + needed"), identifying CTEs from the WBS/requirements, why CTE selection is highest-leverage, independent review, common omissions
ch04The Five-Step TRA ProcessPlan & team selection, identify CTEs, assess readiness, report, use results; Appendix II key questions; roles and independence
ch05Four Characteristics of a Reliable TRAComprehensive, well-documented, credible, defensible — what each means, the evidence each requires, and how a weak TRA fails each
ch06Technology Maturation PlansResponding to immature CTEs, TMP content (steps/resources/schedule/off-ramps), maturing to the required TRL, linking TMP to risk management
ch07Using TRAs in DecisionsKnowledge-based acquisition, TRL thresholds at milestones (TRL 6/7), TRAs in governance/oversight, pitfalls (calendar-driven, optimistic, non-independent assessments)

Topic Index

  • TRA — definition, purpose, snapshot/risk nature → ch01
  • Audience / who uses a TRA → ch01
  • Technology Readiness Levels (TRL 1–9) → ch02, cheatsheet
  • Environments (lab / relevant / operational) → ch02, cheatsheet
  • Hardware vs. software TRLs → ch02
  • Manufacturing Readiness Levels (MRL) / Integration Readiness Levels (IRL) → ch02
  • TRL over-rating pitfalls → ch02, ch07
  • Critical Technology Elements (CTEs) — definition & identification → ch03, cheatsheet
  • Work breakdown structure / requirements as CTE source → ch03
  • Five-step TRA process → ch04, cheatsheet
  • Assessment team / independence → ch04, ch05
  • Appendix II key questions → ch04
  • Four characteristics (comprehensive / well-documented / credible / defensible) → ch05, cheatsheet
  • TRA report → ch04, ch05
  • Technology Maturation Plan (TMP) → ch06, cheatsheet
  • Immature technology / off-ramps → ch06, ch07
  • Knowledge-based acquisition → ch07, ch01
  • TRL thresholds at milestones (TRL 6/7) → ch07, cheatsheet
  • TRAs in governance / oversight / audit → ch07, ch01
  • Pitfalls (calendar-driven, optimistic, non-independent) → ch07

Supporting Files

  • glossary.md — key TRA terms (TRL, CTE, TMP, MRL/IRL, the four characteristics, environments), alphabetical, with chapter references
  • patterns.md — reusable patterns (identifying CTEs, assigning a defensible TRL, running an independent assessment, building a TMP, judging an existing TRA) with When/How/Trade-offs
  • cheatsheet.md — TRL table, environment cues, CTE test, five steps, four characteristics, milestone TRL thresholds, tells & smells

Scope & Limits

Covers: GAO best practices for technology readiness assessment per GAO-20-48G — what a TRA is and why technology maturity matters; the TRL 1–9 scale and the lab/relevant/operational environments; related readiness scales (MRL, IRL); identifying Critical Technology Elements; the five-step process for conducting a high-quality TRA; the four characteristics of a reliable TRA (comprehensive, well-documented, credible, defensible); Technology Maturation Plans for immature technology; and using TRA results in knowledge-based, milestone decisions.

Does not cover in depth: the full systems-engineering process (see dau-se-guidebook, nasa-se-handbook, nasa-npr-7123); cost estimating (see a cost-estimating source / GAO-20-195G); schedule assessment (see the GAO Schedule Assessment Guide); agile adoption (see the GAO Agile Assessment Guide); detailed agency-specific TRA procedures (DoD/DOE/NASA have their own implementing guidance); and the engineering of any specific technology domain.

Jurisdiction: US Government public domain work (GAO). Best practices are cross-government and adoptable by any organisation; they are guidance, not binding requirements outside an agency that adopts them.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Signpost (not a knowledge pack) for the automotive standards landscape: ISO 26262, ASPICE, SAE J3016, UNECE R155, UNECE R156, and the NHTSA vehicle set. Contains NO source content: designation, edition, owner, status, and an official catalogue URL only. Use when you need to identify or locate an automotive standard. Most are paywalled or carry no redistribution grant and cannot be packaged; the one open path is the nhtsa-vehicle pack.

日本語の概要は準備中です。原文の説明を表示しています。

jgsystemsconsulting/jgs-se-knowledge-packs82026年10月9日 更新

cisa-cpg

無料

Knowledge base from CISA Cross-Sector Cybersecurity Performance Goals 2.0. Use for prioritized IT/OT baseline cyber goals aligned to NIST CSF 2.0 (including GOVERN), critical-infrastructure hygiene, MSP/supply-chain expectations, and board-friendly outcome language. Covers CPG 2.0 goals only; does not replace full CSF programs, sector-specific goals (SSGs), or CSET tooling detail.

日本語の概要は準備中です。原文の説明を表示しています。

jgsystemsconsulting/jgs-se-knowledge-packs82026年10月9日 更新

Knowledge base from DAFMAN 63-119 (15 April 2021), Mission-Oriented Test Readiness Certification. Use for continuous MOTRC replacing single-point OTRR thinking: framework/applicability, Certification Official vs PM roles, review cycle and exit criteria, certification memo/decertify gates, DT&E/contractor evidence, ITT integration and cyber resiliency, and the 31-template matrix. DAF T&E readiness process only—does not replace DoDI 5000.89, AFI 99-103, or multi-service lead policies.

日本語の概要は準備中です。原文の説明を表示しています。

jgsystemsconsulting/jgs-se-knowledge-packs82026年10月9日 更新

Knowledge base from the DoD Systems Engineering Guidebook (OUSD R&E, February 2022). Use for the DoD SE process model — the 16 SE processes (8 technical management + 8 technical) mapped to ISO/IEC/IEEE 15288, the event-driven technical reviews and audits across the Major Capability Acquisition life cycle (ASR, SRR, SFR, PDR, CDR, SVR/FCA, PRR, PCA), the Systems Engineering Plan (SEP), risk/issue/opportunity management, TPMs and leading indicators, system-of-systems and digital engineering, and the 24 design considerations (RAM, system safety, HSI, system security engineering, MOSA, supportability, etc.). Acquisition-program oriented: thin on detailed cost estimating, contracting law, and non-DoD or commercial life cycles.

日本語の概要は準備中です。原文の説明を表示しています。

jgsystemsconsulting/jgs-se-knowledge-packs82026年10月9日 更新

Knowledge pack from 'Towards Digital Engineering: The Advent of Digital Systems Engineering' (Huang et al., Old Dominion University, arXiv:2002.11672, 2020). Use when reasoning about digital engineering, the DoD Digital Engineering Strategy and its five goals, the Authoritative Source of Truth, digitalization vs. digitization, digital augmentation, digitalized models, provenance, unique identification, and the four-level (vision/strategy/action/foundation) DSE research framework. Covers the conceptual/vision layer of the field. SCOPE LIMITS: this is a single ~28-page vision paper, not a methods handbook — it is thin on step-by-step procedures, tooling, case studies, and quantitative evaluation, and it predates 2020 so it does not cover later digital-engineering standards or recent AI/LLM advances. Use the sebok pack for established SE canon and MBSE depth.

日本語の概要は準備中です。原文の説明を表示しています。

jgsystemsconsulting/jgs-se-knowledge-packs82026年10月9日 更新

Knowledge base from the DoD Digital Engineering Strategy (2018, OUSD/ODASD(SE)). Use for the Department of Defense's five digital engineering goals — (1) formalize the development, integration, and use of models; (2) provide an enduring authoritative source of truth; (3) incorporate technological innovation; (4) establish supporting infrastructure and environments; (5) transform the culture and workforce — plus their focus areas, the document-to-model and design-build-test→model-analyze-build shifts, model formalisms/provenance, governance and access control of the authoritative source of truth, and the coordinate→plan→pilot→sustain rollout. A vision-and-policy strategy, deliberately non-prescriptive. Does NOT provide a how-to method, tool tutorials, MBSE/SysML mechanics, or implementation-plan content; thin on metrics, acquisition-policy detail, and step-by-step procedure. Excludes the CAC-gated Digital Engineering Body of Knowledge (DEBoK).

日本語の概要は準備中です。原文の説明を表示しています。

jgsystemsconsulting/jgs-se-knowledge-packs82026年10月9日 更新

jgsystemsconsulting のスキルをすべて見る

このスキルの問題を報告する