dotnet-workflow-kit

Comprehensive pre-PR review that runs every reviewer the profile enables against the current branch diff, using parallel sub-agents for the read-only pass. Always includes two built-in reviewers, bug-hunt and conventions, plus whatever optional reviewers the profile turns on. Use whenever the user says "mega review", "full review", "review everything", "pre-PR check", or when the kit's pipeline reaches the Review stage. Prefer this over invoking individual review skills one at a time when the user wants a broad sweep.

The user's automated work-item delivery pipeline. Assesses where the current branch and work item sit in the standard workflow (start ticket, plan, execute, review, draft PR, resolve comments, QA, review page, publish and hand off), prints a status table, then runs stage after stage without asking for input, stopping only at the review checkpoint or on a big blocker. Use whenever the user says "next", "what's next", "move this along", "keep going", "continue the ticket", or "run the pipeline". "/next status" prints the table only, with no execution.

Generate a BDD-format QA report of what was tested this session, covering acceptance runs against a real environment and manual checks and never unit or integration suites, then post it where the profile's qa.evidence says. Use whenever the user says "qa report", "write up the testing", "document what we tested", or wants a test summary after running acceptance tests or manual verification. Also produces pre-hand-off QA notes, testing guidance written before anyone tests, covering what changed, how to test it per persona, test data and accounts, edge cases, out of scope, and environment or flag setup. Use notes mode whenever the user says "qa notes", "test notes", "notes for QA", or passes the literal argument "notes".

Start work on a tracked item, parsing its id or URL from the arguments, fetching it and any linked items through the tracker adapter, branching off the current base branch in place, assigning the item to the user and moving it to the active state, renaming the session, then handing off to the plan skill without entering Claude's own plan mode. Use whenever the user says "start ticket", "start work on <id>", "pick up <id>", or "/start-ticket".

Write a short, budgeted implementation plan for a work item and publish it as an Artifact document, ordered from the requirement outward through the architecture layers the team uses (BDD specs, then domain, application, infrastructure and API for clean architecture; slice, persistence, integration and endpoint for vertical slices), ending with tests, decisions, risks and an answerable open-questions form. Use whenever the user asks to plan a ticket or feature, says "visual plan", "plan this", "plan <ticket id>", "/visual-plan", or when the kit's pipeline reaches the Plan stage. Prefer this over Claude plan mode.

Turn a finished branch or PR into one budgeted review Artifact that serves as the code review and the QA report together. Verdict tiles, plan versus delivered, a diagram of the change, changes grouped by service then slice with every file linked to its diff, contracts other teams must move for, review findings, the BDD QA report, a persistent rollout checklist and an approve / request-changes decision form. Use whenever the user says "review this", "recap", "visual recap", "qa report", "write up the review", "/visual-review", or when the kit's pipeline reaches the Review stage. Prefer this over posting a bare QA report.