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

bkn-requirement

Writing & research

View repository

Updated 10-16 03:05

About this skill

BKN Requirement

Objective

Use this Skill before formal BKN modeling. It is responsible for transforming customer background, research objectives, meeting minutes, PRD, 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 line of V0.7 is the "Requirement 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 summary 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 background 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 perform platform operations. These are the downstream responsibilities of bkn-creator and openbkn .

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;
  • Based on customer background and existing materials, generate pre-meeting research references, suggested attendee roles, and a list of materials to request;
  • Organize requirements from interview minutes, audio transcriptions, PRD, BRD, 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 technically oriented, modeling-oriented, or POC-oriented materials into a standard PRD that business users can review;
  • Assess whether a certain business scenario already has 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 the BKN, hand it over 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 outline 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 requirement discovery stage.

references/bkn-methodology.md is distributed together with this Skill. After installing bkn-requirement separately, at runtime only that file within this Skill is read, without depending on other directories in the repository.

The main line of the requirement discovery lifecycle is:

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

The main execution line for formal output is:

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

The execution protocol is described in references/agentic-harness.md。prd_mode、prd_iteration_mode and handoff_mode A full Harness must be executed;research_plan_mode、meeting_digest_mode and review_mode a lightweight Harness may be executed;intake_mode only the minimum clarification questions are output.

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 PRD body, but they must be used to determine whether Ready can be output. If this round will persist a formal PRD, PRD iteration, or handoff to the project directory, the 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 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 forcibly process scattered 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, preconditions for research
Preparing to visit a customer, with a small amount of background material research_plan_mode Short on-site outline for the customer, meeting objectives, suggested participant roles, material request checklist
Input AI meeting minutes, recording transcripts, or interview summaries 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, with the user requesting "organize requirements / standardize PRD / rewrite PRD / output formal document" prd_mode Business scenario-centered PRD, with a quality summary, questions to be confirmed, and a BKN_Creator handoff summary
Existing PRD / BRD, with the user explicitly requesting "evaluate / review / check / whether it can enter BKN_Creator" review_mode Quality score, gap list, rewriting 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 together. The default directory is uniformly:

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

Uniformly use projects/prj-<项目>/. This shared project directory can carry requirements discovery, PRD, validation output,BKN_Creator handoff summaries, optional ontology modeling solutions, and references for subsequent BKN delivery.

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 a general project 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:

projects/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 copies; 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:

projects/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 validation 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. You must write "copied=no", record the reason for failure, and mark "input archiving incomplete" 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 choose the mode according to the user's intent. Do not stop just because the user did not manually list all input files.

Automatic recognition order:

  1. Identify the latest PRD: prioritize selecting the <项目名>-PRD vX.Y.md；
  2. Identify the latest validation 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", enter by default meeting_digest_mode；
  5. If the user says "update PRD / iterate requirements", enter by default 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", enter by default 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 validation 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 exist in the same directory, the round cannot be determined, or the user's intent conflicts, should the user be asked to confirm. Which files were used in this session must be listed at the beginning of the output as "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 validation output or a PRD, archive or register this round's input files into the project directory's inputs/round-XX/source-manifest.md。
    • Verify that the archive 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 transcript 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 the main scenario 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; 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 write rules prematurely 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 case, a boundary case, a permission/refusal case, an insufficient-data case, and an evidence-explanation 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 open questions and interview follow-up questions must be organized by business scenario and should prioritize business language.
    • 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 outcomes, manual confirmation, responsible persons, or acceptance examples, or moved into 需下游建模阶段判定的问题。
    • If system-, field-, interface-, write-back-, or SLA-level confirmation is genuinely 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, simultaneously judge use_case_readiness and handoff_readiness: the former checks whether the value, decisions, and closed loop hold up, while the latter checks whether the downstream modeling input is sufficient.
    • Use references/quality-scoring.md。
    • for prd_mode、prd_iteration_mode、handoff_mode, and must generate the internal references/requirement-verifier.md according to verification_findings, then decide whether to proceed to revision.

  7. Generate the BKN_Creator handoff summary

    • Output only a Chinese business handover 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 handover 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 body must first appear in each core scenario of the PRD main body, and only then enter the handover summary at the end of the document. Each P0/P1 scenario must be supplemented with a subsection on "the business objects, business relationships, business logic, and responsibility and control required for the scenario to hold", and must record business task clues that can be supported by Skills / Agents, 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 body should preferentially use business headings:需要识别的业务对象（概念模型层）、需要表达的业务联系（关系层）、需要判断、计算或推进的业务逻辑（动力层）、需要控制的责任、权限与留痕（治理层）. Do not merely list nouns or "Candidates: object list", and do not use "operator — ..." as a main-body label.
    • Before entering the four-layer business convergence in the main body, an ontological classification must first be performed: distinguish between 对象候选、事实属性 / 枚举候选、关系候选、结果候选、指标候选、算子 / 逻辑能力候选、状态变化、行动候选 and 治理要求. A word cannot be treated as an object just because it is a noun, and an action cannot be treated as governance just because it occurs on the interface.
    • For the judgment criteria, first look at the objects, relationships, dynamic layer, actions, and governance boundaries of references/bkn-methodology.md , then look at the "ontological judgment discipline" of references/bkn-requirement-method.md and the requirements discovery tailoring examples of references/bkn-requirement-ontology-discovery.md . If the classification, object boundaries, conditions for relationships to hold, logical attribution, or action boundaries are still uncertain, they must be marked as "to be determined by downstream modeling" and must not be handled ambiguously.
    • The Chinese business-readable summary must first summarize the fixed five-layer handover table by scenario, and then output the Chinese global merged heading:业务已确认内容、仍属建模候选、需下游建模阶段判定的问题。
    • Section 15 BKN_Creator The handover 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 merely list nouns, merely list relationship phrases, or write only layer-level overviews.
    • BKN_Creator The handover summary must inherit the business expression of the scenario summaries in the main body, and must not compress business meanings already clearly stated in the main body back into isolated noun lists such as SKU、库存、BOM ; nor may it be written as compressed summaries such as 对象：A、B；关系：A-B；逻辑：X .
    • A "confirmation status gate" must be enforced: the global 业务已确认内容 may only include content that comes from an explicit scenario, has business evidence or acceptance use cases, has clear business meaning, and is not marked "to be confirmed / unconfirmed / to be aligned / whether / scope to be determined / scope to be confirmed / candidate"; as long as a sentence contains any of the above signals, it must not enter 业务已确认内容, and must be split into 仍属建模候选 or 需下游建模阶段判定的问题。
    • An "ontological consistency gate" must be enforced: core nouns appearing in the relationship layer must already have been explained item by item 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 upgraded to objects by default;满足方案行、缺口行、报表行、看板指标 Result-type content enters the result candidates by default; only when it can explain stable identity, lifecycle, owner, or subsequent business actions may it serve as an object candidate.
    • The "core object priority gate" must be enforced: first identify the core object that is managed and judged in the business, then determine whether sub-objects need to be split out. The granularity, state, quantity, caliber, and 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 state, inventory quantity, available quantity, occupied quantity, and occupation source are by default treated as 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 to 替代料覆盖判断 ;拆料来源产品 is by default the role of 产品 or 库存 in the material splitting scenario, 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 confirmation, adjustment, assignment, closure, and review lifecycle, may it be elevated to an object candidate.
    • Candidate objects, relationships, fact attributes, metrics, operators, result candidates, or actions must not be disguised as business-confirmed facts.
    • After the handoff 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 based on the input state, and do not force a complete PRD output 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 on-site outline for the customer, meeting objectives, suggested attendee 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 the 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, not as 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 rewriting suggestions, and do not generate a new 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 "only do modeling input", remind them that this falls within the scope of bkn-creator , and handoff may be output first.

PRD iteration rules

prd_iteration_mode Standard input:

Input Purpose
research_outline This round's research outline, research objectives, and originally planned questions to confirm, used to prevent the PRD update from losing focus after the meeting minutes are input.
meeting_notes_and_materials Meeting minutes, recording transcripts, screenshots, forms, sample data, and supplementary client materials for this round.
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: the new version of the PRD;
  • revision_summary: newly added facts, corrected facts, deprecated content, and affected sections;
  • change_log: version records;
  • unresolved_questions: issues still pending confirmation;
  • next_research_focus: key focuses for the next round of research.

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

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 a complete 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" under:

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

This content must first explain the business significance, and then distill candidate modeling items; it cannot merely be added as 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 can be expressed as a business summary, while Section 15 must use the fixed five-layer table to expand item by item, and 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;
  • the operational closed loop;
  • the business facts, relationships, and logic required to complete the judgment;
  • the corresponding acceptance use cases.

If a certain capability comes only from a quotation in the original text, lacks a definition in the main body, 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, then 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 should not be written verbatim into the main body of the PRD.

When the output file is written to disk,verification_findings does not enter the main body of the PRD, but must be written into 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 who do not understand BKN can still review it;
  • whether there are clear business goals, user roles, trigger conditions, inputs, outputs, and success metrics;
  • whether it is organized by scenario rather than by object, relationship, metric, operator, or action;
  • whether each scenario has the current process, target process, business rules, exception boundaries, manual confirmation points, and interface expectations;
  • whether it records 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;
  • Is the list of open questions and interview follow-up questions organized by scenario, and does it explain "whom to ask, why ask, the risk of not confirming, and suggested wording for asking";
  • Are the open questions 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, have they been translated into business language or moved into 需下游建模阶段判定的问题；
  • Does the PRD iteration output include the current round's input sources, change summary, version record, and next round's follow-up questions;
  • Have the current round's input files been copied and archived or registered in inputs/round-XX/source-manifest.md；
  • source-manifest.md Every 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, has a same-named *-verification-findings.md；
  • BKN_Creator Is the handoff summary placed only at the end and kept as a Chinese business-readable summary;
  • Does the handoff summary first perform five-layer convergence by scenario, then merge into 业务已确认内容、仍属建模候选、需下游建模阶段判定的问题；
  • Does Section 15 of each committed P0/P1 scenario use the fixed five-layer table: conceptual model layer, relationship layer, dynamics layer, governance layer, Skill / Agent application layer;
  • Does the conceptual model layer include 业务对象 | 是什么 | 为什么需要 | 边界 | 确认状态 | 来源 / 验收映射, and does it explain object boundaries rather than only listing names;
  • Is Section 15 not more abstract than Section 6, and not compressed into a noun chain such as 对象：A、B；关系：A-B ;
  • Does the five-layer expression explain 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 noun list;
  • Can all global merge items be traced back to at least one scenario, rule, or acceptance case; content that cannot be traced must not enter 业务已确认内容；
  • 业务已确认内容 Does it pass the confirmation status gate: it must not contain signals such as "pending confirmation / unconfirmed / pending alignment / whether / scope undetermined / scope pending confirmation / candidate";
  • Does the BKN_Creator handoff summary pass 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;
  • Does the BKN_Creator handoff summary pass the ontology modeling gate: objects have identity, lifecycle, responsibility, relationships, or management actions; relationships connect two described objects; metrics have a unified definition; operators explain input, rules, output, and boundaries; actions actually change objects, affect objects, or affect external systems; governance explains responsibility, permissions, approval, traceability, or the boundary of refusing automation;
  • Does the BKN_Creator handoff summary pass the core-object-first gate: the granularity, state, quantity, definition, or deduction items of core objects are not prematurely split into objects; subdivided objects must explain independent lifecycle, management actions, or governance necessity;
  • Does the BKN_Creator handoff summary pass the gate that rules and roles are not objectified: rules, definitions, algorithmic judgments, recommendation results, or scenario role names are not placed directly into the object layer;
  • "Operator" is not used as a business label in the main text; the PRD body 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 decision questions.
  • If hard_stopappears, 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 next round of research questions, and do not declare PRD Ready or handoff Ready.

Reference Materials

  • BKN Methodology Distribution Snapshot:references/bkn-methodology.md. For anything involving objects, fact 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.
  • 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 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 re-technicalized, 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 BKN methodology into the expression of objects, fact attributes / enumerations, relationships, metrics, operators, actions, governance, and Agent tasks in PRD scenarios, and to prevent field-based, report-based, and UI-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 when internally checking 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

  • Short on-site client outline:assets/interview-brief-template.md, use preferentially when visiting a client or preparing an interview outline.
  • Research preparation template:assets/research-plan-template.md, use when client background and visit objectives are already available.
  • Input source list 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 complete 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.