agentic-dev-flow

Converts TC files from the docs/wiki repo at {docs_repo}/test-plans/ into Playwright TypeScript test files in the tests repo at {tests_repo}/{test_dir}/. Auto-discovers both repos (sibling → grandparent → ask), reads playwright.config to find the test directory, then asks the user how to handle the branch — write to current branch, create a test/{feature-name} branch from current, or create one from a different source — and writes one spec file per use case sub-folder. Use when generating, writing, or regenerating Playwright test code from the test plan.

Deterministic ABP code generation from a wiki-published Feature Specification, grounded in a prior scan of the repository. Reconnoitres the solution for existing DTOs, entities, AppServices, background workers, hosted services, hubs and event handlers; reconciles them against the Feat Spec into REUSE / UPDATE / CREATE / CONFLICT; writes code only after two user approval gates. Enforces ABP quality gates (no controllers, DomainService over ILocalEventBus cross-aggregate, exception handling, naming, dynamic sorting, select-before-fetch mapping, DeleteAsync soft-delete, ModelBuilder EF Core config, structured logging, implicit tenant scoping). Commands realize as AppService / BackgroundJob / IHostedService / SignalR Hub / EventHandler / CLI per FS Execution-model declaration plus repo evidence — not AppService-only. Migrations remain manual.

Generate a high-level technical Feature Specification (Feat Spec) from Functional Requirement Specification (FRS) issues in a GitLab milestone. Produces an ABP-layered spec in the wiki and a lightweight coordination issue in GitLab.

Audit an existing Functional Requirements Specification (FRS) against the canonical validation contract: structural completeness, Skill Constraint minimums, Self-Review checklist, NFR rubric, Bundling Detection, AC↔FR traceability, glossary resolution, cross-cutting-concerns non-duplication. Reads, never writes. For generating new FRS, use skill:generate-frs. Trigger phrases: review FRS, audit FRS, FRS quality, FRS check, validate spec, FRS findings.

You MUST use this when the user asks to generate Functional Requirements Specifications, break a product/feature/system into business modules, turn meeting notes or rough briefs into formal requirements, or sync requirements to GitLab as milestones and issues. Triggers on keywords: FRS, BRS, functional requirements, business requirements, spec doc, module breakdown, GitLab milestone sync. Fires even when input is rough — the skill infers structure. Accepts prose, React/TS components, and uploaded files. For reviewing existing FRS, use skill:review-frs instead.

You MUST use this when the user asks to review, audit, validate, lint, or check existing Functional Requirements Specifications. Triggers on: reviewing a GitLab FRS issue, auditing a milestone's worth of FRS, validating a pasted FRS, checking an uploaded FRS file (.md/.docx/.pdf), or any phrase like 'is this FRS correct', 'check my FRS', 'audit these requirements', 'validate the FRS'. Fires whether the user wants findings only or findings with proposed fixes. For generating NEW FRS from prose / code / notes, use skill:generate-frs instead.

You MUST use this when creating, editing, or auditing a Claude Code skill. Covers orchestrator, reference, workflow, forked-context, subagent-dispatching, background, and memory-backed skills. Required before writing any SKILL.md body.

Use for FRS-to-DDD compilation, artifact generation, architecture queries, conflict resolution (CNF/DFB), or milestone closure. Symptoms: need traceability from FRS to Feature Specs, version drift detection, Shadow QA duplication prevention, non-monolithic FRS enforcement, or home.md >150 nodes. Keywords: FRS ingestion, ABSORB compilation pass, DDD nodes (ACT/ENT/CMD/FLOW/STATE), CNF blocking, DFB feedback, version bump rules, deprecation propagation, 6-gate milestone closure, immutable sources, Shadow QA wikilinks, LINT debt (30 classes), TRUN sign-off required, SYNTHESIZE 3-bar quality gate, brownfield init, scenario gap hard gate.

Reads a compiled FEAT- node and posts it to GitLab as a parent issue with one child issue per task, all linked to the correct milestone. Can be invoked manually or automatically by COMPILE when role=BA. When invoked by COMPILE, accepts pre-resolved context and skips status check.

Fetches GitLab issues and saves them as Markdown FRS documents under raw_sources/. Annotates source_type and monolith signals for downstream INGEST processing.

Parse and convert source files into structured knowledge base entries (.md files with YAML frontmatter) in docs/raw/. Use this skill whenever the user mentions `/wiki ingest`, wants to ingest documents into a knowledge base, convert specs/meeting notes/API docs/code into wiki entries, or asks to parse any source file into structured markdown. Trigger on: "ingest this file", "add to wiki", "parse into entries", "convert to knowledge base", or any request to extract structured information from FRS docs, meeting notes, OpenAPI specs, GraphQL SDL, code files, Jira/Linear CSVs, Confluence/Notion exports, changelogs, or Slack/Teams exports.

Architectural Compiler for a microservice DDD wiki. Transforms FRS documents (via GitLab) into a persistent, compounding Domain-Driven Design knowledge graph. Generates Feature Specs, GitLab Issues, Test Plans, Test Runs, Topologies, Changelogs, and API Release Docs. Operates across four roles: Spec Compiler (Agent), BA, Developer, and QA.

Parses a user story .md file into structured data. Use this skill whenever reading user story files from STORIES_DIR. Always invoke from spec-parser at Phase 1.

Manages all reads and writes to per-TC Markdown files in plans/{feature}/{feature}-TC-NNN.md. Replaces state-manager. Use this skill whenever any agent needs to read TC status, create a new TC file, or update a specific field. Never overwrite a TC file entirely — always patch specific fields.

Reads User Story files (US-001.md, US-002.md) and Task files (T-001.md, T-002.md) from a feature folder under docs/feat/{feature-name}/ and creates GitLab issues for each one. User stories are posted as issues with their scenarios and acceptance criteria. Tasks are posted as issues linked back to their source user story issue. Reads project context (project ID, allowed labels, available users) from CLAUDE.md. Use after feature-spec-to-user-stories and user-stories-to-tasks have produced files and you want everything tracked in GitLab.

Converts raw requirements (notes, briefs, bullet points, or a requirements file) into a structured Feature Specification document. Input is either a file path or inline text. Output is a .md feature spec file saved to docs/specs/{feature-name}/. Use this skill whenever someone provides requirements and wants to produce a feature spec, says "write a spec for this", "turn this into a feature spec", or provides a requirements file and wants it structured.

Converts one or more User Story files into a High-Level Technical Task Plan. Reads each story, breaks it down into implementation tasks grouped by layer (backend, frontend, integration, notifications, config, testing), assigns estimates, and links every task back to its source story. Each task is saved as its own file directly inside docs/feat/{feature-name}/ as T-001.md, T-002.md, etc. A combined plan summary is also written. No code snippets are produced — only task descriptions. Use this skill whenever someone says "generate tasks from this story", "break this into tasks", "create a technical plan for this", or provides user stories and wants implementation tasks produced.

Converts a Feature Specification or raw requirements into one or more structured User Story files. Reads the input, determines how many user stories are needed based on the number of distinct actors and actions, and generates each story with scenarios and acceptance criteria. Stories are saved directly inside docs/feat/{feature-name}/ as US-001.md, US-002.md, etc. Use this skill whenever someone says "write user stories for this", "generate stories from this spec", "turn this into user stories", or provides a feature spec or requirements and wants user stories produced from it.

Use when converting raw requirements, BRDs, or feature ideas into a comprehensive Functional Requirements Specification (FRS) with 17 sections, tiered complexity assessment, and downstream readiness scoring. Phase 1 of agentic-dev-flow pipeline. Trigger phrases: "write FRS", "requirement to FRS", "create FRS", "intake requirements". Symptoms: ambiguous requirements, unclear scope, missing actors, vague acceptance criteria.

Chain all 7 phase skills in order, enforcing human approval gates between each phase. Entry point for the complete 8-phase agentic delivery pipeline. Use when user says "full workflow", "8-phase", "start from requirements", "run workflow", or "end-to-end delivery".

Score release readiness against the Definition of Done, generate release notes, and produce a readiness report. Use when user says "release notes", "release readiness", "ready to release", "final review", or "publish". Phase 8 of the agentic development workflow.

Build a traceability matrix across all phase artifacts and create the GitLab milestone, epic, and story issues. Use when user says "milestones", "traceability", "push to gitlab", "track milestone", or "create issues". Phase 7 of the agentic development workflow.

Generate a test plan and acceptance test results from a Feature Spec GitLab issue. Dispatches qa-agent for test generation. Produces TEST_PLAN.md and ACCEPTANCE_RESULTS.md. Use when user says "validate", "acceptance test", "test plan", "QA", or "test coverage". Phase 6 of the agentic development workflow.

Executes implementation from an approved Feature Spec GitLab issue by dispatching implementation-agent for code generation. Internal task decomposition is NEVER persisted as GitLab issues. Use when user says "implement", "build", "generate code", "execution plan", or "code this feature". Phase 5 of the agentic development workflow.

Generates a Feature Specification with user stories and acceptance criteria from an approved FRS GitLab issue and domain design docs. Posts result as a GitLab Feature Spec issue. Use when user says "feature spec", "user stories", "acceptance criteria", or "write feature". Phase 4 of the agentic development workflow.

Design bounded contexts, aggregates, and domain events from an approved FRS GitLab issue. Dispatches domain-analysis-agent for DDD analysis. Produces Layer 2 DDD docs locally. Use when user says "domain model", "bounded context", "DDD design", "aggregate", or "BC mapping". Phase 3 of the agentic development workflow.

Fetches one or more GitLab issues by ID and displays them in Markdown format. Can also fetch linked issues. Simple, focused on output.

Aggregate DDD layer documents into a single Implementation Readiness Spec (IRS) per feature. Produces two output formats: technical (for GSD milestone requirements and backend architects) and business (for GitLab issue descriptions and business analysts). Use this skill when the user says "aggregate specs", "create feature spec from DDD docs", "prepare issue spec", "summarize for GitLab", "combine layer docs", "create IRS", or wants a unified view of a feature across DDD layers.

Generate optimized PostgreSQL queries for Entity Framework Core projects. Automatically discovers domain entities, relationships, and conventions to produce production-ready SQL. Use when: 1. You need complex PostgreSQL queries across multiple related entities 2. Working with ABP Framework and need multi-tenancy/soft delete patterns 3. Querying JSONB fields or need recursive CTEs 4. Building analytics/reporting queries with window functions 5. Optimizing existing queries with proper indexes and joins.

Maps semantic element names from QA specs to real CSS selectors by analysing a live DOM snapshot. Use this skill whenever exploring a page to find selectors for test automation, building or updating a selector map, or when AGENT_explorer needs to identify interactive elements. Always invoke when given a DOM snapshot and a list of target names that need CSS selectors.

Converts a parsed QA scenario and selector map into a Playwright TypeScript test() function. Use this skill whenever generating, writing, or regenerating Playwright test code from spec steps and selectors. Always invoke during Phase 3 script generation or when a single test needs to be regenerated after a selector update during retry.

Validates or creates a Playwright authentication session before page exploration begins. Use this skill whenever the QA explorer agent needs to access authenticated routes, when setup/auth.json is missing or expired, or when a test fails with an unexpected redirect to the login page mid-run. Always invoke at the start of Phase 2 exploration before any page navigation.

Invoked automatically when the user wants to understand task ordering, identify blockers, or visualise dependencies between tasks or modules. Triggers on phrases like "what depends on what", "task order", "what should I do first", "dependency graph", "critical path", "what blocks what", or "execution order". Produces an ordered execution sequence and highlights the critical path.

Invoked automatically when the user asks to break down a single task, user story, or feature into smaller sub-tasks or implementation steps. Triggers on phrases like "break this down", "how do I implement", "sub-tasks for", "expand this task", "what are the steps for", or when a task seems too large to be actionable. Produces a granular, ordered checklist ready to be picked up by a developer.

Invoked automatically when the user wants to plan a project, feature, or complex task. Triggers on phrases like "plan this", "help me plan", "break this project into tasks", "create a development plan", "what are the steps to build", or any request to organise work before coding begins. Produces a structured, actionable plan with phases, milestones, and prioritised tasks.