v20227

Lead-only rules for evidence collection, completion checks, and final delivery.

Lead-only rules for native Hana subagent dispatch, guidance, status, and cancellation.

Lead-only rules for objective control, decomposition, delegation decisions, and authorization gates.

Only for the Hana Development Suite coordinator. Goal state, bounded dispatch, evidence, and completion rules.

Lead-only rules for dynamic task queues, thread reuse, new work, stopping, and recovery.

Security Guardian-only rules for secrets, authentication, authorization, and permission review.

Architect-only rules for module boundaries, ownership, dependencies, and system structure.

Reviewer-only rules for independent correctness and objective-fulfillment review.

Implement the smallest safe and verifiable code change from a confirmed task package while following the current architecture and coding conventions. Use for feature, repair, and refactoring implementation; do not use for requirement definition, evidence-free…

Delegate bounded development research, discussion, testing, or independent review to temporary subagents while the current conversation agent keeps ownership, receives structured reports, and cleans temporary contexts and resources. Use when independent work…

Route software-development requests, select the active stage skill, optionally use bounded subagent support, maintain handoffs and state, and manage the Spec, Research, Plan, Code, Verify, Fix, Review, and Delivery loop. Use for full or cross-stage…

Use a reproducible failure record to identify the root cause, implement the smallest correction, and return to the original verification path. Use after test, build, runtime, or review failure; do not make random evidence-free changes, expand feature scope,…

Build the smallest executable implementation plan from the confirmed specification, acceptance contract, project facts, and research conclusions. Use before coding to define milestones, affected scope, and validation; do not redefine the product goal or write…

Define and enforce observable replication parity for cloning, reimplementation, compatibility, migration, or replacement work. Use when an existing product or system is the behavioral target; do not use for ordinary greenfield development or visual…

Inspect highly relevant GitHub projects and required technical material during actual development to confirm implementation patterns, compatibility, testing approaches, and risks for the current project. Use after specification and before planning; do not use…

Review final changes against the specification, acceptance contract, and actual verification evidence, then return PASS, PASS_WITH_NOTES, FIX_REQUIRED, or BLOCKED. Use for final completion decisions or independent code review; do not implement a feature from…