Brief first execution
Skill markoblogo/abvx-agent-skills/skills/brief-first-execution
Reviewable capability layer for coding agents. Portable skills, delivery gates, workflow patterns, and verification-first engineering.
npx -y skills add markoblogo/abvx-agent-skills --skill brief-first-executionAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Create a single working brief before substantial implementation, audit, or migration work. Use when tasks are non-trivial, risks are real, or the session is likely to drift without one source of truth for scope, non-goals, verification, and done criteria.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.1 KB, as published. Nobody here has run it
Brief First Execution
Start non-trivial work with one live task brief.
Goal
Reduce drift by creating a compact source of truth for:
- scope;
- non-goals;
- affected areas;
- risks;
- verification;
- done criteria.
When To Use
Use for:
- multi-file implementation;
- behavior changes;
- migrations, audits, or refactors;
- long runs where context could drift;
- work with real operational or delivery risk.
Skip for:
- tiny one-file edits with obvious blast radius;
- trivial questions that do not create lasting change.
Workflow
- Name the task
- write a short title that matches the real delivery target.
- Define scope
- describe what is in;
- keep it concrete and delivery-shaped.
- Define non-goals
- state what this task will not do;
- use this to stop opportunistic scope creep.
- List affected areas
- identify modules, docs, data flows, or systems likely to change.
- List risks
- focus on failure modes that matter for this task.
- Define verification early
- list the narrowest useful checks first;
- add broader checks only where the blast radius warrants them.
- Define done criteria
- describe what must be true before closing the task.
- Keep the brief live
- update the brief when scope changes materially;
- do not leave the brief frozen while the work mutates underneath it.
Rules
- One task, one brief.
- Scope and non-goals should both be explicit.
- Verification belongs in the brief before heavy implementation starts.
- If the task changes enough, revise the brief rather than pretending it did not.
Final Report
Return the brief itself and call out any unresolved scope or verification questions.