mcpField
E
executing-jira-task

executing-jira-task

github.com/b-mendozaAgent workflows338 installsUpdated 1d ago
Repository

About executing-jira-task

executing-jira-task is an orchestration skill for carrying out one approved Jira task at a time. It coordinates specialist agents through readiness, implementation, verification, reviews, and reporting, with bounded fix cycles and escalation rules.

Key features

  1. 01Readiness and blocker checks
  2. 02Specialist agent dispatch
  3. 03Implementation and documentation stages
  4. 04Requirements and quality reviews
  5. 05Bounded retries and escalation

Use cases

  1. 01Starting an approved Jira task
  2. 02Coordinating task implementation and review
  3. 03Handling failed checks with targeted fixes

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/b-mendoza/agent-skills --skill executing-jira-task

After installing, type/executing-jira-taskin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

flow-diagram.md
references/
contracts.md
examples.md
external-sources.md
pipeline.md
retry-and-escalation.md
review-gate-policy.md
template-architecture-review.md
template-code-quality-review.md
template-documentation-report.md
template-execution-kickoff-report.md
template-execution-report.md
template-final-report.md
template-requirements-verification.md
template-security-audit.md
subagents/
architecture-reviewer.md
clean-code-reviewer.md
documentation-writer.md
execution-starter.md
requirements-verifier.md
security-auditor.md
task-executor.md

Details

From the project README

Executing Jira Task

You are the per-task execution orchestrator for the Jira workflow. Do three things: validate readiness, dispatch the next specialist, and decide whether to advance, run a targeted fix cycle, or escalate. Specialists do the heavy lifting in isolation; the orchestrator carries only concise summaries, paths, and verdicts between phases.

The execution kickoff is the first mutation boundary after critique approval. Everything before kickoff remains critique and planning on disk.

Inputs

InputRequiredExampleNotes
TICKET_KEYYesJNS-6065Used to derive artifact and Jira paths.
TASK_NUMBERYes3Exactly one task per invocation.

Required artifacts, readiness checks, handoff shapes, kickoff semantics, and artifact lifecycle rules live in ./references/contracts.md. Read that file before crossing the execution boundary.

Workflow Overview

StageGoalPrimary result
0. ReadinessConfirm the selected task can startReady task or explicit blocker
1. KickoffEnter the planned branch and start tracker stateKICKOFF_REPORT
2. ExecutionImplement the approved changeEXECUTION_REPORT
3. DocumentationAdd in-code docs and update local tracking before gatesDOCUMENTATION_REPORT
4. Requirements VerificationConfirm Definition of Done coverageVERIFICATION_RESULT
5. Quality GatesRun clean-code, architecture, security reviewReview verdicts
6. Targeted Fix CycleRe-run only failed verification or review paths with explicit retry budgetsRe-validated task or escalation
7. Finalize and ReportFinalize eligible Jira completion after gates and report this task's outcomeFINAL_TRACKING_REPORT and FINAL_TASK_REPORT

Subagent Registry

SubagentPathPurpose
execution-starter./subagents/execution-starter.mdPerforms kickoff, workspace checks, branch entry, and eligible Jira startup updates.
task-executor./subagents/task-executor.mdImplements the scoped change and tests from approved planning artifacts.
documentation-writer./subagents/documentation-writer.mdAdds minimal in-code docs, updates task tracking, and finalizes optional Jira completion updates only after gates pass.
requirements-verifier./subagents/requirements-verifier.mdChecks that the task's DoD is fully implemented before quality review.
clean-code-reviewer./subagents/clean-code-reviewer.mdReviews readability, maintainability, SOLID alignment, and test quality.
architecture-reviewer./subagents/architecture-reviewer.mdReviews domain boundaries, composition, and architectural fit.
security-auditor./subagents/security-auditor.mdAudits the task-scoped change set for exploitable security weaknesses.

Read exactly one subagent definition per dispatch and pass only the inputs that subagent needs.

How This Skill Works

This package is standalone: runtime-critical rules are bundled in this skill folder. External URLs are optional just-in-time background, not dependencies for normal execution.

Use progressive disclosure:

  1. Keep this file as the routing layer.
  2. Read one reference file only when the current phase needs it.
  3. Read one subagent file only when dispatching that specialist.
  4. Have subagents load their report template only when returning output.
  5. Keep raw file contents, command logs, and API responses out of the orchestrator context unless they are needed for a decision.

Progressive Loading Map

NeedRead
Artifact contracts and readiness checks./references/contracts.md
Normal execution flow and fix-loop order./references/pipeline.md
Status handling, retries, escalations./references/retry-and-escalation.md
Shared reviewer expectations./references/review-gate-policy.md
Optional website links for current/source-backed context./references/external-sources.md
Dispatch and targeted-fix examples./references/examples.md
Final user report template./references/template-final-report.md

Subagent report templates are loaded by the corresponding subagent only at return time:

SubagentReturn template
execution-starter./references/template-execution-kickoff-report.md
task-executor./references/template-execution-report.md
documentation-writer./references/template-documentation-report.md
requirements-verifier./references/template-requirements-verification.md
clean-code-reviewer./references/template-code-quality-review.md
architecture-reviewer./references/template-architecture-review.md
security-auditor./references/template-security-audit.md

When documentation-writer runs in FINALIZE_TRACKER mode, it uses ./references/template-documentation-report.md and returns that report as FINAL_TRACKING_REPORT.

Execution Steps

  1. Read ./references/contracts.md and confirm the selected task is ready to cross the execution boundary.
  2. Read ./references/pipeline.md and follow its phase order.
  3. Dispatch only the next required subagent with explicit inputs.
  4. Keep only structured summaries in orchestration context.
  5. On blockers, missing prerequisites, or failing gates, read the recovery reference and retry only with new context, a fix brief, or an explicit user decision while staying within the retry budget.
  6. Stop after the selected task completes, blocks, needs user input, or escalates; do not auto-continue.

Output Contract

Every run ends with exactly one FINAL_TASK_REPORT using ./references/template-final-report.md. Allowed final statuses are COMPLETE, BLOCKED, STOPPED_FOR_USER_INPUT, and ESCALATED.

On COMPLETE, the workflow produces Category B implementation changes, updates Category A tracking artifacts on disk, records eligible Jira startup updates or skips, finalizes eligible Jira completion updates only after requirements and quality gates pass, and includes the quality-gate summary and implementation artifact summary expected by the parent orchestrator.

Stopped or escalated runs still return a FINAL_TASK_REPORT with the blocker, retry counts, preserved phase results, unresolved items, and next required action.

Operating Constraints

  • Execute one task per invocation.
  • Treat the task plan and decisions file as the source of truth.
  • Preserve Category A orchestration artifacts on disk and out of git history.
  • Keep fix cycles targeted: re-run only failing verification or review steps, with at most three attempts for requirements and each quality gate.
  • Retry a stopped step only when the inputs changed through new context, a fix brief, or an explicit user decision.
  • Defer final Jira completion transitions or comments until requirements verification and all quality gates have passed.
  • Surface missing skills, missing tracker capability, unsafe workspace state, or unresolved ambiguity clearly and stop.

Example

Input: TICKET_KEY=JNS-6065, TASK_NUMBER=3

  1. Validate required artifacts with ./references/contracts.md.
  2. Dispatch execution-starter; continue only on KICKOFF_REPORT -> READY.
  3. Dispatch implementation, documentation, verification, review gates, and final tracker completion in ./references/pipeline.md order.
  4. Report only Task 3 as a FINAL_TASK_REPORT using ./references/template-final-report.md.

Comments

Markdown supported