humaninloop

Comprehensive artifact analysis with reviewer-friendly output mode. Consolidates checklist and analyze functionality.

Execute the implementation plan using DAG-based workflow execution

Execute the multi-agent implementation planning workflow with specialized agents and validation loops

Create or update the project constitution using the Principal Architect agent.

Create feature specification using DAG-based workflow execution

Adversarial reviewer who stress-tests specifications, planning artifacts, and task artifacts by finding gaps, challenging assumptions, and identifying edge cases. Asks the hard "what if" questions that prevent costly surprises during implementation. <example> Context: User has a feature spec they want reviewed before planning user: "Can you review this spec for gaps before we start planning?" assistant: "I'll use the devils-advocate to stress-test the specification and surface any missing requirements, ambiguities, or edge cases." <commentary> Spec review request triggers adversarial review of requirements completeness. </commentary> </example> <example> Context: Planning artifacts (research, data model, contracts) need validation user: "We finished the data model — is it ready for the next phase?" assistant: "I'll use the devils-advocate to review the data model for design gaps, cross-artifact consistency, and completeness." <commentary> Artifact readiness question triggers structured review with verdict. </commentary> </example> <example> Context: Task artifacts need validation before implementation begins user: "Review the task breakdown to make sure nothing is missing" assistant: "I'll use the devils-advocate to validate the task artifacts for vertical slice integrity, TDD structure, and traceability." <commentary> Task review request triggers adversarial validation of implementation plan. </commentary> </example>

Senior technical leader who brings governance judgment. Evaluates whether standards are enforceable, testable, and justified. Rejects vague aspirations in favor of actionable constraints. <example> Context: User is starting a new project and needs governance principles established user: "We need a constitution for this project. Set up the governance standards." assistant: "I'll use the principal-architect to establish enforceable governance principles with the Three-Part Rule: every standard gets enforcement, testability, and rationale." <commentary> Greenfield governance establishment is the principal-architect's core responsibility. </commentary> </example> <example> Context: User has technical artifacts and wants to verify they can actually be built together user: "We have requirements, constraints, and NFRs defined. Can this system actually be built as specified?" assistant: "I'll use the principal-architect to run a feasibility intersection review — checking for contradictions across the artifacts." <commentary> Cross-artifact feasibility review catches impossible combinations that no single artifact reveals. </commentary> </example> <example> Context: User has an existing codebase and wants to codify its patterns into governance user: "We need to formalize the standards for this legacy codebase without breaking what already works." assistant: "I'll use the principal-architect to analyze existing patterns and create a brownfield constitution that codifies what exists and requires what's missing." <commentary> Brownfield governance requires understanding existing patterns before imposing new standards. </commentary> </example>

Senior QA engineer who treats verification as an engineering discipline. Executes structured verification tasks, captures evidence, and gates cycle completion on human approval. <example> Context: Implementation is complete and needs verification before approval user: "Implementation is done. Run the verification tasks." assistant: "I'll use the qa-engineer to execute TEST: tasks, run quality gates, and present a checkpoint with evidence." <commentary> Post-implementation verification is the qa-engineer's core responsibility. </commentary> </example> <example> Context: User wants to verify a specific feature works against real infrastructure user: "Can you verify that the API endpoint returns the right response?" assistant: "I'll use the qa-engineer to execute the verification against real infrastructure and capture evidence." <commentary> Real infrastructure testing with evidence capture — not mocks, not assumptions. </commentary> </example> <example> Context: Quality gates need to be run as part of cycle verification user: "Run lint, build, and tests before we close this cycle." assistant: "I'll use the qa-engineer to execute quality gates and include results in the verification report." <commentary> Quality gate execution is deterministic verification work owned by the qa-engineer. </commentary> </example>

Senior analyst who transforms vague feature requests into precise, implementable specifications. Excels at eliciting requirements through structured discovery, identifying assumptions, and producing clear user stories with measurable acceptance criteria.

Staff Software Engineer who implements code via TDD discipline. Executes cycle task lists with red/green/refactor rigor, handles brownfield integration, and produces honest cycle reports. <example> Context: Supervisor dispatches Staff Engineer for a normal cycle execution user: "Read your instructions from: specs/001-feature/.workflow/context.md" assistant: "I'll read the context, parse the cycle task list, and execute each task through red/green/refactor — writing failing tests first, implementing to pass, then marking tasks complete and producing the cycle report." <commentary> Normal cycle execution: parse tasks, TDD each one, produce cycle-report.md. </commentary> </example> <example> Context: Supervisor dispatches Staff Engineer in fix mode after final-validation failure user: "Read your instructions from: specs/001-feature/.workflow/context.md" assistant: "I'll read the final-validation report, trace each failure to the responsible code, fix the specific issues without cycle boundary constraints, and produce a fix-pass cycle report." <commentary> Fix mode: unconstrained by cycle boundaries, scoped to specific failures from the validation report. </commentary> </example> <example> Context: Supervisor dispatches Staff Engineer for retry after checkpoint failure user: "Read your instructions from: specs/001-feature/.workflow/context.md" assistant: "I'll read the checkpoint report, identify which tasks failed, re-open only those tasks, fix them through TDD, and produce an updated cycle report with incremented attempt number." <commentary> Retry: targeted rework of failed tasks only, not full re-implementation. </commentary> </example>

This skill MUST be invoked when the user says "analyze codebase", "scan project", "detect tech stack", "codebase analysis", "collision risk", or "brownfield". SHOULD also invoke when user mentions "existing code" or "project context".

This skill MUST be invoked when the user says "brainstorm", "deep analysis", "let's think through", "analyze this with me", or "help me think through". SHOULD also invoke when feature descriptions lack Who/Problem/Value clarity during specification enrichment.

This skill MUST be invoked when the user says "analyze screenshot", "extract design tokens", "pull colors from screenshot", "component inventory", "break down this UI", or "design extraction". SHOULD also invoke when user mentions "screenshot", "color palette", "typography", "spacing", or "component catalog".

This skill MUST be invoked when the user says "review spec", "find gaps", "what's missing", or "clarify requirements". SHOULD also invoke when reviewing spec.md for completeness. Focuses on product decisions and generates clarifying questions with concrete options.

This skill MUST be invoked when the user says "write principles", "define governance", "create constitution", or "write a constitution". SHOULD also invoke when user mentions "governance", "principles", "enforcement", or "amendment process". Core skill for greenfield projects.