SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsbkn-requirement

bkn-requirement

Writing & research

View repository

Updated 10-15 23:48

About this skill

BKN Requirement

Objectives

Use this Skill before formal BKN modeling. It is responsible for transforming customer background, research objectives, meeting minutes, PRDs, or business materials into a standard PRD that can be reviewed by business experts, used by product/delivery teams, followed up on by AI engineers, and handed off to bkn-creator to continue modeling.

Current version:V0.7. The main thread of V0.7 is the "Requirements Discovery Agentic Harness": generate a short research outline before the meeting, read AI meeting minutes after the meeting, and continuously iterate the requirements document based on the previous version of the PRD; the formal PRD, PRD iterations, and BKN_Creator handoff summaries must go through the closed loop of Generate → Verify → Revise → Final Gate, and retain internal check findings and revision summaries. BKN elements are only used for backend checks and BKN_Creator handoff summaries.

This Skill does not generate .bkn files, does not bind to data sources or platform data views, does not push knowledge networks, and does not execute platform operations. These are the downstream responsibilities of bkn-creator and kweaver-core .

Applicable Scenarios

Use this Skill when the user needs to complete the following tasks:

  • Prepare a brief business research outline based on customer name, industry, department, visit objectives, or rough direction;
  • Generate pre-meeting research references, suggested participant roles, and a material request list based on customer background and existing materials;
  • Organize requirements from interview minutes, audio transcriptions, PRDs, BRDs, process descriptions, system screenshots, data dictionaries, or rough ideas;
  • Extract this round's research updates, pending confirmation questions, and PRD impacts from AI meeting minutes such as Doubao, Feishu, and Tencent Meeting;
  • Generate a new version of the PRD based on "this round's research outline / research objectives + meeting minutes and related materials + previous version of the PRD";
  • Help AI engineers converse with business experts to clarify business scenarios, processes, rules, systems, data, inputs and outputs, and acceptance examples;
  • Restructure technical, modeling-oriented, or POC-oriented materials into a standard PRD that business users can review;
  • Assess whether a business scenario already meets the conditions for subsequent BKN modeling;
  • Generate business acceptance test cases, pending confirmation questions, and BKN_Creator handoff summaries.

If the user already has confirmed modeling requirements and explicitly requests to create, update, validate, bind, test, or push a BKN, hand off to bkn-creator。

Core Principles

Use business language by default. Business users usually express processes, rules, standards, forms, systems, data, inputs, outputs, objectives, approvals, and exceptions; do not require business users to first understand objects, relationships, metrics, operators, action types, or Skills.

The overall BKN methodology framework of this Skill is references/bkn-methodology.md. When it involves objects, fact attributes, relationships, metrics, operators, actions, governance, the Agent / Skill application layer, and validation criteria, use that file as the unified boundary;references/bkn-requirement-ontology-discovery.md is only a business-oriented tailoring and example set for the requirements discovery stage.

The ../common/bkn-methodology.md in the repository is the common source methodology; to support npx skills add ... --skill bkn-requirement single-Skill distribution and installation,references/bkn-methodology.md is the distribution snapshot packaged with this Skill. When the two are inconsistent, the installed runtime shall be governed by the references/bkn-methodology.md within this Skill, and during maintenance, common should be updated first, then the snapshot synchronized.

The main line of the requirements discovery lifecycle is:

Intake → Research Plan → Interview → Meeting Digest
→ PRD Iteration → Readiness Gate → BKN_Creator Handoff

The main line of formal output execution is:

Archive / Context → Generator → Verifier → Reviser（如有必要）
→ Final Gate → Final Output

For the execution protocol, see references/agentic-harness.md。prd_mode、prd_iteration_mode and handoff_mode must execute the complete Harness;research_plan_mode、meeting_digest_mode and review_mode may execute the lightweight Harness;intake_mode output only the minimum clarification questions.

The intermediate artifacts of the Harness include candidate results,verification_findings, revision summaries, and Final Gate conclusions. Unless the user explicitly requests it, these internal artifacts are not written verbatim into the main body of the PRD, but they must be used to determine whether Ready can be output. If this round will persist a formal PRD, PRD iteration, or handoff in the project directory, a same-named *-verification-findings.md。

BKN elements serve three types of purposes:

  1. as a backend dimension for the AI engineer to check PRD completeness;
  2. as clues when questioning business experts;
  3. as a summary handed off to bkn-creator , not as the main narrative of the PRD.

Core Process

First determine which stage of the requirements discovery lifecycle the input is in. Do not force fragmented background, visit preparation, or meeting minutes into a complete PRD.

Input State Default Mode Output
Only customer name, industry, department, visit purpose, or rough direction intake_mode minimum clarification questions, research prerequisites
Preparing to visit a customer, with a small amount of background material research_plan_mode short on-site customer outline, meeting objectives, suggested attendee roles, material request checklist
Input AI meeting minutes, audio transcription, or interview summary meeting_digest_mode new facts, assumptions, conflicts, scenarios, rules, system data, and questions to be confirmed in this round
Input research outline, meeting minutes and related materials, previous version of the PRD prd_iteration_mode a new version of the PRD, revision summary, version record, maturity changes, next round of follow-up questions
Existing business materials, PRD, or BRD, and the user requests "organize requirements / standardize PRD / rewrite PRD / output formal document" prd_mode business scenario-centered PRD, with quality summary, questions to be confirmed, and BKN_Creator handoff summary
Existing PRD / BRD, and the user explicitly requests "evaluate / review / check / whether it can enter BKN_Creator" review_mode quality score, gap list, rewrite suggestions
PRD has been confirmed and downstream modeling handoff is needed handoff_mode bkn_creator_handoff

Project Directory and Naming Conventions

Each customer or project must have an independent project folder to avoid mixing materials from multiple projects. The default directory is uniformly:

docs/prj-<客户或项目简称>/

Uniformly use docs/prj-<项目>/. This shared project directory can carry requirements discovery, PRD, validation output,BKN_Creator handoff summary, optional ontology modeling scheme, and subsequent BKN delivery reference.

If the user does not provide a project directory, you should first suggest creating a project directory, then output file name suggestions. Do not mix research outlines, meeting minutes, PRDs, and validation outputs from different customers in the general docs/ root directory.

File naming rules:

Document Type Naming Format
Research Outline / Research Reference <项目名>-调研大纲.md or <项目名>-第X轮调研大纲.md
Meeting Minutes / Research Memo YYYYMMDD-<项目名>-第X轮现场交流调研备忘.md
Validation Output / meeting digest <项目名>-prd-第X轮验证输出.md
PRD Document <项目名>-PRD vX.Y.md

Each round of input materials should be archived to:

docs/prj-<客户或项目简称>/inputs/round-XX/

Recommended naming:

Input Type Naming Format
Research Outline YYYYMMDD-<项目名>-第X轮-input-调研大纲.md
Meeting Minutes / Recording Transcript YYYYMMDD-<项目名>-第X轮-input-会议纪要.md
Customer Supplementary Materials YYYYMMDD-<项目名>-第X轮-input-客户材料-<材料名>.<ext>
Previous PRD Reference Do not duplicate; register the version and path in the source manifest

Do not move the user's original files. If the input file specified by the user is not within the project folder, it must first be copied into this round's inputs/round-XX/ as project evidence material; if the input file is already within the project folder, it may not be copied, but the path must be recorded in the output document and source-manifest.md .

Each round of processing should generate or update:

docs/prj-<客户或项目简称>/inputs/round-XX/source-manifest.md

source-manifest.md Record this round's original path, archive path, material type, purpose, processing time, and usage method. For the template, see assets/source-manifest-template.md。

Input archiving is a prerequisite step before generating verification output or a PRD:

  1. First create inputs/round-XX/；
  2. Then copy external input files, or register existing input files within the project;
  3. Then check whether all source-manifest.md in 是否复制=是 or copied_to_project=true of 归档路径 / archived_path actually exist;
  4. Only after the check passes may "copied" be written in the manifest;
  5. If copying fails, permissions are insufficient, or the path is inaccessible, the archive status must not be falsified. "Copied=No" must be written, the reason for failure recorded, and "Input archiving incomplete" marked at the beginning of the final output.

After the first round, there are two output paths:

  • Information is insufficient to form a PRD: output <项目名>-prd-第1轮验证输出.md, used to determine gaps and the focus of the next round of research.
  • Information is sufficient to form an initial PRD: output <项目名>-PRD v0.1.md, and mark Draft, maturity, and unconfirmed items.

Automatic Project Context Recognition

When the user provides only the project directory, adopt the default behavior of being lenient in intake and strict in output: first automatically identify the latest project context, then select the mode based on the user's intent. Do not stop just because the user has not manually listed all input files.

Automatic recognition order:

  1. Identify the latest PRD: prioritize selecting the <项目名>-PRD vX.Y.md；
  2. Identify the latest verification output: prioritize selecting the <项目名>-prd-第X轮验证输出.md；
  3. Identify the latest research outline, meeting minutes, and this round's inputs/round-XX/ materials;
  4. If the user says "process meeting minutes / review this round's research", default to entering meeting_digest_mode；
  5. If the user says "update PRD / iterate requirements", default to entering prd_iteration_mode, using the latest PRD, latest meeting minutes, and latest research outline;
  6. If the user says "organize requirements / standardize PRD / rewrite PRD / output formal document", default to entering prd_mode, read the latest PRD or business materials and output a standard PRD;
  7. If the user says "evaluate PRD / review PRD / check PRD / whether it can enter BKN_Creator", by default read the latest PRD and enter review_mode；
  8. If the user says "prepare for a visit", by default read the project background, the previous round's verification output, or the previous version of the PRD, and generate the next round's research outline.

Only when multiple PRDs of the same version, multiple meeting minutes from the same round, an undeterminable round, or conflicting user intent exist in the same directory should the user be asked to confirm. Which files were used in this session must be listed at the beginning of the output under "Input Sources for This Round".

Execute according to the following principles. Do not skip gap identification: unconfirmed issues are a required output, not a failure.

  1. Organize input materials

    • Identify input sources: rough ideas, interview records, audio transcriptions, PRDs, flowcharts, system descriptions, data dictionaries, screenshots, historical cases.
    • Before generating verification output or a PRD, archive or register the current round of input files in the project directory's inputs/round-XX/source-manifest.md。
    • Verify that archived files marked as copied in the manifest actually exist; if they do not exist, the status must be corrected and the risk exposed.
    • Distinguish confirmed facts, assumptions, conflicting information, and missing information.
    • If the input is an audio transcription or meeting minutes, read references/meeting-transcript-processing.md。
    • If the input is a PRD iteration task, you must simultaneously identify research_outline、meeting_notes_and_materials and previous_prd。

  2. Identify business scenarios

    • First identify the business objectives, user roles, trigger conditions, current process, target process, business inputs, business outputs, and success metrics.
    • Break the material into individually acceptable scenarios; comprehensive requirements must also be broken down into main scenarios and cross-scenario rules.
    • Each P0/P1 scenario must state which business capability it improves and identify the key decision points: who makes what judgment when, which facts and rules it depends on, and what the cost of a wrong judgment is.
    • Each P0/P1 scenario must describe the operational closed loop: discovery → judgment → recommendation → confirmation → execution → status change → tracking → feedback. It cannot merely describe "the user views the result."
    • Use references/fde-method.md the FDE-style business interview method in ; do not write BKN mapping content into the main body of the PRD.

  3. Reconstruct business rules and decisions

    • Record rule definitions, judgment criteria, exception boundaries, human-machine collaboration points, approval points, refusal-to-execute boundaries, and configurable items.
    • Express rules in business language; do not prematurely write rules as BKN actions, technical operators, or platform implementations.

  4. Discover the current state of systems, forms, and data

    • Identify business systems, forms, data sources, sources of truth, key fields, object IDs, refresh frequency, quality risks, access restrictions, and external write-back systems.

  5. Generate business acceptance test cases

    • Each core scenario must include at least a typical test case, a boundary test case, a permission/refusal test case, an insufficient-data test case, and an evidence-explanation test case.
    • Acceptance test cases should use business inputs and business expectations, and should not use objects / relationships / metrics / operators as the primary fields.
    • The list of issues to be confirmed and follow-up interview questions must be organized by business scenario, and business language should be used preferentially.
    • Do not directly ask in business interview questions about object_type、relation_type、ActionType, BKN, data_view, primary keys, relationship cardinality, interface granularity, write-back granularity, or field names; if these appear, they must be translated into business actions, business results, manual confirmation, responsible persons, or acceptance examples, or moved into 需下游建模阶段判定的问题。
    • If system-, field-, interface-, write-back-, or SLA-level confirmation is truly needed, it must be placed in a separate "System and Data Confirmation Questions" subsection and must not crowd out the main follow-up questions for each scenario.

  6. Assess requirement quality

    • Mark requirement maturity:R0 Idea、R1 Use Case Brief、R2 PRD Candidate、R3 PRD Ready、R4 Implementation Ready。
    • Output a business-readable "Requirement Maturity and Next-Step Recommendations," focusing on the current maturity, what is already clear, what key evidence is still missing, what scope should not currently be confirmed, and recommended next steps; do not output the internal scoring YAML in the main body of the PRD.
    • During assessment, also judge use_case_readiness and handoff_readiness: The former checks whether value, decisions, and the closed loop hold; the latter checks whether downstream modeling inputs are sufficient.
    • Use references/quality-scoring.md。
    • For prd_mode、prd_iteration_mode、handoff_mode, it must be done according to references/requirement-verifier.md generate internal verification_findings, then decide whether to enter revision.

  7. Generate BKN_Creator Handoff Summary

    • Output only a Chinese business handoff summary at the end of the PRD; do not output a machine-readable schema.
    • The core of the requirements discovery phase is always business language; the handoff summary is used to help subsequent modeling understand the business, and does not turn the PRD into a modeling input file.
    • The four-layer business convergence in the main text must first appear in each core scenario of the PRD main text, and then enter the handoff summary at the end of the document. Each P0/P1 scenario must be supplemented with a section on "the business objects, business relationships, business logic, responsibilities, and controls required for the scenario to hold," and record clues for business tasks that can be supported by Skill / Agent, explaining why these contents are needed, which business rule or acceptance objective they come from, and what will be affected if they are not confirmed.
    • The PRD main text should prioritize business headings:需要识别的业务对象（概念模型层）、需要表达的业务联系（关系层）、需要判断、计算或推进的业务逻辑（动力层）、需要控制的责任、权限与留痕（治理层）. Do not merely list nouns or "candidates: object list," and do not use "operator — ..." as a main-text label.
    • Before entering the four-layer business convergence in the main text, an ontological classification must first be done: distinguish 对象候选、事实属性 / 枚举候选、关系候选、结果候选、指标候选、算子 / 逻辑能力候选、状态变化、行动候选 and 治理要求. Do not treat a word as an object just because it is a noun, and do not treat an action as governance just because it occurs in the interface.
    • For the judgment criteria, first look at references/bkn-methodology.md 's objects, relationships, dynamic layer, actions, and governance boundaries, then look at references/bkn-requirement-method.md 's "ontological judgment discipline" and references/bkn-requirement-ontology-discovery.md 's requirements discovery tailoring examples. If the classification, object boundaries, conditions for relationships to hold, logical attribution, or action boundaries are still uncertain, they must be marked as "pending downstream modeling judgment" and must not be handled ambiguously.
    • The Chinese business-readable summary must first summarize the fixed five-layer handoff table by scenario, and then output the Chinese global merged heading:业务已确认内容、仍属建模候选、需下游建模阶段判定的问题。
    • Section 15 BKN_Creator The handoff summary must expand the fixed five-layer table for each committed P0/P1 scenario:
      • Conceptual model layer:业务对象 | 是什么 | 为什么需要 | 边界 | 确认状态 | 来源 / 验收映射
      • Relationship layer:业务联系 | 连接什么 | 业务含义 | 为什么需要 | 确认状态 | 来源 / 验收映射
      • Dynamic layer:类型 | 业务逻辑 | 怎么做 / 怎么判断 | 输出什么 | 边界 | 确认状态 | 来源 / 验收映射
      • Governance layer:治理点 | 控制什么 | 谁负责 / 谁使用 | 为什么需要 | 确认状态 | 来源 / 验收映射
      • Skill / Agent application layer:Agent 任务 | 帮谁 | 做什么 | 输出要求 | 不能自动做什么 / 风险边界 | 确认状态 | 来源 / 验收映射
    • The five-layer expression must be "business-oriented item by item": the conceptual model layer must explain item by item what each business object is and why it is needed; the relationship layer must explain item by item what is connected, what the business meaning is, and why it is needed; the dynamic layer must explain item by item how to judge / calculate / advance, what is output, and what the boundaries are; the governance layer must explain point by point what is controlled, who is responsible, and why it is needed; the Skill / Agent layer must explain item by item whom it helps, what it does, and the output requirements. It is forbidden to only list nouns, only list relationship phrases, or only write layer overviews.
    • BKN_Creator The handoff summary must inherit the business expression of the scenario summaries in the main text, and must not compress the business meaning already clearly stated in the main text back into SKU、库存、BOM such isolated noun lists; nor may it be written as 对象：A、B；关系：A-B；逻辑：X such compressed summaries.
    • A "confirmation status gate" must be enforced: global 业务已确认内容 Only content that comes from an explicit scenario, has business evidence or acceptance use cases, has clear business meaning, and is not marked as 'to be confirmed / unconfirmed / to be aligned / whether / scope pending / scope to be confirmed / candidate' may be placed in 业务已确认内容, and must be split into 仍属建模候选 or 需下游建模阶段判定的问题。
    • The 'ontology consistency gate' must be enforced: core nouns appearing in the relationship layer must have already been item-by-item explained in the conceptual model layer; results output by the dynamic layer must be judged as business objects, derived results, or states, and must not be elevated to objects by default;满足方案行、缺口行、报表行、看板指标 and other result-type content enters result candidates by default, and only when stable identity, lifecycle, owner, or subsequent business actions can be explained may it be used as an object candidate.
    • The 'core object priority gate' must be enforced: first identify the core objects that are managed and judged in the business, then determine whether subdivided objects need to be split out. The granularity, state, quantity, caliber, or deduction items of the same core object must not be directly split into multiple objects. For example, in an inventory scenario,库存 should be prioritized as the core object; batch, inventory status, inventory quantity, available quantity, occupied quantity, and occupation source are by default attributes, enumerations, calculation calibers, or relationships with production work orders, and only when the business independently tracks, freezes, releases, approves, counts, or audits by batch or occupation fact may 库存批次 or 库存占用 be elevated to object candidates.
    • The 'rules and roles are not objectified gate' must be enforced: business rules, calibers, algorithmic judgments, recommendation results, and scenario role names must not become objects by default.替代规则 is by default a constraint on the 物料 替代 物料 relationship or a 替代料覆盖判断 logical input;拆料来源产品 is by default 产品 or 库存 in the material splitting scenario and is not a new object. Only when a rule has a number, version, effective period, approval, publication and repeal, and owner, or a recommendation result has a lifecycle of confirmation, adjustment, assignment, closure, and review, may it be elevated to an object candidate.
    • Candidate objects, relationships, factual attributes, metrics, operators, result candidates, or actions must not be disguised as business-confirmed facts.
    • After the handover summary is generated, the Verifier must be executed again; if a hard stop exists, revise first and do not output Ready.

Output mode

When the user does not specify, automatically select the mode according to the input state, and do not force output of a complete PRD by default.

  • intake_mode: output minimal clarification questions for weak input. Do not generate a PRD.
  • research_plan_mode: before the visit, output a short customer site outline, meeting objectives, recommended participating roles, and a list of materials to request. Keep it to 1-2 pages by default, business-oriented and open-ended.
  • meeting_digest_mode: after the meeting, read the AI meeting minutes and output this round's research updates and questions to be confirmed. Do not ask AI engineers to manually fill in internal research records.
  • prd_iteration_mode: generate a new version of the PRD based on the three-input model.
  • prd_mode: output a standard PRD, suitable for business, product, customer, delivery, and project review. If the input is an existing PRD / BRD and the user says 'organize requirements', first make a lightweight quality judgment, then directly restructure it into a standard PRD; the quality score and gaps are written into the PRD as a summary and are not the sole main deliverable. If the PRD is written to the project directory, a file with the same name must also be written *-verification-findings.md。
  • review_mode: used only when the user explicitly requests evaluation, review, inspection, or judgment of whether it can enter BKN_Creator . Output scores, issues, and rewrite suggestions, and do not generate a new version of the PRD by default.
  • handoff_mode: Output only the handoff summary delivered to bkn-creator , suitable for downstream handoff after the PRD has been confirmed.

If the user explicitly requests "modeling input only", remind them that this falls within the scope of bkn-creator , and the handoff may be output first.

PRD Iteration Rules

prd_iteration_mode Standard inputs:

Input Purpose
research_outline This round's research outline, research objectives, and originally planned confirmed questions, used to prevent the PRD update from losing focus after meeting minutes are input.
meeting_notes_and_materials This round's meeting minutes, audio transcriptions, screenshots, forms, sample data, and supplementary customer materials.
previous_prd The previous version of the PRD, serving as the baseline for additions, deletions, modifications, and version records.

prd_iteration_mode Must output:

  • updated_prd: A new version of the PRD;
  • revision_summary: Newly added facts, corrected facts, deprecated content, and affected sections;
  • change_log: Version records;
  • unresolved_questions: Questions still pending confirmation;
  • next_research_focus: Key focus areas for the next round of research.

Each version of the PRD should record the document version, current status, this round's inputs, main changes, and key points pending confirmation. Version records are automatically generated by the Skill; no internal research record template for AI engineers to fill in manually is designed.

If the user only provides the project directory, the three-input model can be automatically identified and completed from the project context; if the previous version of the PRD is missing, do not force entry into prd_iteration_mode, and instead output the meeting_digest_mode verification result, or generate PRD v0.1 Draft。

Standard PRD Structure

A complete PRD uses the following structure by default. When the full template is needed, read assets/requirements-template.md。

# 《<场景名> PRD》

## 1. 文档信息
## 2. 本轮变更摘要（PRD 迭代时必需）
## 3. 业务背景与目标
## 4. 业务用户与职责
## 5. 场景总览
## 6. 场景需求详述
## 7. 跨场景业务规则
## 8. 业务系统、表单与数据来源
## 9. 权限、审批与合规要求
## 10. 界面 / 交互期望
## 11. 非功能需求
## 12. 业务验收用例
## 13. 待确认问题与访谈追问清单
## 14. 需求成熟度与下一步建议
## 15. BKN_Creator 交接摘要
## 16. 版本记录

For each committed P0/P1 scenario,## 6. 场景需求详述 must also include a "scenario convergence summary":

  • 需要识别的业务对象（概念模型层）
  • 需要表达的业务联系（关系层）
  • 需要判断、计算或推进的业务逻辑（动力层）
  • 需要控制的责任、权限与留痕（治理层）

This content must first explain the business significance, then extract candidate modeling items; it cannot be supplemented with just a technical table in the handoff at the end of the document.

## 15. BKN_Creator 交接摘要 must be more complete than the scenario convergence of ## 6. 场景需求详述 , and cannot be more abstract. Section 6 may be expressed as a business summary, while Section 15 must use a fixed five-layer table to expand item by item; in particular, the conceptual model layer must include 边界, to prevent objects from being split too early or incorrectly upgraded.

Each committed P0/P1 scenario must also have a minimal "scenario contract":

  • The business capability that the scenario enhances;
  • Key decision points;
  • Operational closed loop;
  • The business facts, relationships, and logic required to determine completion;
  • Corresponding acceptance test cases.

If a capability comes only from a quotation of the original text, lacks a main-text definition, or still belongs to "scope candidate / scope pending confirmation", do not place it into the committed P0/P1 scenarios; it should be downgraded to a candidate capability or pending-confirmation scope. If it is still retained as P1, a minimal scenario contract must be added.

Quality Gate

Before the final output, the Final Gate must be executed according to references/agentic-harness.md . Unless the user explicitly requests to view the review process, the internal verification_findings is not written verbatim into the main text of the PRD.

When the output file is written to disk,verification_findings does not enter the main text of the PRD, but must be written to the same directory with the same name *-verification-findings.md。

Verifier checks:

  • Whether the anti-drift check for references/anti-drift-checklist.md has been completed;
  • Whether business experts can review it without understanding BKN;
  • Whether there are clear business objectives, user roles, trigger conditions, inputs, outputs, and success metrics;
  • Whether it is organized by scenario, rather than by objects, relationships, metrics, operators, or actions;
  • Whether each scenario has the current process, target process, business rules, exception boundaries, manual confirmation points, and interface expectations;
  • Whether it records the business systems, forms, data sources, sources of truth, field definitions, refresh frequency, access restrictions, and data quality risks;
  • Whether the business acceptance use cases cover typical problems, analysis requests, decision recommendations, permission denials, insufficient data, and evidence explanations;
  • Whether the list of issues to be confirmed and interview follow-up questions is organized by scenario, and explains "whom to ask, why ask, the risk of not confirming, and the suggested way to ask";
  • Whether the issues to be confirmed are prioritized in business terms; if object_type、relation_type、ActionType, BKN, data_view, primary key, relationship cardinality, interface granularity, write-back granularity, or field names appear, whether they have been translated into business language or moved into 需下游建模阶段判定的问题；
  • Whether the PRD iteration output includes the input sources for this round, change summary, version record, and follow-up questions for the next round;
  • Whether the input files for this round have been copied and archived or registered in inputs/round-XX/source-manifest.md；
  • source-manifest.md Whether each archived_path marked as copied in actually exists; if it does not exist, "copied" must not be written;
  • If the output has been written to disk, whether a file with the same name is generated at the same time *-verification-findings.md；
  • BKN_Creator Whether the handoff summary is placed only at the end and remains a Chinese business-readable summary;
  • Whether the handoff summary first performs five-layer convergence by scenario, and then merges into 业务已确认内容、仍属建模候选、需下游建模阶段判定的问题；
  • Whether Section 15 of each committed P0/P1 scenario uses the fixed five-layer table: conceptual model layer, relationship layer, dynamics layer, governance layer, Skill / Agent application layer;
  • Whether the conceptual model layer includes 业务对象 | 是什么 | 为什么需要 | 边界 | 确认状态 | 来源 / 验收映射, and explains object boundaries rather than only listing names;
  • Whether Section 15 is not more abstract than Section 6, and is not compressed into 对象：A、B；关系：A-B such noun chains;
  • Whether the five-layer expression explains item by item "what it is / why / how to do it / who is responsible / what is output", rather than only writing a layer overview or a list of nouns;
  • Whether all global merged items can be traced back to at least one scenario, rule, or acceptance use case; content that cannot be traced must not enter 业务已确认内容；
  • 业务已确认内容 Whether it passes the confirmation status gate: it must not contain signals such as "to be confirmed / unconfirmed / to be aligned / whether / scope undetermined / scope to be confirmed / candidate";
  • Whether the BKN_Creator handoff summary passes the ontology consistency gate: core nouns in the relationship layer have already appeared in the conceptual model layer, and result-type content is not treated as an object by default;
  • Whether the BKN_Creator handoff summary passes the ontology modeling gate: objects have identity, lifecycle, responsibility, relationships, or management actions; relationships connect two already explained objects; metrics have unified definitions; operators explain inputs, rules, outputs, and boundaries; actions truly change objects, affect objects, or external systems; governance explains responsibility, permissions, approval, traceability, or boundaries for rejecting automation;
  • Whether the BKN_Creator handoff summary passes the core object priority gate: it does not prematurely split the granularity, status, quantity, definition, or deduction items of core objects into objects; subdivided objects must explain independent lifecycle, management actions, or governance necessity;
  • Whether the BKN_Creator handoff summary passes the gate that rules and roles are not objectified: it does not directly place rules, definitions, algorithmic judgments, recommendation results, or scenario role names into the object layer;
  • It does not use "operator" as a business label in the main text; the main body of the PRD should be written as business calculation, business judgment, recommendation, explanation, or advancement logic, and operator / logic capability candidates should only be placed in the handoff or downstream modeling determination questions.
  • If hard_stop, it must enter the Reviser; automatic revision is limited to at most 2 rounds. If it still does not pass, output the fail / warn reasons and the research questions for the next round, and must not declare PRD Ready or handoff Ready.

Reference Materials

  • BKN methodology distribution snapshot:references/bkn-methodology.md. For anything involving objects, factual attributes, relationships, metrics, operators, actions, governance, and Agent / Skill application-layer determinations, this file serves as the unified boundary; this Skill is only responsible for business-oriented expression and handoff summaries during the requirements discovery phase. During repository maintenance, the public source file is ../common/bkn-methodology.md, and it must be synchronized to this file before release.
  • Agentic Harness execution protocol:references/agentic-harness.md, required reading before outputting a formal PRD, a PRD iteration, or a BKN_Creator handoff summary, used to execute the Generate / Verify / Revise / Final Gate closed loop.
  • Verifier specification:references/requirement-verifier.md, required reading when generating the internal verification_findings , used to determine hard stop, major, minor, and final gate.
  • Anti-drift check:references/anti-drift-checklist.md, required reading before final output, used to prevent the PRD from becoming technicalized again, candidates from being mixed into confirmed items, and machine schemas from making a comeback.
  • BKN requirements discovery tailoring method:references/bkn-requirement-ontology-discovery.md, required reading before generating the scenario convergence summary and the BKN_Creator handoff summary, used to translate the common methodology into the expression of objects, factual attributes / enumerations, relationships, metrics, operators, actions, governance, and Agent tasks in PRD scenarios, and to prevent field-based, report-based, and interface-based modeling.
  • FDE business interview method:references/fde-method.md, read when an FDE-style questioning method is needed.
  • BKN requirements discovery method:references/bkn-requirement-method.md, read when business materials need to be organized into a PRD.
  • Quality scoring rules:references/quality-scoring.md, read when scoring, maturity, or recommended routes are needed.
  • Interview question bank:references/interview-question-bank.md, read when an interview outline or follow-up question list needs to be generated.
  • Meeting minutes processing:references/meeting-transcript-processing.md, read when the input is meeting minutes, audio transcripts, or interview summaries.
  • Output structure reference:references/output-schema.md, read only during internal checks for structural consistency; the PRD body does not output a machine-readable schema.
  • FDE to BKN post-mapping:references/fde-bkn-mapping.md, read only when generating the handoff_mode or the BKN_Creator handoff summary after the PRD has been formed.

Templates and Cases

  • Customer site short outline:assets/interview-brief-template.md, use preferentially when visiting a customer or preparing an interview outline.
  • Research preparation template:assets/research-plan-template.md, use when customer background and visit objectives are already available.
  • Input source checklist template:assets/source-manifest-template.md, use when archiving input materials for each round.
  • Interview template:assets/interview-template.md, for internal reference by AI engineers; business experts are not required to fill it out manually.
  • Requirements document template:assets/requirements-template.md, use when outputting a complete PRD.
  • Business acceptance test case template:assets/scenario-test-case-template.md, use when supplementing acceptance test cases.
  • BKN_Creator handoff template:assets/bkn-creator-handoff-template.md, use when outputting a handoff.
  • Verifier findings template:assets/verification-findings-template.md, use when persisting *-verification-findings.md .
  • Downstream Agent / Skill Card template:assets/downstream-agent-card-template.md, use only after the PRD is completed and the user requests the design of a downstream Agent / Skill.
  • Cases: read by domain references/examples/operations-alert-triage.md、references/examples/supply-chain-risk.md、references/examples/customer-service.md, do not batch load all examples.