b-mendoza

Audits an implementation plan for requirements traceability, avoidable complexity, risky assumptions, and evidence gaps. Use when reviewing an AI-generated or human-authored plan, design proposal, implementation outline, task breakdown, or architecture plan and the user wants a standalone audit report without overwriting the source plan.

Validates answers that depend on current external facts, including prices, versions, policies, rankings, recommendations, documentation, and availability. Use when the user asks for current, latest, verified, fact-checked, or up-to-date answers. Coordinates recency-checker and claim-verifier subagents to produce a current, qualified final answer.

Create review-ready pull requests or merge requests from the current branch through a fork-aware, idempotent, preview-first, user-approved workflow. Use when the user asks to create, open, draft, or submit a PR, pull request, merge request, or code review request, or says their branch is ready for review.

Reviews one GitHub pull request and prepares a verified local review or posts its exact approved contents. Use when the user asks to review a PR, audit a pull request, draft review comments or request-changes feedback, write a PR review file, or optionally post approved review comments. Handles exactly one PR. Does not open pull requests, fix reviewed code, implement incoming review feedback, or resume saved reviews.

Creates reviewable atomic git commits from an explicit list of files or folders after the user asks, in words, to commit. Use when the user says commit these files, commit only src/x, split my changes into atomic commits, commit the ticket work, or keep unrelated work out of the commit. Shows the exact commit plan for approval before any commit and preserves unrelated staged and unstaged work. Does not push, amend, or rewrite history. Does not open pull requests. Does not summarize recent project state.

Assess and respond to pull request review comments through a status-gated workflow: collect comments, evaluate feedback, draft replies, write a verified local report, and optionally post exact approved replies to supported GitHub review-comment threads.

Runs the conversational clarification layer for workflow orchestration. Use for plan-wide upfront clarification or task-level pre-execution critique while delegating artifact analysis, manifest assembly, and file updates to bundled subagents.

Coordinates consent-gated, evidence-isolated, behavior-preserving simplification refactors. Use when simplifying, splitting, renaming, moving, deduplicating, or clarifying existing code while preserving the canonical protected surfaces.

Rewrite existing Python, TypeScript/JavaScript, or Go code for strict static typing, boundary validation, and maintainable idioms while preserving behavior. Use when the user asks to harden code, remove unsafe escape hatches, add validation, or align with mypy, Pyright, tsc, go vet, or Staticcheck. Coordinates baseline mapping, strategy, approved implementation, and review through co-located subagents and just-in-time language references.

Diagnoses runtime bugs, crashes, regressions, failing CI/CD pipelines, and underspecified user reports through read-only, evidence-first root-cause analysis with traceable reports and bounded subagent workflows.

Improve existing test suites into minimal, high-signal behavior-focused harnesses with approval-before-mutation, conformance checks, guarded validation, bounded repair, and auditable handoff statuses. Use when asked to improve, trim, rewrite, delete, review, or harden tests around public contracts, business logic, schemas, security behavior, failures, edge cases, readability, or maintainability.

Plan a codebase restructuring through read-only architecture mapping, DDD and Screaming Architecture analysis, reference quarantine, bounded review repair, and a persisted decision report. Use when a user wants an evidence-backed restructuring plan without implementing file moves or refactors.

Retrieves a Jira ticket into docs/ .md. Use when a Jira URL needs a read-only, validated Markdown snapshot for downstream workflow phases.

Phase 2 of the Jira planning workflow. Reads a Jira ticket snapshot, dispatches a plan/prioritize/validate pipeline, and writes docs/ -tasks.md with branch names for every planned Jira subtask.

Creates or reconciles Jira subtasks for an approved Phase 4 task plan. Use after docs/ -tasks.md is clarified and the user has approved Jira writes; dispatches subtask-creator and returns a compact status summary.

Retrieves a Jira ticket or a GitHub issue into docs/ .md as a read-only, validated Markdown snapshot for downstream workflow phases. Use when a Jira URL, a GitHub issue URL, or owner/repo/number coordinates need the Phase 1 fetch-work-item step. Detects the platform from the input and loads the matching playbook just-in-time.

Creates, refines, repairs, or decomposes Markdown plus Mermaid workflow diagrams (flowchart or stateDiagram) with explicit approval gates, staged writes, empirical Mermaid validation, and compact run reports. Use when generating process flows, Mermaid flowcharts or state diagrams, agent operating procedures, human-in-the-loop gate maps, or decomposing a skill package flow diagram.

Convert prose prompts into compact, structured XML prompt contracts through staged passes. Use when a user asks to structure, harden, formalize, debug, revise, or convert a prompt; mentions XML tags, agent drift, ambiguity, hidden assumptions, success criteria, anti-patterns, autonomous prompts, or prompt suites; or provides natural-language instructions that need to become a reliable agent contract.

Coordinate an end-to-end Jira ticket workflow from ticket fetch through per-task implementation. Use this skill when the user provides a Jira URL, says "work on ticket PROJECT-123", "resume PROJECT-123", "continue this Jira ticket", "start the Jira workflow", or asks for status on a ticket without naming a specific phase. This top-level coordinator keeps SKILL.md as a routing layer, loads bundled references just in time, and dispatches execution-heavy work to downstream skills or co-located utility subagents.

Executes exactly one planned Jira or GitHub work-item task after critique approval. Use when a numbered task should move through kickoff, implementation, documentation, requirements verification, clean-code, architecture, and security gates, targeted fix cycles, tracker finalization, and a final report without continuing to the next task. Does not plan tasks or select the next task.

Plans a Phase 1 Jira ticket or GitHub issue snapshot into staged, validated Phase 2 task-plan artifacts with deterministic branch names. Use when an orchestrator or user asks to decompose docs/ .md, plan Jira tasks, plan GitHub issue tasks, or re-plan a work item after critique. Does not fetch work items, create subtasks or child issues, implement tasks, or mutate the work-item platform.

Creates or reconciles GitHub child task issues or Jira subtasks from an approved Phase 4 task plan, then updates docs/ -tasks.md with validated remote linkage. Use after the task plan has been clarified and the user has approved the exact platform writes plus scoped plan-file update. Does not plan tasks, implement code, commit changes, or mutate unrelated tracker state.

Plans how to execute exactly one already-selected numbered Jira or GitHub task by producing an execution brief, implementation plan, behavior-oriented test specification, and scoped refactoring recommendation. Use for Phase 5 task-execution planning with a workflow key and TASKNUMBER. Does not decompose the parent work item, plan multiple tasks, implement code, or advance to the next task.