the_agentic_developer_2026_04

Vision refinement skill for this team. Invoke with /brainstorm. Reads memory/project/INDEX.md to learn the active project and either loads the active vision or starts a fresh one. Leads a structured interview to co-create or update vision.md — covering problem framing, target users, value proposition, key capabilities, and success signals. Use whenever the team is starting a new initiative or pressure-testing direction.

Structured business research for this team. Invoke with /business-research. Reads memory/project/INDEX.md to learn the active project and grounds in the active vision/research artifacts. Supports two modes — (1) competitive analysis: maps the competitor landscape, features, pricing, and positioning gaps; (2) customer journey: traces the target user's path, pain points, decision triggers, and emotional states. Delegates web searches to multiple parallel specialized agents. Always produces an unopinionated research.md artifact saved to the active session folder. Use whenever market intelligence, competitor data, user journey insight, or factual grounding is needed before making a product decision.

Idea and task capture skill for this team. Invoke with /capture. Three modes — Quick (fast brain-dump with minimal friction), Deep (structured interview that extracts tasks with acceptance criteria), Refine (cleans up and re-prioritises existing tasks). Reads memory/project/INDEX.md to learn the active project, then loads vision/research/domain artifacts as grounding. Outputs to docs/tasks.md, initialising it if missing. Use whenever the team has new ideas to capture, wants to extract tasks from a conversation, or needs to groom the backlog.

Strategic DDD domain modeling skill for this team. Invoke with /domain. Reads memory/project/INDEX.md to learn the active project, then grounds in the active research.md artifact. Leads a structured conversation to co-build a domain.md following Domain-Driven Design strategic patterns — core domain identification, subdomain classification, bounded context discovery, context mapping, ubiquitous language, and key aggregates. Emits glossary proposals for accepted ubiquitous-language terms. Use whenever the team needs to translate research insights into a shared domain model before moving to feature planning.

Reconcile memory/project/INDEX.md with what is actually on disk under exercise_one/. Invoke with /reindex. Runs the deterministic scripts/reindex_memory.sh report, presents drift to the user, proposes an updated INDEX.md, and applies it only on confirm. Use whenever a skill warns about possible memory drift, after manual edits to session folders, or as a periodic sanity check.

General-purpose research skill for this team. Invoke with /research. Reads memory/project/INDEX.md to learn the active project and grounds in the active vision. Complements /business-research (which covers competitive analysis and customer journeys) by handling technical, regulatory, UX pattern, and open-ended topic research. Always produces an unopinionated research.md artifact saved to the active session folder. Use when the team needs depth on a topic that is not a competitor landscape or customer journey map.

Tactical DDD modeling skill for this team. Invoke with /tactical-ddd. Reads memory/project/INDEX.md to learn the active project, then grounds in the active domain.md. Leads a structured conversation to produce a tactical-ddd.md with ASCII entity diagrams and Mermaid class/sequence diagrams for each bounded context. After saving the artifact, appends implementation tasks surfaced during modeling to docs/tasks.md. Carries glossary proposals forward from the domain layer. Use after /domain has produced a strategic model and before /worker begins implementation.

Task execution skill for this team. Invoke with /worker. Reads memory/project/INDEX.md and docs/tasks.md, lets the user select one task, then creates an isolated git worktree to implement it. Reads decisions.md and glossary.md before implementation so chosen names and constraints stay aligned with the team's accepted language and prior commitments. One worker, one worktree, one task at a time. Marks tasks in-progress and done. Use whenever the team is ready to move a task from backlog to implementation.

DDD domain modeling and brainstorming skill. Use this skill whenever the user wants to explore a domain, create or refine a vision, plan a project, think strategically, figure out what to build and why, or do any kind of structured modeling session. Engage in Socratic dialogue — ask, challenge, synthesize. Never produces code. Produces a VISION.md. Trigger on "let's brainstorm", "model this with me", "let's plan", "I want to think through", "what should we build", "let's do a domain session", or any intent to explore purpose and direction before building. Also trigger when the user seems stuck on direction or wants to revisit the vision.

Frictionless idea and feature capture into the project backlog. Use this skill whenever the user mentions a new idea, feature, insight, or discovery — at any point, mid-conversation, mid-implementation, even mid-brainstorm. This skill is always available and should never feel like an interruption. Trigger on "capture this", "I want to add", "new idea", "let's not forget", "note that", "backlog this", "I just thought of", or any spontaneous insight the user wants to preserve before it's lost. Also trigger when the user describes something that sounds like a feature or strategic shift, even if they don't explicitly ask to capture it.

Backlog implementation skill for building frontend features. Use when the user wants to implement something, start building, pick up a task, or asks what to work on next. Reads VISION.md and BACKLOG.md, pulls an item into focus, implements it as plain HTML/CSS/JavaScript, and marks it done. No backend, no frameworks. Trigger on "let's build", "implement this", "start working", "what's next", "pick up a task", "let's ship something", or any intent to move from planning into doing.

Multi-stage feature development pipeline for the Personal Finance App. Takes a rough feature idea through four stages — clarification (subagent questions), user journeys (subagent), technical plan with architectural decisions (subagent, in parallel with journeys), and parallel implementation by worker subagents. Pauses between stages so you can review before moving on. Use this skill whenever the user describes a feature to build or add and asks to "take it through the pipeline", "build it end-to-end", "do the whole thing", "plan and implement", or explicitly references `.features/`. Also use when the user says "continue the feature pipeline", "resume the feature …", or otherwise points at an in-flight feature folder. Prefer this skill over `feature-request-designer` when the user wants to go past the spec all the way to implementation; prefer `feature-request-designer` when they only want the spec.

Turn a rough product idea into a fully-specified feature request document that a downstream implementation skill (or engineer) can build from with no further clarification. Use this whenever the user describes a new feature, capability, enhancement, or user-facing behavior they want for the Personal Finance App — phrases like "I want to add…", "what if the app could…", "we should let users…", "idea: …", "feature request:", or any description of a capability that doesn't yet exist. Also use when the user explicitly says "design this feature", "spec this out", "write a feature request", or references `docs/feature-requests`. Err on the side of triggering: a half-formed idea is exactly what this skill is for.

Our team's house style for any HTML/CSS/UI work — intentionally trashy 1990s Geocities aesthetic. Green buttons, pastel complementary background, centered divs, Comic Sans, plus the full retro toolkit (marquee, blink, tiled backgrounds, visitor counters, "under construction" vibes, clashing colors). Use whenever you are writing, editing, or scaffolding HTML, CSS, or any web page / web UI / landing page / form / dashboard — even when the user only says "build a page", "add a screen", "style this", "make it look nicer", or sketches markup inline. If the output is something a browser will render, this skill applies. Do NOT produce clean/minimal/modern-looking pages; the trashiness is the point.

Stage 1 of the `/idea` pipeline — restate an informal idea in concrete terms, locate it in the hexagon, fix what's out of scope, and surface at most two focused questions. Use when invoked by the `/idea` orchestrator, when the user says "clarify this idea", or when they drop a rough feature idea that needs shape before planning. Updates `.claude/idea/current.md` and hands off to `idea-plan`.

Stage 3 of the `/idea` pipeline — write the code and tests for an already-approved plan, respecting the hexagonal layout, CSV persistence conventions, and JUnit 5 + AssertJ testing style from `exercise_1/CLAUDE.md`. Use when the orchestrator invokes this, when the user says "implement the plan" / "let's build it", or when `.claude/idea/current.md` has `Status: planned` and `Approved: yes`. Appends a file-log to the state and hands off to `idea-verify`.

Stage 2 of the `/idea` pipeline — turn a clarified idea into a concrete implementation plan (files by hex layer, port signatures, tests, compatibility cost) and get the user's nod before any code is written. Use when the orchestrator invokes this, when the user says "plan this" / "draft a plan", or when a clarified idea is in `.claude/idea/current.md` with `Status: clarified`. Updates the state file and hands off to `idea-implement`.

Orchestrate the idea → commit pipeline for the personal finance app. Primary invocation is `/idea <the idea in plain words>`, but also use whenever the user starts a message with "idea:", says "let's add…", "we should be able to…", "can we track…", or asks "where were we" / "resume the idea" / "what's the idea status". Routes to the stage skills (`idea-clarify`, `idea-plan`, `idea-implement`, `idea-verify`, `commit`) via a shared state file so work is resumable across sessions.

Stage 4 of the `/idea` pipeline — prove an implemented change works by running the relevant tests, exercising the UI where applicable, and doing a fast self-review. Use when the orchestrator invokes this, when the user says "verify it" / "does it work?" / "run the tests", or when `.claude/idea/current.md` has `Status: implemented`. Records results in the state file and hands off to `/commit`.

Refine and scaffold a feature slice (brainstorm → Gherkin spec → React + TypeScript + localStorage) for team duePi's personal finance & budgeting app from an entry in `teams/duePi/exercise_one/features.md`. Trigger whenever the user runs `/feature`, asks to "build the next feature", "implement track-expenses", "turn this markdown spec into code", "scaffold a feature", "refine a feature before building", or otherwise wants to move an item in `features.md` from pending to implemented. Also trigger when the user adds a new feature description in discussion and asks what's next to build. Use even when `/feature` is not typed verbatim, as long as the intent is to realise a `features.md` entry in the duePi app.

Structured feature brainstorming for team Laszlo & Robert. Use this skill whenever someone proposes a new feature, asks "what should we build next", wants to think through an idea before coding, or says things like "I want to add X", "let's brainstorm Y", "what do you think about building Z". The goal is to lock intent → requirements → rough design before any code is written. Trigger even when the idea sounds simple — simple ideas benefit from 5 minutes of structure too.

Split independent work across parallel subagents to save time. Use this skill when implementing multiple features, views, or files that don't depend on each other. Trigger when someone says "build these in parallel", "can we do these at the same time", or when the implementation plan has steps that are clearly independent — e.g. building IncomeView and SavingsView simultaneously. Do not use when tasks share state, write to the same files, or when one task's output is another's input.

TDD workflow for logic-heavy code in the Laszlo & Robert budgeting app. Use this skill for budget calculations, categorisation rules, data transformations, and any function with non-trivial logic. Skip for pure UI components, layout changes, or wiring code. Trigger when someone says "let's TDD this", "write tests first", "add tests for X", or when implementing anything involving money math, percentage calculations, filtering, or aggregation.

Write an implementation plan for multi-step work. Use this skill when the team is about to start a feature, a new exercise, or any work that spans more than a handful of files. Trigger when someone says "let's plan this", "write a plan for X", "what's our approach", or after a brainstorm has been agreed on. The plan is written first, reviewed by the team, and only then does implementation begin — Claude does not write code until the plan is approved.

DDD and TDD workflow for implementing features. Use this skill whenever the user asks to implement a feature, add functionality, build something new, or work on a user story. This includes requests like "add X", "implement Y", "build the Z feature", "I need a way to...", or any task that involves adding new behavior to the codebase. Use this even for small features — the workflow scales down gracefully. Do NOT use for pure refactoring, bug fixes, or config changes.

Create a git commit with a short, present-tense summary of the staged and unstaged changes. Use whenever the user wants to commit, save, ship, or wrap up work — including casual phrasings like "commit this", "commit it", "save this". Never pushes.

Design, review, or refactor Java/Spring codebases to strict hexagonal architecture with clear domain, ports, and adapters. Use when creating new modules, restructuring package layout, defining incoming/outgoing adapters (web, Kafka, HTTP clients, database), or enforcing boundaries with ArchUnit and dependency rules.

Rules for writing Java unit tests. Use this skill whenever you create or update unit tests in a Java project (`*Test`). Do not use this skill for integration tests (`*IT`) or Spring Boot context tests (`@SpringBootTest`).

Analyze the current git diff and create a well-crafted commit that matches the repository's existing style. Use this skill whenever the user wants to commit changes, save their work, wrap up a change, or mentions committing in any form — including casual phrasings like "commit this", "ship it", "let's commit", "save this", "make a commit", or "wrap this up". Stages files intelligently (skipping secrets, build artifacts, and editor/OS cruft), reads recent commit messages to match the repo's existing style and conventions, writes a message focused on why the change was made rather than what mechanically changed, and commits without pushing.