implement

Implements tickets from a spec by working the unblocked frontier with TDD and reporting.

Updated Aug 13, 2026
One-click install
npx skills add https://github.com/Evolutionary-Leadership/harness --skill implement-evolutionary-leadership
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: implement
Source: https://github.com/Evolutionary-Leadership/harness/tree/main/.claude/skills/implement
Command: npx skills add https://github.com/Evolutionary-Leadership/harness --skill implement-evolutionary-leadership

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Turning a spec or a set of tickets into committed, tested code requires disciplined sequencing: knowing which ticket is unblocked, keeping acceptance criteria in view, and reporting progress without drowning observers in noise. This Skill drives that loop so implementation stays honest and traceable. ## Core Features & Use Cases - Frontier-based ticket execution: Works only tickets whose blockers are all closed, re-reading acceptance criteria before starting each one. - Paired progress reporting: Reports ticket start and close as matched pairs via the cockpit script, so a stalled session is visible instead of silent. - TDD and verification: Applies test-driven development at the seams the spec agreed on, typechecks and runs relevant tests as it goes, and runs the full project check at the end. - Use Case: After running /feature to produce a spec and tickets, invoke this Skill to implement each unblocked ticket in order, commit per ticket, run the full check, and hand off to /code-review. ## Quick Start Ask the AI to implement the work described in the current spec or the open tickets on the issue tracker, working the unblocked frontier one ticket at a time.

Frequently Asked Questions about implement

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement a feature from a spec or tickets?

Work the frontier: pick any ticket whose blockers are all closed, re-read its acceptance criteria, implement it with TDD, commit with a message naming the ticket, then close it. Repeat until no unblocked tickets remain, then run the full project check.

What is the frontier in ticket-based implementation?

The frontier is the set of tickets whose blockers are all closed, making them safe to start. Never begin a ticket with open blockers, since that violates the dependency order the tracker encodes.

Can I use this without a spec or tickets?

If you only have a feature description and no spec, the Skill says so and offers /feature instead of inventing requirements. It works from tracker tickets first, then the spec issue, then a user description.

Does this Skill push or merge the branch when finished?

No. It leaves the branch committed; pushing and merging are owned by other steps. Inside /feature the phase gate owns the push, and /to-preprod or /review owns the merge.

Why report progress as start and close pairs?

Paired reports mean an unfinished pair signals a session that died mid-ticket, rather than leaving observers guessing. Reporting per commit or per test run would produce a log nobody reads instead of a useful heartbeat.