morningman opened a new pull request, #16: URL: https://github.com/apache/doris-skills/pull/16
Adds two contributor-side skills for the part of a Doris change that comes before review: writing it, and then opening its PR. A handoff file connects them, so the PR description is written from the evidence gathered during development instead of being reconstructed from the diff afterward. `doris-repo-review` already covers the review itself. Three commits: one per skill, and the docs that the two new skills made out of date. `doris-pr-description` comes first because `develop-with-evidence` points into its files. ## 1. `feat: add doris-pr-description skill` `skills/doris-pr-description` writes, rewrites, or checks the title and description of an `apache/doris` PR against a PR standard built around what a reviewer needs in the first minute: a Background for readers who don't know the module, a Problem Summary that explains the size of the diff, and the answers only the author can give (why this approach, what was tested, what changes for existing users). | Path | Purpose | |---|---| | `SKILL.md` | Four modes (Create, Update, Rewrite, Check) and the workflow: collect facts → classify → stop and ask → write → check → show and publish | | `references/types/`, `references/examples/` | 10 PR types, each with what reviewers check, its required Details fields, and a complete worked example | | `references/handoff-intake.md`, `references/development.md` | The two ends of the handoff with `develop-with-evidence`: what the PR step takes as given, and what development must establish | | `references/facts/` | Collecting facts without a handoff file: the diff, existing tests and CI coverage, where a bug came from and which release branches have it, submodule pointers | | `scripts/check_pr.py` | Structural checker: title format, PR type, sections, required fields, the Change map of a large diff, the Check List, the Feature issue rule, leftover placeholders, length. `--self-test` checks every example and type file | | `scripts/diff_profile.py` | Where a diff's lines go (production code, tests, generated output, docs, submodule pointers), overall and per commit | GitHub writes (`git push`, `gh pr create` / `gh pr edit`, and `gh issue create` for a Feature without an issue) happen only after the user confirms the drafts, or when the request itself said to publish without review. Rewrite and Check modes never write to GitHub. ## 2. `feat: add develop-with-evidence skill` `skills/develop-with-evidence` is a six-stage development workflow. Its aim is that every claim in the final PR rests on evidence that matches the final code. | Stage | What it establishes | |---|---| | 1. Scope | For a bug, that the defect is real (reproduced on the baseline, or traced through a causal chain) before any code changes, and a stop-and-ask when it is disproved or can't be judged; the contract, the acceptance results, the PR type, and a verification plan sized to the change | | 2. Implement | The causal chain or the target contract, the related paths, and the reason for every non-obvious edit | | 3. Verify | Tests that tell right from wrong: they fail on the baseline and pass on the candidate, show no false passes (zero cases, everything skipped, mocks hiding the logic), and will actually run in CI | | 4. Self-review | One purposeful pass over the current diff, always called a self-review, never an independent review | | 5. Evidence | Evidence bound to the final candidate: re-verification after later edits, commits, or rebases; stale results become `NOT_RUN` | | 6. Deliver | A `Ready` / `Partially verified: <gap>` / `Not ready: <reason>` pre-submission status and a summary for the developer | Verification is chosen by change type (`references/change-types/`: bugfix, feature, enhancement, refactor, performance, test/CI, config/build/migration, frontend and low-impact, revert). Reading-heavy evidence work, such as long logs, caller tracing, and cross-branch checks, can go to subagents; every judgment and code change stays with the main agent. The skill leaves an English handoff file at `$(git rev-parse --git-common-dir)/pr-handoff/<branch>.md`, inside `.git` so that it is never committed. It holds a PR description draft in the repository's template, the decisions and their alternatives, the parts of the change, the existing tests, the evidence entries, and the AI involvement. The skill never pushes or opens a PR. ## 3. `docs: add develop-with-evidence and doris-pr-description to the README` - Adds both skills to the "Working on Doris itself" table, with a short paragraph on how the three contributor-side skills follow a change and on the handoff file that connects the first two. Also adds two "You say / What loads" rows, the per-skill dependencies, the checker self-test under Verification, and the layout tree entries. - Rewrites the paragraph that said nothing here builds Doris or runs tests and that the only GitHub write was the PASS comment, since neither is true any longer. It now says which skill edits code, builds, and runs tests (`develop-with-evidence`), which stays read-only (`doris-repo-review`), and where GitHub writes come from. - `CLI-CONTRACT.md`: names all three contributor-side skills as outside the doriscli contract. ## Notes for reviewers - Both skills are in English, like the rest of the repository's skills (#5). `develop-with-evidence` was drafted in Chinese and is translated here one to one: same rules, structure, and file layout. A side-by-side review of the translation against the Chinese original found no omitted rules; its wording fixes are folded in. `doris-pr-description` was already English apart from the Chinese trigger phrases in its `description`; those are now English examples, with a note that requests in any language count. The repository's own triggering test (`verify/behavior/triggering.sh`) already routes Chinese prompts to skills whose descriptions are English only. - `check_pr.py` and `diff_profile.py` are marked executable, like every other script under `skills/`. - No `verify/` changes: neither skill makes a DDL or doriscli claim for L1/L2 to check, and `doris-pr-description` carries its own self-test. ## Testing - `python3 skills/doris-pr-description/scripts/check_pr.py --self-test` → `Self-test: 11 examples in 10 files, 0 problems`. - `python3 skills/doris-pr-description/scripts/diff_profile.py HEAD~3..HEAD` runs on this repository and prints the per-kind and per-commit split. - No CJK characters remain under either skill directory. Every relative link in `develop-with-evidence/SKILL.md` and `README.md` resolves, `agents/openai.yaml` parses, and both `description` fields are under the 1024-character limit (920 for `doris-pr-description`, 743 for `develop-with-evidence`). - The four source links in `develop-with-evidence/references/sources.md` return HTTP 200. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
