| name | feature-workflow |
| model | claude-sonnet-4-6 |
| description | Kick off intentional feature work with the full ticketed workflow: clarify scope, create a goal-oriented JIRA ticket, set up the branch, develop the solution, commit, and open a PR. Use this skill when the user says "start feature: X", "start a feature", "kick off work on X", or "full workflow for X". This is a deliberate mode the user enters — do NOT trigger for casual coding requests, experiments, spikes, or when the user just asks to "add X" or "implement X" without explicit feature framing. The phrase "start feature" is the signal.
|
Start Feature Workflow
This skill orchestrates the full lifecycle of intentional feature work:
ticket → clarify → specify → plan → branch → develop → test → commit → review → PR → finalize.
It is designed to be entered deliberately. Experiments and spikes skip this
entirely — the user just codes. This workflow is for work that deserves a
JIRA ticket, a clean branch, and a PR.
There is exactly one human gate: spec and plan approval in Phase 1. After
that, all phases run autonomously.
Project configuration
JIRA, Azure DevOps, and git conventions are externalized to
.claude/skills/feature-workflow/config.json. Sub-agents read it directly.
Before Phase 1-pre, verify the config is present and parseable:
Tool: Read
file_path: .claude/skills/feature-workflow/config.json
Hold these values for use in Phase 1-pre and beyond:
<projectKey> ← jira.projectKey<urlBase> ← jira.urlBase<branchTypes> ← git.branchTypes (array, e.g., ["feature","bugfix","hotfix"])<branchPattern> ← git.branchPattern (template, e.g., "{type}/{ticket}/{slug}")
If the config is missing or invalid, stop and ask the user to populate it
before continuing — the workflow cannot create tickets or PRs without it.
The main branch (main vs master) is auto-detected at runtime by the
git-agent and the prepare-*.sh scripts via
.claude/skills/feature-workflow/scripts/lib.sh — no config entry needed.
Agent architecture
Specialized work — BDD specification, architecture planning, JIRA ticket
management, and PR creation — runs as scoped sub-agents via the Agent tool.
Each sub-agent receives only the tools it needs and a self-contained prompt;
it returns a small JSON result block that the main agent uses to continue.
- sdd-expert-agent — domain expert in BDD specifications, writes
exhaustive Gherkin specs using actor/action/outcome pattern
- architect-agent — expert in high-level architecture, software
contracts (OpenAPI, DB entities, repository ports, DTOs, commands), and
precise task decomposition into checkpoint-based execution plans
- jira-agent — manages JIRA tickets: creation with AI labels, description
updates, status transitions, work logging, and comments
- pr-agent — creates Azure DevOps pull requests
- spec-reviewer — verifies implementation matches BDD spec scenarios
- design-reviewer — verifies code quality against repo standards and rules
- git-agent — handles all git repository operations: branch creation,
staging, committing, squashing, amending, syncing, and pushing
- implementation-agent — implements code changes: baseline verification,
checkpoint-by-checkpoint development with build/test/lint/live-test loops,
and review fix application
The main agent's job is to orchestrate: spawn sub-agents, pass context, and
route results. It does not touch Atlassian or Azure DevOps MCP tools
directly — those belong to the sub-agents. It does not write code, run
builds, or execute tests — that belongs to the implementation-agent.
Main agent (Sonnet 4.6)
├── Phase 1: Ticket, clarify, specify, plan
│ ├── 1-pre. Create JIRA ticket → spawn jira-agent (create) → {ticketKey}
│ │ Record WORKFLOW_START timestamp
│ ├── 1a. Clarify scope (main — conversation)
│ │ → spawn jira-agent (updateDescription)
│ ├── 1b. Create BDD spec → spawn sdd-expert-agent → {specFiles}
│ ├── 1c. Execution plan → spawn architect-agent → {planPath}
│ ├── 1d. User gate (user confirms spec + plan)
│ │ → spawn jira-agent (addWorklog — "Requirement refinement work")
│ │ Record CHECKPOINT timestamp
├── Phase 2: Create branch → spawn git-agent (create-branch)
├── Phase 3: Develop and test
│ ├── 3a. Baseline + checkpoint 1 IN PARALLEL (both run_in_background)
│ │ ├── spawn implementation-agent (baseline)
│ │ └── spawn implementation-agent (checkpoint 1)
│ │ If baseline fails: STOP workflow
│ └── 3b. Remaining checkpoints → spawn implementation-agent (checkpoint N)
├── Phase 4: Commit → spawn git-agent (count-commits, squash, stage-and-prepare, commit)
├── Phase 5: Review
│ ├── 5a. Spec review → spawn spec-reviewer → {passed, findings}
│ │ If failed: spawn implementation-agent (fix-findings)
│ │ → spawn git-agent (amend) → re-spawn spec-reviewer
│ └── 5b. Design review → spawn design-reviewer → {passed, findings}
│ If failed: spawn implementation-agent (fix-findings)
│ → spawn git-agent (amend) → re-spawn design-reviewer
├── Phase 6: PR creation
│ ├── spawn git-agent (validate-pr-readiness, sync-and-push)
│ └── spawn pr-agent → {prUrl}
└── Phase 7: Finalize JIRA → spawn jira-agent (composite)
├── addWorklog — "Implementation work"
├── addComment — cost analysis with per-agent breakdown
└── transition → "In Review"
Phase 1: Ticket, clarify, specify, and plan
Call mcp__bosch__phase_start with { num: 1, title: "Ticket · Clarify · Specify · Plan" }.
This phase creates the JIRA ticket immediately, then produces two
deliverables before any code is written: a complete BDD specification and
a detailed technical execution plan. Both live in the specs/ directory
and are committed with the feature — they are code, not throwaway notes.
Time tracking
Record the workflow start time at the very beginning of Phase 1. This is
used to calculate work log durations later.
WORKFLOW_START=$(date +%s)
Hold this value throughout the workflow. After Phase 1d, calculate the
elapsed time and log it. Record a second timestamp (CHECKPOINT) to
measure the implementation phase separately.
1-pre. Ticket setup
Read the agent instructions from
.claude/skills/feature-workflow/agents/jira-agent.md once and reuse
for all JIRA spawns in Phase 1.
Path A — user provided a JIRA ticket key:
The ticket already exists. Delegate to the JIRA sub-agent to prepare it
for the workflow (transition, sprint, assign, labels):
Tool: Agent
Parameters:
prompt: |
<paste the full contents of jira-agent.md as instructions>
INPUT CONTEXT:
{
"action": "fetchAndPrepare",
"ticketKey": "<ticket key from user>",
"area": "<BE | FE | DevOps | Docs — infer from user's request>"
}
allowedTools:
- mcp__atlassian__searchJiraIssuesUsingJql
- mcp__atlassian__getJiraIssue
- mcp__atlassian__getTransitionsForJiraIssue
- mcp__atlassian__transitionJiraIssue
- mcp__atlassian__editJiraIssue
- mcp__atlassian__atlassianUserInfo
The agent will emit a JSON result block. Extract and hold:
{
"action": "fetchAndPrepare",
"ticketKey": "<projectKey>-XXXXX",
"ticketUrl": "<urlBase>/browse/<projectKey>-XXXXX",
"existingDescription": true,
"currentStatus": "In Progress"
}
Hold existingDescription — it determines whether the description is
updated after scope clarification (1a).
Tell the user the ticket URL, then proceed to 1a.
Path B — no ticket provided:
Create a new ticket. Before spawning the agent, classify the user's
initial request:
Issue type — Task vs Story:
"Task" — purely technical/internal work: refactoring, tech debt,
dependency upgrade, config change, internal tooling, removing dead
code, migration, performance optimization, fixing code quality"Story" — new feature, change request, user-facing behavior change,
new API endpoint, new UI component, business rule change
Priority — infer from tone and wording:
"Critical" — words like "critical", "urgent", "production down",
"hotfix", "breaking", "blocker""High" — words like "important", "needed urgently", "ASAP",
"high priority", "blocking other work""Medium" — default for neutral requests, or words like "should",
"needed", "please add""Low" — words like "could", "nice to have", "eventually",
"when possible", "potential", "consider", "minor"
Delegate to the JIRA sub-agent:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of jira-agent.md as instructions>
INPUT CONTEXT:
{
"action": "create",
"scope": "<initial description from user's request — use as-is, even if brief>",
"area": "<BE | FE | DevOps | Docs — infer from user's request>",
"issueType": "<Task | Story — from classification above>",
"priority": "<Critical | High | Medium | Low — from classification above>",
"acceptanceCriteria": [
"<derive what you can from the initial request — even if minimal>"
],
"context": "<any background the user mentioned>"
}
allowedTools:
- mcp__atlassian__searchJiraIssuesUsingJql
- mcp__atlassian__createJiraIssue
- mcp__atlassian__getTransitionsForJiraIssue
- mcp__atlassian__transitionJiraIssue
- mcp__atlassian__editJiraIssue
- mcp__atlassian__atlassianUserInfo
The agent will emit a JSON result block. Extract and hold:
{
"action": "create",
"ticketKey": "<projectKey>-XXXXX",
"ticketUrl": "<urlBase>/browse/<projectKey>-XXXXX"
}
For newly created tickets, set existingDescription to false (the
description will always be refined after clarification).
Tell the user the ticket URL, then proceed to 1a.
1a. Clarify scope
Ask targeted questions until every aspect of the feature is understood. You
are building the foundation for an exhaustive spec, so do not leave
ambiguities — dig until the picture is complete.
Things worth clarifying:
- Which monorepo service or MFE is this for?
- Is there a user-facing impact, or is it internal/infra?
- Any known constraints or related tickets?
- Who are the actors? What are their roles and permissions?
- What are the error and edge cases?
- Are there authorization requirements?
- Are there event/integration boundaries (e.g., cross-service calls)?
- What validation rules apply to inputs?
After scope is fully clarified, update the JIRA ticket description —
but only if it needs updating:
- Newly created ticket (
existingDescription is false): always
update — refine the initial description with the fully clarified scope.
- Existing ticket with thin/missing description (
existingDescription
is false): update with the clarified scope.
- Existing ticket with well-populated description (
existingDescription
is true): skip the description update — the ticket is already
well-described.
When updating, compose a description using the ticket description template
(Goal / Acceptance Criteria / Context) populated with the clarified scope,
then delegate to the JIRA sub-agent:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of jira-agent.md as instructions>
INPUT CONTEXT:
{
"action": "updateDescription",
"ticketKey": "<ticketKey from 1-pre>",
"description": "<updated markdown description using the Goal / Acceptance Criteria / Context template, populated with the fully clarified scope>"
}
allowedTools:
- mcp__atlassian__editJiraIssue
1b. Create the BDD spec
Once scope is fully clear, determine the spec directory, then delegate to
the SDD Expert sub-agent.
Directory naming:
Determine the next sequence number by inspecting existing directories:
ls -d specs/[0-9]* 2>/dev/null | sort -n | tail -1
If none exist, start at 001. Otherwise increment the highest number by 1,
zero-padded to 3 digits. Use ticketKey from Phase 1-pre. The directory
name follows this pattern:
specs/<NNN>-<TICKET>-<short-slug>/
Example: specs/001-PLAT-12345-short-description/
Delegate to sdd-expert-agent:
Read the agent instructions from
.claude/skills/feature-workflow/agents/sdd-expert-agent.md, then spawn
the agent:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of sdd-expert-agent.md as instructions>
INPUT CONTEXT:
{
"scope": "<clarified scope from 1a>",
"specDir": "specs/<NNN>-<TICKET>-<slug>/",
"service": "<service name and path — e.g., invitations-service at services/invitations-service/>",
"actors": ["<actor 1 and role>", "<actor 2 and role>"],
"constraints": "<known constraints, related tickets, edge cases>",
"area": "<BE | FE | DevOps | Docs>"
}
The agent will emit a JSON result block. Extract and hold for Phase 1c:
{
"specDir": "specs/001-PLAT-12345-short-description/",
"specFiles": ["business-behavior-spec.md", "authorization-spec.md"],
"scenarioCount": 15,
"concerns": ["business-behavior", "authorization"],
"openQuestions": []
}
If openQuestions is non-empty, present them to the user and resolve
before proceeding. Do not continue to 1c with unresolved ambiguities.
1c. Create the technical execution plan
After the spec is complete, delegate to the Architect sub-agent to produce
the execution plan.
Delegate to architect-agent:
Read the agent instructions from
.claude/skills/feature-workflow/agents/architect-agent.md, then spawn
the agent:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of architect-agent.md as instructions>
INPUT CONTEXT:
{
"specDir": "specs/<NNN>-<TICKET>-<slug>/",
"service": "<service name and path>",
"area": "<BE | FE | DevOps | Docs>",
"specFiles": <specFiles array from sdd-expert-agent result>
}
The agent will emit a JSON result block:
{
"planPath": "specs/001-PLAT-12345-short-description/execution-plan.md",
"checkpointCount": 4,
"taskCount": 12,
"layersAffected": ["domain", "application", "adapter-in", "adapter-out"],
"contractsDefined": ["rest-api", "domain-model", "db-entity", "repository-port", "command", "authorization"],
"risks": []
}
If risks is non-empty, include them in the gate presentation (1d) so the
user can acknowledge or resolve them.
1d. Gate — spec and plan review
Request human approval via the bosch MCP server:
Read the full text of all spec files in specDir and the execution plan,
then call the gate tool:
Call mcp__bosch__gate_request with:
{
"kind": "spec+plan",
"payload": {
"ticket": "<ticketKey>",
"spec": "<full text of all BDD spec files from specDir, concatenated>",
"plan": "<full text of execution-plan.md>"
}
}
The gate_request tool suspends the workflow and delivers the spec + plan to
the bosch web UI for human review. It returns only when the user resolves the gate.
Branch on the gate result:
If result is "approved": proceed to time-logging below, then Phase 2.
If result is { status: "rejected", changes: "<feedback>" }: re-invoke
sdd-expert-agent and architect-agent with the change request, then re-issue
mcp__bosch__gate_request. Repeat until approved.
After the gate is approved, log the requirement refinement work and record
the checkpoint timestamp before proceeding autonomously.
Calculate elapsed time since workflow start:
PHASE1_END=$(date +%s)
ELAPSED_SECONDS=$((PHASE1_END - WORKFLOW_START))
Convert ELAPSED_SECONDS to JIRA time format (e.g., "1h 30m", "45m",
"2h"). Round to the nearest 5 minutes. Use hours and minutes — do not
use seconds or days.
Delegate to the JIRA sub-agent to log the work:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of jira-agent.md as instructions>
INPUT CONTEXT:
{
"action": "addWorklog",
"ticketKey": "<ticketKey>",
"timeSpent": "<elapsed time in JIRA format — e.g., 1h 30m>",
"comment": "Requirement refinement work"
}
allowedTools:
- mcp__atlassian__addWorklogToJiraIssue
Record the checkpoint timestamp for Phase 7:
CHECKPOINT=$(date +%s)
Once confirmed and worklog is recorded, execute Phases 2–7 autonomously
without pausing.
Call mcp__bosch__phase_complete with { num: 1 }.
Phase 2: Create branch
Call mcp__bosch__phase_start with { num: 2, title: "Create Branch" }.
Use ticketKey from Phase 1. Derive a short kebab-case slug from the
ticket summary (3-5 words, no area prefix). Do not ask the user.
Branch naming follows git.branchPattern from config — by default
{type}/{ticket}/{slug} where {type} is one of git.branchTypes
(default feature, bugfix, hotfix) and {ticket} is the full
<ticketKey> (e.g., <projectKey>-12345).
Example with default config: feature/<projectKey>-12345/short-description
Delegate to the git sub-agent. Read the agent instructions from
.claude/skills/feature-workflow/agents/git-agent.md, then spawn
the agent:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of git-agent.md as instructions>
INPUT CONTEXT:
{
"action": "create-branch",
"branchName": "feature/<projectKey>-XXXXX/short-description"
}
allowedTools:
- Bash
The agent will emit a JSON result block:
{
"action": "create-branch",
"branch": "feature/<projectKey>-XXXXX/short-description"
}
Call mcp__bosch__phase_complete with { num: 2 }.
Phase 3: Develop and test
Call mcp__bosch__phase_start with { num: 3, title: "Develop and Test" }.
All implementation work is delegated to the implementation-agent. Read the
agent instructions from
.claude/skills/feature-workflow/agents/implementation-agent.md once and
reuse for all spawns in this phase.
3a. Baseline and checkpoint 1 — in parallel
Launch both the baseline verification and checkpoint 1 simultaneously.
Send them in a single message with two Agent tool calls, both with
run_in_background: true:
Tool: Agent (run_in_background: true)
Parameters:
prompt: |
<paste the full contents of implementation-agent.md as instructions>
INPUT CONTEXT:
{
"action": "baseline",
"service": "<service path — e.g., services/employees-service/>",
"area": "<BE | FE>"
}
allowedTools:
- Read
- Edit
- Write
- Bash
Tool: Agent (run_in_background: true)
Parameters:
prompt: |
<paste the full contents of implementation-agent.md as instructions>
INPUT CONTEXT:
{
"action": "checkpoint",
"executionPlanPath": "specs/<NNN>-<TICKET>-<slug>/execution-plan.md",
"checkpointNumber": 1,
"specDir": "specs/<NNN>-<TICKET>-<slug>/",
"service": "<service path>",
"area": "<BE | FE>"
}
allowedTools:
- Read
- Edit
- Write
- Bash
Wait for both to complete.
If baseline fails (passed: false): Stop the entire workflow
immediately. Tell the user the baseline is broken (compilation or boot
failure), include the failureDetails from the result, and ask them to
fix the issues before re-invoking the workflow. Any checkpoint 1 work
done in parallel is discarded — the branch can be deleted and recreated.
Do NOT proceed with further checkpoints.
If baseline passes: Continue with checkpoint 1's result. If checkpoint 1
also completed successfully, proceed to checkpoint 2. If checkpoint 1 hit a
blocker, present it to the user.
3b. Remaining checkpoints
For each remaining checkpoint (2 to N) in the execution plan, spawn the
implementation-agent sequentially:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of implementation-agent.md as instructions>
INPUT CONTEXT:
{
"action": "checkpoint",
"executionPlanPath": "specs/<NNN>-<TICKET>-<slug>/execution-plan.md",
"checkpointNumber": <N>,
"specDir": "specs/<NNN>-<TICKET>-<slug>/",
"service": "<service path>",
"area": "<BE | FE>"
}
allowedTools:
- Read
- Edit
- Write
- Bash
If completed is false: the agent hit a blocker. Present the
blocker description to the user and wait for guidance before retrying
or proceeding.
After each checkpoint: aggregate testsRun, testsPassed, and
liveTestResults from the result into a cumulative test summary. This
summary is passed to the PR agent in Phase 6.
Only proceed to Phase 4 when all checkpoints are complete and every
scenario in the BDD spec is satisfied.
Phase 4: Commit
One commit per branch. If multiple commits accumulated during Phase 3, squash
them first. The commit message must be prefixed with ticketKey from Phase 1.
All git operations in this phase are delegated to the git sub-agent. Read the
agent instructions from .claude/skills/feature-workflow/agents/git-agent.md
once and reuse for all spawns in this phase.
Important: The spec directory (specs/<NNN>-PLAT-XXXXX-slug/) is code and
must be included in the commit. Pass it as specDir to stage-and-prepare.
4a. Check commit count
Spawn the git-agent:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of git-agent.md as instructions>
INPUT CONTEXT:
{
"action": "count-commits"
}
allowedTools:
- Bash
Extract commitCount:
- If 1 commit: skip to Step 4c
- If > 1 commits: run the squash flow (Steps 4b then 4c)
- If 0 commits: something went wrong in Phase 3 — check staging
4b. Squash (only if > 1 commit)
Spawn the git-agent with the squash action. The agent runs
prepare-squash.sh, creates a backup branch, and does a soft-reset to the
detected main branch. If the rebase encounters conflicts, the agent
reports an error — stop and tell the user to resolve manually.
Tool: Agent
Parameters:
prompt: |
<paste the full contents of git-agent.md as instructions>
INPUT CONTEXT:
{
"action": "squash"
}
allowedTools:
- Bash
Extract combinedDiff and backupBranch from the result.
Use the combinedDiff to compose the commit message (Step 4c format), then
spawn the git-agent with the commit action (see 4c below).
After committing, verify the squash integrity by spawning the git-agent with
the verify-squash action:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of git-agent.md as instructions>
INPUT CONTEXT:
{
"action": "verify-squash",
"backupBranch": "<backupBranch from squash result>"
}
allowedTools:
- Bash
If verified is false, stop and tell the user. Include the recovery
command from the error result.
4c. Stage and commit
Stage — spawn the git-agent:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of git-agent.md as instructions>
INPUT CONTEXT:
{
"action": "stage-and-prepare",
"specDir": "specs/<NNN>-PLAT-XXXXX-slug/"
}
allowedTools:
- Bash
Compose the commit message:
<TICKET>: <message>
<description_block>
Message line: imperative mood, ≤50 chars after the ticket prefix.
Description block: explain why and what; wrap at 72 chars; group changes
under headings when the diff spans multiple areas.
Commit — spawn the git-agent:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of git-agent.md as instructions>
INPUT CONTEXT:
{
"action": "commit",
"message": "<full commit message>"
}
allowedTools:
- Bash
After committing, collect the final commit message (first line + body) — you
will pass this to the PR agent in Phase 6.
Phase 5: Review
Two automated review gates verify the implementation before creating the PR.
Both reviewers are read-only — they report findings, and the
implementation-agent applies fixes.
5a. Spec review
First, get the list of changed files:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of git-agent.md as instructions>
INPUT CONTEXT:
{
"action": "get-changed-files"
}
allowedTools:
- Bash
Then spawn the spec-reviewer. Read agent instructions from
.claude/skills/feature-workflow/agents/spec-reviewer.md:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of spec-reviewer.md as instructions>
INPUT CONTEXT:
{
"specDir": "specs/<NNN>-<TICKET>-<slug>/",
"service": "<service path>",
"changedFiles": <changedFiles array from git-agent>,
"area": "<BE | FE>"
}
allowedTools:
- Read
- Bash
If passed is false (Critical findings):
- Spawn the implementation-agent with
fix-findings:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of implementation-agent.md as instructions>
INPUT CONTEXT:
{
"action": "fix-findings",
"findings": <Critical + Major findings from spec-reviewer>,
"reviewerType": "spec",
"service": "<service path>",
"area": "<BE | FE>"
}
allowedTools:
- Read
- Edit
- Write
- Bash
- Amend the commit:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of git-agent.md as instructions>
INPUT CONTEXT:
{
"action": "amend"
}
allowedTools:
- Bash
- Re-run the spec-reviewer to verify fixes resolved the Critical findings.
If still failing after one fix cycle, present the remaining findings to the
user and ask for guidance.
5b. Design review
Spawn the design-reviewer. Read agent instructions from
.claude/skills/feature-workflow/agents/design-reviewer.md:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of design-reviewer.md as instructions>
INPUT CONTEXT:
{
"service": "<service path>",
"changedFiles": <changedFiles array from git-agent>,
"area": "<BE | FE>"
}
allowedTools:
- Read
- Bash
If passed is false (Critical findings): follow the same
fix → amend → re-review loop as 5a, using "reviewerType": "design".
Phase 6: PR creation
6a. Validate and push
Spawn the git-agent to validate PR readiness:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of git-agent.md as instructions>
INPUT CONTEXT:
{
"action": "validate-pr-readiness"
}
allowedTools:
- Bash
Then sync and push:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of git-agent.md as instructions>
INPUT CONTEXT:
{
"action": "sync-and-push",
"branch": "<branch name>",
"remoteStatus": "<remoteStatus from validate result>"
}
allowedTools:
- Bash
6b. Create the PR
Delegate to the PR sub-agent. Read the agent instructions from
.claude/skills/feature-workflow/agents/pr-agent.md:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of pr-agent.md as instructions>
INPUT CONTEXT:
{
"ticketKey": "<projectKey>-XXXXX",
"ticketUrl": "<urlBase>/browse/<projectKey>-XXXXX",
"branch": "feature/<projectKey>-XXXXX/short-description",
"commitMessage": "<first line of commit message>",
"commitBody": "<commit message body>",
"testSummary": "<X unit tests passed; live tested POST /api/v1/foo (200), GET /api/v1/bar (200)>",
"diffStat": "<summary of changed files>"
}
allowedTools:
- Bash
- mcp__azure-devops__repo_create_pull_request
The agent will emit a JSON result block. Extract prUrl and tell the user.
Phase 7: Finalize JIRA
After the PR is created, finalize the JIRA ticket with work logging, cost
analysis, and status transition. All operations are delegated to the
jira-agent.
Read the agent instructions from
.claude/skills/feature-workflow/agents/jira-agent.md once and reuse for
all spawns in this phase.
7a. Log implementation work
Calculate elapsed time since the checkpoint recorded after Phase 1d:
IMPL_END=$(date +%s)
IMPL_SECONDS=$((IMPL_END - CHECKPOINT))
Convert to JIRA time format (round to nearest 5 minutes). Then log it:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of jira-agent.md as instructions>
INPUT CONTEXT:
{
"action": "addWorklog",
"ticketKey": "<ticketKey>",
"timeSpent": "<implementation elapsed time in JIRA format>",
"comment": "Implementation work"
}
allowedTools:
- mcp__atlassian__addWorklogToJiraIssue
7b. Cost analysis comment
Build a per-phase/per-agent cost analysis and post it as a JIRA comment.
Step 1: Read the pricing reference:
Read: .claude/skills/feature-workflow/references/claude-pricing.md
Step 2: Collect workflow metadata:
- Which agents were spawned during this run
- How many checkpoints were completed
- How many spawns per agent type
- Whether context compaction occurred
Step 3: Ask the user for the actual session cost:
"Please type /cost and share the total so I can include the actual
figure in the JIRA comment."
Hold the actual cost value.
Step 4: Estimate per-agent costs using the agent profiles from the
pricing reference. For each agent spawn, calculate:
cost = (input_tokens × cache_write_rate + output_tokens × output_rate) / 1,000,000
Use the mid-range of each agent's profile. For the orchestrator, use the
blended input rate (30% cache-write + 70% cache-hit).
Step 5: Compose the JIRA comment using this template:
## AI-Assisted Development — Cost Analysis
**Actual session cost:** $XX.XX (from `/cost`)
### Per-Phase / Per-Agent Breakdown (estimated)
| Phase | Agent | Model | Est. Input | Est. Output | Est. Cost |
|-------|-------|-------|-----------|-------------|-----------|
| 1-pre Ticket | jira-agent | Haiku 4.5 | 8K | 2K | $0.02 |
| 1a-d Clarify | Orchestrator | Sonnet 4.6 | 80K | 20K | $0.60 |
| 1b Spec | sdd-expert | Sonnet 4.6 | 30K | 15K | $0.34 |
| 1c Plan | architect | Sonnet 4.6 | 40K | 20K | $0.45 |
| 1d Worklog | jira-agent | Haiku 4.5 | 8K | 2K | $0.02 |
| 2 Branch | git-agent | Haiku 4.5 | 8K | 2K | $0.02 |
| 3 Baseline | impl-agent | Sonnet 4.6 | 30K | 10K | $0.26 |
| 3 CP 1 | impl-agent | Sonnet 4.6 | 150K | 50K | $1.31 |
| ... | ... | ... | ... | ... | ... |
| 4 Commit | git-agent (xN) | Haiku 4.5 | NK | NK | $X.XX |
| 5a Spec review | spec-reviewer | Sonnet 4.6 | 50K | 8K | $0.31 |
| 5b Design review | design-reviewer | Sonnet 4.6 | 50K | 8K | $0.31 |
| 6 PR | pr-agent + git | Sonnet+Haiku | 25K | 5K | $0.17 |
| 7 Finalize | jira-agent (x3) | Haiku 4.5 | 24K | 6K | $0.06 |
| Orchestrator (impl) | — | Sonnet 4.6 | 200K | 60K | $1.65 |
| **Total estimate** | | | | | **$X.XX** |
### Pricing Rates Used
| Model | Input (cache-write) | Cache Hit | Output |
|-------|-------------------|-----------|--------|
| Sonnet 4.6 | $3.75/MTok | $0.30/MTok | $15/MTok |
| Haiku 4.5 | $1.25/MTok | $0.10/MTok | $5/MTok |
> Per-agent estimates use cache-write rate for input (fresh context per spawn).
> Orchestrator uses blended rate (30% cache-write, 70% cache-hit).
> Delta between estimate and actual reflects context compaction, retries,
> and estimation error.
Fill in actual values from the run: number of checkpoints, agent spawns,
and the actual total from /cost. Use mid-range values from the agent
profiles in the pricing reference for the token estimates.
Step 6: Post the comment:
Tool: Agent
Parameters:
prompt: |
<paste the full contents of jira-agent.md as instructions>
INPUT CONTEXT:
{
"action": "addComment",
"ticketKey": "<ticketKey>",
"commentBody": "<composed cost analysis comment>"
}
allowedTools:
- mcp__atlassian__addCommentToJiraIssue
7c. Transition to "In Review"
Tool: Agent
Parameters:
prompt: |
<paste the full contents of jira-agent.md as instructions>
INPUT CONTEXT:
{
"action": "transition",
"ticketKey": "<ticketKey>",
"targetStatus": "In Review"
}
allowedTools:
- mcp__atlassian__getTransitionsForJiraIssue
- mcp__atlassian__transitionJiraIssue
Final report to user
After Phase 7 completes, tell the user:
- The PR URL
- The JIRA ticket URL (now "In Review")
- A brief summary of what was implemented
- Test results (from the test summary built in Phase 3)
- The actual session cost
- A reminder to request reviewers if needed
Quick reference
| Phase | Who | Action | Gate |
|---|
| 1-pre Ticket | jira-agent (Haiku) | Create or prepare ticket with AI labels | — |
| 1a Clarify | Main (Sonnet) | Ask targeted questions until fully understood | — |
| 1b Specify | sdd-expert (Sonnet) | Write BDD specs to specs/<NNN>-PLAT-XXXXX-slug/ | Resolve openQuestions |
| 1c Plan | architect (Sonnet) | Write execution-plan.md with checkpoints and contracts | Acknowledge risks |
| 1d Review | Main (Sonnet) | Present spec + plan to user | User confirms ← only gate |
| 2 Branch | git-agent (Haiku) | git checkout -b feature/<projectKey>-X/slug | — |
| 3a Baseline + CP1 | impl-agent (Sonnet) ×2 | Compile+boot check ‖ first checkpoint (parallel) | Stop if baseline fails |
| 3b Checkpoints | impl-agent (Sonnet) | Remaining checkpoints sequentially | — |
| 4 Commit | git-agent (Haiku) | Squash → stage → commit | — |
| 5a Spec review | spec-reviewer (Sonnet) | Verify all BDD scenarios implemented + tested | Fix Critical findings |
| 5b Design review | design-reviewer (Sonnet) | Verify code quality against project rules | Fix Critical findings |
| 6 PR | git-agent (Haiku) + pr-agent (Sonnet) | Validate → sync → push → create PR | — |
| 7a Worklog | jira-agent (Haiku) | Log implementation time | — |
| 7b Cost | jira-agent (Haiku) | Post per-agent cost analysis comment | — |
| 7c Transition | jira-agent (Haiku) | Move ticket to "In Review" | — |
What this is NOT
- Not for experiments or spikes — those just get coded, no ticket needed
- Not for quick fixes with no PR — commit directly without this workflow
- The ticket documents the goal, not the solution — implementation details
belong in the commit message and PR description, written after the work
Upgrade Path
Generated by claudboard-workflow on 2026-05-13 from template version v1.
To regenerate with updated templates, remove this directory and re-run /claudboard-workflow.
