doc-standard

doc-standard skill

Overview

The process document'sgranularity(separation of What/Why and How, traceability, verifiability, prohibition of deferring NFRs, etc.) is generatedし deviation-checkedusing the principles, recipes, rubrics, and machine-judgment scripts of the library bundled in this directory. Responsibility is limited to the single perspective of granularity boundaries. Proofreading, code review, design decision records, and finished-product review are not handled (see the delegation destinations below).

Implementation scope of this skill: In the library, machine judgment is supported for 19 doc_types and both WF/agile methodologies＝WF: data-design(basic design = logical data design) / external-design(basic design = external design) / architecture-design(basic design = method design) / nonfunctional-design(basic design = non-functional design) / operations-design(basic design = operation/migration design) / detailed-design-data(detailed design = physical data) / detailed-design-process(detailed design = process details = class/process, WF detailed 2nd, paired with data) / srs(requirements definition) / test-case-spec(test case specification) / test-plan(test plan = IEEE 829 series, WF test 2nd) / test-design-spec(test design specification = IEEE 829 series, WF test 3rd, directly above case specification) / test-procedure-spec(test procedure specification = IEEE 829 series, WF test 4th, directly below case specification) / test-strategy(test strategy = organization-wide, WF test 5th, topmost =test process 5 levels complete）、agile: user-story(user story) / acceptance-criteria(acceptance criteria = Given-When-Then, agile 2nd) / design-doc(design agreement document = Google Style/arc42/C4, agile 3rd) / adr(Architecture Decision Record, agile 4th = S5 touchstone of delegation dual definition) / rfc(Request for Comments, agile 5th = exploration/proposal document before decision, paired with ADR on the time axis) / pr-faq(PR-FAQ = Amazon Working Backwards, agile 6th = future press release from the customer's perspective + anticipated Q&A for back-calculating planning, the conclusion of the agile core system). These 19 doc_types are exactly what this skill can actually generate and check. Basic design (M3) has all five subdivisions in operation: data design, external design, method design, non-functional design, and operation/migration design =basic design M3 complete. WF testing is complete with the 5 levels: strategy/plan/design specification/case/procedure. Detailed design has the two: data/process. Agile's main artifacts (user-story/AC/design-doc/ADR/RFC/PR-FAQ) are all present, and the remaining unmaintained ones are waterfall/ and other doc_types, etc., withfuture expansionHowever, this skill does not pretend to be exhaustive. The trigger words in the description include future processes, but if a process that has not yet been prepared is requested, it announces "recipe not prepared" and does not perform generation or checking.

When and what to read (deferred reference; libraries are not always loaded)

Each file of the bundled libraries isread after this skill is triggered(not always loaded = avoid context bloat). What to read by situation is as follows. All paths are relative paths from this skill's directory (the location where SKILL.md is).

Situation	Target to Read / execute (relative path from the skill's directory)
Immediately after startup (mandatory)	`principles/` existence check (if absent, go to fail-safe)
Generation mode, after process is determined (basic = logical)	Applicable recipe `waterfall/basic-design/data-design.md`（doc_type=`data-design`) + principles `principles/granularity-axis.md`
Generation mode, after process is determined (basic = external design)	Applicable recipe `waterfall/basic-design/external-design.md`（doc_type=`external-design`) + principles `principles/granularity-axis.md`
Generation mode, after process is determined (basic = method design)	Applicable recipe `waterfall/basic-design/architecture-design.md`（doc_type=`architecture-design`) + principles `principles/granularity-axis.md`. Records of design decisions (ADR) are `architecture-decision-records` delegated to the skill = this skill only links, references, and checks existence (S5)
Generation mode, after process is determined (basic = non-functional design)	Applicable recipe `waterfall/basic-design/nonfunctional-design.md`（doc_type=`nonfunctional-design`) + principles `principles/granularity-axis.md`. Make the measurement method an independent mandatory section to mechanize verifiable / put technical names, SQL, and ambiguous expressions into the rubric
Generation mode, after process is determined (basic = operations/migration design)	Applicable recipe `waterfall/basic-design/operations-design.md`（doc_type=`operations-design`) + principles `principles/granularity-axis.md`. Operations policy and migration policy at the policy level / procedure documents and migration SQL downstream
Generation mode, after process is determined (detailed = physical data)	Applicable recipe `waterfall/detailed-design/data-design.md`（doc_type=`detailed-design-data`) + principles `principles/granularity-axis.md`
Generation mode, after process is determined (detailed = processing)	Applicable recipe `waterfall/detailed-design/process-design.md`（doc_type=`detailed-design-process`) + principles `principles/granularity-axis.md`。paired with data(split the axes: data side = DB physical / processing side = classes and processing),narrow down what is mandatory(module structure/processing specifications/traceability), both extremes of ghost doc (too thick with verbatim code)/substantially empty (too thin) are the rubric, vocab is `なぜなら業務` carried over from data
Generation mode, after process is determined (requirements definition)	Applicable recipe `waterfall/requirements/srs.md`（doc_type=`srs`) + principles `principles/granularity-axis.md`
Generation mode, after process is determined (test case specifications)	Applicable recipe `waterfall/test/test-case-spec.md`（doc_type=`test-case-spec`) + principles `principles/granularity-axis.md`
Generation mode, after process is determined (test plan)	Applicable recipe `waterfall/test/test-plan.md`（doc_type=`test-plan`) + principles `principles/granularity-axis.md`。narrow down what is mandatory(Scope/exit criteria/traceability = IEEE 829 not all sections mandatory; organization/schedule/risk recommended) - Include "out of scope + reason" in scope (same form as Non-Goals) - Make exit criteria measurable (P6) - Do not write concrete test case values in the plan (put them in test-case-spec = same form as F1) - vocab follows the 3 terms of test-case-spec
Generation mode: after process is fixed (test design specification)	Applicable recipe `waterfall/test/test-design-spec.md`（doc_type=`test-design-spec`) + principles `principles/granularity-axis.md`。Keep mandatory items minimal(test conditions/coverage policy/traceability) - Test conditions are abstract (high-level cases)/Concrete values go to the case specification = same form as F1(design specification ↔ case specification = logical ER ↔ physical ER) - Coverage policy must be independent (same form as nonfunctional measurement method) - vocab follows the 3 terms (empirically verified)
Generation mode: after process is fixed (test procedure specification)	Applicable recipe `waterfall/test/test-procedure-spec.md`（doc_type=`test-procedure-spec`) + principles `principles/granularity-axis.md`。Keep mandatory items minimal(preconditions/execution steps/traceability) -Separation of execution ↔ judgment= Procedures are operations (How to run) / pass/fail judgment belongs to the case specification (What to expect) and references case IDs - Preconditions must be independent to ensure reproducibility - vocab follows the 3 terms (a sign of expected results being mixed into procedures; empirically verified)
Generation mode: after process is fixed (test strategy)	Applicable recipe `waterfall/test/test-strategy.md`（doc_type=`test-strategy`) + principles `principles/granularity-axis.md`。Keep mandatory items minimal(test policy/test levels/traceability) -Abstraction boundary between strategy (organization-wide) ↔ plan (project-level)= Project-specific details go to the plan - Trace upward to higher-level (quality goals/business goals) - Do not enforce fixed 1:1 V-model -vocab is the only empty one among the 5 WF tests(strategy is at the policy level, so there is no main battlefield for the 3 terms)
Generation mode: after deliverable is fixed (user story =agile）	Applicable recipe `agile/user-story.md`（doc_type=`user-story`) + principles `principles/granularity-axis.md`
Generation mode: after deliverable is fixed (acceptance criteria =agile・Given-When-Then）	Applicable recipe `agile/acceptance-criteria.md`（doc_type=`acceptance-criteria`) + principles `principles/granularity-axis.md`. Then must contain only observable behavior / internal implementation goes downstream.agile but has vocab(3 terms for ambiguous expected results = follows test-case-spec) -First agile one with check_traceability enabled(scenario → corresponding user-story)
Generation mode: after deliverable is fixed (Design Doc =agile- design agreement document)	Applicable recipe `agile/design-doc.md`（doc_type=`design-doc`) + principles `principles/granularity-axis.md`。Keep mandatory items minimal(Context/Non-Goals/traceability = making all sections mandatory is the deviation; alternatives considered/cross-cutting concerns are recommended) -vocab is empty(Deviations are rubric-led due to structure/quantity/context) - Do not draw the entire L4 class diagram from the start - Delegate important decisions via ADR links (S5)
Generation mode/after artifact finalization (ADR=agileArchitecture Decision Record)	Applicable recipe `agile/adr.md`（doc_type=`adr`) + principle `principles/granularity-axis.md`。5 sections are mandatory(Nygard 2011's Context/Decision/Status/Consequences + this library's own rejected options) -Make rejected options an independent mandatory itemand mechanically detect one-sided missing Why (after-the-fact justification) -vocab is empty(deviations are structure/context) - traceability is within Context = check_traceability skipped (same type as user-story) - do not write English Decision in H1 to avoid decoys.Avoiding duplicate delegation definitions = doc-standards owns granularity boundaries/numbering (ADR-NNNN), while generation and content evaluation are owned by the architecture-decision-records skill(S5, paired with the side where design-doc/architecture-design delegates ADRs via links)
Generation mode/after artifact finalization (RFC=agileRequest for Comments, pre-decision proposal)	Applicable recipe `agile/rfc.md`（doc_type=`rfc`) + principle `principles/granularity-axis.md`。Keep mandatory items narrow(proposal content/alternatives/unresolved issues/traceability) -`未解決の論点` as independent mandatoryand mechanically detect "pretending to be undecided when already decided = not functioning as an RFC" (same type as ADR rejected options and design-doc Non-Goals) -vocab empty(no expected results written in the proposal document and no three-word main battlefield, 5th example) -Independent traceability enabled(asymmetric with ADR's skipped within Context = RFC is unique to doc-standards and does not conflict with an externally owned skill format, so check_traceability is enabled) - do not write the four required words in H1 to avoid decoys.Paired with ADR on the time axis= RFC alternatives arelive options/ ADR rejected options areburied options- chained in the direction RFC exploration -> adoption -> ADR record (not delegation but cross-reference of adjacent artifacts)
Generation mode/after artifact finalization (PR-FAQ=agileAmazon Working Backwards, planning backcast)	Applicable recipe `agile/pr-faq.md`（doc_type=`pr-faq`) + principle `principles/granularity-axis.md`。Keep mandatory items narrow(press release/anticipated Q&A/success metrics/traceability) -`成功指標` as independent mandatoryand mechanically detect "missing measurable success conditions = pie in the sky" (P6 series = same type as nonfunctional measurement method/test termination criteria/coverage policy/assumptions) -`FAQ`(3 characters) partially matches H1 "PR-FAQ" and becomes a decoy, so avoid required as the compound word `想定問答` avoid・vocab empty(no expected results written in planning backcast and no three-word main battlefield, 6th example) -Independent traceability enabled(The trace target is the corresponding customer issue/business goal = a feature not linked to a customer issue = Working Backwards violation/product-out; same type as the empty-cell detection and the upper-level trace of test-strategy). Turning a PR into an internal feature list/optimism bias/turning it into slides/vague expressions of success metrics is the rubric. PR-FAQ ≒ the reverse-engineered version of requirements definition (SRS) = the chain from planning entry point to requirement finalization (separate process on the methodology axis S4, not a duplicate definition)
Generation mode/process attribution boundary judgment	Responsibility comparison table `principles/responsibility-map.md`(boundaries of include/not include/pass on/deviate. WF = process phase axis / agile = deliverable lifecycle axis = S4)
Check mode/machine judgment	`python3 <スキルのディレクトリ>/scripts/check_headings.py <path> <doc_type>` ・ `check_vocabulary.py` ・ `check_traceability.py`(empty cells in the traceability table = detect isolated design elements) of the3 checkers（`<doc_type>`=`data-design` / `external-design` / `architecture-design` / `nonfunctional-design` / `operations-design` / `detailed-design-data` / `detailed-design-process` / `srs` / `test-case-spec` / `test-plan` / `test-design-spec` / `test-procedure-spec` / `test-strategy` / `user-story` / `acceptance-criteria` / `design-doc` / `adr` / `rfc` / `pr-faq`）
Check mode/qualitative judgment (basic = logic)	rubric `rubric/data-design.md`（doc_type=`data-design`）
Check mode/qualitative judgment (basic = external design)	rubric `rubric/external-design.md`（doc_type=`external-design`）
Check mode/qualitative judgment (basic = method design)	rubric `rubric/architecture-design.md`（doc_type=`architecture-design`. Includes ADR link existence check; S5)
Check mode/qualitative judgment (basic = non-functional design)	rubric `rubric/nonfunctional-design.md`（doc_type=`nonfunctional-design`. Look at quantification of grade values, leakage of implementation means, and the NFR granularity boundary between requirements and basic design)
Check mode/qualitative judgment (basic = operations/migration design)	rubric `rubric/operations-design.md`（doc_type=`operations-design`. Look at the granularity of policy vs. procedures, leakage of migration SQL, and the verifiability of rollback conditions)
Check mode/qualitative judgment (detailed = physical data)	rubric `rubric/detailed-design-data.md`（doc_type=`detailed-design-data`）
Check mode/qualitative judgment (detailed = processing)	rubric `rubric/detailed-design-process.md`（doc_type=`detailed-design-process`. 5 perspectives = quality of class/module structure / quality of processing specifications / ghost document (too thick = verbatim code; perspective 3) / substantially empty (too thin = branches/error conditions not described; perspective 4) / quality of trace linking.Empty cell detection is handled by the machine check_traceability＝F5・`SQL` is a false positive due to product-name partial matching, hence the rubric)
Check mode/qualitative judgment (requirements definition)	rubric `rubric/srs.md`（doc_type=`srs`）
Check mode/qualitative judgment (test case specifications)	rubric `rubric/test-case-spec.md`（doc_type=`test-case-spec`）
Check mode/qualitative judgment (test plan)	rubric `rubric/test-plan.md`（doc_type=`test-plan`. 5 perspectives = quality of scope (evading with out-of-scope/nothing in particular) / measurability of exit criteria (vague expressions other than the 3 words) / mixing in concrete case values (same type as F1) / requirement transcription / quality of trace linking.Empty cell detection is handled by the machine check_traceability＝F5）
Check mode/qualitative judgment (test design specifications)	rubric `rubric/test-design-spec.md`（doc_type=`test-design-spec`. 5 perspectives = abstractness of test conditions / quality of coverage policy [technique fit, coverage measurability] / low-level case contamination [F1 isomorphic; when duplicating perspective 1, perspective 3 takes priority] / requirement transcription / quality of trace linkage.Empty cell detection is handled by the mechanical check_traceability＝F5）
Check mode / qualitative judgment (test procedure specification)	Rubric `rubric/test-procedure-spec.md`（doc_type=`test-procedure-spec`. 5 perspectives = quality of preconditions/setup / quality of execution steps [reproducible in step order] / contamination of judgment criteria [execution↔judgment adjacency boundary, structural judgment] / case transcription / quality of trace linkage.Empty cell detection is handled by the mechanical check_traceability＝F5）
Check mode / qualitative judgment (test strategy)	Rubric `rubric/test-strategy.md`（doc_type=`test-strategy`. 5 perspectives = quality of test policy / quality of test level types [do not enforce fixed V-model 1:1, ISTQB v4] / contamination of project-specific details [strategy↔plan boundary, structural judgment] / measurability of policy / quality of trace linkage.Empty cell detection is handled by the mechanical check_traceability＝F5・Since vocab is empty, the mechanical layer checks only headings + trace empty cells; qualitative judgment is primary）
Check mode / qualitative judgment (user story =agile・primary judgment）	Rubric `rubric/user-story.md`（doc_type=`user-story`. Since vocab is empty, the mechanical layer is thin and the rubric is the primary judgment = S4)
Check mode / qualitative judgment (acceptance criteria =agile・primary judgment）	Rubric `rubric/acceptance-criteria.md`（doc_type=`acceptance-criteria`. 5 perspectives = GWT structure / contamination of implementation inside Then / unmeasurable expressions other than the 3 words / more than 20 scenarios / quality of trace linkage.Empty cell detection is handled by the mechanical check_traceabilityand explicitly stated = F5 lesson. agile but asymmetric in having vocab)
Check mode / qualitative judgment (Design Doc =agile・primary judgment）	Rubric `rubric/design-doc.md`（doc_type=`design-doc`. 5 perspectives = quality of Goals/Non-Goals / L4 full depiction, gold plating / post-hoc justification of alternatives and delegation to ADR / quality of Context / quality of trace linkage.Empty cell detection is handled by the mechanical check_traceability= F5 lesson.vocab empty = deviations are structural/quantitative/contextual, so rubric-led）
Check mode / qualitative judgment (ADR =agile・primary judgment）	Rubric `rubric/adr.md`（doc_type=`adr`. 5 perspectives = quality of Context and clarity of Status/Decision / presence of rejected options and Why on both sides / Consequences [both positive and negative] / semantic validity of traces.Perspective 5 = judge's boundary-crossing self-check= numbering and content evaluation are the domain of the architecture-decision-records skill, and doc-standards covers only granularity boundaries; a judgment that crosses the boundary is invalid along with the judgment text itself (a guardrail that upholds S5 at the operational layer).vocab empty = deviations are structural/contextual, so rubric-led）
Check mode / qualitative judgment (RFC =agile・primary judgment）	Rubric `rubric/rfc.md`（doc_type=`rfc`. 5 perspectives = quality of proposal content [concreteness vs. too abstract] / quality of alternatives [whether not a straw man, trade-offs] / quality of unresolved issues [whether truly undecided, whether not pretending to be undecided while already decided] / premature mixing in of implementation details / quality of trace linking.Empty cell detection is handled by the mechanical check_traceability= F5; the core is `未解決の論点` independently mandatory and `代替案` omissions are also mechanically detected together.vocab empty = deviations are structural/contextual, so rubric-led）
Check mode: qualitative judgment (PR-FAQ =agile・main judgment）	rubric `rubric/pr-faq.md`（doc_type=`pr-faq`. 5 perspectives = customer perspective of the press release [customer benefits vs. turning it into an internal feature list = the biggest deviation] / quality of the FAQ [whether it is honest about hard points, costs, and risks for internal audiences vs. optimism bias] / measurability of success metrics [ambiguity such as "significantly improved" vs. measurable; presence/absence of clauses is mechanical] / scope bloat [turning it into a 15p feature list, slide-ification] / quality of trace linking.Empty cell detection is handled by the mechanical check_traceability＝F5。vocab empty = deviations are structural/quantitative/contextual, so rubric-led）
Check mode: confirmation of process boundaries	Responsibility comparison table `principles/responsibility-map.md`
Confirmation of delegation destination	"Existing skill delegation table" in the responsibility comparison table (coding-principles / architecture-decision-records / review-handoff / santa-method)

The principles layer (granularity-axis.md) is the only truth. If recipes, rubrics, or this skill conflict with it, the principles layer is taken as true.

Mode 1: Generation

Create process documents according to the granularity standard.

First determine the methodology (WF / agile), then branch to the corresponding recipe. Determine the methodology, and on that basis determine which deliverable it is. If ambiguous, confirm.WF is the process phase axis(requirements definition -> basic design -> detailed design -> testing, dividing the process in chronological order) goes to the recipe for the corresponding process.agile is the deliverable lifecycle axis(grows as living docs and is elaborated JIT = S4) goes to the recipe for the corresponding deliverable. Recipes corresponding to mechanical judgment exist for WF: data-design(basic = logical) / external-design(basic = external design) / architecture-design(basic = method design) / nonfunctional-design(basic = non-functional design) / operations-design(basic = operations/migration design) / detailed-design-data(detailed = physical data) / detailed-design-process(detailed = processing) / srs(requirements definition) / test-case-spec(test case specification) / test-plan(test plan) / test-design-spec(test design specification) / test-procedure-spec(test procedure specification) / test-strategy(test strategy), agile: user-story(user story) / acceptance-criteria(acceptance criteria = Given-When-Then) / design-doc(design agreement document) / adr(architecture decision record) / rfc(Request for Comments = pre-decision proposal) / pr-faq(PR-FAQ = Amazon Working Backwards / working backwards from the plan), for a total of 19 doc_type. If asked for anything else, announce "recipe not yet prepared = future extension" and do not force generation relying only on the principles layer and the responsibility comparison table (avoid false comprehensiveness).
Read the applicable recipe. For data-design, waterfall/basic-design/data-design.md; for external-design, waterfall/basic-design/external-design.md; for architecture-design, waterfall/basic-design/architecture-design.md; for nonfunctional-design, waterfall/basic-design/nonfunctional-design.md; for operations-design, waterfall/basic-design/operations-design.md; for detailed-design-data, waterfall/detailed-design/data-design.md; for detailed-design-process, waterfall/detailed-design/process-design.md; for srs, waterfall/requirements/srs.md; for test-case-spec, waterfall/test/test-case-spec.md; for test-plan, waterfall/test/test-plan.md; for test-design-spec, waterfall/test/test-design-spec.md; for test-procedure-spec, waterfall/test/test-procedure-spec.md; for test-strategy, waterfall/test/test-strategy.md; for user-story, agile/user-story.md; for acceptance-criteria, agile/acceptance-criteria.md; for design-doc, agile/design-doc.md; for adr, agile/adr.md; for rfc, agile/rfc.md; for pr-faq, agile/pr-faq.md. The required headings, includes/excludes, and template examples are there.
Generate in accordance with the principles. principles/granularity-axis.md Observe the invariants (P2: separation of What/Why and How, P4: traceability and design rationale, P5: numerical precision is a process marker, P6: verifiability, P9: no deferring NFRs). If unsure about process attribution, draw the line with the applicable row in responsibility-map.md (includes/excludes/hand off to adjacent).
After generation, run a self-check. Run mode 2 mechanical judgment once on the generated artifact, eliminate your own deviations, and then present it.

Mode 2: Deviation check

Determine whether existing documents deviate from the granularity standard.Mechanical judgment → qualitative judgment, two layers.

Determine the doc_type. Identify the type of document (mechanical judgment support is WF: data-design(basic = logical) / external-design(basic = external design) / architecture-design(basic = method design) / nonfunctional-design(basic = nonfunctional design) / operations-design(basic = operations/migration design) / detailed-design-data(detailed = physical data) / detailed-design-process(detailed = process) / srs(requirements definition) / test-case-spec(test case specification) / test-plan(test plan) / test-design-spec(test design specification) / test-procedure-spec(test procedure specification) / test-strategy(test strategy), agile: user-story(user story) / acceptance-criteria(acceptance criteria = Given-When-Then) / design-doc(design agreement document) / adr(architecture decision record) / rfc（Request for Comments）／ pr-faq(PR-FAQ), 19 in total. Other types have undefined schemas/vocabularies, so mechanical judgment becomes skipped = fail-open. Note that user-story・design-doc・test-strategy・adr・rfc・pr-faq has a vocabularyemptyNote that it returns pass rather than skipped = discussed later.acceptance-criteria・test-plan・test-case-spec・test-design-spec・test-procedure-spec has three ambiguous expected-result words,data-design・detailed-design-data・detailed-design-process は なぜなら業務 has a vocab of = discussed later).
Execute mechanical判定(deterministic; deviations that can be handled by string matching).
```
python3 scripts/check_headings.py     <markdown_path> <doc_type>
python3 scripts/check_vocabulary.py   <markdown_path> <doc_type>
python3 scripts/check_traceability.py <markdown_path> <doc_type>
```
- check_headings.py: Detects missing required headings. data-design = **basic design (logical)は 論理ER / トレーサビリティ two headings. Physical ER, table definitions, constraints, and indexes are in F1 stance Aseparated into detailed design (physical)** =waterfall/detailed-design/data-design.md（doc_type=detailed-design-data), andthis one also has mechanical判定 in place(required headings =物理ER / テーブル定義 / 制約とインデックス / トレーサビリティ). **detailed-design-process = detailed design (process details, paired with data)** required headings are モジュール構造[actual heading クラス・モジュール構造 partial match,クラス is in the body "class diagram" and false-fires, so mechanically express with the latter word = decoy avoidance] / 処理仕様 / トレーサビリティ（narrow down the required・process specification independent required, mechanically detect missing core. Data side = DB physical / process side = class/process, split the axis and avoid double definition. Both extremes, ghost doc [too thick with verbatim code] / substantially empty [too thin], are structure/quantity判定, so rubric). **external-design = basic design (external design)** required headings are 画面設計 / 外部インターフェース / トレーサビリティ(make the two pillars of externally observable specifications, UI/IF, required = detect from the side of missing external specifications. Basic design M3's second subdivision). **architecture-design = basic design (architecture design)** required headings are アーキテクチャ方式 / 技術選定 / 横断懸念 / トレーサビリティ(also detect missing cross-cutting concerns [logging/auth/error handling policy] = basic design M3's third subdivision. Presence/absence of ADR links is checked by rubric). **nonfunctional-design = basic design (nonfunctional design)** required headings are 非機能要件 / 測定方法 / トレーサビリティ（make the measurement method independently required and mechanically detect "there is a value but no measurement method = verifiable violation" as a missing heading= basic design M3's fourth subdivision).operations-design = basic design (operations/migration design)required headings are 運用方針 / 移行方針 / トレーサビリティ(detect missing both on the operations side [monitoring/BU/incident response] and the migration side [migration/cutover/rollback] = basic design M3's fifth subdivision =M3 complete）。srs = requirements definitionrequired headings are 機能要件一覧 / 非機能要件 / トレーサビリティ(NFR made required in P9 = mechanize parallel consideration at the requirements stage and prohibition of postponement.機能要件 rather than 機能要件一覧 and make it concrete＝機能要件 は 非機能要件 is a substring, so close the blind spot where the functional requirements section omission falsely passes with a partial-match checker [overall audit should_fix; among 19 doc_types, this is the only inclusion among required ones]).test-case-spec = test case specificationrequired headings are テストケース / トレーサビリティ(make traceability required = mechanize P6 requirement ID references and full-element tracing). **test-plan = test plan (second WF test)** required headings are スコープ / 終了基準 / トレーサビリティ（narrow down the required= IEEE 829 does not mandate all sections; structure/schedule/risk are recommended. Requires "out of scope + reason" in the scope to prevent scope creep [same type as Non-Goals]・Make exit criteria independently mandatory to mechanically detect missing measurable completion conditions[same type as P6・making the measurement method mandatory for nonfunctional requirements]. Not writing concrete case values in the plan = move them to test-case-spec [same type as F1] is rubric).test-design-spec = test design specification (3rd WF test document・directly above case specification)The mandatory headings of テスト条件 / 網羅方針 / トレーサビリティ（keep mandatory items limited. Test conditions are abstract [high-level cases] / concrete values go to the case specification =design specification ↔ case specification is the same type as F1 [logical ER ↔ physical ER] = split abstract/concrete。網羅方針 make independently mandatory to mechanically detect "conditions are listed but no coverage rationale"= same type as making the measurement method mandatory for nonfunctional requirements. Mixing in low-level cases is a structural judgment, hence rubric).test-procedure-spec = test procedure specification (4th WF test document・directly below case specification)The mandatory headings of 前提 / 実行手順 / トレーサビリティ（keep mandatory items limited。前提・セットアップ make independently mandatory to mechanically detect "start state unknown = unreproducible"= same type as making the measurement method/coverage policy mandatory・required is 前提 partial match with [do not place headings containing 前提 in the recommended section = decoy avoidance].Separation of execution ↔ judgment= procedures are operations [How to run] / pass-fail judgment references case IDs in the case specification [What to expect]・mixing judgment into procedures is a structural judgment, hence rubric). **test-strategy = test strategy (5th WF test document・topmost = complete 5 test process levels)** has mandatory headings テスト方針 / テストレベル / トレーサビリティ（keep mandatory items limited。テストレベル partially matches the actual heading テストレベル/タイプ = mechanically detect missing levels/types framework of organizational standards.Abstraction boundary between strategy (organization-wide) ↔ plan (project-level)= project-specific details go to the plan test-plan・trace to higher levels [quality goals/business goals]・do not force fixed V-model 1:1 [ISTQB v4] is rubric). **user-story = user story (agile)** has mandatory headings ユーザーストーリー / 受入基準(making the acceptance criteria = AC section mandatory is the main work of the mechanical layer of user-story. Other deviation judgments are mainly rubric = described later).acceptance-criteria = acceptance criteria (agile・Given-When-Then)The mandatory headings of 受入シナリオ / トレーサビリティ(by making traceability mandatory,the first agile slice with check_traceability enabled= mechanically detect each scenario's corresponding user-story empty cell [orphan scenario]. More than 20 scenarios = split sign is rubric = user-story's more than 5 ACs = different level from story splitting).design-doc = design agreement document (agile・Google Style/arc42/C4)The mandatory headings of Context / Non-Goals / トレーサビリティ（Limit the mandatory ones to three= Because a Design Doc with "all sections mandatory = deviation," alternatives considered / cross-cutting concerns are recommended.Goals / Non-Goals Headings are mechanically expressed as required with Non-Goals = partial matching detects omissions on the scope-negation side.Goals/Non-Goals If you make the slash-inclusive form required, beware the trap that it will not partially match the actual heading Goals / Non-Goals .adr = Architecture Decision Record (agile)'s mandatory headings are Context / Decision / Status / 却下案 / Consequences（5 mandatory= Nygard 2011's 4 sections + this library's own 却下案. Related ADRs are recommended [avoid gold plating].却下案 as independently mandatory to mechanically detect "one-sided missing Why = post-hoc justification"= isomorphic to design-doc's mandatory Non-Goals and nonfunctional's mandatory measurement method. Writing the English Decision of the official name "Architecture Decision Record" in the H1 is a trap that turns required Decision into a decoy, so the recipe H1 has no English Decision. Traceability is written inside Context and not made into an independent traceability section = check_traceability skipped [same type as user-story]).rfc = Request for Comments (agile, pre-decision proposal)'s mandatory headings are 提案内容 / 代替案 / 未解決の論点 / トレーサビリティ（limited to 4 mandatory= Motivation / Scope of impact / Prior art are recommended.未解決の論点 as independently mandatory to mechanically detect "already-decided pretending to be undecided = does not constitute an RFC"= same type as ADR rejected alternatives and design-doc Non-Goals [the core also detects missing 未解決の論点・代替案 ]. required 提案内容 is a compound word = if it were "propose" alone, it would misfire on the body text "propose ~," so avoid decoys and do not include the 4 required words in the H1/recommended sections.Unlike ADR, it has an independent traceability section and check_traceability is enabled[RFC is specific to doc-standards and does not conflict with the externally owned skill format]).pr-faq＝PR-FAQ（agile・Amazon Working Backwards）'s mandatory headings are プレスリリース / 想定問答 / 成功指標 / トレーサビリティ（limited to 4 mandatory= the customer's problem / internal supplementary notes [Internal FAQ] / how to get started are recommended.成功指標 as independently mandatory to mechanically detect "missing measurable success criteria = pie in the sky"= same type as the P6 family [nonfunctional measurement method, test exit criteria / coverage policy / preconditions].FAQ is 3 characters and partially matches the H1 "PR-FAQ," turning it into a decoy, so make required the compound word 想定問答 and set the actual heading to ## 想定問答（FAQ） に[do not include "anticipated Q&A" in the Internal FAQ recommended section].Unlike ADR, independent traceability is enabled[trace targets are the corresponding customer problems / business goals = detect features not tied to customer problems as empty cells]). Neither generation nor checking makes or requests physics in basic design or data design.
- check_vocabulary.py: Detects scattered inappropriate forbidden terms in the process (SQL/DDL inside code fences is out of scope).Forbidden terms differ by doc_type= Even for the same term, legitimacy flips depending on process attribution:
  - なぜなら業務(Transcription of upper-level Why = business rationale is already present in requirements/basic design, so it is not included) is forbidden in the three processes data-design / detailed-design-data / detailed-design-process (detailed-design-process follows data from cycle-19 = "because transcription of business rationale can be picked up cleanly by machine even in process details." Rephrased business Why is viewed cross-sectionally by the rubric.SQL is not forbidden because it is a false positive from partial matching of a product name = full SQL contamination [ghost doc] is rubric).
  - btree(physical index type) is forbidden in data-design (physical premature adoption) but legitimate in detailed-design-data = not forbidden.
  - The forbidden terms of external-design (basic design = external design) are internal implementation markers＝クラス図 / シーケンス図 / インデックス / テーブル定義(4 terms. Detects premature contamination of internal implementation into externally observable specifications).API terms (REST/OpenAPI/endpoint/Swagger), technology stack names, pixels/hex,SQL are not forbidden——because they can be legitimate descriptions in external design and would cause false positives under literal matching, this is left to the qualitative viewpoint of rubric/external-design.md (P2 corrected version, same policy as cycle-4 srs).In particular, SQL is removed from vocab because partial matching falsely hits substrings of the product names PostgreSQL/NoSQL/MySQL, and SQL query contamination is viewed by the rubric (cross-sectional detection in cycle-8)。Examples of flipping by doc_type: インデックス= external-design forbidden / detailed-design-data allowed (data-design does not use the general term but the specific type btree to detect physical premature adoption, so 'index' itself is not rejected = even for the same physical index premature adoption, the detection term differs by doc_type).テーブル定義= srs forbidden / detailed-design-data required heading / external-design forbidden.
  - The forbidden terms of architecture-design (basic design = architecture design) are internal implementation markers＝クラス図 / メソッド仕様 / シーケンス図(3 terms).Technology stack names, product names,SQL are not forbidden——architecture design has technology selection at its core and technology names are legitimately essential, and SQL falsely hits substrings of product names, so SQL query contamination is left to the qualitative viewpoint of rubric/architecture-design.md (vocab asymmetry).Examples of flipping by doc_type: メソッド仕様= architecture-design forbidden / detailed-design-data allowed (detailed design has method specifications at its core). Records of design decisions (ADR) are delegated to the architecture-decision-records skill, and this skill only confirms the existence of ADR links (S5).
  - The forbidden terms of nonfunctional-design (basic design = nonfunctional design) are downstream implementation premature adoption markers＝チューニング手順 / 計測スクリプト(2 terms. Detects premature contamination of realization means).Technology stack names, product names,SQL・Vague expressions ("at high speed", "stably", "sufficiently") are not prohibited——In non-functional design, technical names are legitimate as measurement target environments and monitoring product names,SQL causes false positives as a substring of a product name, and vague expressions also cause false positives because they cannot be distinguished from legitimate contexts by partial matching; therefore, the lack of quantification of grade values and the leak of implementation means are left to the qualitative perspective of rubric/nonfunctional-design.md (vocab asymmetry).測定方法 was made an independent mandatory heading, so "there is a value but no measurement method = verifiable violation" is caught by machine (missing heading).
  - The prohibited words of operations-design (basic design = operations/migration design) are downstream-preemption markers＝手順書 / 移行スクリプト(2 words. Detect preemption of execution means and implementation rather than policy).手順Standalone・インフラ構成・tech stack names・SQL are not prohibited——because of partial-match false positives with "policy for operation procedures", "detailed values of infrastructure configuration to be finalized in a later process", and product names such as PostgreSQL (avoid false positives by narrowing with the deliverable name 手順書 ). Mixing in the full migration SQL, the granularity of "procedures, not policy", and ambiguity of rollback conditions are left to rubric/operations-design.md(perspectives 1/2/5) (vocab asymmetry).
  - The prohibited words of srs (requirements definition) are design-structure markers＝クラス図 / テーブル定義 / モジュール分割 / インデックス(detect design preemption into requirements).Tech stack names, product names, and protocol names are not prohibited even in srs——they may appear with rationale as legitimate constraints (P2 revised edition), and literal matching causes false positives. Whether a technical name is design preemption or a legitimate constraint is left to qualitative judgment =rubric/srs.md .
  - The prohibited words of test-case-spec (test case specification) are ambiguous-expression markers for expected results＝正しく表示 / 正しく動作 / 適切に処理(detect unverifiable expected results = P6: expected results must be written measurably/observably).Transcription of requirement sentences is a structural problem that cannot be rejected by specific words, so it is not included in the machine vocabulary and is left to qualitative judgment =rubric/test-case-spec.md(perspective 2: requirement-transcription anti-pattern). Vague expressions that also do not count as prohibited words, such as paraphrases ("easy to use", "fast enough"), are caught by rubric perspective 1.
  - test-plan (test plan/WF) also follows the 3 words of test-case-spec＝正しく表示 / 正しく動作 / 適切に処理(unmeasurable markers for exit criteria = P6).It is not that it has vocab because it is WF; empirical verification decided the follow-through= it has a role as a P6 violation of exit criteria (real-machine deviation) and does not cause false positives on legitimate prose (real-machine pass・適切に処理∉適切にカバー）。Whether vocab is present is determined by "whether deviations can be cleanly caught by machine", not by agile/WF distinction(WF-side proof of the design-doc/cycle-14 principle = paired with user-story/design-doc being emptied even under agile). Technical names, product names,SQL・tool names (JUnit, etc.) are リソース・環境 etc., it appears legitimately, so it is not prohibited. Mixing case-specific values into the plan (structural judgment, same type as F1), and paraphrases of the termination criteria other than the three words ("sufficiently", "comprehensively") are rubric/test-plan.md へ。
  - test-design-spec (test design specification, WF) also follows the three words＝正しく表示 / 正しく動作 / 適切に処理(non-observability marker for test conditions = P6).Because it is abstract, there was a possibility it would rarely come into play, but empirical verification confirmed it is followed= deviations where non-observable conditions of the "viewpoint of confirming that the function operates correctly" type get mixed into high-level cases actually exist (real-machine deviation), and there were no false positives on legitimate narrative text (real-machine pass). If it had rarely come into play, it would have been left empty = a re-demonstration of "whether vocab exists is determined by whether deviations can be cleanly picked up by machine, not by agile/WF distinction".Mixing in low-level cases (specific values) is a structural judgment, so it is not vocab but rubric(same type as F1, viewpoint 3). Technical names,SQL, and tool names are legitimate in target environment/technique descriptions, so they are not prohibited.
  - test-procedure-spec (test procedure specification, WF) also follows the three words＝正しく表示 / 正しく動作 / 適切に処理。The three words appearing in a procedure specification = a sign that judgment of expected results (the domain of the case specification) has mixed into the procedure= it functions as a deviation (empirical verification showed it does come into play = real-machine deviation / no false positives on operation descriptions such as "press the button" or on precondition setup = real-machine pass). If it had rarely come into play, it would have been left empty = a third re-demonstration of "whether vocab exists is determined by whether deviations can be cleanly picked up by machine, not by agile/WF distinction".Mixing judgment criteria into procedures and backflow of design intent are structural judgments, so they are not vocab but rubric(execution↔judgment boundary, viewpoint 3). Technical names,SQL, and tool names are legitimate in preconditions/execution environments, so they are not prohibited.
  - The vocab of test-strategy (test strategy, WF) is empty(the only one among the five WF tests). Strategy describes organization-wide policy-level matters (quality goals, overall approach, test level/type standards) and does not write expected results, completion criteria, test conditions, or pass/fail judgmentNot write= there is no main battlefield for the three words. The three words can appear as literal text (of the "take it as a quality goal that the main functions operate correctly" type), but that is a narrow literal subset of the broader deviation "unmeasurable quality goals [high quality/stable/sufficient]", and because of P6 and false-positive proneness it is the domain of rubric = mechanizing only the three words creates false reassurance =strictly applying "cleanly pickable up = follow" and leaving it empty。The four followings and one empty across case/plan/design-spec/procedure-spec is the strongest demonstration of the principle that "whether vocab exists is determined not by process but by the machine-detectability of deviations". Mixing in project-specific details and vagueness of policy are rubric/test-strategy.md へ。
  - The vocab of user-story (user story, agile) is empty. Implementation verbs (work such as configure/upgrade/migrate) arethe same token as legitimate user goalscan be (the same verb expresses both value and implementation work), and partial matching of English verbs migrated/upgrades etc. would cause false positives, so machines cannot split it off = judgment of implementation verbs is rubric へ（rubric/user-story.md viewpoint 5 is what is intended and looked at).An empty vocab returns status=pass (not skipped) = the narrow claim "no deviation from prohibited words"and is different from skipped, which means out of scope for machine judgment. The real machine-layer work of a user-story is presence/absence of an AC (acceptance criteria) section(required heading check), not prohibited-word matching. Whether the subject is System / missing so that / number of ACs / INVEST violations are all judgments of structure, count, and context, so the rubric is the primary judgment (S4 and agile are rubric-led).
  - acceptance-criteria (acceptance criteria, agile), unlike user-story, has a vocab＝正しく表示 / 正しく動作 / 適切に処理(three words marking ambiguous expected results). Reason = the observability of Then in AC is the same P6 requirement as the expected results of test-case-spec, and these three words have already been demonstrated in test-case-spec to be machine-detectable without partial-match false positives, so this is followed.The principle is not "agile = vocab is always empty" but "only deviations that can be cleanly picked up by machine are left to the machine"(user-story just happened to be empty; asymmetric). Technical names, product names,SQL, and GWT keywords (Given/When/Then) are not prohibited (false-positive avoidance). GWT structure, internal implementation contamination in Then [index scanning, etc.], unmeasurable expressions other than the three words, scenario count [over 20], and quality of trace linkage go to rubric/acceptance-criteria.md (agile rubric-led is maintained).
  - The vocab of design-doc (design agreement document, agile) is empty(same type as user-story). Design Doc deviations (mandatory filling of all sections, filling all 12 arc42 sections, drawing all C4 L4 class diagrams from the start, over-documentation of self-evident implementation, gold plating) are judgments of structure/volume/context and cannot be picked up by partial matching, and making "class diagram" a prohibited word would cause false positives in legitimate delegation sentences to C4/detailed design.Important principle = presence/absence of vocab is determined by "whether deviations of that doc_type can be cleanly picked up by machine," not by agile/WF distinction(AC had a vocab because it could be picked up, while user-story and design-doc are empty because they cannot be picked up). Drawing all L4, gold plating, self-evident documentation, ex post justification of alternatives, and quality of trace linkage go to rubric/design-doc.md . Important decisions are delegated to ADR links (S5).
  - The vocab of adr (architecture decision record, agile) is empty(the fourth empty case after user-story / design-doc / test-strategy). ADR deviations (ex post justification, trivial decisions, no Why) are judgments of structure/context and cannot be picked up by partial matching (absence of explicit rejected options is already machine-detected by missing headings), andaccepted when made a prohibited word would cause false positives with the same token as a legitimate approval Status declaration.Following the principle that "whether a doc_type has vocab is determined by whether its deviations can be cleanly caught by machine, not by agile/WF distinction"(AC has vocab because it could be caught; user-story/design-doc/adr have none because they could not). For the quality of post-hoc justification, trivial, and one-sided Why omissions, see rubric/adr.md . Numbering (ADR-NNNN) and content evaluation are delegated to the architecture-decision-records skill (S5).
  - rfc (Request for Comments, agile) has an empty vocab(the fifth empty case following user-story / design-doc / test-strategy / adr). An RFC is a pre-decision proposal document and does notwrite expected results, completion criteria, or test pass/fail= the main battlefield of the three ambiguous-expected-result words is structurally absent; rather, an RFC's legitimate statement of undecided matters about future behavior ("whether the proposed mechanism works correctly is an unresolved point to be examined") causes false positives via partial matches. An RFC's true deviations (preempting implementation details, presenting decided matters as undecided, straw-man alternatives) do not support partial matching and require structural/contextual judgment = the domain of the rubric. Technical names, product names, andSQL are not prohibited (in RFCs, technical names legitimately appear frequently during technology-selection exploration).Following the principle that "whether a doc_type has vocab is determined by whether its deviations can be cleanly caught by machine, not by agile/WF distinction"。
  - pr-faq (PR-FAQ, agile) has an empty vocab(the sixth empty case following user-story / design-doc / test-strategy / adr / rfc). A PR-FAQ is a proposal document that works backward from the plan and does notwrite expected results, completion criteria, or test pass/fail= the main battlefield of the three ambiguous-expected-result words is structurally absent; rather, a PR's legitimate description of future customer experience ("overstocked rows will come to be displayed correctly" = a statement of benefit) causes false positives via partial matches. A PR-FAQ's true deviations (turning the PR into an internal feature list, optimism bias, slide-ification/a 15-page feature list, ambiguous expressions of success metrics such as "greatly improved" and "high satisfaction" = adverbs/adjectives, hence false positives via partial matches just like nonfunctional's "quickly") are judgments of structure/volume/context = the domain of the rubric. Technical names, product names, andSQL are not prohibited.Following the principle that "whether a doc_type has vocab is determined by whether its deviations can be cleanly caught by machine, not by agile/WF distinction"。
- check_traceability.py: Of the traceability table,empty cells = isolated design elements(an empty corresponding-requirement-ID column = a design element not tied to any requirement, a scope-creep candidate, a P4 violation) is detected deterministically (cycle-12, newly established by the F5 resolution). ID column identification is by "excluding the first column + columns containing '対応/上位要求'", and the test-case-spec reverse-lookup table (要件 ID｜検証するケース ID｜カバレッジ) is out of scope =（なし）is not falsely detected.Documents that do not have a traceability section user-story・adr は skipped(fail-open. adr writes the trace [driven by requirements/design] inside Context and does not have an independent trace section = avoiding conflict with the architecture-decision-records skill, which owns numbering and recording formats. P4 requires 'traceable', not 'trace table mandatory', so there is no contradiction).acceptance-criteria is the first slice in agile where check_traceability becomes enabled= by including "correspondence" in the ID column header of the trace table (対応 user-story), each scenario's empty cell for its corresponding user-story [orphan scenario] is machine-detected.design-doc is likewise trace-enabled(each design decision's empty cell for its corresponding user-story/requirement = detecting orphan design decisions).rfc is likewise trace-enabled(each proposal/issue's empty cell for its corresponding requirement = detecting orphan proposals [scope creep candidates]. Symmetric with the fact that ADR is skipped inside Context,asymmetric= RFC is doc-standards-specific and does not conflict with externally owned skill formats, and has an independent trace section).pr-faq is likewise trace-enabled(each claim/metric's empty cell forits corresponding customer problem/business goal= detecting features not tied to a customer problem = Working Backwards violations/product-out. Being the most upstream, the trace target is not a requirement ID but a customer problem/business goal = same shape as test-strategy's upstream trace).
- Output is JSON.status は pass / deviation / skipped。deviation exit 1 only when.
- fail-open: if the schema/vocabulary is undefined, the JSON is corrupted, or it cannot be read, then skipped(exit 0). Report skipped not as "no deviation" but as "outside the scope of machine judgment" (do not swallow it).
report deviations. Enumerate as-is the detected missing headings (missing), prohibited-word hits (hits= term and reason). Machine judgment only reports detections; whether to block is left to the user's judgment.
run qualitative judgment. Deviations that machines cannot catch (intrusion of abstraction level, too thick/too thin, presence or absence of design rationale, semantic validity of traceability, readability; for tests, paraphrasing of expected results that cannot be verified and requirement transcription; for user-stories, presence or absence of subject/value, whether it is an implementation verb, the number of ACs, INVEST) are checked against the relevant rubric (for data-design, rubric/data-design.md, for external-design, rubric/external-design.md, for architecture-design, rubric/architecture-design.md, for nonfunctional-design, rubric/nonfunctional-design.md, for operations-design, rubric/operations-design.md, for detailed-design-data, rubric/detailed-design-data.md, for detailed-design-process, rubric/detailed-design-process.md, for srs, rubric/srs.md, for test-case-spec, rubric/test-case-spec.md, for test-plan, rubric/test-plan.md, for test-design-spec, rubric/test-design-spec.md, for test-procedure-spec, rubric/test-procedure-spec.md, for test-strategy, rubric/test-strategy.md, for user-story, rubric/user-story.md, for acceptance-criteria, rubric/acceptance-criteria.md, and for design-doc rubric/design-doc.md, and for adr rubric/adr.md, and for rfc rubric/rfc.md, and for pr-faq rubric/pr-faq.md＝agile uses the rubric as the primary judgment) and examine from that perspective. Strictly observe the rubric's operating rules:
- Excerpt of evidence required: failWhen judging as (deviation), always attach theoriginal text excerptof the relevant location (section heading + relevant line). Judgments without an excerpt or judgments by summary are invalid.
- fail-open: When it cannot be determined whether something is a deviation, do not conclude it is a deviation; lean to pass and leave the reason as "judgment not possible, therefore to human judgment".
- Items that can be settled by mechanical judgment (presence of required headings, simple occurrence of prohibited words) shall not be duplicated in the rubric.
Present the results together. Report mechanical judgment (pass/deviation/skipped) and qualitative judgment (pass/fail per perspective + excerpt) separately.

doc_type が data-design / external-design / architecture-design / nonfunctional-design / operations-design / detailed-design-data / detailed-design-process / srs / test-case-spec / test-plan / test-design-spec / test-procedure-spec / test-strategy / user-story / acceptance-criteria / design-doc / adr / rfc / pr-faq If it is other than that, since mechanical judgment is skipped and the qualitative rubric is also not yet in place, announce "this document has no recipe prepared = out of scope" and stop the check. Do not issue a mistaken pass judgment.

fail-safe (when the library is absent)

If a library body such as principles/・scripts/ is not found in the skill's directory, this skill announces "library not deployed" andstops. In a state where none of the principles, recipes, or scripts can be referenced, donot performgeneration by guesswork or checking by original criteria (because mistaken generation or checking is itself a deviation from the standard).
If the library exists but only the schema/vocabulary definitions are missing, the checker itself falls back safely with fail-open (skipped). This is not an announcement stop but is reported as "the relevant process is out of scope for mechanical judgment" and compensated for by qualitative judgment.
Distinction: The library as a whole is absent → announcement stop. Individual definitions absent → fail-open with skipped report.

Delegation (do not expand responsibilities)

The responsibility of doc-standard is limited to "granularity boundaries of process documents and handoffs between processes". The following are not handled, and if a corresponding skill is present, they are passed to it. Do not define them twice (for details, see the delegation table in principles/responsibility-map.md ).

Code quality (naming, comments, structure, tests) → coding-principles
Recording design decisions (ADR numbering, generation) → architecture-decision-records(this skill only references, links, and checks existence)
Two-perspective review of deliverables → review-handoff / santa-method(it only provides granularity as a single perspective)

Design decision: Co-locate generation/inspection (reason: co-locate while the trigger words in the description can be separated for both generation and checking uses. If the description becomes bloated and splitting by process improves invocation accuracy, or if the triggers for generation and checking come into conflict, split them and make that decision an ADR).