---
name: implement
description: Phase 3 of the SDLC pipeline (also usable standalone). Use when the user invokes /implement after a /design in conversation context, OR with a direct task description. Executes the change list, editing source files. Reads design context from the conversation — not from disk. Does NOT run the full test suite (that is /test's job), but does sanity-check imports and syntax.
---

# implement — SDLC phase 3 (standalone-capable)

You are in the **implementation** phase. Your job is to execute concrete code changes.

This skill can run after `/design` OR standalone (e.g. user says `/implement add a --since flag` without prior phases). Input source, in priority order:

1. A `/design` output present in the recent conversation — use its **Change list** verbatim.
2. The user's `/implement` arguments — treat them as the task. Do a brief in-head plan, confirm with the user if non-trivial, then proceed.

## Pre-flight

1. Look for a recent `/design` Change list in the conversation. If absent and the user's instructions are non-trivial (more than one file, or unclear scope), ask the user whether they want you to do a quick design-in-head first or just execute. For simple/explicit tasks, just execute.
2. Read `CLAUDE.md` for conventions if you haven't already in this session.

## How to work

- For multi-step changes, use `TaskCreate` to mirror the change list as trackable tasks. Mark each `in_progress` when you start it and `completed` immediately when done — do not batch. For single-edit tasks, skip TaskCreate.
- Edit with `Edit` (preferred) or `Write` (only for new files). Read the file first if you have not already in this session.
- After each non-trivial edit to `gh_dependents_info.py` or `__main__.py`, run `poetry run python -c "import github_dependents_info; from github_dependents_info.__main__ import app"` to catch import/syntax errors early.
- If the plan specified test additions, write the test stubs/files in this phase — but do not run them. `/test` (or the user) runs them.

## Code conventions (enforced)

- Black, line length 120. Don't hand-format; let `make codestyle` reflow.
- isort sections: FUTURE → TYPING → STDLIB → THIRDPARTY → FIRSTPARTY → LOCALFOLDER.
- Python ≥ 3.10 syntax is fine (`X | None`, PEP 604 unions).
- Default to no comments. Only add a comment when the **why** is non-obvious.
- Don't refactor beyond the requested change. If you spot adjacent cleanup, note it as a follow-up in your end-of-phase summary, do not do it.
- Keep the CLI thin: behavior belongs on the `GithubDependentsInfo` class.
- Forward new CLI options with env-var fallbacks only when explicitly set (the `if X is not None: gh_options[...] = X` pattern in `__main__.py`).
- Mirror new user-facing CLI flags into `action.yml` inputs AND the shell `set -- "$@" ...` branches.

## Things not to touch unless explicitly requested

- The badge marker strings `<!-- gh-dependents-info-used-by-start -->` and `<!-- gh-dependents-info-used-by-end -->`.
- The `packages_<repo>.csv` / `dependents_<name>.csv` filename patterns under `csv_directory` — downstream users may script against them.
- The pinned `image: docker://nvuillam/github-dependents-info:vX.Y.Z` in `action.yml` — that moves at release time, not feature work.
- `requirements.txt` directly — it's regenerated from `poetry.lock` by `make install`.

## When you hit a problem

- Failing pre-commit hook on commit: fix the underlying issue, never `--no-verify`.
- An edit breaks an unrelated test: stop and surface it. Do not blindly "fix" it.
- A dependency needs adding: use `poetry add <pkg>` (or instruct the user), do not hand-edit `pyproject.toml`'s dependency list.

## Output

When all changes are done:

1. Summarize what changed in 2-3 sentences (one paragraph, no headers).
2. List any follow-ups you noticed but did not do.
3. End with a single line suggesting the next step, e.g. `Run /test to verify, or review the diff above.` — do not assume the user will continue.