「documentation」の検索結果

Knowledge base from MIL-STD-40051-2C (15 Dec 2015), Preparation of Digital Technical Information for Page-Based Technical Manuals. Use for TM/TDP structure, work packages, front/back matter, style/format, warnings/HAZMAT, change packages, content selection matrices, and plate exemplars. Primary Training & Documentation pack (cluster 25) with Ops & Maintenance procedure use—page-based (-2C) only, not IETM 40051-1.

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

Knowledge base from the FAA Human Factors Design Standard (HF-STD-001B, 2016) — the FAA's consolidated human-factors / human-systems-integration design criteria for systems it manages, operates, or maintains. Use for requirement-level design rules on: general human-factors design principles; automation and function allocation; designing equipment for maintenance; displays, controls, and visual indicators; alarms, audio, and voice communications; the computer-human interface (information presentation, coding, interaction styles, windows, dialogue); keyboards, input devices, and workstation/workplace ergonomics; system security, personnel safety, environment, anthropometry, and user documentation; plus intended-use and tailoring guidance. It is a quantified, source-attributed synthesis (heavily citing MIL-STD-1472G, MIL-HDBK-759C, DOD-HFDG-ATCCS, NUREG-0700, NASA-STD-3000, ANSI, OSHA, ISO 9241). Complements nasa-hsi as a parallel HSI tradition from the civil-aviation domain. Scope limits: it is design criteria, NOT an HSI lifecycle/process model (use nasa-hsi, nasa-npr-7123, or dau-se-guidebook for process); it does NOT reproduce the third-party standards it cites; it is FAA-acquisition-oriented (ATC, towers, TRACONs, airway facilities), not a general consumer-UX guide; and it is thin on modern touchscreen/mobile, web, and AI-driven interface patterns and on quantitative human-reliability analysis.

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

Knowledge base from FAA-STD-025f (Preparation of Interface Documentation). Use for IRD/ICD family definitions, common format and content, IRD shall-requirements, ICD design characteristics, verification/VRTM, and CM/revision/approval of FAA Enterprise Subsystem interfaces. Covers rev F preparation rules only; does not replace FAA-STD-005 drawing/spec prep, Order 1800.66 full CM procedures, or non-FAA interface standards.

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

Knowledge base from the NASA Schedule Management Handbook (2024 edition, Revision 2). Use for program/project schedule management of aerospace and large engineering efforts: the five sub-functions (Planning, Development, Assessment & Analysis, Maintenance & Control, Documentation & Communication); the Integrated Master Schedule (IMS) and the WBS/OBS/CBS breakdown structures; the Schedule Management Plan (SMP) and Basis of Estimate (BoE); Critical Path Method, logic, durations, float and margin; tiered schedule assessment (Requirements/Health/Basis checks, the Shock Test) and the Dimensions of Schedule Reliability; Schedule Risk Analysis (SRA), Integrated Cost-Schedule Risk Analysis (ICSRA), Monte Carlo, correlation, merge bias, and the Joint Confidence Level (JCL); baselining, replan vs. rebaseline, EVM schedule metrics (SPI, BEI, CEI, HMI, Earned Schedule, CPLI), and status/progress/forecast reporting. This is NASA's scheduling doctrine grounded in NPR 7120.5 and the GAO Schedule Assessment Guide. Thin on the underlying mechanics of CPM, statistics, and EVM (it points to companion handbooks); aerospace/space-flight-centric; anchored to the 2024 second edition.

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

GitHub リポジトリを安全に作成、公開、リリース、監査、保守するためのプロトコル。ローカルルールとロックの確認、最初の git add 前の .gitignore 作成、プライバシーチェックの実行、README/i18n/バナー/メタデータの準備、リリースタグおよび GitHub releases の検証、組織プロファイル、llms.txt ファイル、レジストリリンクの更新を行います。

Протокол для безопасного создания, публикации, релиза, аудита и обслуживания репозиториев GitHub: проверка локальных правил и блокировок, создание .gitignore перед первым git add, проверка конфиденциальности, подготовка README/i18n/баннера/метаданных, проверка тегов релиза и релизов GitHub, а также обновление профилей организаций, файлов llms.txt и ссылок в реестрах.

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

安全创建、发布、Release、审计和维护 GitHub 仓库的规范协议：检查本地规则与锁文件，在首次 git add 前创建 .gitignore，运行隐私检查，准备 README/i18n/Banner/元数据，验证 release 标签与 GitHub releases，并更新组织 Profile、llms.txt 文件及注册表链接。

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

Protocolo para crear, publicar, lanzar, auditar y mantener repositorios de GitHub de forma segura: verificar reglas locales y bloqueos, crear .gitignore antes del primer git add, realizar verificaciones de privacidad, preparar README/i18n/banner/metadatos, verificar etiquetas de release y lanzamientos de GitHub, y actualizar perfiles de organización, archivos llms.txt y enlaces a registros.

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

Regelmäßiger Pflegedurchlauf für ein bereits veröffentlichtes GitHub-Repository (Stufe 1, günstig und oft wiederholbar): zuerst alle Distributionsflächen des Projekts ermitteln (npm, PyPI, Registries, Marketplaces, Stores, Website) und Änderungen später dorthin spiegeln, dann Topics setzen, Privacy-Gate, Dokumente auf Veröffentlichungsabsicht prüfen und interne Planungsdateien nachträglich ignorieren, Banner ergänzen, Aussagen im README gegen den echten Code-Stand abgleichen, Darstellung verbessern, Sprachfassungen der README vervollständigen, Sichtbarkeitsmaßnahmen umsetzen, Eintrag auf der Organisationsseite prüfen sowie offene Issues und Pull Requests abarbeiten. Nutze diesen Skill, wenn ein bestehendes Repo gepflegt, aufgeräumt, aktualisiert, aufgehübscht oder "mal wieder durchgesehen" werden soll, wenn ein Repo veraltet oder unaufgeräumt wirkt, bei Formulierungen wie "Repo-Pflege", "after care", "Nachpflege", "Repo auf Stand bringen", "aufräumen und pushen" oder bei rotierenden Qualitätsrunden über mehrere Repos. Für die tiefe Runde inkl. Rechtscheck und orga-übergreifenden Querverweisen stattdessen full-after-care nutzen; für die Erstveröffentlichung github-repo-care.

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

Protocol for safely creating, publishing, releasing, auditing, and maintaining GitHub repositories: check local rules and locks, create .gitignore before the first add, run privacy checks, prepare README/i18n/banner/metadata, verify release tags and GitHub releases, and update organization profiles, llms.txt files, and registry links.

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

Tiefe Pflegerunde für ein veröffentlichtes GitHub-Repository (Stufe 2): enthält den vollständigen surface-after-care-Durchlauf und ergänzt ihn um drei teure Schritte — rechtliche Ersteinschätzung über die Law-Checker mit Wiedervorlage nach einem Jahr (Gutachten bleibt gitignored im Repo), Querverweise zu verwandten Repos über ALLE Organisationen hinweg sowie das Nachziehen aller Sprachen auf App-Ebene, nicht nur in der Doku. Nutze diesen Skill bei "full after care", "deep after care", "tiefe Repo-Pflege", "große Runde", "Repo grundlegend durchgehen", wenn ein Repo länger nicht geprüft wurde, vor größeren Releases oder wenn rechtliche Relevanz, Querverweise oder Mehrsprachigkeit ausdrücklich Thema sind. Für die günstige, oft wiederholte Runde stattdessen surface-after-care; für die Erstveröffentlichung github-repo-care.

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

Einmaliger Tasksolver+Writer+Maintainer-Durchlauf fuer den Projektordner, in dem die Session gerade sowieso gearbeitet hat (inkl. Unterordner) — kein systemweiter Sweep. Loest offene triviale/autonome Register-Punkte, aktualisiert Dokumentation auf den gemessenen Ist-Stand (im Projekt UND in der Root der Pipeline, in der das Projekt liegt) und raeumt Strays/Temp- Dateien nach dem Papierkorb-Prinzip weg. Nutze diesen Skill bei /tidy-up, "raeum das Projekt auf", "mach hier sauber bevor wir weitermachen", am Ende einer Arbeitssitzung an einem Projekt, oder als faellige autonome Aufgabe innerhalb von /work-autonomous + /goal.

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

Builds a DRAFT data dictionary from a schema export, table definition, sample rows or a partial existing dictionary: one row per field with the name as stated, type as stated or observed, meaning quoted from the documentation supplied, owner, allowed values, and UNKNOWN wherever no source defines the field, plus a gap list for the data owner. Never infers a definition from a column name. Use when the user asks to "build a data dictionary for this table", "document these columns", "what does each field mean", "turn this schema export into a dictionary" or "fill in the field definitions from these documents". Do not use for profiling values or finding patterns in the data, use dataset-insight-pack instead; for metric definitions, use kpi-definition-sheet; for logging data defects, use data-quality-issue-log. Drafts for human review; never approves, authorises or signs off.

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

Find the answer in the SuperCollider documentation that ships with the install instead of guessing - what sc_help's search, answer, class and index actions return, what the .schelp tree looks like (over a thousand files: Classes, Guides, Reference, Overviews), how to read a class page for its argument names, and where the server's OSC commands are written down.

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

Review translated documentation for content fidelity — detect injected, off-topic, or unauthorized content by comparing against the English source. Use when reviewing translation PRs or translated docs.

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

Create, update, fix, or refine documentation using Diataxis framework and BMad Method style guide. Use when user asks to 'create a doc', 'update docs', 'fix docs style', 'refine docs', or 'improve docs writing'.

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

Fetch up-to-date library, framework, and SDK documentation via Context7's search and docs endpoints. Use when the user asks about a library/API (React, Next.js, Prisma, Supabase, Tailwind, Django, Vue, etc.) and you need current docs, not Claude's training-time knowledge. Skip this skill for generic programming questions that don't require library-specific docs.

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

Discover and execute specialized skills from a curated marketplace catalog on GitHub, fetched on-demand and run ephemerally (no permanent installation). The catalog covers a broad and growing range — document generation (PDF/Word/Excel/PowerPoint), visual design, presentations, web app testing, animated GIFs, dev tooling (MCP scaffolding, frontend components), creative outputs (algorithmic art), technical documentation lookup (library/API/framework references), and more. Consult this skill whenever the user asks for a capability that could plausibly be covered by a community skill — the catalog is the source of truth, not this description.

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

Use when locating TBQ3 documentation, function references, examples, or source docs under docs without loading the full corpus; supports rg-based search and curated topic/function indexes.

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

Use when reviewing, debugging, or improving TBQ3/TB language code for trading correctness, Bar strategy behavior, order direction, position state, sizing, costs, backtest realism, event timing, multi-symbol logic, or function documentation consistency.

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

Document completed work — update task log, sync documentation, log observations. Use after finishing a task or batch of changes.

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

Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design.

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

Builds production-ready REST API endpoints with validation, error handling, authentication, and documentation. Follows best practices for security and scalability.

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

Master API documentation with OpenAPI 3.1, AI-powered tools, and modern developer experience practices. Create interactive docs, generate SDKs, and build comprehensive developer portals.

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