Claude Code and Codex SDLC plugin

evo-talos Devkit Usage Guide

Use this kit to turn product intent, existing code, or design artifacts into a controlled SDLC flow with role agents, on-demand skills, guarded permissions, and QA evidence before work is marked done.

Big Picture Workflow

The kit is organized as a gated pipeline. Each role owns a narrow artifact set, and detailed behavior is loaded through skills only when that mode is needed.

Basic Usage

Install or enable the plugin

Make the kit available to Claude Code or Codex as a plugin. Claude Code uses slash commands; Codex uses command-shim skills and starter prompts.

Initialize inside the target project

Claude Code: run /sdlc-init. Codex: prompt Run sdlc-init. The initializer injects the plugin guidance into project AGENTS.md by default for Codex, warns about conflicts, and skips Claude-specific .claude settings/hooks unless --target claude or --target both is supplied.

Provide the starting source

Use a PRD, an existing SRS, a requirements folder, an external source, a Figma URL, or an existing codebase. The BA route depends on what exists.

Start the SDLC loop

Claude Code: run /sdlc-loop. Codex: prompt Start the SDLC loop or Run sdlc-loop. The Orchestrator dispatches the right role agents, checks gates, and moves tasks through planning, implementation, deployment, and QA.

Review gates and answer only blocking questions

The kit halts for explicit approvals such as dependency choices, design confirmation, unresolved SRS questions, or missing external integration details.

Operating Recipes

These are practical starting paths for common project states. The short prompts are intentionally plain; the kit reads the project artifacts and routes to the right BA, design, architecture, planning, development, deployment, and QA modes.

Greenfield from requirement materials

Use this when you are starting a new project from PRDs, feature notes, screenshots, exported docs, spreadsheets, or design links.

  1. Open the target project in Codex or Claude Code.
  2. Run the initializer: Claude Code: /sdlc-init Codex: Run sdlc-init
  3. Create or use docs/requirements/ in the target project.
  4. Copy all requirement materials into docs/requirements/. Good file names are explicit, for example product-brief.md, payment-flow.md, admin-dashboard-notes.md, or figma-links.md.
  5. Prompt the assistant: start project
  6. The kit should route to BA requirements-folder synthesis, ask only for missing blocking context, draft the SRS/user stories/FRs, then move through sign-off, architecture, planning, implementation, deployment, and QA.

Greenfield with existing Figma

Use this when Figma is already part of the product source and should influence the SRS instead of being treated as a later handoff.

  1. Initialize with /sdlc-init in Claude Code or Run sdlc-init in Codex.
  2. Put the PRD and a Figma URL/page note into docs/requirements/.
  3. Prompt: start project
  4. The kit should use Design-Flow A: extract confirmed Figma details before BA synthesis, including palette, typography, spacing, radius, component-pattern evidence, and a Design-Guideline: from-figma recommendation when the design is strong enough.
  5. After BA synthesis, the kit maps Figma frames to SRS surfaces before sign-off.
  6. If the Figma page is ambiguous, answer the page-scope question with the project design page name or Node ID.

Existing SRS migration

Use this when the project already has an SRS, user stories, or functional requirement documents and you want the kit to normalize them.

  1. Initialize with /sdlc-init in Claude Code or Run sdlc-init in Codex.
  2. Place the SRS and related documents under docs/requirements/, or keep existing kit-shaped files under docs/SRS.md, docs/user-stories/, and docs/frs/.
  3. Prompt: continue SDLC from existing SRS
  4. The kit should detect the existing structure, surface gaps or orphaned files, and continue from the earliest unsafe gate instead of regenerating everything blindly.

Brownfield codebase onboarding

Use this when source code exists but reliable requirements and architecture documentation are missing or outdated.

  1. Initialize with /sdlc-init in Claude Code or Run sdlc-init in Codex.
  2. Keep the codebase in place. Add any known product notes to docs/requirements/.
  3. Prompt: start brownfield onboarding
  4. The kit should run codebase archaeology, SA extract mode, and BA reverse-engineering. Extracted facts are tagged with confidence and confirmation questions before downstream work depends on them.

New feature or scope change

Use this after a project is already under the kit and a stakeholder adds scope or changes behavior.

  1. Add the new request under docs/requirements/conversational-additions/ or provide it directly in the chat.
  2. Prompt: add this requirement to the project
  3. The kit should run augmentation, produce an SRS diff, identify impacted architecture/design/tests, and ask for sign-off before implementation.

Resume an interrupted run

Use this when Claude Code or Codex stopped mid-flow, the machine restarted, or a previous run halted on a gate.

  1. Open the project again with the plugin enabled.
  2. Prompt: continue SDLC
  3. The kit should inspect SRS status, open issues, master plan, task statuses, deploy reports, and QA reports, then choose the next safe action.

Use Cases By Entry Track

Greenfield from one product document

Use when the team has a PRD or raw requirement document but no structured kit artifacts yet.

  • BA Mode A turns the document into SRS, user stories, and FR files.
  • SA creates architecture after sign-off.
  • TL creates the master plan and task files.

Greenfield from a requirements folder

Use when the source is already split across markdown docs, spreadsheets exported to text, or topic files.

  • BA Mode F reads docs/requirements/.
  • Source coverage is preserved so requirements remain auditable.
  • Missing or conflicting fragments become open questions.

Existing SRS with separate US/FR files

Use when a project already has structured analysis artifacts and needs kit normalization.

  • BA Mode B pairs the SRS with per-story and per-FR files.
  • Orphans, duplicate IDs, and incomplete anchors are surfaced.
  • Downstream agents consume the normalized artifact layout.

External source ingestion

Use when requirements live in Confluence, Notion, Jira, SharePoint, or another connected system.

  • BA Mode C imports content through the available connector or documented source export.
  • Source provenance is recorded for auditability.
  • Re-ingestion supports controlled updates later.

Brownfield reverse engineering

Use when the codebase exists but reliable product and architecture documents do not.

  • Codebase Archaeologist first produces reports from source and history.
  • SA extract mode creates provisional architecture with confidence tags.
  • BA Mode E derives SRS from confirmed code evidence and open questions.

Augment an existing signed-off scope

Use for change requests, iteration planning, or scope additions after initial sign-off.

  • BA Mode D captures new requirements verbatim before synthesis.
  • Change synchronization decides which artifacts must be updated.
  • TL plans only the delta instead of redoing the whole project.

Design Tracks

Track When to use What the kit does Primary artifacts
Design-Flow A: Figma already exists Product source includes Figma before SRS sign-off. Extracts design requirements and design-guideline evidence pre-BA, maps frames to SRS surfaces pre-sign-off, and skips post-sign-off design work when mapping is qualified. docs/requirements/design-extracted/, docs/uiux/figma-mappings/, SRS Design References.
Design-Flow B: agent creates designs No existing Figma is available and the user approves agent-authored design. Creates Foundation tokens/components, draws screens, runs canvas lint, and emits handoff artifacts for BA review. docs/uiux/handoffs/, docs/uiux/refs/, SRS Node IDs.
Design-Flow C: agent drafts, human edits The user wants a starting Figma draft but expects a human designer or approver to modify it. Creates initial designs, waits for human edits, then incorporates the new Figma version into a refreshed handoff. Handoff, refs, reconciliation notes, design confirmation status.
Revision and import BA completeness review fails, or existing pinned nodes must be converted into kit handoff form. Revises Figma only when allowed, or imports read-only and records gaps. Completeness reports, updated handoffs, open issues.

Implementation Tracks

Frontend development

FE Dev chooses a coding-standard skill from the SRS Frontend-Framework header. On brownfield projects, the stack is detected from source and written back into the SRS before implementation.

React Native ReactJS Flutter Vue.js Angular Next.js
  • FE work requires confirmed design artifacts for UI tasks, including the Design Element Manifest.
  • Instrumentation IDs come from SA's contract, not from ad-hoc selectors.
  • Implementation is checked against QA executable specs, visual specs, and every required Figma field/item/copy/action.

Backend development

BE Dev chooses both a backend track and framework from SRS headers. The kit separates request/response web backends from service-oriented microservice work.

TypeScript Express TypeScript NestJS Python FastAPI Java Spring Boot .NET Core C# Pure Golang Java Core Go Gin Go Fiber Go Echo Go Kratos
  • Backend web: HTTP/API surfaces, auth, validation, status codes, and API contracts.
  • Backend service: microservice boundaries, events, queues, data ownership, retries, and observability.
  • Contract drift between FRs and API contracts becomes an open issue, not a silent implementation choice.

Architecture, QA, And Deployment Tracks

Solution architecture

SA runs only after the right gate for the mode.

  • design: greenfield architecture from signed-off SRS.
  • extract: brownfield architecture from code evidence.
  • external-integration-adequacy: fill integration interface details before sign-off.

QA authoring

QA-Author writes the test contract before QA-Exec runs it.

  • by-us: functional tests per User Story.
  • by-task: API, structural, e2e, and rare task-functional tests.
  • Visual specs are generated for UI tasks before structural tests.

QA execution

QA-Exec verifies a deployed build, not just code existence.

  • Checks deploy report, executable specs, selectors, and visual-spec freshness.
  • Runs functional, structural/token, and visual-diff tiers as required.
  • Reports pass, fail, blocked, and skipped separately with evidence.

Operational rule: A task should not move to done because code was written. It moves to done only when the correct deployment and QA evidence exists, with failures routed back to the responsible track.

Artifacts You Will See

Artifact Owner Purpose
docs/SRS.md, docs/user-stories/, docs/frs/ BA Signed-off product scope, behavior, acceptance scenarios, and functional requirements.
docs/architecture.md, docs/decisions/ SA C4 architecture, API/data/async inventories, ADRs, and dependency decisions.
docs/instrumentation-contract.md SA Stable test IDs and accessibility identifiers shared by FE Dev and QA.
docs/uiux/ UI/UX Designer, BA, QA-Author Figma mappings, handoffs, references, completeness reports, and visual specs.
docs/plan/ TL and Orchestrator Master plan, phases, tasks, statuses, dependencies, and track routing.
docs/test-cases/ QA-Author Markdown test cases linked to US, FR, task, and executable spec paths.
docs/deploy-reports/ DevOps Local test environment URL, fixtures, env vars, health status, and reset commands.
docs/qa-reports/ QA-Exec Runtime evidence, screenshots, traces, logs, visual diffs, and pass/fail routing.
docs/open-issues.md Shared Blocking questions, adequacy gaps, selector gaps, drift, and deferred decisions.

How To Choose The Right Path

If you have a PRD

Start with BA ingestion. Include any Figma URLs and external integration notes in the source input.

If you have Figma first

Use Design-Flow A. The kit extracts design facts before BA writes the SRS, then maps frames before sign-off.

If you have code first

Use brownfield onboarding. Archaeology and SA extraction run before BA derives confirmed requirements.

If you are adding scope

Use augmentation and iteration planning. The kit routes the delta through BA/SA/TL and only then to Dev/QA.

This file is static documentation only. It is intentionally stored under plugin/docs/ so it does not participate in Claude Code plugin runtime loading, hooks, commands, agent generation, or skill discovery.