Review knowledge setup#2
Conversation
Add a template for reporting corrections in issues.
Configure Dependabot to check for updates weekly for GitHub Actions, npm, and pip dependencies.
Adds a GitHub Actions workflow for link checking markdown files using Lychee.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Summary of ChangesHello @s977043, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request initializes the core infrastructure for a public review knowledge repository, focusing on establishing clear governance, streamlining contribution workflows, and integrating automated quality checks. The changes aim to create a reliable and maintainable knowledge base by adopting GitHub best practices from the outset. Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Pull Request Overview
This PR establishes the foundational infrastructure for a public review knowledge repository, implementing GitHub best practices for licensing, contribution workflows, and automated quality checks. It introduces dual licensing (MIT for code, CC BY 4.0 for content), standardized contribution templates in Japanese, and automated CI workflows for link validation, Markdown linting, and prose quality checks.
Key Changes:
- Dual licensing structure with separate LICENSE-CODE and LICENSE-CONTENT files
- Japanese-language contribution templates (PR template and three issue templates) with clear checklists
- Three GitHub Actions workflows for automated quality checks (link validation, Markdown linting, Vale prose linting)
Reviewed Changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| LICENSE-CODE | MIT license for code/software components |
| LICENSE-CONTENT | CC BY 4.0 license for documentation and content |
| CITATION.cff | Citation metadata for academic/professional references |
| pull_request_template.md | Japanese PR template with validation checklist |
| .github/CODEOWNERS | Repository ownership assignment to @s977043 |
| .github/ISSUE_TEMPLATE/content_request.yml | Template for content addition requests |
| .github/ISSUE_TEMPLATE/correction.yml | Template for error correction reports |
| .github/ISSUE_TEMPLATE/term_proposal.yml | Template for terminology standardization proposals |
| .github/dependabot.yml | Weekly dependency updates for GitHub Actions, npm, and pip |
| .github/workflows/link-check.yml | Lychee-based link validation on PRs and weekly schedule |
| .github/workflows/markdownlint.yml | Markdown linting workflow configuration |
| .github/workflows/prose-lint.yml | Vale prose style checking workflow |
| .markdownlint.json | Markdown linting rules configuration |
| .vale.ini | Vale prose linting configuration using Microsoft style |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - type: textarea | ||
| id: sources | ||
| attributes: | ||
| label: 出共URLや書記（最低1つ） |
There was a problem hiding this comment.
Corrected spelling of '出共' to '出典' and '書記' to '書籍'.
| label: 出共URLや書記（最低1つ） | |
| label: 出典URLや書籍（最低1つ） |
| @@ -0,0 +1,11 @@ | |||
| name: "\U0001F4DA 用語提案/\u8868記接当" | |||
There was a problem hiding this comment.
Corrected spelling of '接当' to '整合' in the term proposal template name.
| name: "\U0001F4DA 用語提案/\u8868記接当" | |
| name: "\U0001F4DA 用語提案/\u8868記整合" |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request does a great job of setting up the foundational infrastructure for the review knowledge repository. The inclusion of licenses, contribution guidelines, issue templates, and automation workflows establishes a solid framework for future contributions. My review includes a few suggestions to fix typos in the Japanese-language templates, improve the maintainability of the CODEOWNERS file, and address a potential configuration issue with the Vale linter. Overall, these are excellent additions to the project.
| @@ -0,0 +1,4 @@ | |||
| StylesPath = .vale | |||
There was a problem hiding this comment.
The StylesPath is set to .vale, but this directory is not included in the pull request. If the Vale GitHub Action relies on styles from this local directory, it will fail. Please either add the .vale directory with the necessary style files or remove this line if the styles are provided by the action or another source.
| * @s977043 | ||
| /docs/ @s977043 | ||
| /.github/ @s977043 |
There was a problem hiding this comment.
The ownership rules for /docs/ and /.github/ are redundant because the wildcard rule * @s977043 already covers all files and directories. You can simplify this file by keeping only the wildcard rule, which makes it easier to maintain.
* @s977043
| - type: textarea | ||
| id: sources | ||
| attributes: | ||
| label: 出共URLや書記（最低1つ） |
There was a problem hiding this comment.
There appears to be a typo in the label. 出共 is likely a typo for 出典 (source/reference), and 書記 might be a typo for 書籍 (book). Correcting this will improve clarity for users creating issues.
label: 出典URLや書籍（最低1つ）| @@ -0,0 +1,11 @@ | |||
| name: "\U0001F4DA 用語提案/\u8868記接当" | |||
There was a problem hiding this comment.
There seems to be a typo in the issue template name. 表記接当 does not appear to be a correct Japanese phrase. Based on the context of 用語提案 (term proposal), you might have intended 表記統一 (notation unification).
name: "📚 用語提案/表記統一"| @@ -0,0 +1,12 @@ | |||
| ## 目的 | |||
| - [ ] 説明の正確性（出典あり） | |||
| - [ ] 用語/表記が taxonomy と整合 | |||
There was a problem hiding this comment.
For consistency with the rest of the Japanese text in this file, consider replacing the English word taxonomy with a Japanese equivalent. For example, you could use 用語集 (yougoshuu) or write taxonomy in Katakana as タクソノミー.
| - [ ] 用語/表記が taxonomy と整合 | |
| - [ ] 用語/表記が用語集と整合 |
| ## チェック | ||
| - [ ] `Link Check` / `Markdown Lint` / `Prose Lint` が全て通過 | ||
| - [ ] 画像の出典とライセンス表記 | ||
| - [ ] 図の元データ（.drawio など）を `assets/` に同包 |
There was a problem hiding this comment.
The word 同包 (douhou) is used here, but in a technical context like including files in a commit, the word 同梱 (doukon) is more idiomatic and commonly used. Consider replacing it for better clarity.
| - [ ] 図の元データ（.drawio など）を `assets/` に同包 | |
| - [ ] 図の元データ（.drawio など）を `assets/` に同梱 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - uses: actions/checkout@v4 | ||
| - uses: DavidAnson/markdownlint-cli2-action@v17 | ||
| with: | ||
| globs: | | ||
| **/*.md |
There was a problem hiding this comment.
The workflow runs DavidAnson/markdownlint-cli2-action@v17, which only reads configuration files named .markdownlint-cli2.* (or a file passed via the config input) and expects the file contents to be wrapped under a config key. The repository adds .markdownlint.json with plain rule settings (MD013, MD033, MD041), but that file is ignored by CLI2, so those rules remain enabled and pull requests will fail once long lines or inline HTML appear. Consider renaming the file to .markdownlint-cli2.jsonc (with { "config": { … } }) or pass it explicitly via the action inputs so the intended rule relaxations are applied.
Useful? React with 👍 / 👎.
- Remove files parameter from prose-lint.yml to use .vale.ini config - Add artifact upload to link-check.yml for detailed error reporting
- Add Packages = Microsoft to .vale.ini for automatic style download - Add continue-on-error to Link Check for artifact upload even on failures
- Move --output and --format from args to with block - Fix 'output is set in args as well as in the action configuration' error - Improve maintainability by explicit parameter declaration
There was a problem hiding this comment.
Pull Request Overview
Copilot reviewed 37 out of 38 changed files in this pull request and generated 9 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| - **複雑性・保守性**: 単純化余地・将来の理解容易性 | ||
|
|
||
| - **テスト**: 適切で納入的か |
There was a problem hiding this comment.
The phrase '納入的' appears unclear in this context. Consider whether '納得的' (convincing) or '網羅的' (comprehensive) was intended. The current text may confuse readers.
| - **テスト**: 適切で納入的か | |
| - **テスト**: 適切で網羅的か |
|
|
||
| レビュー自体の健全性: | ||
|
|
||
| - **小さく、焦点を絞る**（~400行/ レビューを目定） |
There was a problem hiding this comment.
The term '目定' appears to be a typo. Consider changing to '目安' (guideline/target) which is the standard term for this context.
| - **小さく、焦点を絞る**（~400行/ レビューを目定） | |
| - **小さく、焦点を絞る**（~400行/ レビューを目安） |
|
|
||
| - **協調的・非敵対的**、仮定で断じず**質問から入る** | ||
|
|
||
| - **方程かつ建設的**なフィードバック |
There was a problem hiding this comment.
The term '方程' appears to be a typo. Consider changing to '丁寧' (polite) or '適切' (appropriate) which would make more sense in the context of feedback.
| - **方程かつ建設的**なフィードバック | |
| - **丁寧かつ建設的**なフィードバック |
|
|
||
| - 生成コードが仕様を満たすかを **シンボリック実行/モデル検査/証明支援** で検証 | ||
|
|
||
| ### 有効性メトリクス(虚榮を避ける) |
There was a problem hiding this comment.
The term '虚榮' uses an uncommon kanji. Consider changing to the standard '虚栄' for better readability.
| ### 有効性メトリクス(虚榮を避ける) | |
| ### 有効性メトリクス(虚栄を避ける) |
|
|
||
| - **意図との一致**（PR説明・チケットとの整合） | ||
|
|
||
| - 受加ではなく **敵対的テスト生成**（ミューテーション / シンボリック実行） |
There was a problem hiding this comment.
The term '受加' appears unclear. Consider whether '受動的' (passive) or '楽観的' (optimistic) was intended to provide better contrast with '敵対的'.
| - 受加ではなく **敵対的テスト生成**（ミューテーション / シンボリック実行） | |
| - 受動的ではなく **敵対的テスト生成**（ミューテーション / シンボリック実行） |
|
|
||
| - 循環的/認知複雑度、コードスメル、命名、コメントの質 | ||
|
|
||
| - スタイルガイド処理を機械で扱い主覧論争を回避 |
There was a problem hiding this comment.
The term '主覧論争' appears to be a typo. Consider changing to '主観論争' (subjective disputes) which is more commonly used in this context.
| - スタイルガイド処理を機械で扱い主覧論争を回避 | |
| - スタイルガイド処理を機械で扱い主観論争を回避 |
|
|
||
| ### モジュラーなエージェント群 | ||
|
|
||
| - **CoordinatorAgent**: 台抜。専門エージェントの結果を統合し要約。HITLのエスカレーション判断。 |
There was a problem hiding this comment.
The term '台抜' appears unclear or may be a typo. Consider whether '司令塔' (command tower/coordinator) or '中枢' (central hub) was intended to better describe the coordinator role.
| - **CoordinatorAgent**: 台抜。専門エージェントの結果を統合し要約。HITLのエスカレーション判断。 | |
| - **CoordinatorAgent**: 司令塔。専門エージェントの結果を統合し要約。HITLのエスカレーション判断。 |
|
|
||
| - 人間は**理由・格振・不確実性**を一直で把握 | ||
|
|
||
| - **オーバーライド理由を学習データ化** → 偽陳陽性を減らしドメイン適合が進む |
There was a problem hiding this comment.
The term '偽陳陽性' appears to be a typo. The standard term is '偽陽性' (false positive). Consider removing '陳' for clarity.
| - **オーバーライド理由を学習データ化** → 偽陳陽性を減らしドメイン適合が進む | |
| - **オーバーライド理由を学習データ化** → 偽陽性を減らしドメイン適合が進む |
|
|
||
| - DevOps/MLOpsエンジニア: CI/CDに自律的な品質ゲートを組み込みたい方 | ||
|
|
||
| - AppSec抽象者: AI生成コードのセキュリティリスクを系統的に管理したい方 |
There was a problem hiding this comment.
The term 'AppSec抽象者' appears to be a typo. Consider changing to 'AppSec担当者' (AppSec personnel) or 'AppSec実践者' (AppSec practitioners) for clarity.
| - AppSec抽象者: AI生成コードのセキュリティリスクを系統的に管理したい方 | |
| - AppSec担当者: AI生成コードのセキュリティリスクを系統的に管理したい方 |
- checklist.md: '主覧論争' → '主観的論争' - README.md: '必要に従って' → '必要に応じて'
There was a problem hiding this comment.
Pull Request Overview
Copilot reviewed 37 out of 38 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (1)
docs/framework/security-gauntlet.md:39
- The text '誤脫を隔た' appears garbled and unclear. This should likely be '誤検出を排除' or similar clear phrasing.
| ロールプレイ / DAN | 出力検証で誤脫を隔た |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -28,8 +40,10 @@ AI生成コード特有のリスクを振り返え、**必ず通過する多段 | |||
| | 難読化 / タイボ | 入力正規化・怪しいパターン検知 | | |||
| | テンプレ破壊 | 無害な定型プロンプトへ置換 | | |||
| | コンテキスト汚染 | 重要項前のセッション検証 | | |||
There was a problem hiding this comment.
Typo in '重要項前' should be '重要項目前'.
| | コンテキスト汚染 | 重要項前のセッション検証 | | |
| | コンテキスト汚染 | 重要項目前のセッション検証 | |
There was a problem hiding this comment.
Pull Request Overview
Copilot reviewed 37 out of 38 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
markdownlint-cli2-actionが正しく設定を読み込めるように、 .markdownlint-cli2.jsonc を追加。config キーでラップした 適切な形式で設定を提供。
- Remove unused `import matter from 'gray-matter'` (Copilot #4) - Add explicit ID collision deduplication in convertAgentSkillToRR() so duplicate frontmatter IDs get `-2` suffix instead of silent overwrite (Sentry #1, Copilot #2) - Resolve fromPath relative to projectRoot instead of CWD in discoverAgentSkillPaths() (Copilot #3) - Clarify --to help text for import/export subcommands (Gemini #5) - Add test for colliding explicit IDs Co-Authored-By: Claude Opus 4.6 <[email protected]>
* docs(examples): add risk-map example file + adoption guide Codex's final-pass review (post-25-PR) flagged that docs/guides reference .river/risk-map.yaml but the repo carries no concrete example for adopters to copy. Add one under examples/risk-map/ with a README explaining the three action values and the apply / verify flow. Contents - examples/risk-map/risk-map.yaml — sample with 10 rules covering require_human_review (security-sensitive files, credentials, CI workflows), escalate (LLM call path, config, action dist, package.json), and comment_only (docs, pages, tests). Each rule has a reason string so adopters see the intent, not just the pattern. - examples/risk-map/README.md — adoption guide pointing at schemas/risk-map.schema.json, the user guide pages/guides/repo-wide-review.md, the execution-context-contract doc, and PR #877 (riskAssessment forwarding on the exec path). - examples/README.md — link to the new directory. The example was validated end-to-end with the real loadRiskMap + evaluateRisk implementation: 10 rules parse cleanly, sample paths classify correctly (require_human_review hit on secret-redactor.mjs, escalate on review-engine.mjs, comment_only on docs/, fall-through on unknown paths). No code or runtime change. 1087/1087 tests green. Refs: #800 (Codex final-pass review item #2 of 3). Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * docs(examples): correct risk-map verification + use absolute schema link (gemini PR #896) Apply both gemini PR #896 comments. HIGH: the README's verify step claimed "jq .plan.riskAssessment /tmp/r.json" would show aggregateAction / escalatedFiles. End-to-end test against the real runReviewPlan + loadRiskMap confirmed this is wrong: the artifact's `plan` schema only carries selectedSkills / skippedSkills / plannerMode. riskAssessment is computed internally and only forwarded to generateReview's prompt context. Rewrite step 4 to (a) verify file parses by any river review command succeeding and (b) state honestly that risk classification is not echoed on the artifact. MEDIUM: the YAML header comments referenced ../../schemas/... relative paths that break the moment an adopter copies this file to .river/risk-map.yaml. Replace with absolute GitHub URLs so the references stay resolvable after the copy. No code change; user-facing accuracy fix only. Refs: PR #896 (gemini review). Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> --------- Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>
* docs(runbook): add release-smoke.md (codex final-pass review item #3) Close the third drift item from Codex's final-pass review (after the v0.51.0–v0.55.0 sprint). Items #1 and #2 already landed: - #1 README Epic 1 status drift (PR #889) - #2 risk-map example (PR #896) - #3 release smoke runbook (this PR) Add docs/runbook/release-smoke.md as a sibling to docs/runbook/dev.md. It is not a release runbook (release-please handles tagging), but the smoke test that confirms a fresh tag installs cleanly for an adopter. Sections - When to run: post release-please merge, post dependabot prod-dep bump, pre announcement. - What it verifies: lint/tests/skills validate, river run dry-run, npm pack --dry-run, npm audit --omit=dev, GitHub Release presence. - Smoke sequence: single bash block, all commands must exit 0. - Release confirmation via gh: tagName / publishedAt / changelog body. - When the smoke fails: concrete recovery moves for the 5 common failure modes (lockfile drift, dist staleness, audit vuln, release 404, skill loader error), pointing at the existing docs and PRs that document each fix. - Out of scope: cross-platform install, npx river try, real LLM, Vercel. No code change. Refs: PRs #889, #896 (sibling Codex final-pass items), docs/development/npm-distribution-design.md, AGENT_LEARNINGS.md gh-api empty-commit entry. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * docs(runbook): apply gemini PR #897 review on release-smoke Both gemini comments are valid; apply. 1. Resolve TAG via the upstream GitHub Release instead of the local package.json. The previous form trusted that the operator had already pulled main after the release-please merge; if they had not, the local package.json could point at the previous version and the smoke would run against the wrong commit. Use `gh release view --json tagName --jq .tagName` so the upstream release is the source of truth. 2. The "feedback_release_please_workflow_race.md memory if available" pointer was misleading — that file is Claude's internal memory, not a repo doc. Replace with a concrete pointer to the AGENT_LEARNINGS.md 2026-05-24 entry that actually carries the gh-api empty-commit pattern in the repo. No content change beyond these two clarifications. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> --------- Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>
…iveTo, awesome-devsecops (#1393) Prepare copy-paste-ready submission materials for the top remaining external-listing candidates (awareness backlog #2/#3/#8), so the maintainer can submit quickly. Each draft's submission method was researched against the live list: - awesome-claude-code: ISSUE FORM only (recommend-resource.yml) — NOT a PR / gh CLI (CONTRIBUTING forbids it); category 'Infrastructure & DevOps'; exact form field values included. - AlternativeTo: website 'Suggest new application' wizard (no PR); note the ~1-week new-account wait; field values included. Applied review fixes: dropped the misleading 'static-code-analysis' tag (River Review is not a SAST scanner) and neutralized comparative phrasing. - awesome-devsecops: fork+PR to the MAINTAINED TaptuIT/awesome-devsecops (the higher-star devsecops/awesome-devsecops is abandoned since 2021); honest 'marginal' fit noted; entry frames it as complementing SAST. Built via a research+verify workflow; drafts checked for rule compliance, accuracy, and non-promotional tone. Actual submission is a maintainer action per the repo's external-listing policy. Co-authored-by: Antigravity <[email protected]> Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
This pull request introduces the initial setup for our public review knowledge repository based on GitHub best practices. Key additions include:
LICENSE-CODE(MIT) andLICENSE-CONTENT(CC BY 4.0) to clarify usage rights.CITATION.cffto provide citation guidelines.CODEOWNERSfile, three issue templates (content request, correction, term proposal), and a comprehensive pull request template to standardize contributions.dependabot.ymlto enable weekly updates for GitHub Actions and package managers.lychee-action), Markdown linting, and prose linting (Vale) under.github/workflows..markdownlint.jsonand.vale.inito configure lint rules and prose style.docs/directory (future pages will live here).This setup lays the groundwork for a reliable, maintainable knowledge base with clear review and update processes.