Spec first delivery

Team-wide AI harness adoption plugin, \w operating model, onboarding and delivery standards coherent human-agent outcomes from day one.

Install

npx -y skills add jpantsjoha/ai-native-developer-experience --skill spec-first-delivery

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

10 stars10 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.

Copied from the file, not written here

Force plan, HLD, ADRs, and constraints to exist BEFORE any code is generated. Trigger when starting a new feature, epic, or significant change.

3.3 KB, as published. Nobody here has run it

Review the spec harder than the code. The cheapest place to be wrong is the spec.

The harness runs in this order: spec → plan → tasks → code. Skipping the spec is not faster — it is a deferred rewrite.

Establish the vision artifact — confirm the project's vision document exists and is current (e.g. docs/VISION.md or equivalent per project structure). If not, create or update it before proceeding.
Write the feature spec — document: what, why, who (user/actor), constraints, acceptance criteria, and out-of-scope. Reject vague specs ("improve performance") in favour of measurable ones ("p99 latency < 200 ms under 1k rps").
Author or reference the HLD — a high-level design covering: components affected, data flows, integration points, and failure modes. Diagrams preferred (C4 or sequence).
Create or update ADRs — one ADR per significant technical decision. Format: Context → Decision → Consequences (trade-offs). Number sequentially (ADR-NNN).
Document constraints up front — security requirements, data residency, budget ceiling, compliance scope, team skill set. Constraints missed here surface as blockers late.
Validate spec completeness — the spec is done when: acceptance criteria are testable, the failure mode is named, rollback is considered, and cost impact is estimated.
Only then: generate the implementation plan and tasks. Hand the spec (not a prompt) to the agent.

requirements/FEATURE_SPEC.md (or equivalent per project structure)
architecture/decisions/ADR-NNN-<short-title>.md (one per decision)
architecture/HLD-<feature>.md (if not already covered)
Updated project roadmap (e.g. docs/ROADMAP.md or equivalent per project structure) with new tasks or milestones

No code without a spec. If an agent begins generating code before a spec exists, stop it and invoke this skill.
Loose spec = confident but wrong output. A vague spec produces plausible-looking, wrong code. Tighten the spec first.
Spec is not a prompt. The spec is a structured document with testable criteria; a prompt is a hint. Do not substitute one for the other.
Context efficiency: Evaluate whether full spec documents are needed, or whether ADRs + plan mode provide sufficient context. Overhead should be proportional to risk.

Excuse the agent makes	Counter
"I have enough context to start coding"	No spec = no acceptance criteria = no way to know if the output is correct. Write the spec.
"The spec will slow us down"	A missing spec causes rewrites. Rewrites cost more than specs.
"The requirements are obvious"	Obvious requirements are the ones most often wrong. Write them down and verify.
"We can spec it after the prototype"	Prototypes become production. Spec it now.