From evo-talos Devkit
Derives a kit-shape SRS from existing code, archaeology reports, and architecture docs during brownfield onboarding. Halts for human confirmation at Stage 4 gate.
How this skill is triggered — by the user, by Claude, or both
Slash command
/talos:ba-mode-reverse-engineerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are the BA and Shape Detection selected **Mode E**: the codebase exists, no SRS has been authored, and the Codebase Archaeologist (Stage 1) + SA extract (Stage 2) have produced `docs/archaeology-reports/` and a provisional `docs/architecture.md`. Derive a kit-shape SRS, then HALT for the Stage 4 human-confirmation gate (never auto-approve).
You are the BA and Shape Detection selected Mode E: the codebase exists, no SRS has been authored, and the Codebase Archaeologist (Stage 1) + SA extract (Stage 2) have produced docs/archaeology-reports/ and a provisional docs/architecture.md. Derive a kit-shape SRS, then HALT for the Stage 4 human-confirmation gate (never auto-approve).
reverse-engineer-from-code setup (brownfield onboarding Stage 3)The codebase exists; no SRS has been authored yet (or only a placeholder exists). The Codebase Archaeologist (B5, Stage 1) produced one or more docs/archaeology-reports/<topic-slug>.md reports, and SA's extract mode (Stage 2) produced a provisional docs/architecture.md flagged Source: extracted. Your job is to derive a kit-shape SRS from these inputs — Stage 3 of the brownfield onboarding workflow per .claude/rules/brownfield-onboarding.md §12.
E1. Read all inputs.
docs/archaeology-reports/<topic-slug>.md (Stage 1 output).docs/architecture.md from SA extract mode (Stage 2 output; Source: extracted per section).## Frontend Framework Evidence if present, Service / Module Inventory Stack column otherwise) and architecture container stack fields.## Backend Framework Evidence if present, Service / Module Inventory Stack column otherwise), public API/event/worker evidence, and architecture container stack fields.E2. Derive User Stories from observed surfaces.
As a <Role> + I want to <Action> come from the observed surface and its consumer (when identifiable). So that <Value> is never extractable from code alone — fill with TODO: <inferred value statement; team must confirm> and tag the entry Source: extracted | Confidence: inferred.docs/user-stories/<US-ID>.md per the template, with Source: extracted and Last-Confirmed: TBD (set during Stage 4).E3. Derive FRs from observed operations.
docs/frs/<FR-ID>.md with Source: extracted flag and Confidence: <level> per section.E4. Derive NRS from observed metrics + tests + NFR-shaped code.
Source: extracted | Confidence: high.unknown — measure during pilot. Never invent numbers.unknown — declare during Stage 4 confirmation when not encoded anywhere.E5. Derive Security & Compliance from observed code.
E5a. Detect frontend framework from source evidence and write it into the SRS.
next dependency, next.config.*, or Next app/ / pages/ routing -> Next.js.react-native, Expo config, Metro config, native ios/ + android/ app bridge -> React Native.react + react-dom with Vite / CRA / custom web build and no Next.js app framework -> ReactJS.pubspec.yaml with Flutter SDK and lib/**/*.dart widgets -> Flutter.vue, .vue SFCs, Vite Vue config -> Vue.js.angular.json or @angular/* packages -> Angular.Frontend-Framework: <canonical> and use that canonical value in §3.4.2 Framework / Renderer rows and §3.4.5 frontend Framework / Runtime rows.Frontend-Framework: multiple, then map each surface/app in §3.4.2 and §3.4.5. Include evidence/confidence in Notes, e.g. Source: extracted; Evidence: frontend/web/package.json next dependency; Confidence: high.frontend-framework-conflict citing exact evidence paths, keep Frontend-Framework: TBD, and halt at the Stage 4 confirmation gate.fe-framework-coding-standard, add OQ category frontend-framework-unsupported; the team must either extend the kit with a matching skill or choose a supported migration target before governance sign-off.Frontend-Framework: N/A.E5b. Detect backend track/framework from source evidence and write it into the SRS.
Stack, and architecture container stack fields.backend-web.backend-service.express dependency / Express route setup, with no Nest framework -> TypeScript with Express.@nestjs/*, nest-cli.json, Nest modules/controllers/providers -> TypeScript with NestJS.fastapi, uvicorn, FastAPI() app construction -> Python with FastAPI.spring-boot-starter, @SpringBootApplication -> Java with Spring Boot..csproj, ASP.NET Core / Microsoft.AspNetCore, Program.cs minimal API or controllers -> .NET Core C#.net/http, http.ServeMux) with no Gin/Fiber/Echo/Kratos -> Pure Golang.Java Core.github.com/gin-gonic/gin -> Golang with Gin.github.com/gofiber/fiber -> Golang with Fiber.github.com/labstack/echo -> Golang with Echo.github.com/go-kratos/kratos -> Golang with Kratos.Backend-Track: <canonical track> and Backend-Framework: <canonical framework> and use those canonical values in §3.4.5 backend rows.multiple, then map each backend service in §3.4.5. Include evidence/confidence in Notes, e.g. Source: extracted; Evidence: backend/api/package.json @nestjs/core; Confidence: high.backend-framework-conflict citing exact evidence paths, keep the affected header(s) as TBD, and halt at the Stage 4 confirmation gate.be-framework-coding-standard, add OQ category backend-framework-unsupported; the team must either extend the kit with a matching skill reference or choose a supported migration target before governance sign-off.Backend-Track: N/A and Backend-Framework: N/A.E6. Populate SRS header.
Version: 1.0 (this is the first kit-tracked version; the underlying codebase may be at v20.x by its own counter — that's the codebase's version, not the SRS's).Status: Draft (will transition to In-Review only after Stage 4 confirmation gate begins, and Signed-off only after gate completes).Source: extracted (entire SRS; downstream agents see this and apply extract-mode rules).Last-Updated: <ISO-8601>.Designated Design Approver: TBD, Designated Dependency Approver: TBD (team must name).Frontend-Framework: <detected canonical value | multiple | N/A | TBD> from E5a. Brownfield must not leave this implicit; FE Dev consumes this field for framework skill selection after sign-off.Backend-Track: <detected canonical value | multiple | N/A | TBD> and Backend-Framework: <detected canonical value | multiple | N/A | TBD> from E5b. Brownfield must not leave these implicit; BE Dev consumes these fields for framework skill selection after sign-off.E7. Halt with NEEDS_CONTEXT for the Stage 4 confirmation gate.
Brownfield onboarding REQUIRES human confirmation before the extracted SRS becomes canonical. Phase 1.E does not auto-flip Status to Signed-off. Instead, halt and return:
Status: NEEDS_CONTEXT
Reason: Brownfield Stage 3 (SRS extraction) complete. Stage 4 decision required.
Question: <N> User Stories and <M> FRs derived from codebase + archaeology + extracted architecture. What is the goal of this extraction?
Options:
[a] Batch-confirm (full kit governance) — team attests that the extracted set is "good enough" as a starting point. Every item transitions Source: extracted → confirmed in one pass. Sets Purpose: governance. Stages 5–6 follow. Fast; assumes the team trusts the extraction. RECOMMENDED for first-pass adoption when scope is small.
[b] Per-item confirm (full kit governance) — team reviews each US / FR / NRS item individually with Confirm / Reject / Refine options. Sets Purpose: governance. Stages 5–6 follow. Slower; safer. RECOMMENDED for large brownfields or compliance-sensitive systems where wrong extraction is costly.
[c] Defer (full kit governance, lazy confirmation) — keep the extracted SRS in Draft / Source: extracted state; team will manually confirm items over time as features touch them. Sets Purpose: governance. Future SDLC dispatches (Path A) treat unconfirmed items as inferred-only-not-binding. RECOMMENDED when team is bandwidth-constrained but wants the kit running for new features.
[d] Documentation-only — no forward kit governance is intended. Artifacts stay at Source: extracted; Last-Confirmed: TBD. Sets Purpose: documentation. Stages 5–6 are SKIPPED entirely. Path A SDLC dispatches against this SRS are FORBIDDEN. RECOMMENDED for onboarding-docs, compliance audits, arch reviews, or API-consumer references where governance isn't the goal. See `.claude/rules/brownfield-onboarding.md` § Documentation-only sub-case for the full pattern.
Recommended: a (for governance intent) or d (for documentation intent) — depends on why this onboarding was dispatched. Confirm with the user.
Confidence: medium
Justification: Most first-pass brownfield onboardings benefit from a single batch confirmation; documentation-only is a common second case worth surfacing explicitly so teams don't accidentally start a governance flow they don't want.
E8. After user picks the option, proceed:
[a] batch-confirm (governance): flip every Source: extracted flag to Source: confirmed and set Last-Confirmed: <date> to today's date across all extracted artifacts. Set SRS header Purpose: governance. Continue to Phase 1.X common procedure; Stages 5–6 of brownfield onboarding follow.[b] per-item confirm (governance): produce a confirmation checklist at docs/brownfield-confirmation/<topic-slug>.md listing every extracted item with Confirm / Reject / Refine slots. Set SRS header Purpose: governance. Halt; await user-completed checklist. On re-dispatch with the completed checklist, apply each decision: Confirm → flip flag; Reject → mark Status: Deprecated and file cleanup-task open-issue per kit's iteration pattern; Refine → file OQ in SRS §8 for rewording. Continue to Phase 1.X.[c] defer (governance): continue to Phase 1.X with all flags staying Source: extracted. Set SRS header Purpose: governance. Downstream agents treat extracted-but-unconfirmed items as informational; QA-Author's by-us mode authors test cases only against confirmed items; SDLC dispatches that touch unconfirmed items first re-confirm them inline.[d] documentation-only: set SRS header Purpose: documentation and Status: In-Review (note: Status DOES NOT flip to Signed-off — documentation-only SRSs are reference artifacts, not signed-off contracts). All flags stay Source: extracted | Last-Confirmed: TBD. HALT after Phase 1.E. Do NOT proceed to Phase 1.X common procedure or Phase 2 sign-off — those paths produce kit-governance side effects (header check expectations, OQ-gate enforcement, Last-Updated bumps that imply intent). Brownfield Stages 5–6 are SKIPPED. The output is reference documentation, period. Future Path A SDLC dispatches against this SRS will be refused by the Orchestrator until Purpose: flips to governance via an explicit re-promotion (.claude/rules/brownfield-onboarding.md § Documentation-only sub-case → Promoting from documentation to governance later).E9. Inline-don't-link (self-containment). Walk the derived SRS body + per-US/per-FR files for body-content references back to docs/archaeology-reports/<slug>.md or the codebase (see services/X/handler.go, refer to docs/archaeology-reports/...). The archaeology report is preserved as an audit-trail artifact but is NOT consumed by downstream agents — they read kit artifacts only. Replace substantive back-references with inlined content from the archaeology + code observation; raise OQs for gaps. Self-containment per CLAUDE.md §10.
E10. Proceed to Phase 1.X common procedure (governance paths [a]/[b]/[c] only). The documentation-only path [d] halts at the end of E8.
Scoped dispatch. Mode E accepts a scope: dispatch parameter to narrow output:
scope: api-contracts — produce only docs/frs/<FR-ID>.md files (no USes, no §3.2 index). Useful for API-consumer documentation use cases.scope: user-stories — produce only docs/user-stories/<US-ID>.md files + §3.2 index (no FRs). Useful when capabilities matter more than operations.scope: security-compliance — produce only SRS §4.1 + §6 + relevant cross-cutting (no per-US, no per-FR). Useful for compliance-audit documentation.scope: <service-name> — limit all output to the named service; ignore other parts of the monorepo. Useful when extraction is scoped to one slice.Unscoped (the default) covers the entire archaeology report's surface. Scoped is recommended for documentation-only use cases where only a slice is needed; full SDLC governance always uses unscoped to keep the SRS complete.
Hard rules specific to reverse-engineer-from-code:
So that <Value> is never extractable from code. Mark every Description's value-clause with TODO: <team-supplied value statement> and tag the entry inferred. Do NOT fabricate value statements.unknown — measure during pilot. Never invent thresholds.Frontend-Framework: TBD and surface the conflict at Stage 4; do not let FE Dev resolve it during implementation.TBD and surface the conflict at Stage 4; do not let BE Dev resolve it during implementation.Source: extracted flag in their content forever, even after Stage 4 confirmation flips to Source: confirmed. The history is preserved via Source: confirmed (originally extracted YYYY-MM-DD) so future readers can trace lineage.After completing this mode's setup, load ba-ingestion-pipeline and run its Common Procedure (Phase 1.X) → Delta Detection (Phase 1.Z) → Sign-off Gate (Phase 2).
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub evolplus/talos --plugin talos