From b5e9c938fbb52b8e558588211b2c8a7e58894b81 Mon Sep 17 00:00:00 2001 From: Mounil Date: Thu, 1 Jan 2026 22:03:35 +0530 Subject: [PATCH 1/3] Add CodeRabbit documentation review prompts for docs, sdk_users, and sdk_developers - General docs guidance with correctness, clarity, completeness, consistency, and navigation priorities - SDK users guidance focused on runnable examples, step-by-step clarity, and zero assumptions - SDK developers guidance emphasizing workflow accuracy, edge cases, and training progression - Edge case checks: external link versioning, deprecated patterns, audience signposts, platform gotchas, and standalone training modules - Audience alignment and explicit next steps for mixed-audience pages and training Resolves #1236 Signed-off-by: Mounil --- .coderabbit.yaml | 143 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 143 insertions(+) diff --git a/.coderabbit.yaml b/.coderabbit.yaml index 224d77eab..0747c768c 100644 --- a/.coderabbit.yaml +++ b/.coderabbit.yaml @@ -168,6 +168,149 @@ reviews: - When tests fail in CI, developers should immediately understand what broke. - Redundant setup code should be refactored, but clarity trumps abstraction. + # --- DOCUMENTATION REVIEW INSTRUCTIONS --- + - path: "docs/**" + instructions: | + You are reviewing documentation for the Hiero Python SDK. These pages serve both SDK users and SDK developers. + + Priority 1 - Correctness (code, commands, links, facts) + 1. Verify code snippets conceptually run and match the current SDK API, patterns, and file layout. + 2. Check shell commands, config examples, and workflow steps against the actual project tooling and CI setup. + 3. Validate URLs and cross-references where possible; flag clearly broken or misleading links. + 4. For external links, ensure they remain relevant and don't introduce version mismatches with our SDK. + 5. Flag references to deprecated SDK patterns without noting the modern alternative. + + Priority 2 - Clarity and comprehensibility + 1. Ensure each page states its purpose and expected outcome early. + 2. Prefer concrete, step-wise explanations over vague descriptions. + 3. Highlight missing pre-requisites or hidden assumptions that would block a reader. + + Priority 3 - Completeness and usefulness + 1. Identify critical gaps that prevent a reader from completing the described task. + 2. For larger missing sections or conceptual overviews, suggest filing a follow-up issue instead of blocking the PR. + 3. Encourage adding minimal examples or links when they would unlock understanding. + + Priority 4 - Consistency with existing docs + 1. Encourage consistent terminology with the SDK, examples, and tests (e.g. operator, client, network, transaction lifecycle). + 2. Suggest aligning naming and structure with existing docs when inconsistencies could confuse readers. + 3. Avoid bikeshedding tone or style when meaning is already clear. + + Priority 5 - Accessibility and navigation + 1. Check headings and sections form a logical reading path. + 2. Encourage scannable sections, short paragraphs, and descriptive headings where it materially aids navigation. + + Audience alignment + - Confirm each page makes clear which audience it serves (SDK user, SDK developer, or both) and stays focused on their goals. + - Flag mixed guidance that lacks transitions or pointers to the audience-specific sections. + - For pages serving both audiences, suggest clear signposts (e.g., "if you're an SDK user, skip to X; if you're a developer, continue here"). + + PHILOSOPHY + - Treat documentation as work-in-progress: optimize for correctness and clarity over perfection. + - Prefer incremental improvements and follow-up issues for bigger restructures or training gaps. + - Keep feedback concise, action-oriented, and focused on what most improves reader success. + + CRITICAL PRINCIPLES + - Flag incorrect or outdated code, commands, or links. + - Flag steps that cannot be followed successfully as written. + - Do not request large-scale restructures unless current structure actively blocks understanding. + + AVOID + - Avoid lint-style feedback on Markdown formatting or minor wording when meaning is already clear. + - Avoid proposing new conventions without clear benefit or alignment with existing docs. + - Avoid turning every high-level gap into a blocker; prefer suggesting an issue instead. + + - path: "docs/sdk_users/**" + instructions: | + These documents are for SDK users who want to USE the Hiero Python SDK quickly and correctly, not learn internals or project workflow. + + Priority 1 - Code snippet correctness and completeness + 1. Ensure examples are copy-pasteable and complete enough to run (imports, client/operator setup, core logic). + 2. Verify import paths and APIs follow current patterns, e.g. `from hiero_sdk_python... import ...`, and agree with `examples/`. + 3. Encourage minimal, realistic error handling where it prevents user confusion, without overwhelming the reader. + 4. Highlight platform-specific gotchas (Windows vs POSIX, Python version constraints, virtual environment steps) that could block users. + + Priority 2 - Step-by-step clarity + 1. Check that instructions form an explicit, ordered sequence from setup to successful result. + 2. Flag vague phrases (e.g. "just configure X") and suggest concrete, actionable steps or links. + 3. Ensure required environment variables, keys, and network choices are clearly stated or linked. + 4. Verify prerequisites (e.g., `NETWORK`, operator credentials, .env defaults) align with our current quick-start guidance. + 5. Highlight edge cases that could cause confusion or errors, such as handling multiple accounts or tokens. + + Priority 3 - No hidden assumptions about SDK knowledge + 1. Assume zero prior knowledge of this SDK and minimal Hedera background. + 2. Avoid requiring knowledge of repository layout, tests, or contribution workflow. + 3. Encourage brief explanations of key concepts only as needed to complete the task. + + Priority 4 - Actionable, unambiguous instructions + 1. Prefer specific commands, parameters, and expected outputs over high-level advice. + 2. Flag ambiguous wording that could lead to multiple interpretations or errors. + 3. Suggest adding small clarifications instead of large rewrites when only a step or sentence is missing. + + Priority 5 - Real-world applicability + 1. Encourage examples that reflect realistic use cases (transfers, tokens, contracts), not only trivial snippets. + 2. Suggest cross-linking to `examples/` where it directly helps the user achieve a goal. + + PHILOSOPHY + - Time-to-first-success is the main metric: make it easy for a new user to send a working transaction. + - Keep explanations concrete, self-contained, and immediately actionable. + - Prefer small, focused improvements that make the happy path smoother. + + CRITICAL PRINCIPLES + - Do not assume any knowledge of how the SDK is implemented or how this repo is structured. + - Flag incomplete examples (missing imports, initialization, or essential parameters). + - Ensure examples match the current API and example patterns in this repository. + + AVOID + - Avoid introducing contribution, CI, or workflow details; link to developer docs instead if truly needed. + - Avoid overloading user-facing docs with deep architectural discussion. + - Avoid suggesting structural changes that do not materially improve the user's ability to complete tasks. + + - path: "docs/sdk_developers/**" + instructions: | + These documents are for SDK developers and contributors, including `docs/sdk_developers/training/**`. Assume mixed experience: some readers are new to the codebase, others are experienced. + + Priority 1 - Accuracy of workflows and commands + 1. Ensure contribution, branching, rebasing, signing (DCO, GPG), CI, linting, and testing instructions match the actual repo configuration. + 2. Verify `git` and GitHub flows agree with CONTRIBUTING.md and current project practice. + 3. Flag outdated references to scripts, make targets, directories, or configuration files. + 4. Ensure automation references (assignment guards, dry-run toggles, required permissions) match the latest workflow behavior. + + Priority 2 - Coverage of edge cases and gotchas + 1. Encourage documentation of common pitfalls (merge conflicts, flaky tests, environment issues) when they affect contributors often. + 2. Suggest referencing real examples (PRs, tests, workflows) when they clarify tricky behavior. + 3. Keep warnings concrete and actionable rather than generic. + + Priority 3 - Alignment with codebase conventions + 1. Check terminology, naming, and patterns (e.g. transaction lifecycle, Executable usage, retry logic) against the actual code. + 2. Encourage examples that reflect how the SDK is structured and tested today. + 3. Flag inconsistencies between docs, examples, and tests that could mislead contributors. + + Priority 4 - Progressive learning flow (especially training/) + 1. For training docs, ensure a logical progression from setup → small change → tests → advanced topics. + 2. Check that numbering, cross-links, and prerequisites between training files are coherent. + 3. Highlight gaps where a new contributor would not know what to do next. + 4. Encourage explicit "next steps" or pointers to subsequent modules when a lesson ends. + 5. For each training module, confirm whether it can stand alone or silently assumes knowledge from earlier modules. + + Priority 5 - References to source code and examples + 1. Encourage deep links to relevant modules, tests, and examples when they serve as canonical patterns. + 2. Ensure file paths and symbol names referenced in docs actually exist and are up-to-date. + + PHILOSOPHY + - Treat these docs as a training ground for future maintainers and regular contributors. + - Help readers move from “I cloned the repo” to “I can safely extend and debug the SDK”. + - Balance approachability for beginners with enough depth for experts looking for specific architectural details. + + CRITICAL PRINCIPLES + - Verify that all workflow and tooling instructions reflect the current CI, linting, testing, and release practices. + - Flag inaccurate references to internal architecture or modules (e.g. Executable, transaction pipeline, retry behavior). + - Ensure training materials are not misleading or internally contradictory. + + AVOID + - Avoid demanding large structural rewrites of the training program in a single PR; prefer suggesting follow-up issues. + - Avoid generic documentation advice that does not consider this repository's actual patterns. + - Avoid blocking changes for minor stylistic issues when the technical guidance is sound. + # --- CUSTOM INSTRUCTIONS FOR .GITHUB DIRECTORY --- - path: ".github/workflows/**/*" instructions: | From 23cf5787c532f42bb7a005bf5079755124d7a330 Mon Sep 17 00:00:00 2001 From: Mounil Date: Fri, 2 Jan 2026 00:55:42 +0530 Subject: [PATCH 2/3] chore: add CodeRabbit documentation prompts entry to CHANGELOG Signed-off-by: Mounil --- .coderabbit.yaml | 147 +++++++++++++++-------------------------------- CHANGELOG.md | 3 +- 2 files changed, 47 insertions(+), 103 deletions(-) diff --git a/.coderabbit.yaml b/.coderabbit.yaml index 0747c768c..cb32f5c4a 100644 --- a/.coderabbit.yaml +++ b/.coderabbit.yaml @@ -173,143 +173,86 @@ reviews: instructions: | You are reviewing documentation for the Hiero Python SDK. These pages serve both SDK users and SDK developers. - Priority 1 - Correctness (code, commands, links, facts) - 1. Verify code snippets conceptually run and match the current SDK API, patterns, and file layout. - 2. Check shell commands, config examples, and workflow steps against the actual project tooling and CI setup. - 3. Validate URLs and cross-references where possible; flag clearly broken or misleading links. - 4. For external links, ensure they remain relevant and don't introduce version mismatches with our SDK. - 5. Flag references to deprecated SDK patterns without noting the modern alternative. - - Priority 2 - Clarity and comprehensibility + Priority 1 - Correctness (code, commands, links) + 1. Verify code snippets conceptually run and match the current SDK API. + 2. Check shell commands and workflow steps against actual project tooling. + 3. Validate URLs and cross-references; flag broken or misleading links. + + Priority 2 - Clarity and completeness 1. Ensure each page states its purpose and expected outcome early. 2. Prefer concrete, step-wise explanations over vague descriptions. - 3. Highlight missing pre-requisites or hidden assumptions that would block a reader. - - Priority 3 - Completeness and usefulness - 1. Identify critical gaps that prevent a reader from completing the described task. - 2. For larger missing sections or conceptual overviews, suggest filing a follow-up issue instead of blocking the PR. - 3. Encourage adding minimal examples or links when they would unlock understanding. - - Priority 4 - Consistency with existing docs - 1. Encourage consistent terminology with the SDK, examples, and tests (e.g. operator, client, network, transaction lifecycle). - 2. Suggest aligning naming and structure with existing docs when inconsistencies could confuse readers. - 3. Avoid bikeshedding tone or style when meaning is already clear. + 3. Highlight missing prerequisites that would block a reader. + 4. For larger gaps, suggest filing a follow-up issue instead of blocking. - Priority 5 - Accessibility and navigation - 1. Check headings and sections form a logical reading path. - 2. Encourage scannable sections, short paragraphs, and descriptive headings where it materially aids navigation. - - Audience alignment - - Confirm each page makes clear which audience it serves (SDK user, SDK developer, or both) and stays focused on their goals. - - Flag mixed guidance that lacks transitions or pointers to the audience-specific sections. - - For pages serving both audiences, suggest clear signposts (e.g., "if you're an SDK user, skip to X; if you're a developer, continue here"). + Priority 3 - Consistency and navigation + 1. Encourage consistent terminology with the SDK and examples. + 2. Check headings form a logical reading path. + 3. Confirm each page makes clear which audience it serves. PHILOSOPHY - - Treat documentation as work-in-progress: optimize for correctness and clarity over perfection. - - Prefer incremental improvements and follow-up issues for bigger restructures or training gaps. - - Keep feedback concise, action-oriented, and focused on what most improves reader success. - - CRITICAL PRINCIPLES - - Flag incorrect or outdated code, commands, or links. - - Flag steps that cannot be followed successfully as written. - - Do not request large-scale restructures unless current structure actively blocks understanding. + - Treat docs as work-in-progress: optimize for correctness and clarity over perfection. + - Keep feedback concise, action-oriented, and focused on reader success. + - Do not request large-scale restructures unless current structure blocks understanding. AVOID - - Avoid lint-style feedback on Markdown formatting or minor wording when meaning is already clear. - - Avoid proposing new conventions without clear benefit or alignment with existing docs. - - Avoid turning every high-level gap into a blocker; prefer suggesting an issue instead. + - Avoid lint-style feedback on Markdown formatting or minor wording. + - Avoid proposing new conventions without clear benefit. + - Avoid turning every high-level gap into a blocker. - path: "docs/sdk_users/**" instructions: | - These documents are for SDK users who want to USE the Hiero Python SDK quickly and correctly, not learn internals or project workflow. + These documents are for SDK users who want to USE the Hiero Python SDK quickly and correctly. - Priority 1 - Code snippet correctness and completeness - 1. Ensure examples are copy-pasteable and complete enough to run (imports, client/operator setup, core logic). - 2. Verify import paths and APIs follow current patterns, e.g. `from hiero_sdk_python... import ...`, and agree with `examples/`. - 3. Encourage minimal, realistic error handling where it prevents user confusion, without overwhelming the reader. - 4. Highlight platform-specific gotchas (Windows vs POSIX, Python version constraints, virtual environment steps) that could block users. + Priority 1 - Runnable examples + 1. Ensure examples are copy-pasteable and complete (imports, setup, core logic). + 2. Verify import paths follow current patterns and agree with `examples/`. + 3. Highlight platform-specific gotchas (Windows vs POSIX, Python version) that could block users. Priority 2 - Step-by-step clarity - 1. Check that instructions form an explicit, ordered sequence from setup to successful result. - 2. Flag vague phrases (e.g. "just configure X") and suggest concrete, actionable steps or links. - 3. Ensure required environment variables, keys, and network choices are clearly stated or linked. - 4. Verify prerequisites (e.g., `NETWORK`, operator credentials, .env defaults) align with our current quick-start guidance. - 5. Highlight edge cases that could cause confusion or errors, such as handling multiple accounts or tokens. + 1. Check instructions form an explicit, ordered sequence from setup to result. + 2. Flag vague phrases (e.g. “just configure X”) and suggest concrete steps. + 3. Ensure required environment variables and network choices are clearly stated. - Priority 3 - No hidden assumptions about SDK knowledge + Priority 3 - No hidden assumptions 1. Assume zero prior knowledge of this SDK and minimal Hedera background. - 2. Avoid requiring knowledge of repository layout, tests, or contribution workflow. - 3. Encourage brief explanations of key concepts only as needed to complete the task. - - Priority 4 - Actionable, unambiguous instructions - 1. Prefer specific commands, parameters, and expected outputs over high-level advice. - 2. Flag ambiguous wording that could lead to multiple interpretations or errors. - 3. Suggest adding small clarifications instead of large rewrites when only a step or sentence is missing. - - Priority 5 - Real-world applicability - 1. Encourage examples that reflect realistic use cases (transfers, tokens, contracts), not only trivial snippets. - 2. Suggest cross-linking to `examples/` where it directly helps the user achieve a goal. + 2. Avoid requiring knowledge of repository layout or contribution workflow. + 3. Encourage brief explanations of key concepts only as needed. PHILOSOPHY - - Time-to-first-success is the main metric: make it easy for a new user to send a working transaction. + - Time-to-first-success is the main metric: make it easy to send a working transaction. - Keep explanations concrete, self-contained, and immediately actionable. - - Prefer small, focused improvements that make the happy path smoother. - - CRITICAL PRINCIPLES - - Do not assume any knowledge of how the SDK is implemented or how this repo is structured. - - Flag incomplete examples (missing imports, initialization, or essential parameters). - - Ensure examples match the current API and example patterns in this repository. + - Do not assume any knowledge of how the SDK is implemented or this repo is structured. AVOID - - Avoid introducing contribution, CI, or workflow details; link to developer docs instead if truly needed. + - Avoid introducing contribution, CI, or workflow details. - Avoid overloading user-facing docs with deep architectural discussion. - - Avoid suggesting structural changes that do not materially improve the user's ability to complete tasks. - path: "docs/sdk_developers/**" instructions: | - These documents are for SDK developers and contributors, including `docs/sdk_developers/training/**`. Assume mixed experience: some readers are new to the codebase, others are experienced. + These documents are for SDK developers and contributors, including `docs/sdk_developers/training/**`. - Priority 1 - Accuracy of workflows and commands - 1. Ensure contribution, branching, rebasing, signing (DCO, GPG), CI, linting, and testing instructions match the actual repo configuration. - 2. Verify `git` and GitHub flows agree with CONTRIBUTING.md and current project practice. - 3. Flag outdated references to scripts, make targets, directories, or configuration files. - 4. Ensure automation references (assignment guards, dry-run toggles, required permissions) match the latest workflow behavior. + Priority 1 - Workflow accuracy + 1. Ensure contribution, branching, rebasing, signing (DCO, GPG), CI, linting, and testing instructions match the repo. + 2. Verify `git` and GitHub flows agree with CONTRIBUTING.md and current practice. + 3. Flag outdated references to scripts, directories, or configuration files. - Priority 2 - Coverage of edge cases and gotchas - 1. Encourage documentation of common pitfalls (merge conflicts, flaky tests, environment issues) when they affect contributors often. + Priority 2 - Edge cases and gotchas + 1. Encourage documentation of common pitfalls (merge conflicts, flaky tests, environment issues). 2. Suggest referencing real examples (PRs, tests, workflows) when they clarify tricky behavior. - 3. Keep warnings concrete and actionable rather than generic. - - Priority 3 - Alignment with codebase conventions - 1. Check terminology, naming, and patterns (e.g. transaction lifecycle, Executable usage, retry logic) against the actual code. - 2. Encourage examples that reflect how the SDK is structured and tested today. - 3. Flag inconsistencies between docs, examples, and tests that could mislead contributors. - Priority 4 - Progressive learning flow (especially training/) - 1. For training docs, ensure a logical progression from setup → small change → tests → advanced topics. + Priority 3 - Training flow + 1. For training docs, ensure logical progression from setup → small change → tests → advanced topics. 2. Check that numbering, cross-links, and prerequisites between training files are coherent. - 3. Highlight gaps where a new contributor would not know what to do next. - 4. Encourage explicit "next steps" or pointers to subsequent modules when a lesson ends. - 5. For each training module, confirm whether it can stand alone or silently assumes knowledge from earlier modules. - - Priority 5 - References to source code and examples - 1. Encourage deep links to relevant modules, tests, and examples when they serve as canonical patterns. - 2. Ensure file paths and symbol names referenced in docs actually exist and are up-to-date. + 3. Encourage explicit “next steps” or pointers to subsequent modules when a lesson ends. PHILOSOPHY - Treat these docs as a training ground for future maintainers and regular contributors. - Help readers move from “I cloned the repo” to “I can safely extend and debug the SDK”. - - Balance approachability for beginners with enough depth for experts looking for specific architectural details. - - CRITICAL PRINCIPLES - - Verify that all workflow and tooling instructions reflect the current CI, linting, testing, and release practices. - - Flag inaccurate references to internal architecture or modules (e.g. Executable, transaction pipeline, retry behavior). - - Ensure training materials are not misleading or internally contradictory. + - Balance approachability for beginners with enough depth for experts. AVOID - - Avoid demanding large structural rewrites of the training program in a single PR; prefer suggesting follow-up issues. - - Avoid generic documentation advice that does not consider this repository's actual patterns. - - Avoid blocking changes for minor stylistic issues when the technical guidance is sound. + - Avoid demanding large structural rewrites of the training program in a single PR; prefer follow-up issues. + - Avoid generic documentation advice that does not consider this repository’s actual patterns. # --- CUSTOM INSTRUCTIONS FOR .GITHUB DIRECTORY --- - path: ".github/workflows/**/*" diff --git a/CHANGELOG.md b/CHANGELOG.md index a2f1340f6..121b2dd70 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,4 +1,4 @@ -# Changelog +# Changelog All notable changes to this project will be documented in this file. This project adheres to [Semantic Versioning](https://semver.org). @@ -125,6 +125,7 @@ This changelog is based on [Keep a Changelog](https://keepachangelog.com/en/1.1. - Updated `transfer_transaction_hbar.py` example to use `Hbar` objects instead of raw integers and added receipt checking with `ResponseCode` validation.([#1249](https://github.com/hiero-ledger/hiero-sdk-python/issues/1249)) - Renamed `pr-missing-linked-issue.yml` and `pr_missing_linked_issue.js` to `bot-pr-missing-linked-issue.yml` and `bot-pr-missing-linked-issue.js` respectively. Enhanced LinkBot PR comment with clickable hyperlinks to documentation for linking issues and creating issues. (#1264) - Enhance assignment bot to guard against users with spam PRs `.github/scripts/bot-assignment-check.sh` +- Add CodeRabbit documentation review prompts for docs, sdk_users, and sdk_developers with priorities, philosophy, and edge case checks. ([#1236](https://github.com/hiero-ledger/hiero-sdk-python/issues/1236)) ### Fixed - GFI workflow casing From 2cf00352c4baf7339149249bc6a69a3711af1051 Mon Sep 17 00:00:00 2001 From: Mounil Date: Fri, 2 Jan 2026 15:01:42 +0530 Subject: [PATCH 3/3] chore: tidy CodeRabbit documentation prompts Signed-off-by: Mounil --- .coderabbit.yaml | 41 ++++++++++------------------------------- 1 file changed, 10 insertions(+), 31 deletions(-) diff --git a/.coderabbit.yaml b/.coderabbit.yaml index cb32f5c4a..f1a2bd502 100644 --- a/.coderabbit.yaml +++ b/.coderabbit.yaml @@ -203,29 +203,17 @@ reviews: instructions: | These documents are for SDK users who want to USE the Hiero Python SDK quickly and correctly. - Priority 1 - Runnable examples - 1. Ensure examples are copy-pasteable and complete (imports, setup, core logic). - 2. Verify import paths follow current patterns and agree with `examples/`. - 3. Highlight platform-specific gotchas (Windows vs POSIX, Python version) that could block users. + Priority 1 - High-level guidance + 1. Ensure explanations are conceptual and point to `/examples` for runnable code. + 2. Check that required environment variables and network choices are clearly stated. - Priority 2 - Step-by-step clarity - 1. Check instructions form an explicit, ordered sequence from setup to result. - 2. Flag vague phrases (e.g. “just configure X”) and suggest concrete steps. - 3. Ensure required environment variables and network choices are clearly stated. - - Priority 3 - No hidden assumptions + Priority 2 - No hidden assumptions 1. Assume zero prior knowledge of this SDK and minimal Hedera background. 2. Avoid requiring knowledge of repository layout or contribution workflow. - 3. Encourage brief explanations of key concepts only as needed. PHILOSOPHY - - Time-to-first-success is the main metric: make it easy to send a working transaction. - - Keep explanations concrete, self-contained, and immediately actionable. - - Do not assume any knowledge of how the SDK is implemented or this repo is structured. - - AVOID - - Avoid introducing contribution, CI, or workflow details. - - Avoid overloading user-facing docs with deep architectural discussion. + - Keep explanations high-level and conceptual; defer runnable examples to `/examples`. + - Focus on what users need to know before diving into code examples. - path: "docs/sdk_developers/**" instructions: | @@ -236,24 +224,15 @@ reviews: 2. Verify `git` and GitHub flows agree with CONTRIBUTING.md and current practice. 3. Flag outdated references to scripts, directories, or configuration files. - Priority 2 - Edge cases and gotchas - 1. Encourage documentation of common pitfalls (merge conflicts, flaky tests, environment issues). - 2. Suggest referencing real examples (PRs, tests, workflows) when they clarify tricky behavior. - - Priority 3 - Training flow - 1. For training docs, ensure logical progression from setup → small change → tests → advanced topics. - 2. Check that numbering, cross-links, and prerequisites between training files are coherent. - 3. Encourage explicit “next steps” or pointers to subsequent modules when a lesson ends. + Priority 2 - Training flow + 1. For training docs, ensure logical progression and clear prerequisites. + 2. Check that cross-links between training files are coherent. PHILOSOPHY - Treat these docs as a training ground for future maintainers and regular contributors. - - Help readers move from “I cloned the repo” to “I can safely extend and debug the SDK”. + - Help readers move from "I cloned the repo" to "I can safely extend and debug the SDK". - Balance approachability for beginners with enough depth for experts. - AVOID - - Avoid demanding large structural rewrites of the training program in a single PR; prefer follow-up issues. - - Avoid generic documentation advice that does not consider this repository’s actual patterns. - # --- CUSTOM INSTRUCTIONS FOR .GITHUB DIRECTORY --- - path: ".github/workflows/**/*" instructions: |