sdlc-kit

Optional code-navigation aid for large or unfamiliar codebases. Use during the plan or implement phases to map module dependencies, find where a symbol is defined and used, and orient before making changes. This is a navigation helper only — it is NOT the memory layer. Skip for small projects.

Persistent memory layer across sessions. Use to recall prior context at the start of work, to store checkpoints at phase boundaries, and to answer "what did we decide / do before" questions. Backed by the agentmemory server (local SQLite + vector embeddings) on port 3111, with an MCP-only fallback. Every phase skill calls this to survive /clear and compaction boundaries.

Phase 4 of the SDLC, used ONLY for user-facing features. Use this to produce UI/UX design documentation and a persistent design system before implementation. Triggers when tasks.md exists and the spec marked a UI surface. Coordinates with the ui-ux-pro-max skill to generate design-system/MASTER.md and per-page specs. Skip entirely for CLI tools, libraries, or backend-only work.

Phase 5 of the SDLC. Use this to write code that satisfies the tasks, strictly test-first (TDD). Triggers when tasks.md exists and design is done or not needed. Implements one task at a time, writing a failing test before code, then making it pass, then refactoring. Persists progress to memory after each task so work survives session boundaries.

Master coordinator for the full software development lifecycle. Use this when starting a new feature or project, when the user is unsure which phase to run, when resuming work after a break, or to establish/edit the project constitution. Routes to specify, plan, tasks, design, implement, review, and ship phases in the correct order and enforces that no phase is skipped. ALWAYS consider this skill first at the start of any development work.

Phase 2 of the SDLC. Use this to decide HOW a specified feature will be built — architecture, tech choices, data model, API contracts, and trade-offs. Triggers after a spec exists and the user wants a technical plan or design decisions. Produces specs/<feature>/plan.md plus Architecture Decision Records (ADRs). Must read spec.md and memory/constitution.md and respect their constraints.

Phase 6 of the SDLC. Use this to verify the implementation against the spec's acceptance criteria and the project constitution before shipping. Triggers when implementation is complete. Produces specs/<feature>/review.md — a filled acceptance checklist with pass/fail per criterion and required fixes. Does not ship; gates whether ship is allowed.

Phase 7 of the SDLC, the final phase. Use this to prepare a release after review has passed. Triggers when review.md shows all criteria passing. Runs the mandatory security-scan gate, generates release notes in Ukrainian, and prepares (but does not auto-execute) the commit/tag/PR. A failing security scan blocks the ship and is surfaced to the user.

Phase 1 of the SDLC. Use this to capture WHAT a feature does and WHY it exists, before any technical design. Triggers when the user describes a new feature, requirement, user story, or problem to solve. Produces specs/<feature>/spec.md focused on user value and acceptance criteria, deliberately avoiding implementation details. Reads memory/constitution.md first.

Phase 3 of the SDLC. Use this to break an approved plan into an ordered list of small, independently testable tasks ready for implementation. Triggers after plan.md exists. Produces specs/<feature>/tasks.md where each task has a clear definition of done and maps to acceptance criteria. Each task should be completable and verifiable on its own.

Security gate for the ship phase. Use before any release to scan the change for secrets, injection risks, insecure dependencies, dangerous file operations, and policy violations. Triggered by sdlc-ship as a hard gate. Produces a findings report with severity levels; findings above the project threshold block the ship until resolved or explicitly overridden by the user.

Maintenance utility for the skill bundle itself. Use to audit and tidy installed skills — detect duplicate or overlapping descriptions, overly long descriptions that risk the skill-listing budget truncation, broken frontmatter, and dead/unused skills. Run after each major phase and before release, or whenever /doctor or /context shows skill-description truncation. Keeps autonomous skill triggering reliable.

Core behavioral discipline applied across ALL phases — brainstorming alternatives before deciding, planning before doing, strict test-driven development, and adversarial self-review. Use this whenever you are about to make a non-trivial decision, write code, or evaluate work. This is the default working style for the whole SDLC; other skills defer to it for HOW to think and work.

Design intelligence for producing professional UI/UX documentation across platforms (web, mobile, desktop). Use during the design phase of user-facing features to generate a persistent design system — tokens, component specs, layout, states, accessibility — and per-page design docs. Invoked by sdlc-design. Produces design-system/MASTER.md as the single source of truth for visual and interaction design.