テスト・セキュリティのスキル

Knowledge base from the FAA System Safety Handbook (Dec 30, 2000). Use for system safety as a specialty within systems engineering: the five-step safety risk management process (mandated by FAA Order 8040.4 and the AMS), the severity-by-likelihood risk matrix and acceptance bands, the Safety Order of Precedence, system-description models (5M, SHEL(L)), the hazard-analysis activities (PHL/PHA/RHA/SSHA/SHA/O&SHA/HHA), integrated system hazard analysis, the analysis techniques (FTA, FMEA/FMECA, Fault Hazard, Common Cause, Sneak Circuit, Energy Trace), closed-loop hazard tracking (Safety Action Record), and the specialty domains the handbook covers — acquisition-lifecycle safety and contracting (OSA/CSA/SSPP/ISSPP), software safety (control-capability ranking, SHCM, DO-178B), test & evaluation safety, facilities safety, commercial launch safety (AST licensing, expected casualty, MPL/DAMP), system safety training, and Operational Risk Management (ORM) with human/organizational factors. Scope limits: this is a year-2000 FAA how-to; it predates the modern FAA/ICAO Safety Management System (SMS) and Just Culture regulatory frameworks, and many cited orders, advisory circulars, and launch-licensing rules have since been restructured. It is FAA/NAS-centric, leans on MIL-STD-882C, and does not define the SE life-cycle processes themselves (use nasa-npr-7123 / dau-se-guidebook) or reproduce third-party standard text (MIL-STD-882, DO-178B, ISO/IEC/IEEE).

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

Knowledge base from MIL-HDBK-338B (Electronic Reliability Design Handbook). Use for electronic reliability engineering: R/M/A theory, reliability specification/allocation/prediction, parts management and derating, reliable circuit and fault-tolerant design, environmental and human performance reliability, FMEA/FMECA/FTA/sneak circuit analysis, design reviews and testability, FRACAS, reliability demonstration and growth testing, and systems-level R&M parameters. Covers selected Part 2 design-guidance topics only; skips large annex/part-stress tables. Guidance handbook — not a contractual requirement text. Does not replace MIL-HDBK-217 prediction libraries, service-specific reliability regs, or safety standards (see mil-std-882).

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

Knowledge base from NASA Human Systems Integration (HSI) Practitioner's Guide (NASA/SP-2015-3709). Use for HSI process implementation, lifecycle phase activities, function allocation, ConOps development, HSI Plan writing, HSI metrics (MOE/MOP/TPM/KPP), HITL testing strategy, HSI team organisation, scaling/tailoring for program size, and V&V planning. Does not cover the specific human engineering design standards (NASA-STD-3001 content) or detailed HFE methods beyond what the guide itself provides.

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

Knowledge base from the GAO Cost Estimating and Assessment Guide (GAO-20-195G). Use for program cost estimating: the four characteristics of a reliable estimate (comprehensive, well documented, accurate, credible) and the 18 best practices; the 12-step cost estimating process (purpose, plan, technical baseline, WBS, ground rules and assumptions, data, point estimate, sensitivity, risk/uncertainty, document, present, update); estimating methods (analogy, parametric, engineering build-up, learning curves); Monte Carlo risk/uncertainty analysis, confidence levels and contingency; auditing and validating an estimate against the characteristics; earned value management (EIA-748, BCWS/BCWP/ACWP, CPI/SPI/TCPI, EAC, PMB, IBR); and specialized techniques (software cost estimating, learning curves, Analysis of Alternatives, WBS templates, the Green Book internal-control framework). This is the cost-estimating companion to the GAO Schedule and Technology Readiness Assessment guides. Does not cover schedule estimating/risk in depth (see the GAO Schedule Assessment Guide), agency-specific cost models, or the full text of referenced standards (EIA-748, MIL-STD-881D, the Green Book) — these are named, not reproduced.

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

Knowledge base from the DoD Manufacturing Readiness Level (MRL) Deskbook (Version 2022, OSD ManTech / Joint Service–Industry MRL Working Group). Use for assessing and managing manufacturing maturity and producibility risk in defense acquisition: the 10-level MRL scale and its non-linear, target-not-grade nature; the five demonstration environments (laboratory → production-relevant → production-representative → pilot line → production line); the nine manufacturing-risk threads and sub-threads; how MRL targets map onto Adaptive Acquisition Framework milestones (MRL 4/6/7/8/9); conducting an MRL Assessment; building a Manufacturing Maturation Plan; putting MRL maturity into contract language (Section L/M, SOW, AS6500A, DIDs); tailoring criteria for S&T, single-system, ship, sustainment, and industry contexts; and screening operational-technology cybersecurity. Manufacturing-readiness focused — it measures producibility risk and frames mitigation; it is NOT a technology-readiness (TRL) guide, a full systems-engineering process model, a cost-estimating or schedule guide, or a deep cybersecurity audit method (see sibling packs for those).

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

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.

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

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.

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

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).

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

Knowledge base from the OUSD(R&E) guidebook Implementing a MOSA in DoD Programs (Feb 2025). Use for the Modular Open Systems Approach as a DoD acquisition + design discipline: the statutory/regulatory basis (10 U.S.C. 4401–4403, FY2017/FY2021 NDAA, DFARS), the five OUSD(R&E) pillars, the plan→modularize→identify→define→standardize interface lifecycle, technical levers (WBS/MIL-STD-881F taxonomy, standards profiling, API-first software, COTS/cybersecurity), MOSA assessment metrics and tools (PART/OAAT/KOSS/SEAM/MAUT), technology-change and DMSMS management, roadmaps, MOSA across the six AAF pathways, and contracting/IP/data-rights mechanics. SCOPE LIMITS: this is U.S. DoD weapon-system acquisition policy, not a general open-architecture or interface-standards reference — it names standards (FACE, OMS, DISR) without reproducing them, is light on detailed engineering of any specific standard, and does not cover the underlying SE processes (use dau-se-guidebook / nasa-npr-7123) or general systems-engineering theory (use sebok).

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

Knowledge base from the DoD Test & Evaluation Enterprise Guidebook (OUSD R&E, August 2022). Use for DoD test and evaluation (T&E) across the Adaptive Acquisition Framework — the four test communities (contractor testing, developmental DT&E, operational OT&E, live-fire LFT&E); the five operational events (Operational Demonstration, EOA, OA, IOT&E, FOT&E) and the OTRR gate; the T&E Strategy / TEMP and its IDSK, with the upstream documents that feed it and the test plans that decompose it; the T&E organizations and oversight roles (USD(R&E), DOT&E, TRMC, the Service Executives and OTAs, the T&E WIPT, CDT); and pathway-specific T&E for all six acquisition pathways (Urgent Capability, Middle Tier, Major Capability, Software, Defense Business Systems). Statutory anchors include 10 U.S.C. §4171 (IOT&E) and §4172 (LFT&E/FUSL). This is guidance, not policy: it points outward to DoDI 5000.89 and the DoDI 5000-series for binding detail, and is thin on detailed test statistics/design-of-experiments methodology, cost estimating, the Acquisition of Services pathway, and any CUI/CAC-gated companion guides.

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

Design an auditable playbook when no narrower one fits: a large migration, an ambitious multi-part change, or work a human reviews after stepping away. Scales rigor to the task, runs a hypothesis loop, and logs decisions via show-me-your-work. Use for /figure-it-out, 'figure it out', a large migration, or when no narrower playbook applies.

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

Use for "interrogate", "adversarial review", "multi-model review", "challenge this", "stress test this code", "find blind spots", or "tear this apart". Multiple LLM reviewers challenge changes from independent angles.

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

Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.

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

Periodic pass that keeps a project's verification skill and feature map honest: parallel source readers per feature, one live session driving every feature, at most one PR of proven corrections. Use for /maintain-verification-skill or "audit the verify skill".

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

既存のパイプライン、個別プロジェクトフォルダ、ドキュメント構造、またはソフトウェアスタックを改善、改修、再構築するための構造化された6ステップのプロシージャ。「pipeline optimizer」（ソフトウェア、研究、ゲーム開発パイプラインなど、トピック全体のパイプライン対象）または「project-folder optimizer」（単一のソフトウェアツールや論文プロジェクトなど、パイプライン内の個別プロジェクトフォルダ対象）として呼び出し可能。「パイプラインXを改善する」、「スタックを最適化する」、「Yを再構築する」、「改修」、「パイプラインのリファクタリング」、「プロジェクトフォルダのクリーンアップ」、「フォルダ構造の改善」、「規約の統一」、「ドキュメントの統合」、「既存システムへの統合」、または確立された構造に対する実質的な介入タスクで起動。既存資産の調査、目的の明確化、理想像のスケッチ、ギャップ計画、経験的課題の特定、および新しいサブエージェントによる再テストを提供。並行標準の発生、重複、パイプラインの破綻を防止。

8フェーズの開発サイクル：機能リクエスト、現状確認、機能計画、フロントエンド、バックエンド計画、バックエンドコード、テスト、ユースケース。体系的なソフトウェア開発のための反復フレームワーク。

A relentless interview to sharpen a plan or design. Use when the user says "grill me", "grill mich", "grill mich zu diesem Plan", or explicitly invokes /grill-me. Does NOT fire on generic "review this", "poke holes", "stress-test", "devil's advocate" or "critique" phrasing -- for reviewing an already-written artifact (code, PR, paper) use code-review, 3agenten-review, 7phasen-review or caveman-review instead; grill-me interrogates a still-open plan or idea before it is built.

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

Parallel geführte Sprachfassungen eines Dokuments (Paper DE/EN, README + README_de, SKILL.md + SKILL.en.md, Website-Texte) synchron halten: fehlende Fassung nachziehen, Abschnitts-Parallelität prüfen, Divergenzen beheben — mit klarer Leitsprache-Regel und kontrolliertem Rücktransfer, wenn die Nebenfassung etwas besser löst. Nutze diesen Skill bei „sind DE und EN synchron?", „zieh die englische/deutsche Version nach", „Übersetzung ist veraltet", bei zweisprachigen Papers/READMEs/Skills, oder als periodischen Check über einen Dokumentbestand. Enthält auch das Expansions-Audit: bewerten, ob ein Projekt/Dokument WEITERE Sprachen verdient (i18n-Eignung nach Zielgruppe, technische Vorbereitung, kein blindes Massenübersetzen).

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

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrase -- including German ones such as "grill mich", "grill mich zu diesem Plan" or "zerpflück meinen Plan im Grill-Modus". Entry point for the /grill-me command; can also be invoked directly.

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

体系的な 6 段階デバッグプロトコル。クイックチェック、孤立テスト、20分ルール、バグレポートテンプレートを備えた構造化アプローチ。

Teststrategie-Berater für Softwareprojekte — wählt die richtigen Teststufen (Unit/Integration/System/Abnahme), Testarten (funktional, nicht-funktional, änderungsbezogen) und Testentwurfsverfahren (Äquivalenzklassen, Grenzwerte, Entscheidungstabellen, explorativ) für die jeweilige Situation und SDLC-/CI-Phase, inkl. Testpyramide, CI/CD-Gates, Shift-Left und Best Practices. Nutze diesen Skill IMMER, wenn Tests geschrieben, geplant, priorisiert oder bewertet werden sollen — bei "schreibe Tests", "Teststrategie", "Testplan", "Testkonzept", "was/wie soll ich testen", "welche Tests fehlen", "Testabdeckung verbessern", "QA aufsetzen", Fragen zu Regression/Smoke/Sanity/Last/Stress/Security-Tests oder beim Einrichten einer Test-Pipeline — auch wenn "Test" nur beiläufig fällt. Abgrenzung — für die TDD-Schleife selbst superpowers:test-driven-development, für Bug-Diagnose bugfix-protocol, für systematische Bug-Suche bugsweep nutzen.

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

Prüfungsvorbereitung, Selbsttests, Probeklausuren und systematische Fehleranalyse.

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

Interaktives Reißverschluss-Audit-Verfahren für eine Serie von Apps/Prüfobjekten: der User testet live und gibt kurzes Feedback im Chat, der Agent startet dabei bereits das nächste Objekt UND wertet parallel das Feedback des vorigen aus (strukturiert erfassen, Reparaturaufträge sofort an Worker delegieren) — statt sequenziell zu warten. Nutze diesen Skill bei "human-loop-audit", "lass uns die Apps im Reißverschluss durchtesten", "ich teste, du wertest aus und reparierst", oder wenn eine Reihe von GUIs/Produkten gemeinsam mit dem Nutzer durchgetestet werden soll und Befunde sofort in Reparaturen münden sollen. Abschluss ist eine strukturierte Befundliste je Objekt (Funktioniert/Defekt/Wunsch) plus die Liste der bereits gestarteten Reparaturen.

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

Systematic 6-phase debugging protocol. Structured approach to bugs with quick checks, isolated testing, 20-minute rule, and bug report template.

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