「criteria」の検索結果

Design and write QA test artifacts - test cases, test plans, acceptance criteria, API test specs, and PR testability reviews. Use this skill whenever a QA engineer or SDET needs to translate requirements, user stories, or feature specs into structured test documentation. Trigger on phrases like "write test cases", "create a test plan", "define acceptance criteria", "review this PR for testability", "write API test specs", "test coverage for this feature", "what should we test", "how do we test this", or any request to structure what and how to test before execution begins. Also trigger when a developer asks "is this testable?" or a PM asks "what are the edge cases?".

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

Write user stories with acceptance criteria. Use when the user says "write user stories", "convert this to stories", "create acceptance criteria", "break this into tickets", "story map", "walking skeleton", "story for this feature", or wants to translate a feature idea into sprint-ready items - even if they don't explicitly say "user stories".

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

Generate a User Acceptance Testing plan with scenarios and sign-off criteria. Use when the user says "UAT plan", "acceptance testing", "user testing plan", "how do we test this with users", "test scenarios for business validation", "sign-off criteria", "go/no-go for release", "acceptance test cases", "validate with stakeholders" - even if they don't explicitly say "UAT".

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

Use when access must reach past the record owner's role hierarchy. Trigger keywords: sharing rule, criteria-based sharing rule, owner-based sharing rule, sharing rule recalculation, guest user sharing rule, share with a public group, SharingRules metadata. NOT for org-wide defaults - use admin/sharing-and-visibility. NOT for programmatic shares - use apex/apex-managed-sharing. NOT for subtracting access - use admin/restriction-rules.

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

Requirements for a Salesforce Enterprise Territory Management (ETM) territory design: alignment criteria, coverage model selection, assignment rule logic, hierarchy depth and breadth, and user-to-territory ratios. Trigger keywords: territory design, territory alignment, territory model requirements, sales coverage model, territory criteria, geographic territory, named account territory, overlay territory. NOT for ETM setup steps — use admin/enterprise-territory-management. NOT for loading territory assignment data — use data/territory-data-alignment. Trigger keywords: territory design questionnaire, territory requirements document, assignment rule matrix, territory type priority, realignment plan, territory access level decision, accountAccessLevel, opportunityAccessLevel, ObjectTerritory2Association, UserTerritory2Association, Planning state model, territory acceptance tests.

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

Use this skill when designing the human-executable UAT test cases that prove a Salesforce feature works for a specific persona — the per-persona scripts with preconditions, data setup, permission setup, ordered steps, and pass/fail evidence that close out an RTM row. Trigger keywords: UAT test case salesforce, user acceptance test script salesforce, manual test salesforce feature, UAT script per persona, UAT precondition data setup, UAT permission set assignment for testing, negative path UAT case. NOT for high-level UAT planning, defect classification, regression strategy, or sign-off (use admin/uat-and-acceptance-criteria). NOT for the Given/When/Then technique used to write the AC the case is derived from (use admin/acceptance-criteria-given-when-then). NOT for Apex test method generation (use agents/test-class-generator). NOT for test data factory patterns (use templates/apex/tests/TestDataFactory.cls). NOT for performance or load testing.

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

Use when writing or auditing the conversational copy layer of a Salesforce bot or Agentforce agent: utterance authoring strategy, fallback message copy, escalation-criteria phrasing, and persona-consistent dialog scripting across channels. NOT for designing the bot dialog structure, intent model, or handoff architecture — use architect/einstein-bot-architecture. NOT for encoding agent tone in Agentforce system instructions — use agentforce/agentforce-persona-design.

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

Verify ticket completion criteria — use when finishing a ticket, before marking work done, or checking acceptance criteria. Runs tests, build, lint, scenarios, and dependency drift checks.

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

Use when negotiating a file-based sprint contract between the generator (developer) and evaluator before code is written. Translates a product-level spec into testable acceptance criteria with rubric tie-ins. Triggers on /mk:sprint-contract, "draft a sprint contract", "negotiate scope for sprint", or before any harness-driven sprint kicks off.

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

Validates an approved plan against 8 dimensions before Phase 3 begins. Catches incomplete acceptance criteria, missing dependencies, and unresolved risks. Use after Gate 1 approval and before Phase 2 (Test). Produces a validation report with pass/fail per dimension.

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

Use when loading, listing, composing, or validating graded evaluation rubrics — PASS/WARN/FAIL grading with weighted criteria and balanced PASS/FAIL anchor examples. Triggers on /mk:rubric, "load rubric", "compose rubric preset", "validate rubric", or evaluator-style code review that needs anchor-grounded judgments.

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

Test-to-requirement coverage mapping. Reads plan acceptance criteria and test files, produces a coverage gap report showing which requirements have no tests. Use during Phase 2 (Test) or Phase 4 (Review) to verify test completeness. Named after the Nyquist sampling theorem — sufficient test coverage prevents aliased (missed) requirements. NOT for running tests (see mk:testing); NOT for structural code review (see mk:review).

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

Filter and select sequences by criteria (length, ID, GC content, N content, motifs, patterns, description) using Biopython, streaming so large files never load into RAM. Use when subsetting a FASTA/FASTQ file, removing unwanted or low-quality records, or selecting records by specific criteria. Use the paired-end-fastq skill instead whenever the input is paired R1/R2 reads.

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

Agile product ownership for backlog management and sprint execution. Covers user story writing, acceptance criteria, sprint planning, and velocity tracking. Use when writing user stories, creating acceptance criteria, planning sprints, estimating story points, breaking down epics, or prioritizing the backlog.

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

Use when verifying a story or ticket implementation against its spec and acceptance criteria - per-AC verdicts with file:line evidence and proving tests, code reuse and design conformance, dead code, stale docs, comment discipline. Finds the spec from an explicit path, the ticket key in the branch name, or plan files - and asks rather than guessing. For defect-hunting code review use dotnet-techne-code-review instead. Keywords: story QA, acceptance criteria, spec conformance, AC coverage, definition of done, dead code check, reuse check, comment check, verify story, QA this branch.

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

Turn a wireframe and everything already agreed into a written spec in traditional agile shape — an initiative broken into epics, epics into user stories with acceptance criteria, and themes as the labels that span them — presented as an interactive drill-down tree the user prunes, edits and annotates in the browser, with a plain-markdown spec generated from it. Use when the user wants a spec, an initiative or epic broken into user stories, acceptance criteria, to formalise what a wireframe or mockup does, or to review and edit a spec visually.

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

Agile product ownership for backlog management and sprint execution. Covers user story writing, acceptance criteria, sprint planning, and velocity tracking. Use for writing user stories, creating acceptance criteria, planning sprints, estimating story points, breaking down epics, or prioritizing ...

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

採用・人材戦略の専門スキル。職務記述書（JD）作成、採用計画策定、コンピテンシーモデル設計、 面接評価基準設計、オンボーディング計画をサポート。採用要件の明確化から内定後のフォローまで 一貫した人材獲得プロセスを支援。日英両言語のテンプレートを提供し、グローバル採用にも対応。 Use when: creating job descriptions, designing competency models, planning recruitment strategies, developing interview evaluation criteria, or creating onboarding plans. Triggers: "JD作成", "採用計画", "面接評価", "オンボーディング", "コンピテンシー", "人材獲得", "job description", "recruitment plan", "interview evaluation", "hiring", "talent acquisition"

Internal audit support skill aligned with IIA (Institute of Internal Auditors) International Standards. Provides risk-based audit planning, audit program development, workpaper documentation, finding development (Condition/Criteria/Cause/Effect), and Corrective Action Request (CAR) tracking. Use when: planning annual/quarterly audits, creating risk assessment matrices, developing audit programs and test procedures, documenting audit workpapers, writing audit findings and reports, tracking corrective actions and follow-ups, preparing for external audits (SOX, ISO). Triggers: "internal audit", "audit plan", "audit program", "audit workpaper", "audit finding", "risk assessment", "CAR tracking", "corrective action", "IIA Standards", "COSO framework", "監査計画", "監査プログラム", "監査調書", "是正措置", "リスク評価".

Write acceptance criteria for a Jira story using Given/When/Then scenarios. Use this skill when the user asks to write AC, acceptance criteria, write scenarios, improve a story, add AC to a ticket, or mentions a Jira ticket and wants better requirements. Also triggers on "write better AC", "this story needs AC", "add scenarios to this ticket", or when reviewing a Jira story for completeness.

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

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 MIL-HDBK-516C (Airworthiness Certification Criteria). Use for DoD air-system airworthiness planning: tailoring a certification basis, systems engineering criteria, and domain clusters for structures, flight technology, propulsion/installation, avionics/electrical/E3/diagnostics, computer systems/software, and crew systems (including applicable UAS control-station elements). Qualitative guidance handbook — not raw contractual requirements. Does not replace service airworthiness authority policy, civil FAA certification rules as authorities, or detailed JSSG/MIL performance specs.

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

Turns a business need and its constraints into a DRAFT RFP requirements pack: traced functional and non-functional requirements with priorities, mandatory gates, evaluation criteria with weights left to the business owner, and fact-seeking supplier questions. Solution-neutral; never names a supplier or product. Use when the user asks to "write the RFP requirements", "turn this business case into tender requirements", "draft the supplier questionnaire", "structure our RFQ from this brief" or "set up evaluation criteria before we go to market". Do not use for responses already received, use rfp-comparison-pack to compare them or supplier-evaluation-matrix to score them instead. Drafts for human review; never approves, authorises or signs off.

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

ISTQB/JSTQB のテスト完了（test completion）活動のうち、テスト実行結果の評価と完了基準（exit criteria）判定を支援するスキル。テスト実行ログ（test-execution-log.md）と test-plan の完了基準を突き合わせ、完了とみなせるかを判定した test-summary-report.md を作る。テスト完了時の最終レポートにも、テスト途中の中間評価にも使える。「テスト結果をまとめて」「完了基準を満たしたか判定して」「テストレポートを書いて」「今どこまでテストが進んだか評価して」と依頼されたときに使う。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-report <テスト対象名> で明示的に呼び出されたときのみ使用する。