dakota-review

Review Dakota pull requests and work with issues, data-donation reports, labels, and contributor workflow.

Repository: projectbluefin/dakota
Letzte Quellaktivität: 19. August 2026 um 01:26
Erkannte Sprache von SKILL.md: Englisch
Sterne: 147
Forks: 28

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.

npx skills add https://github.com/projectbluefin/dakota --skill dakota-review

Der Befehl bleibt in einer Zeile. Scrollen Sie horizontal, um ihn vor dem Kopieren vollständig zu prüfen.

Sie bevorzugen eine lokale Kopie? Laden Sie die Dateien herunter, die SkillsMP derzeit vorliegen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md

Quellanweisungen · Schreibgeschützte Vorschau

Zurück zur Suche Zurück zur Installation

dakota-buildstream

BuildStream elements, junctions, patches, dependency graphs, and build failures in Dakota. Use when editing elements, project.conf, junctions, or patches.

2026-08-19

dakota-ci

Diagnose or change Dakota validation, build, publish, e2e, cache, remote-execution, and architecture workflows.

2026-08-19

dakota-image

OCI layer assembly, boot testing, installer boundaries, VM work, and local OTA verification for Dakota images.

2026-08-19

Alle aus diesem Repository ansehen

Dakota review and issue workflow

Before reviewing a PR

Read docs/workflow.md and docs/pr-checklist.md.

Compare the branch against upstream/testing unless the PR explicitly targets next.

Identify the change category and apply only its relevant checklist.

Inspect required checks without treating pending or skipped work as proven.

Review correctness after branch hygiene, scope, and test evidence.

Priorities: minimal diff, one logical change, correct target branch, appropriate checks, then implementation details.

Issue evidence

Work from scoped status/queued issues and respect existing ownership.

Do not act on hold, do-not-merge, or open design discussions.

If the issue widget says report: attached, read the linked user-owned report before asking for additional logs.

confirms: N indicates real-hardware breadth. verified: N/3 is post-ship evidence and cannot be replaced by CI.

Do not close a shipped issue with no hardware verification without explicit maintainer direction.

GitHub communication

Never post a comment, review, or body edit unless explicitly asked.

Post at most one combined comment per requested event.

Do not duplicate checks, approval counts, queue position, or other GitHub UI state.

Test reports state only what ran, pass/fail, and blockers.

Mention a person only when asking them for a specific action.

The absolute prohibition on writes to ublue-os/* also applies during review.

Review checks

Changes use BST rather than RPM/DNF/Containerfile overlays.

OCI filesystem layers are compose, not stack.

Cargo source blocks are generated.

Third-party actions are SHA-pinned; managed projectbluefin action tags remain intentional.

Commit messages are conventional and use Assisted-by:, never Co-authored-by:.

Evidence matches the completion claim.

References

name	dakota-review
description	Review Dakota pull requests and work with issues, data-donation reports, labels, and contributor workflow.

Dakota review and issue workflow

Before reviewing a PR

Read docs/workflow.md and docs/pr-checklist.md.
Compare the branch against upstream/testing unless the PR explicitly targets next.
Identify the change category and apply only its relevant checklist.
Inspect required checks without treating pending or skipped work as proven.
Review correctness after branch hygiene, scope, and test evidence.

Priorities: minimal diff, one logical change, correct target branch, appropriate checks, then implementation details.

Issue evidence

Work from scoped status/queued issues and respect existing ownership.
Do not act on hold, do-not-merge, or open design discussions.
If the issue widget says report: attached, read the linked user-owned report before asking for additional logs.
confirms: N indicates real-hardware breadth. verified: N/3 is post-ship evidence and cannot be replaced by CI.
Do not close a shipped issue with no hardware verification without explicit maintainer direction.

GitHub communication

Never post a comment, review, or body edit unless explicitly asked.
Post at most one combined comment per requested event.
Do not duplicate checks, approval counts, queue position, or other GitHub UI state.
Test reports state only what ran, pass/fail, and blockers.
Mention a person only when asking them for a specific action.
The absolute prohibition on writes to ublue-os/* also applies during review.

Review checks

Changes use BST rather than RPM/DNF/Containerfile overlays.
OCI filesystem layers are compose, not stack.
Cargo source blocks are generated.
Third-party actions are SHA-pinned; managed projectbluefin action tags remain intentional.
Commit messages are conventional and use Assisted-by:, never Co-authored-by:.
Evidence matches the completion claim.

dakota-review

Quellinformationen

Installationsoptionen

Quelldateien prüfen

Mehr aus diesem Repository

Mehr aus diesem Repository

Dakota review and issue workflow

Before reviewing a PR

Issue evidence

GitHub communication

Review checks

References

Dakota review and issue workflow

Before reviewing a PR

Issue evidence

GitHub communication

Review checks

References