Skip to content
Back to skills

Sdlc Plan

ASecurity

SDLC stage 3 — from an intent + spec produce docs/sdlc/plans/<slug>.md, an ordered implementation plan (files that change, order of work, risks, proof/tests, rollback) that the main session then executes step by step. Use after /sdlc-spec, "plan the implementation", "make the plan from the spec".

  • 3 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 27, 2026
ai-agentsgit

Works with

  • claude code

Security analysis

A100/100

Scanned September 27, 2026

npx -y skills add vanssata/claude-agentic-sdlc-module --skill sdlc-plan --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Sdlc Plan?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Sdlc Plan
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/vanssata-sdlc-plan/badge)](https://www.skillsdirectory.com/skills/vanssata-sdlc-plan)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: sdlc-plan
description: SDLC stage 3 — from an intent + spec produce docs/sdlc/plans/<slug>.md, an ordered implementation plan (files that change, order of work, risks, proof/tests, rollback) that the main session then executes step by step. Use after /sdlc-spec, "plan the implementation", "make the plan from the spec".
argument-hint: <path to docs/sdlc/specs/<slug>.md>
---

# /sdlc-plan $ARGUMENTS

Input: a spec file (default: most recent `docs/sdlc/specs/*.md`) and its sibling intent.
Output: `docs/sdlc/plans/<slug>.md`.

## Steps

1. **Prerequisites** — read `docs/sdlc/constitution.md` first: it is this project's own list of principles, `C1`…`C<n>`. Cite the ones a decision rests on as `C<n>`. If the file is absent, say so in one line and carry on — it is not a blocker.
   Spec and intent exist; `docs/sdlc/plans/TEMPLATE.md` exists (else
   `/project-init`). If the spec's **Flagged concerns** contains unresolved items, list them and
   ask the user to resolve or explicitly accept each one before planning.
2. **Plan-mode reasoning** — treat this as plan mode: read, do not edit code. If the
   `superpowers:writing-plans` skill is available, use it for the step granularity; otherwise:
   - map each requirement to the files that must change (`grep -n`, `Explore` for discovery);
   - order the steps so each one leaves the repo working and verifiable;
   - one step ≈ one commit; name the command/test that proves it.
3. **Challenge it** before writing: answer explicitly
   - *What could this break?* (callers, migrations, config, other environments)
   - *Which step is the riskiest, and can it move earlier or be split?*
   Put the answers into **Risks** and mark the risky step in **Order of work**.
4. **Write** — copy `docs/sdlc/plans/TEMPLATE.md` to `docs/sdlc/plans/<slug>.md`, replace
   `{{TITLE}}`/`{{SLUG}}`, fill **Files that change / Order of work / Risks / Proof / Rollback**.
   Proof maps every requirement R<n> to a test or command.
5. **Confirm** — one round of corrections.
6. **Hand-off** — suggested commit `git add docs/sdlc/plans/<slug>.md && git commit -m "plan: <title>"`;
   then build in the main session one step at a time, running `ai-reviewer` before each commit.
   In a repository with `.ai/`, hand the plan to `/ai-task` instead and let the pipeline
   run the review and approval gates for the task's risk tier.
   If the plan is approved in plan mode, also save it to the runtime's plan directory —
   `.claude/plans/<slug>.md` under Claude Code, `.codex/plans/<slug>.md` under Codex. The
   canonical copy stays in `docs/sdlc/plans/`, which is shared by both.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…