dakota-review

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

Repositorio: projectbluefin/dakota
Última actividad en el origen: 19 de agosto de 2026 a las 01:26
Idioma detectado de SKILL.md: inglés
Estrellas: 147
Forks: 28

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.

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

El comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.

¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

SKILL.md

Instrucciones de origen · Vista previa de solo lectura

Volver a la búsqueda Volver a la instalación

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

Ver todos los de este repositorio

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

Datos de origen

Opciones de instalación

Revisa los archivos de origen

Más de este repositorio

Más de este repositorio

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