dakota-review

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

Repositório: projectbluefin/dakota
Última atividade na origem: 19 de agosto de 2026 às 01:26
Idioma detectado do SKILL.md: inglês
Estrelas: 147
Forks: 28

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.

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

O comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.

Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

SKILL.md

Instruções da origem · Visualização somente leitura

Voltar à pesquisa Voltar à instalação

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 todas deste repositório

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

Informações da origem

Opções de instalação

Revise os arquivos de origem

Mais deste repositório

Mais deste repositório

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