Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

Commencer

completing-work

Étoiles4

Forks1

Mis à jour23 avril 2026 à 08:12

Use when about to claim work is complete or before committing - enforces verification and proposes a commit

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

apenlor

apenlor/opencode-expert-mode

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

name	completing-work
description	Use when about to claim work is complete or before committing - enforces verification and proposes a commit
license	MIT
compatibility	opencode

Completing Work

Overview

Evidence before claims. Verify before committing. Run the verification, read the output, then propose a commit.

Core principle: No completion claims without fresh verification evidence.

When to Use

Before making ANY claim of success, completion, or readiness — including finishing a task, proposing a commit, or moving to the next plan item.

The Gate

Identify what command proves the claim (test suite, build, linter)
Run the full command fresh — do not rely on a previous run
Read the output — check exit code, count failures
If PASS: propose a commit with message and changed files
If FAIL: state the actual status with evidence, fix first

If the project has no automated checks, say that explicitly and report the manual validation you performed instead of pretending a test gate exists.

Propose, Don't Execute

After verification passes, propose the commit in your response only if the user has asked for commit guidance:

Verification passed (42 tests, 0 failures).

Suggested commit:
  git add <files>
  git commit -m "feat: add user validation endpoint"

Let the user decide whether to commit. Do not run git commit automatically.

Fallbacks

If the validation command is unknown, identify the most credible available verification step and say what it does not prove
If verification cannot run in the environment, report that limitation explicitly and avoid completion claims that depend on it

Red Flags

These all mean: stop, run verification first.

Using "should pass", "probably works", "looks correct"
Expressing satisfaction before running verification
Trusting a subagent's success report without checking
Relying on a previous run instead of a fresh one
Thinking "just this once" about skipping

Claim	Requires	Not Sufficient
Tests pass	Fresh output: 0 failures	Previous run, assumption
Build succeeds	Build command: exit 0	Linter passing
Bug fixed	Original symptom now passes	"Code changed"
Requirements met	Line-by-line checklist	"Tests pass"

Plus depuis ce dépôt

même dépôt

brainstorming

apenlor/opencode-expert-mode

Explore ideas and create designs before implementation

2026-04-234

context7-mcp

apenlor/opencode-expert-mode

Fetch current library and framework documentation from Context7 instead of relying on training data

2026-04-234

executing-plans

apenlor/opencode-expert-mode

Use when you have a written implementation plan to execute - direct execution by default, subagents for complex tasks

2026-04-234

systematic-debugging

apenlor/opencode-expert-mode

Use when encountering any bug, test failure, or unexpected behavior — find root cause before proposing any fix

2026-04-234

test-driven-development

apenlor/opencode-expert-mode

Use when implementing any feature or bugfix, before writing implementation code

2026-04-234

using-expert-mode

apenlor/opencode-expert-mode

Use when starting substantive work to choose the right workflow skill without adding unnecessary ceremony to trivial interactions

2026-04-234

Completing Work

Overview

Evidence before claims. Verify before committing. Run the verification, read the output, then propose a commit.

Core principle: No completion claims without fresh verification evidence.

When to Use

Before making ANY claim of success, completion, or readiness — including finishing a task, proposing a commit, or moving to the next plan item.

The Gate

Identify what command proves the claim (test suite, build, linter)

Run the full command fresh — do not rely on a previous run

Read the output — check exit code, count failures

If PASS: propose a commit with message and changed files

If FAIL: state the actual status with evidence, fix first

If the project has no automated checks, say that explicitly and report the manual validation you performed instead of pretending a test gate exists.

Propose, Don't Execute

After verification passes, propose the commit in your response only if the user has asked for commit guidance:

Verification passed (42 tests, 0 failures). Suggested commit: git add <files> git commit -m "feat: add user validation endpoint"

Let the user decide whether to commit. Do not run git commit automatically.

Fallbacks

If the validation command is unknown, identify the most credible available verification step and say what it does not prove

If verification cannot run in the environment, report that limitation explicitly and avoid completion claims that depend on it

Red Flags

These all mean: stop, run verification first.

Using "should pass", "probably works", "looks correct"

Expressing satisfaction before running verification

Trusting a subagent's success report without checking

Relying on a previous run instead of a fresh one

Thinking "just this once" about skipping

Claim

Requires

Not Sufficient

Tests pass

Fresh output: 0 failures

Previous run, assumption

Build succeeds

Build command: exit 0

Linter passing

Bug fixed

Original symptom now passes

"Code changed"

Requirements met

Line-by-line checklist

"Tests pass"