# Mk Jira Ops

> JIRA-side cache + project-context discovery via jira-as, diagnostic-only, no Atlassian state changes. NOT issue CRUD or project admin (mk:jira-admin).

- Skill: `ngocsangyem/mk-jira-ops-3` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ngocsangyem/mk-jira-ops-3`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ngocsangyem/mk-jira-ops-3/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: ngocsangyem (https://skillmd.com/u/ngocsangyem)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ngocsangyem/mk-jira-ops-3

---


# mk:jira-ops

Forks to the `jira-ops` agent. Diagnostic surface only.

## Triggers

- "jira cache status"
- "clear jira cache"
- "discover project context for PROJ"

## Examples

- Cache check: "is the jira-as cache fresh?"
- Cache clear: "clear the cache, my admin renamed a status"
- Discovery: "what's the default issue type and mandatory field set for PROJ?"

## Power-User Note

`cache-warm` is intentionally NOT exposed as a primary trigger. If a user explicitly needs it, they can invoke directly:

```bash
bash $(git rev-parse --show-toplevel)/.cursor/skills/jira/scripts/jira-as.sh ops cache-warm --project PROJ
```

## See also

- Agent: `../../agents/jira-ops.md`
- Shared: `../jira/references/{install-and-auth,cli-idioms,safety-framework}.md`
- Domain refs:
  - `references/rate-limits.md` — Atlassian rate-limit ceilings + back-off behaviour
- Peer leaves: any leaf hitting Atlassian-side throttling first lands here for diagnosis. `mk:jira-bulk` is the most common trigger for cache-warm + rate-limit awareness.

## Gotchas

- (none yet)