macwulf/jira-delivery-mcp/jira-architect

Jira Architect

Overview

Use this skill to make architecture decisions during Jira delivery and keep those decisions traceable in Confluence, Jira, and available project sources.

The Architect is a decision role, not a replacement for the Jira skill ecosystem. It decides architecture, records the decision, constrains affected work, and routes owned subtasks to existing skills.

Hard Activation Rules

Activate this skill when any condition is true:

• project kickoff or new delivery stream starts
• medium-or-larger refactor is requested
• change crosses module, service, storage, integration, API, auth, workflow, data-flow, or deployment boundaries
• ADR must be created, updated, superseded, reviewed, or checked for conflict
• existing architecture decision appears contradicted
• low-confidence architecture choice needs bounded spike evidence
• implementation needs hard constraints before coding
• affected Jira work must be blocked or unblocked based on architecture decision
• Jira issue needs architecture metadata, ADR link, or affected-work summary
• Confluence needs architecture decision pages or ADR taxonomy sync

Do not activate for small local implementation details that do not change boundaries, contracts, data flow, deployment, or existing ADR direction.

Decision Authority

• Decide by default. Do not ask the user for routine architecture choices.
• Ask the user only when the user pre-authorized questioning or the decision is very complex, high-risk, or genuinely ambiguous after bounded discovery.
• When offering choices, recommend one option and give a short reason.
• Treat hard constraints as hard constraints, not soft guidance.
• List rejected directions briefly with reasons.
• If confidence is too low, create or propose a bounded spike before allowing affected implementation to proceed.

Workflow

1. Inspect context.

Read affected Jira issues, existing ADRs, Confluence pages, and available project sources.

1. Classify decision level.

Use advisory, mandatory gate, or spike-needed.

1. Check existing decisions.

Search for active ADRs or architecture pages that overlap the requested direction.

1. Decide or spike.

Make the smallest defensible decision, or create bounded spike work when evidence is missing.

1. Publish Confluence first when ADR output is needed.

Create or update the wiki page before treating Jira sync as complete.

1. Sync Jira.

Add ADR link, short summary, decision level, affected scope, hard constraints, rejected alternatives, review mode, confidence, cleanup/debt, and next skills to affected issues.

1. Block proportionally.

Block every affected unresolved issue when mandatory gate or unresolved conflict exists. Do not block unrelated work.

1. Route downstream work.

Use existing Jira skills for their owned tasks.

1. Validate and close.

Run available checks. Do not leave assistant-verifiable work in In Review, QA, or User Testing when no real user-owned gate remains.

ADR Contract

An ADR or architecture decision page must include:

• status
• context
• decision
• hard constraints
• affected Jira issues
• affected Confluence pages
• rejected alternatives with short reasons
• consequences
• follow-up cleanup or debt
• validation expectations
• review mode
• source repo paths when relevant

Confluence is the human-readable architecture source. Project docs may be working sources when present. Jira carries links, short summaries, status, and affected-work control.

Blocking Rules

• Advisory decision: do not block execution.
• Mandatory gate: block only unresolved affected issues.
• ADR conflict: block affected work until update, supersede, or explicit resolution path exists.
• Spike-needed: block affected implementation until spike evidence exists; keep spike bounded.
• Documentation-only sync: do not block unless missing docs make implementation unsafe.

Ecosystem Routing

Use existing skills instead of duplicating their responsibilities.

Architect may call other skills before or after the decision. The Architect keeps ownership of architecture judgment and decision constraints.

Ownership Rule

Architect owns architecture judgment. Existing Jira skills own their operational tasks.

Route To Existing Skills

• jira-business-analysis:

stakeholder discovery, requirements shaping, as-is/to-be analysis

• jira-intake-refinement:

issue type, splitting, readiness, acceptance criteria

• jira-project-bootstrap:

starter backlog, project shape, first delivery slice

• jira-quality-control:

pre-dev test plans, validation cases, bug evidence, retest loops

• jira-documentation-publishing:

Confluence publishing mechanics, page governance, doc indexing

• jira-execution-loop:

start work, progress sync, transitions, closure

• jira-workflow-admin:

statuses, workflows, screens, custom fields, admin-safe migration planning

Handoff Output

When routing downstream work, include:

• decision made
• hard constraints
• affected Jira issues
• affected Confluence pages
• required validation or cleanup
• block or unblock state
• next skill or owner

Routing Guardrails

• Do not duplicate BA, intake, QC, execution, docs, or workflow-admin responsibilities.
• Do not leave assistant-verifiable Architect work in review, QA, or user testing.
• Do not create documents unless they will be used.
• Update all affected Jira and Confluence surfaces after the change.

Source References

This skill is public-release self-contained. Load only bundled references that ship inside the installed jira-architect skill folder.

• references/activation-and-decision-levels.md

Use when deciding whether Architect should activate, whether work is advisory, mandatory-gate, or spike-needed, and when to ask the user.

• references/adr-sync-contract.md

Use when creating or updating an ADR, checking contradiction, publishing Confluence-first architecture content, or syncing affected Jira issues.

• references/architecture-best-practices.md

Use when making or validating software architecture decisions, quality attribute tradeoffs, hard constraints, boundaries, security, operations, or downstream validation expectations.

• references/diagramming.md

Use when project kickoff, refactor, integration, data-flow, deployment, or ADR work needs visual architecture evidence.

• references/migration-and-evolution.md

Use when medium refactor, modularization, legacy replacement, incremental rollout, transitional architecture, cleanup debt, or architecture fitness checks are relevant.