sdlc-implement

Estrellas4

Forks0

Actualizado25 de junio de 2026 a las 13:47

Use during active implementation of a planned, tested feature - once a spec and failing tests exist and it's time to write code. Drives the agent to implement against the spec + tests, reserves your attention for the hard 20% (ambiguity, edge cases, correctness), and reviews code as it appears instead of accepting it blind. Make sure to use this whenever you are coding a feature that already has a spec/tests, or says "now build it", "make the tests pass", "implement the slice". Fourth step of the SDLC loop.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

Jeff-Kazzee

Jeff-Kazzee/sdlc-skills

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

Explorador de archivos

3 archivos

SKILL.md

readonly

name

sdlc-implement

description

sdlc-implement - build to green, own the hard 20%

Fourth beat of the SDLC loop. The agent does the well-specified bulk; you focus your judgment where the model is weak. The goal is the tests from sdlc-test going green without you having shipped code you don't understand.

Why this matters

The 80% problem: agents generate ~80% of a feature fast, but the last 20% - edge cases, error handling, integration points, subtle correctness - needs context they lack, and those failures are dangerous because the code "looks right" and may pass basic tests. The winning posture isn't accepting everything faster; it's spending your attention exactly where AI struggles.

Procedure

Implement against the contract. Point the agent at the spec + failing tests and have it work to green, one slice at a time.
Guard the 20%. Personally scrutinize: ambiguous requirements (ask, don't assume), edge cases from the plan, integration seams, and correctness under the unhappy path. Don't delegate these to the model's confidence.
Review as it appears. Read the code as it's written. Be skeptical of anything clever. Verify imports are real packages (hallucinated deps are a known failure mode). Confirm error handling covers realistic failures, not just the happy path.
Keep slices small and checkable. After each slice, run the tests. Don't let a big unverified blob accumulate.
Pick the mode that fits. Conductor (hands-on, real-time) for tricky/unfamiliar logic; orchestrator (delegate, review output) for well-specified slices against established patterns.

Output

Working code for the slice that passes its tests, that you understand well enough to maintain.

Gate

Tests green + you understand the code -> hand to sdlc-review before it ships. Note any agent miss (hallucinated import, missed edge case) for sdlc-learn.

References

Load these as needed:

references/the-80-percent-problem.md - where to spend your attention vs let the agent run.
references/conductor-vs-orchestrator.md - picking the right working mode for the task.

Más de este repositorio

mismo repositorio

sdlc-design

Jeff-Kazzee/sdlc-skills

Use after the spec is clear and before implementation, when a coding task involves real architecture or design trade-offs - data model, API shape, build-vs-buy, a new module, choosing a library, or how the agent's context and guardrails are set up. Make sure to use this whenever you ask "how should we structure this", "what's the architecture", "which library", or faces any non-trivial structural decision, even if he doesn't say "design". Second step of the SDLC loop; skip it for trivial changes.

2026-06-254

sdlc-learn

Jeff-Kazzee/sdlc-skills

Use on a weekly cadence, or after a rough project, to turn logged failures into durable improvements. Reads the agent-run log, clusters recurring agent failures, encodes each into an AGENTS.md rule or checklist, and updates the KPI tracker so the trend is visible. This is the compounding self-improvement step that makes you measurably better at directing agents over time. Make sure to use this whenever you say "weekly review", "retro", "what did we learn", "update my rules", or "let's improve the loop". Final step of the SDLC loop - it feeds the next cycle.

2026-06-254

sdlc-plan

Jeff-Kazzee/sdlc-skills

Use at the START of any coding task, feature, or project - before design or code. Turns a rough idea or request into a clear, testable spec that clarifies real intent, surfaces edge cases, and deliberately hunts for the simplest path to the same outcome (fewest steps, least complexity). Make sure to use this whenever you say "let's build", "I want to add", "new feature/project", "plan this out", or hands over a vague coding request - even if he doesn't say the word "plan". First step of the SDLC loop.

2026-06-254

sdlc-review

Jeff-Kazzee/sdlc-skills

Grade agent output before it ships, and log it. Use when agent-produced code is about to ship - a PR, a merge, a deploy, or "is this ready". Runs deterministic gates first, then grades the change against a short rubric (spec adherence, error handling, approach, reviewability), and logs the run so the self-improvement loop has data. This is the ONLY place an LLM judge is allowed, and only for code review. Make sure to use this whenever you say "review this", "before I ship/merge", "is this ready", or hands over a diff/PR. Fifth step of the SDLC loop.

2026-06-254

sdlc-test

Jeff-Kazzee/sdlc-skills

Use BEFORE generating implementation code for any feature with verifiable behavior. Writes the tests (and evals, if output quality is judgment-based) FIRST, as the contract that defines "correct," so the agent implements against a real target instead of a vibe check. Make sure to use this whenever you say "implement", "write the code for", "build the function/endpoint/feature" - intercept and do tests first - and also on "write tests" or "add coverage". Third step of the SDLC loop and the single highest-leverage habit.

2026-06-254

name

sdlc-implement

description

sdlc-implement - build to green, own the hard 20%

Why this matters

Procedure

Implement against the contract. Point the agent at the spec + failing tests and have it work to green, one slice at a time.
Guard the 20%. Personally scrutinize: ambiguous requirements (ask, don't assume), edge cases from the plan, integration seams, and correctness under the unhappy path. Don't delegate these to the model's confidence.
Review as it appears. Read the code as it's written. Be skeptical of anything clever. Verify imports are real packages (hallucinated deps are a known failure mode). Confirm error handling covers realistic failures, not just the happy path.
Keep slices small and checkable. After each slice, run the tests. Don't let a big unverified blob accumulate.
Pick the mode that fits. Conductor (hands-on, real-time) for tricky/unfamiliar logic; orchestrator (delegate, review output) for well-specified slices against established patterns.

Output

Working code for the slice that passes its tests, that you understand well enough to maintain.

Gate

Tests green + you understand the code -> hand to sdlc-review before it ships. Note any agent miss (hallucinated import, missed edge case) for sdlc-learn.

References

Load these as needed:

references/the-80-percent-problem.md - where to spend your attention vs let the agent run.
references/conductor-vs-orchestrator.md - picking the right working mode for the task.