Creates entity model documents with Mermaid.js ER diagrams and attribute tables defining entities, relationships, data types, and validation rules. Use when the user asks to "create an entity model", "design a data model", "draw an ERD", "define database schema", "model entities", or mentions entity-relationship diagram, ER diagram, database design, or data modeling. Also trigger whenever the task is to produce, write, or design an entity model or data model document (e.g. docs/entity_model.md) from a requirements catalog — including phrasings like "data model design", "the team needs an entity model before development", or a request to document entities with attributes, data types, precision, and validation or cross-attribute constraints.

Reads the state of an AI Unified Process project and names the next command with its reason: which documents are missing, which blocking questions wait for an answer, which use cases wait for a review, the stack file, implementation, tests, acceptance, the user guide, or the release notes. Shows a short state table (use cases and test cases per status, open and blocking questions, stack file, spec lint, last Git tag) and one or two Next lines. Use when the user asks "what next", "what should I do now", "where are we", "which command comes next", "what is the state of the project", "what is missing before the release", or is new to the AI Unified Process and does not know which skill to run. It is read-only: it never runs the next command and never writes a file.

Keeps the log of open questions about the specification in docs/open-questions.md: records a question on a use case step, alternative flow, business rule, requirement, glossary term, or entity with the next OQ-XXX id, lists the questions filtered by use case, status, or blocking, records a person's answer, and withdraws a question that no longer applies. Owns the format every other skill appends in. Use when the user asks to "record an open question", "add a question for the product owner", "list the open questions", "which questions block UC-003", "answer OQ-002", "withdraw OQ-004", or mentions open questions, specification gaps, or docs/open-questions.md. It never resolves a question: putting the answer into the specification is /use-case-spec, /requirements, or /entity-model.

Writes the business release notes of a version into docs/release-notes.md from the specifications, not from commit messages: which use cases reached Done since a Git tag (new), which accepted use cases changed their scenario, flows, or rules (changed), which became Obsolete (removed), and which requirements were delivered (every use case that realizes them Done), each told in the glossary's terms for the people who use the system. Compares the use case files at the tag with the working tree; the newest version goes on top. Use when the user asks to "write the release notes", "what is new in this release", "what changed since v1.3.0", "prepare the release announcement", "which features were accepted since the last release", or mentions business release notes, a changelog for users, or the Transition phase. It never edits a specification and never reads the commit history for content.

Gathers, organizes, and documents software requirements into structured catalogs with functional requirements (user stories), non-functional requirements (measurable quality attributes), and constraints. Use when the user asks to "write requirements", "create a PRD", "gather requirements", "document feature specs", "write user stories", "define NFRs", "list constraints", "write a glossary", "define domain terms", or mentions requirements catalog, requirements analysis, product requirements document, feature specification, or glossary.

Reverse-engineers an existing software project into AI Unified Process artifacts: a PlantUML use case diagram, per-use-case specification documents, and an entity model with a Mermaid ER diagram. Use when the user asks to "reverse engineer this codebase", "extract use cases from existing code", "document the system we already have", "generate use case specs from controllers", "derive an entity model from the database", "create AI Unified Process artifacts from a legacy project", or mentions reverse engineering, legacy documentation, or onboarding an inherited codebase. Trigger this skill whenever a user wants to produce use cases, an ER diagram, or a use case diagram from code that already exists rather than from a fresh vision document — even if they don't say "reverse engineer" explicitly.

Reviews the specification artifacts in docs/ (requirements, use case diagram, use cases, test cases, BPMN models, entity model, glossary, ADRs) against each other: a deterministic lint that can block a build (missing specifications, duplicate or unresolved ids, uncovered FRs, unmapped BPMN activities, actor mismatches, weak words, glossary synonyms, blocking questions, unlinked ADRs) and an advisory semantic review (contradicting or duplicated rules, wrong level of detail, missing alternative flows, untestable rules, ambiguity), plus a traceability matrix, requirement coverage, an HTML report, and a change impact analysis of what a changed requirement, rule, or use case affects. Use when the user asks to "review the specs", "lint the use cases", "find contradictions", "is this use case ready", "show the traceability matrix", "which use cases realize FR-014", "are all requirements covered", "HTML report", "what does FR-014 affect", "impact analysis", or wants a CI spec gate. It never edits a specification.

Records the technical layers of a project in docs/architecture/stack.md, the AI Unified Process stack file: which technology and which layer skill builds and tests the migration, persistence, client, service, API, UI, and end-to-end layers, the integration layer, the external systems, the module layout, the API contract, and the commands. Detects the stack from pom.xml, package.json, and the source tree, discovers the installed layer skills from their references/layer.md, and asks in a new project. Works next to any architecture documentation (arc42, C4, 4+1), which it reads but never writes. The construction skills read the file. Use when the user asks to "set up the stack", "choose the stack", "which layers does this project have", "we only need a REST API", "add a UI layer", "we call a payment provider", or mentions layer plugins, an external system, or a technology stack for construction. Also trigger when /use-case-implement or /use-case-test finds no stack file.

Audits an already-automated test case (TC-XXX) — one end-to-end journey across several use cases — against its document and reports a coverage matrix: which Flow rows, Validation items, and postconditions have a test step and code behind them, which are still open, and which test steps have drifted away from the test case. Use when the user asks to "check coverage of TC-001", "is TC-001 completely automated", "audit the journey", "show me the coverage matrix for the test case", "what is still missing for TC-001", or "can I set TC-001 to Automated". This is specification coverage, not line coverage. It reports only — it writes no code, no tests, and no files. For projects that combine layer plugins and record them in docs/architecture/stack.md; aiup-vaadin-jooq and aiup-angular-jpa bring their own /coverage-check TC-XXX. A use case (UC-XXX) is /use-case-coverage. When the user wants the gaps closed rather than listed, use /test-case-implement or /use-case-implement instead.

Implements a test case (TC-XXX) as an automated end-to-end test: runs the E2E test skill recorded in docs/architecture/stack.md (vaadin-e2e-test, playwright-e2e-test) with the journey, so every Flow row of the test case becomes a test step and every Validation item an assertion against the running application. Applies the rules of /use-case-test: the test case is the oracle, a test that disagrees with the code stays failing, an existing journey test is reconciled rather than duplicated. Use when the user asks to "implement TC-001", "automate TC-001", "write the end-to-end test for this test case", "turn the journey into a test", or mentions an automated test for a TC-* document in a project that combines layer plugins (aiup-vaadin, aiup-playwright). With a combined stack plugin (aiup-vaadin-jooq, aiup-angular-jpa, aiup-blazor-dotnet, aiup-nestjs-nextjs), use its /playwright-test TC-XXX. Writes test code; the TC-*.md document itself is /test-case.

Creates end-to-end test case documents (TC-*.md) that chain several use cases into one user journey with a step-by-step Flow table, concrete test data, and final validations. Use when the user asks to "create a test case", "write a test case", "define an end-to-end scenario", "document a user journey for testing", "chain use cases into a test", or mentions a test case document, TC-001, journey test, or end-to-end test scenario. Also trigger whenever the user lists several use case IDs (UC-*) and wants one test definition spanning them, or wants test cases derived from a business process (BP-001), a BPMN process model, or a .bpmn file (one test case per path through the process) — the resulting TC-* document is what /test-case-implement TC-001 (layer plugins) or a stack's /playwright-test TC-001 automates.

Audits an already-written use case (UC-XXX) against its specification and reports a coverage matrix: which main success scenario steps, alternative flows, business rules, preconditions, and postconditions have code and tests behind them, which are still open, and which code or tests have drifted away from the specification. Use when the user asks to "check coverage", "run a coverage check", "is UC-001 fully implemented", "is UC-001 completely tested", "audit the use case", "show me the coverage matrix", "do a traceability check", "what is still missing for UC-001", or "can I set the status to Tested". This is specification coverage, not line coverage from a coverage report. It reports only and writes no file. For projects that combine layer plugins and record them in docs/architecture/stack.md; aiup-vaadin-jooq and aiup-angular-jpa have /coverage-check. When the user wants the gaps closed rather than listed, use /use-case-implement or /use-case-test instead. A TC-XXX journey is /test-case-coverage.

Creates or updates PlantUML use case diagrams (docs/use_cases.puml) from the requirements catalog: identifies primary and secondary actors, derives one use case per user goal with a UC-XXX id traced to its functional requirements, draws include and extend relationships, and keeps a split by module. Use when the user asks to "create a use case diagram", "draw a UML use case diagram", "map actors to use cases", "add a use case to the diagram", "generate a .puml file", or mentions PlantUML, use case overview, actor diagram, or system use cases. Class, sequence, and ER diagrams are not use case diagrams; the entity model is /entity-model.

Implements a use case (UC-XXX) across the technical layers of the project by running the layer skills recorded in docs/architecture/stack.md bottom-up — migration, persistence, client, service, API, UI, limited to the entry layers its **Layers:** line names — after checking the specification's status, reading exactly the requirements the use case links. Owns the shared rules: no assumptions for specification gaps (recorded in docs/open-questions.md), decision rights, UC-XXX BR-YYY markers, no edits to tests or docs. Use when the user asks to "implement UC-001", "build this use case", "implement the use case end to end", "implement only the API layer of UC-001", or mentions implementing a use case in a project that combines layer plugins (aiup-flyway, aiup-jooq, aiup-jpa, aiup-spring-boot, aiup-vaadin, aiup-angular). For a project that uses a combined stack plugin (aiup-vaadin-jooq, aiup-angular-jpa, aiup-blazor-dotnet, aiup-nestjs-nextjs), use that plugin's /implement instead.

Creates and updates detailed use case specification documents (docs/use_cases/UC-XXX-*.md) with actors, trigger, preconditions, main success scenarios, alternative flows, postconditions, and business rules, clarifies open questions first, links the requirements each use case realizes, and validates every file with a bundled script. Use when the user asks to "write a use case", "specify a use case", "document system behavior", "define scenarios", "write a functional spec", or mentions use case specification, acceptance criteria, or user scenarios. Also trigger whenever the task is to write use case specification documents for the use cases in a use case diagram (e.g. docs/use_cases.puml) — including phrasings like "detailed use case specifications before writing any code", "one file per use case", or a request to cover the happy path, alternative flows, postconditions, and business rules for each use case.

Writes the tests for a use case (UC-XXX) by running the test skills recorded in docs/architecture/stack.md from the integration layer up — looked up in its Integration layer table for the entry layer the use case is offered through — plus E2E per the E2E scope; a lower layer gets tests only as a second entry layer or when named. Owns the rules every test layer shares: the specification is the oracle, a test that disagrees with the code stays failing, existing tests are reconciled rather than duplicated, and every test carries the use case id. Use when the user asks to "test UC-001", "write the tests for this use case", "test only the service layer", or mentions tests for a use case in a project that combines layer plugins (aiup-jooq, aiup-jpa, aiup-spring-boot, aiup-vaadin, aiup-angular, aiup-playwright). With a combined stack plugin (aiup-vaadin-jooq, aiup-angular-jpa, aiup-blazor-dotnet, aiup-nestjs-nextjs), use its test skills. A TC-* journey is /test-case-implement; a TC-*.md document is /test-case.

Writes the user guide of the system in docs/user_guide/ from the use case specifications: one chapter per primary actor (or per module in a project split by module), one task section per use case written in the second person from its main success scenario, alternative flows, preconditions, business rules, and postconditions, in the terms of docs/glossary.md and the language of the specifications. Covers the use cases that are Tested or Done; keeps the sections the team added by hand; never invents screens, buttons, or menu paths the specification does not name. Use when the user asks to "write the user guide", "create the user manual", "document the system for end users", "update the user guide for UC-004", "write help pages", "prepare training material", or mentions the Transition phase, end-user documentation, or docs/user_guide. It never edits a specification.

Interpret and calibrate already-collected research material derived from Product Hunt so agents do not mistake launch-day momentum, supportive comments, or leaderboard position for durable product quality or market truth. Use when weighing notes, summaries, reviews, rankings, or quoted material from Product Hunt as part of research, or when deciding how much weight to give Product Hunt launch traction, comments, and maker feedback. This is an informational calibration skill, not a browsing or execution workflow.

Calibrate research done on Reddit so agents do not mistake subreddit culture, anecdotal intensity, or comment popularity for reliable evidence. Use when summarizing Reddit threads, extracting recurring user pain from Reddit discussions, citing Reddit as part of research, or deciding how much weight to give repeated subreddit sentiment.