mcpField
L
light-implement

light-implement

github.com/light-chengAgent workflows510 installsUpdated 4d ago
Repository

About light-implement

light-implement is a user-invoked skill for completing one bounded work item, verifying the artifact, and handing it to review. It defines safeguards for routing, plan gaps, and reporting.

Key features

  1. 01Pins one ticket, Spec section, or conversation slice
  2. 02Inspects project context and records sources
  3. 03Executes and locally verifies the bounded task
  4. 04Routes the artifact to a suitable review skill
  5. 05Reports results and plan gaps

Use cases

  1. 01Implementing a ready tracker ticket
  2. 02Producing and validating a bounded non-code artifact
  3. 03Stopping and reporting when approved scope no longer holds

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/light-cheng/skills --skill light-implement

After installing, type/light-implementin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

ATTRIBUTION.md
agents/
openai.yaml
references/
EXAMPLES.md
WORKFLOW.md
tests/
test_implement_contract.py

Details

From the project README

Implement

light-implement is a user-invoked bounded executor. Run it only after an explicit $light-implement request. It turns one ready work item into a verified artifact and hands it to review.

Core loop

  1. Pin one work item. Resolve exactly one ticket, Spec section, or explicit conversation slice and record it as the target. For a tracker ticket, set Status: claimed before changing any other file.
  2. Inspect relevant context. When docs/agents/light-project.md exists, read its tracker, domain-context, and review-profile fields. Then skim only the named glossary, ADRs, and files the item touches; record source locations.
  3. Offer execution routing when materially useful. Clearly bounded solo work skips routing without a judgment (WORKFLOW §3A). Otherwise make the yes/no call "would routing materially help?" through light-decide (Optional capabilities). When model right-sizing, reasoning effort tuning, delegated implementation with stronger review, or execution topology would materially help, offer the user a choice to invoke agent-config or proceed directly. If the user explicitly requested routing, invoke agent-config directly; if the user declined or disabled routing, or for bounded solo work, proceed directly without blocking. When agent-config returns, follow its readiness as described in WORKFLOW.md §3E. NEED_PROJECT_TICKETS always halts: recommend $project-tickets and stop.
  4. Execute the bounded slice, then verify. Use light-tdd for code when appropriate; produce non-code artifacts per their contract. Verify locally (tests, render, schema, or domain check).
  5. Hand to review-loop with the matching reviewer: light-code-review for code, generic-review or a domain reviewer for non-code.
  6. Write the implementation report and stop. For a tracker ticket, append the report under the ticket's ## Comments: scope, fixed point, verification results, the findings review-loop left open, and Plan gap: (WORKFLOW.md §7). project-review reads it in a later session.

Optional capabilities

  • Step 3 asks whether routing would materially help for work that is not clearly bounded solo work, and the user has neither requested nor declined it → call light-decide with question id light-implement/offer-agent-config (yes or no). Unavailable → judge it yourself.
  • A plan gap (the approved SPEC, ticket or acceptance items no longer hold), found at any step → claim the ticket if it is not claimed yet, stop the item, write the report with Outcome: BLOCKED and the gap in Plan gap:, then call light-redirect with the ticket path. If it hands back a local fix, continue the item; the next report supersedes this one. For a SPEC or conversation slice, skip the claim and pass the report you return as the trigger. Unavailable or declined → report the gap and stop.
  • .scratch/<feature>/plan.html exists → after the report, call light-html-plan to refresh it. Missing page or capability → skip.

Composition

light-implement
   ↓
inspect bounded task
   ↓
would routing materially help?
   ├─ no  → execute directly
   └─ yes → offer agent-config
              ├─ accept  → agent-config → consume AgentConfigResult (READY / NEED_INPUT / NEED_PROJECT_TICKETS / BLOCKED / UNSUPPORTED)
              └─ decline → execute directly
   ↓
light-tdd when appropriate
   ↓
review-loop → light-code-review (code) / generic-review (non-code)

light-implement composes these capabilities; it does not reimplement them. agent-config is an optional enhancement: declining it or running on a Host without model-routing capabilities does not block implementation. If a routing problem affects only an optional enhancement, the current session is evidenced as capable and authorized, and the user has not required that route, continue the bounded item directly and explain the fallback without another setup question. Never bypass a model restriction, configuration-preview approval, required independent review, or user-required execution method. An ambiguous rejection or missing task prerequisite remains a BLOCKED handoff gap: return its diagnostic and smallest unblock to the caller. Skill completion returns this item's status; it does not complete a larger request or authorize another item. Full per-artifact procedures are in WORKFLOW.md; examples are in EXAMPLES.md.

Comments

Markdown supported