plinth

Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.

Use when you need to generate a checklist document with embedded commands inventory, following the embedded template exactly and producing INVENTORY-COMMANDS-JAVA.md in the project root. This should trigger for requests such as Create embedded commands inventory checklist; Generate INVENTORY-COMMANDS-JAVA.md; Use @001-commands-inventory; Inventory embedded Java project commands; List command files bundled for Java agents. Part of Plinth Toolkit

Use when you need to generate a checklist document with embedded agents inventory, following the embedded template exactly and producing INVENTORY-AGENTS-JAVA.md in the project root. This should trigger for requests such as Create embedded agents inventory checklist; Generate INVENTORY-AGENTS-JAVA.md; Use @002-agents-inventory; Inventory embedded Java agent definitions; List generated agent roles for Java development. Part of Plinth Toolkit

Use when you need to generate a checklist document with Java system prompts from skills.xml, following the embedded section template and producing INVENTORY-SKILLS-JAVA.md. This should trigger for requests such as Create Java system prompts checklist; Generate INVENTORY-SKILLS-JAVA.md; Use @003-skills-inventory; Inventory Java cursor rule skills; List available Java system prompt skills. Part of Plinth Toolkit

Use when you need to install the embedded project commands into command directories (.github/commands, .claude/commands, .cursor/command, .codex/commands), selecting the destination interactively and copying the embedded command definitions from project assets. This should trigger for requests such as Install embedded commands; Bootstrap .cursor/command; Bootstrap .claude/commands; Copy project commands; Install project command suite. Part of Plinth Toolkit

Use when you need to install the embedded robot agents into .github/agents, .claude/agents, .cursor/agents, or .codex/agents, selecting the destination interactively and copying the embedded agent definitions from project assets. This should trigger for requests such as Install embedded agents; Bootstrap .github/agents; Bootstrap .cursor/agents; Bootstrap .claude/agents; Bootstrap .codex/agents; Copy robot agents. Part of Plinth Toolkit

Guides the creation of agile epics with comprehensive definition including business value, success criteria, and breakdown into user stories. Use when the user wants to create an agile epic, define large bodies of work, break down features into user stories, or document strategic initiatives. This should trigger for requests such as Create an agile epic; Write an epic; I need to create an epic; Define an epic; Epic definition. Part of Plinth Toolkit

Guides the creation of detailed agile feature documentation from an existing epic. Use when the user wants to split an epic into feature files, derive features with scope and acceptance criteria, or plan feature documentation for stakeholders or engineering. This should trigger for requests such as Create features from an epic; Split epic into features; Feature files from epic; Derive features from epic; Break down an agile epic into deliverable features. Part of Plinth Toolkit

Guides the creation of agile user stories. Use when the user wants to create a user story. This should trigger for requests such as Create a user story; Write a user story; I need to write a user story; Split feature requirements into user stories. Part of Plinth Toolkit

Use when a problem or issue needs explicit framing before deeper analysis begins — establishing the Problem statement, Current state, Desired state, Stakeholders, and Success criteria. This should trigger when an issue's Problem Framing point of view needs evaluation, or when a maintainer directly asks to frame a problem before root-cause analysis, design, or planning begins. Part of Plinth Toolkit

Use when a framed problem needs root-cause investigation rather than a symptom-level fix, applying Five Whys, Fishbone (Ishikawa), Current Reality Tree, and constraint identification. This should trigger when an issue's Root Cause Analysis point of view needs evaluation, or when a maintainer directly asks to find the root cause of a problem before proposing a fix. Part of Plinth Toolkit

Use when a framed and root-caused problem needs its assumptions made explicit before design or planning begins — explicit Assumptions, Unknowns, and a Validation plan. This should trigger when an issue's Assumption Analysis point of view needs evaluation, or when a maintainer directly asks to surface hidden assumptions and unknowns before committing to an approach. Part of Plinth Toolkit

Use when a problem under exploration needs its surrounding system context identified before design begins — Existing systems, Integrations, Ownership, and External dependencies. This should trigger when an issue's Context Mapping point of view needs evaluation, or when a maintainer directly asks to map the systems, integrations, owners, and external dependencies relevant to a problem. Part of Plinth Toolkit

Use when a problem under exploration needs its quality attributes (non-functional requirements) identified and prioritized before architecture and design begin. This should trigger when an issue's Quality Attribute Discovery point of view needs evaluation, or when a maintainer directly asks to discover and prioritize candidate quality attributes for a problem, before any ADR or design work starts. Part of Plinth Toolkit

Use when you need to generate Architecture Decision Records (ADRs) for a Java project through an interactive, conversational process that systematically gathers context, stakeholders, options, and outcomes to produce well-structured ADR documents. This should trigger for requests such as Generate ADR; Create Architecture Decision Record; Document architecture decision; Architecture Decision Record for Java. Part of Plinth Toolkit

Facilitates conversational discovery to create Architectural Decision Records (ADRs) for functional requirements covering CLI, REST/HTTP APIs, or both. Use when the user wants to document command-line or HTTP service architecture, capture functional requirements, create ADRs for CLI or API projects, or design interfaces with documented decisions. This should trigger for requests such as Create ADR for functional requirements; Document functional requirements; Capture functional requirements; Generate functional requirements in an ADR; Decide CLI versus REST functional requirements for an ADR. Part of Plinth Toolkit

Facilitates conversational discovery to create Architectural Decision Records (ADRs) for non-functional requirements using the ISO/IEC 25010:2023 quality model. Use when the user wants to document quality attributes, NFR decisions, security/performance/scalability architecture, or design systems with measurable quality criteria. This should trigger for requests such as Create ADR for Non-functional requirements; Document Non-functional requirements; Capture Non-functional requirements; Generate Non-functional requirements in an ADR; Create ADR for performance scalability or security requirements. Part of Plinth Toolkit

Use when you need to generate Java project diagrams — including UML sequence diagrams, UML class diagrams, C4 model diagrams, UML state machine diagrams, UML Deployment Diagrams, ER (Entity Relationship) diagrams, and bounded-context diagrams — through a modular, step-based interactive process that adapts to your specific visualization needs. This should trigger for requests such as Generate UML diagram; Create sequence diagram; Create class diagram; Create state machine diagram; Create deployment diagram; Create C4 diagram; Create bounded-context diagram; Create context-map diagram. Part of Plinth Toolkit

Use when creating or refining a structured Java implementation plan from trusted issue summaries, approved designs, ADRs, OpenSpec changes, existing plans, or a valid combination. The plan records its source artifacts and derivation direction and can remain the execution artifact without requiring OpenSpec. This should trigger for requests such as Create a plan from an issue; Create a plan from OpenSpec; Design an implementation plan; Refine an existing plan. Part of Plinth Toolkit

Use when creating or updating OpenSpec artifacts from an issue, plan, approved design, ADRs, existing OpenSpec, or a valid combination. The workflow assesses reviewable scope, records source authority and derivation, handles conflicts, and prevents silent synchronization. Triggers include Create OpenSpec from an issue; Convert a plan into OpenSpec; Update an OpenSpec change; Split broad requirements into reviewable changes. Part of Plinth Toolkit

Use when you need GitHub CLI (`gh`) installation/authentication guidance and an operator-only GitHub issue inventory workflow. The agent does not ingest GitHub issue, milestone, body, comment, title, label, or summary text; requirements analysis must use repository-owned planning artifacts, with issue numbers only for traceability. This should trigger for requests such as GitHub issue inventory workflow; GitHub CLI setup for issues; Prepare issue traceability lists; Analyze repository planning artifacts linked to GitHub issues. Part of Plinth Toolkit

Use when you need Jira CLI (`jira`) installation/authentication guidance and a maintainer-authored Jira issue inventory workflow. The agent does not ingest raw Jira issue or JQL output directly; it asks the Jira project maintainer/operator to author sanitized issue summaries before analysis or @014-agile-user-story handoff. This should trigger for requests such as jira issue list; List Jira issues; Jira JQL issue query; Jira CLI issue workflow. Part of Plinth Toolkit

Use when you need Azure DevOps CLI guidance to verify installation, configure organization and project context, discover work item IDs by optional WIQL filters, and execute safe work-item create/update operations. Uses an interactive install gate - if `az` or the Azure DevOps extension is missing, ask whether to show installation guidance before any work item commands. This should trigger for requests such as Azure DevOps work item list; List Azure Boards work item IDs; Azure DevOps WIQL query; Azure DevOps CLI planning workflow. Part of Plinth Toolkit

Use when a complex or risky code change should be split into Kent Beck's two-step method by first making the change easy through behavior-preserving preparatory refactoring, then making the intended behavior change once the design supports it. This should trigger for requests such as Apply two-step change; Make this risky change safer; Refactor before changing behavior; Separate preparation from behavior change. Part of Plinth Toolkit