{
  "manifest": {
    "id": "project-management",
    "name": "Project Management",
    "description": "Jira integration patterns, project workflow operations, sprint planning, issue tracking, and development process automation",
    "version": "1.0.0",
    "author": "Adiuvo",
    "tags": [
      "jira",
      "project",
      "workflow",
      "agile",
      "automation"
    ],
    "icon": "",
    "created_at": "2026-06-11T01:40:46Z",
    "updated_at": "2026-06-11T01:40:46Z",
    "category": "",
    "pack_type": "operator",
    "required_mcp_servers": [],
    "optional_mcp_servers": [],
    "on_install": null,
    "procedure_count": 0,
    "context_file_count": 2,
    "always_loaded": false
  },
  "index": "# Project Management\n\nProject management integration patterns covering Jira, workflow automation, and development process operations.\n\n## What's Included\n\n- **Jira Integration** -- Jira API usage, issue creation, sprint management, workflow transitions, custom fields, and JQL queries\n- **Project Flow Ops** -- Development workflow automation, status tracking, milestone management, and team coordination patterns\n\n## When to Use\n\nActivate this pack when:\n- Integrating with Jira for issue management\n- Automating development workflows\n- Building project tracking dashboards\n- Implementing sprint planning automation\n- Coordinating team workflows programmatically\n",
  "procedures": [],
  "commands": [],
  "context_files": [
    {
      "filename": "jira-integration.md",
      "content": "---\nname: jira-integration\ndescription: Use this skill when retrieving Jira tickets, analyzing requirements, updating ticket status, adding comments, or transitioning issues. Provides Jira API patterns via MCP or direct REST calls.\norigin: ECC\n---\n\n# Jira Integration Skill\n\nRetrieve, analyze, and update Jira tickets directly from your AI coding workflow. Supports both **MCP-based** (recommended) and **direct REST API** approaches.\n\n## When to Activate\n\n- Fetching a Jira ticket to understand requirements\n- Extracting testable acceptance criteria from a ticket\n- Adding progress comments to a Jira issue\n- Transitioning a ticket status (To Do → In Progress → Done)\n- Linking merge requests or branches to a Jira issue\n- Searching for issues by JQL query\n\n## Prerequisites\n\n### Option A: MCP Server (Recommended)\n\nInstall the `mcp-atlassian` MCP server. This exposes Jira tools directly to your AI agent.\n\n**Requirements:**\n- Python 3.10+\n- `uvx` (from `uv`), installed via your package manager or the official `uv` installation documentation\n\n**Add to your MCP config** (e.g., `~/.claude.json` → `mcpServers`):\n\n```json\n{\n  \"jira\": {\n    \"command\": \"uvx\",\n    \"args\": [\"mcp-atlassian==0.21.0\"],\n    \"env\": {\n      \"JIRA_URL\": \"https://YOUR_ORG.atlassian.net\",\n      \"JIRA_EMAIL\": \"your.email@example.com\",\n      \"JIRA_API_TOKEN\": \"your-api-token\"\n    },\n    \"description\": \"Jira issue tracking — search, create, update, comment, transition\"\n  }\n}\n```\n\n> **Security:** Never hardcode secrets. Prefer setting `JIRA_URL`, `JIRA_EMAIL`, and `JIRA_API_TOKEN` in your system environment (or a secrets manager). Only use the MCP `env` block for local, uncommitted config files.\n\n**To get a Jira API token:**\n1. Go to <https://id.atlassian.com/manage-profile/security/api-tokens>\n2. Click **Create API token**\n3. Copy the token — store it in your environment, never in source code\n\n### Option B: Direct REST API\n\nIf MCP is not available, use the Jira REST API v3 directly via `curl` or a helper script.\n\n**Required environment variables:**\n\n| Variable | Description |\n|----------|-------------|\n| `JIRA_URL` | Your Jira instance URL (e.g., `https://yourorg.atlassian.net`) |\n| `JIRA_EMAIL` | Your Atlassian account email |\n| `JIRA_API_TOKEN` | API token from id.atlassian.com |\n\nStore these in your shell environment, secrets manager, or an untracked local env file. Do not commit them to the repo.\n\n## MCP Tools Reference\n\nWhen the `mcp-atlassian` MCP server is configured, these tools are available:\n\n| Tool | Purpose | Example |\n|------|---------|---------|\n| `jira_search` | JQL queries | `project = PROJ AND status = \"In Progress\"` |\n| `jira_get_issue` | Fetch full issue details by key | `PROJ-1234` |\n| `jira_create_issue` | Create issues (Task, Bug, Story, Epic) | New bug report |\n| `jira_update_issue` | Update fields (summary, description, assignee) | Change assignee |\n| `jira_transition_issue` | Change status | Move to \"In Review\" |\n| `jira_add_comment` | Add comments | Progress update |\n| `jira_get_sprint_issues` | List issues in a sprint | Active sprint review |\n| `jira_create_issue_link` | Link issues (Blocks, Relates to) | Dependency tracking |\n| `jira_get_issue_development_info` | See linked PRs, branches, commits | Dev context |\n\n> **Tip:** Always call `jira_get_transitions` before transitioning — transition IDs vary per project workflow.\n\n## Direct REST API Reference\n\n### Fetch a Ticket\n\n```bash\ncurl -s -u \"$JIRA_EMAIL:$JIRA_API_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  \"$JIRA_URL/rest/api/3/issue/PROJ-1234\" | jq '{\n    key: .key,\n    summary: .fields.summary,\n    status: .fields.status.name,\n    priority: .fields.priority.name,\n    type: .fields.issuetype.name,\n    assignee: .fields.assignee.displayName,\n    labels: .fields.labels,\n    description: .fields.description\n  }'\n```\n\n### Fetch Comments\n\n```bash\ncurl -s -u \"$JIRA_EMAIL:$JIRA_API_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  \"$JIRA_URL/rest/api/3/issue/PROJ-1234?fields=comment\" | jq '.fields.comment.comments[] | {\n    author: .author.displayName,\n    created: .created[:10],\n    body: .body\n  }'\n```\n\n### Add a Comment\n\n```bash\ncurl -s -X POST -u \"$JIRA_EMAIL:$JIRA_API_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"body\": {\n      \"version\": 1,\n      \"type\": \"doc\",\n      \"content\": [{\n        \"type\": \"paragraph\",\n        \"content\": [{\"type\": \"text\", \"text\": \"Your comment here\"}]\n      }]\n    }\n  }' \\\n  \"$JIRA_URL/rest/api/3/issue/PROJ-1234/comment\"\n```\n\n### Transition a Ticket\n\n```bash\n# 1. Get available transitions\ncurl -s -u \"$JIRA_EMAIL:$JIRA_API_TOKEN\" \\\n  \"$JIRA_URL/rest/api/3/issue/PROJ-1234/transitions\" | jq '.transitions[] | {id, name: .name}'\n\n# 2. Execute transition (replace TRANSITION_ID)\ncurl -s -X POST -u \"$JIRA_EMAIL:$JIRA_API_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"transition\": {\"id\": \"TRANSITION_ID\"}}' \\\n  \"$JIRA_URL/rest/api/3/issue/PROJ-1234/transitions\"\n```\n\n### Search with JQL\n\n```bash\ncurl -s -G -u \"$JIRA_EMAIL:$JIRA_API_TOKEN\" \\\n  --data-urlencode \"jql=project = PROJ AND status = 'In Progress'\" \\\n  \"$JIRA_URL/rest/api/3/search\"\n```\n\n## Analyzing a Ticket\n\nWhen retrieving a ticket for development or test automation, extract:\n\n### 1. Testable Requirements\n- **Functional requirements** — What the feature does\n- **Acceptance criteria** — Conditions that must be met\n- **Testable behaviors** — Specific actions and expected outcomes\n- **User roles** — Who uses this feature and their permissions\n- **Data requirements** — What data is needed\n- **Integration points** — APIs, services, or systems involved\n\n### 2. Test Types Needed\n- **Unit tests** — Individual functions and utilities\n- **Integration tests** — API endpoints and service interactions\n- **E2E tests** — User-facing UI flows\n- **API tests** — Endpoint contracts and error handling\n\n### 3. Edge Cases & Error Scenarios\n- Invalid inputs (empty, too long, special characters)\n- Unauthorized access\n- Network failures or timeouts\n- Concurrent users or race conditions\n- Boundary conditions\n- Missing or null data\n- State transitions (back navigation, refresh, etc.)\n\n### 4. Structured Analysis Output\n\n```\nTicket: PROJ-1234\nSummary: [ticket title]\nStatus: [current status]\nPriority: [High/Medium/Low]\nTest Types: Unit, Integration, E2E\n\nRequirements:\n1. [requirement 1]\n2. [requirement 2]\n\nAcceptance Criteria:\n- [ ] [criterion 1]\n- [ ] [criterion 2]\n\nTest Scenarios:\n- Happy Path: [description]\n- Error Case: [description]\n- Edge Case: [description]\n\nTest Data Needed:\n- [data item 1]\n- [data item 2]\n\nDependencies:\n- [dependency 1]\n- [dependency 2]\n```\n\n## Updating Tickets\n\n### When to Update\n\n| Workflow Step | Jira Update |\n|---|---|\n| Start work | Transition to \"In Progress\" |\n| Tests written | Comment with test coverage summary |\n| Branch created | Comment with branch name |\n| PR/MR created | Comment with link, link issue |\n| Tests passing | Comment with results summary |\n| PR/MR merged | Transition to \"Done\" or \"In Review\" |\n\n### Comment Templates\n\n**Starting Work:**\n```\nStarting implementation for this ticket.\nBranch: feat/PROJ-1234-feature-name\n```\n\n**Tests Implemented:**\n```\nAutomated tests implemented:\n\nUnit Tests:\n- [test file 1] — [what it covers]\n- [test file 2] — [what it covers]\n\nIntegration Tests:\n- [test file] — [endpoints/flows covered]\n\nAll tests passing locally. Coverage: XX%\n```\n\n**PR Created:**\n```\nPull request created:\n[PR Title](https://github.com/org/repo/pull/XXX)\n\nReady for review.\n```\n\n**Work Complete:**\n```\nImplementation complete.\n\nPR merged: [link]\nTest results: All passing (X/Y)\nCoverage: XX%\n```\n\n## Security Guidelines\n\n- **Never hardcode** Jira API tokens in source code or skill files\n- **Always use** environment variables or a secrets manager\n- **Add `.env`** to `.gitignore` in every project\n- **Rotate tokens** immediately if exposed in git history\n- **Use least-privilege** API tokens scoped to required projects\n- **Validate** that credentials are set before making API calls — fail fast with a clear message\n\n## Troubleshooting\n\n| Error | Cause | Fix |\n|---|---|---|\n| `401 Unauthorized` | Invalid or expired API token | Regenerate at id.atlassian.com |\n| `403 Forbidden` | Token lacks project permissions | Check token scopes and project access |\n| `404 Not Found` | Wrong ticket key or base URL | Verify `JIRA_URL` and ticket key |\n| `spawn uvx ENOENT` | IDE cannot find `uvx` on PATH | Use full path (e.g., `~/.local/bin/uvx`) or set PATH in `~/.zprofile` |\n| Connection timeout | Network/VPN issue | Check VPN connection and firewall rules |\n\n## Best Practices\n\n- Update Jira as you go, not all at once at the end\n- Keep comments concise but informative\n- Link rather than copy — point to PRs, test reports, and dashboards\n- Use @mentions if you need input from others\n- Check linked issues to understand full feature scope before starting\n- If acceptance criteria are vague, ask for clarification before writing code\n"
    },
    {
      "filename": "project-flow-ops.md",
      "content": "---\nname: project-flow-ops\ndescription: Operate execution flow across GitHub and Linear by triaging issues and pull requests, linking active work, and keeping GitHub public-facing while Linear remains the internal execution layer. Use when the user wants backlog control, PR triage, or GitHub-to-Linear coordination.\norigin: ECC\n---\n\n# Project Flow Ops\n\nThis skill turns disconnected GitHub issues, PRs, and Linear tasks into one execution flow.\n\nUse it when the problem is coordination, not coding.\n\n## When to Use\n\n- Triage open PR or issue backlogs\n- Decide what belongs in Linear vs what should remain GitHub-only\n- Link active GitHub work to internal execution lanes\n- Classify PRs into merge, port/rebuild, close, or park\n- Audit whether review comments, CI failures, or stale issues are blocking execution\n\n## Operating Model\n\n- **GitHub** is the public and community truth\n- **Linear** is the internal execution truth for active scheduled work\n- Not every GitHub issue needs a Linear issue\n- Create or update Linear only when the work is:\n  - active\n  - delegated\n  - scheduled\n  - cross-functional\n  - important enough to track internally\n\n## Core Workflow\n\n### 1. Read the public surface first\n\nGather:\n\n- GitHub issue or PR state\n- author and branch status\n- review comments\n- CI status\n- linked issues\n\n### 2. Classify the work\n\nEvery item should end up in one of these states:\n\n| State | Meaning |\n|-------|---------|\n| Merge | self-contained, policy-compliant, ready |\n| Port/Rebuild | useful idea, but should be manually re-landed inside ECC |\n| Close | wrong direction, stale, unsafe, or duplicated |\n| Park | potentially useful, but not scheduled now |\n\n### 3. Decide whether Linear is warranted\n\nCreate or update Linear only if:\n\n- execution is actively planned\n- multiple repos or workstreams are involved\n- the work needs internal ownership or sequencing\n- the issue is part of a larger program lane\n\nDo not mirror everything mechanically.\n\n### 4. Keep the two systems consistent\n\nWhen work is active:\n\n- GitHub issue/PR should say what is happening publicly\n- Linear should track owner, priority, and execution lane internally\n\nWhen work ships or is rejected:\n\n- post the public resolution back to GitHub\n- mark the Linear task accordingly\n\n## Review Rules\n\n- Never merge from title, summary, or trust alone; use the full diff\n- External-source features should be rebuilt inside ECC when they are valuable but not self-contained\n- CI red means classify and fix or block; do not pretend it is merge-ready\n- If the real blocker is product direction, say so instead of hiding behind tooling\n\n## Output Format\n\nReturn:\n\n```text\nPUBLIC STATUS\n- issue / PR state\n- CI / review state\n\nCLASSIFICATION\n- merge / port-rebuild / close / park\n- one-paragraph rationale\n\nLINEAR ACTION\n- create / update / no Linear item needed\n- project / lane if applicable\n\nNEXT OPERATOR ACTION\n- exact next move\n```\n\n## Good Use Cases\n\n- \"Audit the open PR backlog and tell me what to merge vs rebuild\"\n- \"Map GitHub issues into our ECC 1.x and ECC 2.0 program lanes\"\n- \"Check whether this needs a Linear issue or should stay GitHub-only\"\n"
    }
  ]
}