safe-implementer

name	safe-implementer
description	Create or modify code, tests, configuration, and project files safely with real file changes.
version	1.0.0
since	2026-07-28
last_modified	2026-07-28
authors	["platform-engineering"]
stability	stable
min_platform_version	{"codex":"unknown","amazon-q":"unknown","antigravity":"unknown","auggie":"unknown","bob":"unknown","claude-code":"unknown","cline":"unknown","codebuddy":"unknown","continue":"unknown","costrict":"unknown","crush":"unknown","github-copilot":"unknown","gitlab-duo":"unknown","factory":"unknown","forgecode":"unknown","opencode":"unknown","openhands":"unknown","cursor":"unknown","roo-code":"unknown","kiro":"unknown","junie":"unknown","gemini-cli":"unknown","iflow":"unknown","kilocode":"unknown","kimi":"unknown","lingma":"unknown","pi":"unknown","qoder":"unknown","qwen":"unknown","windsurf":"unknown","ollama":"unknown"}
deprecated_since	null
replaces	null
supersedes	[]
changelog	[{"version":"1.0.0","date":"2026-07-28","change":"Initial generated production-ready SDLC / DevSecOps skill"}]

Safe Implementer

Purpose

Implement changes safely, minimally, and auditable while preserving public APIs, tests, rollback, input validation, error handling, safe defaults, and validation evidence.

When to use

• The user asks for code, configuration, tests, documentation, or generated file changes.
• A requirement is ready for implementation.
• A bug fix needs a minimal, testable change.
• A migration or feature flag needs safe rollout treatment.
• Validation evidence must accompany the change.

Operating model

1. Inspect existing patterns, tests, ownership boundaries, and generated-file flows before editing.
2. Implement only requested behavior and avoid broad refactoring.
3. Add or update tests for changed behavior and relevant failure paths.
4. Validate inputs at trust boundaries and handle errors safely.
5. Report changed files, validation evidence, rollback notes, and residual risk.

Spec-Driven Change Context

• Treat repository specs, ADRs, runbooks, change proposals, design notes, and task files as durable context that outlives a chat session.
• For non-trivial changes, prefer a checked-in change artifact or equivalent proposal/design/tasks record before implementation begins.
• Capture requirement deltas explicitly: added, modified, removed, deprecated, or unchanged behavior.
• Keep implementation tasks traceable to acceptance criteria, affected specs, validation commands, and owners.
• During verification, compare the implementation against the proposal, design decisions, task checklist, and spec deltas.
• After completion, sync or archive completed change artifacts so the repository's source of truth reflects the final behavior.
• If the repository has no spec workflow yet, report the missing artifact and provide a minimal proposal/spec/tasks outline instead of relying on chat-only intent.

Skill-Specific Review Scope

• Minimal change principle and no broad refactoring.
• Input validation, error handling, safe defaults, and API compatibility.
• Tests, validation evidence, rollback, and feature flags when appropriate.
• Secrets avoidance, no global side effects, and concurrency safety.
• Generated-file synchronization and reviewable diffs.

Skill-Specific Checklist

• Implement only the requested behavior.
• Avoid broad refactoring unless explicitly required.
• Preserve public APIs unless a breaking change is explicitly requested.