Sign inSign up

jfeeneydemo3/dubjug-atlassian-context-kit:1.0.0

Multi-platform
Manifest digest

sha256:62a2ec10648832e93a44a9d03807c6d84ee022c84a36861a29d83fdd32bb97ff

Last pushed

7 days by jfeeneydemo3

Type

Sandbox Kit

Manifest digest

sha256:62a2ec10648832e93a44a9d03807c6d84ee022c84a36861a29d83fdd32bb97ff

yaml
schemaVersion: "3"
displayName: Atlassian guidance (MCP gateway)
description: Jira rules for the "Ecommerce Monorepo" project, for an agent that reaches the Atlassian MCP server through the sandbox MCP gateway. Carries no network rule, credential or MCP registration.
version: 1.0.0
kind: mixin
capabilities:
    - type: com.docker.sandbox/lifecycle@1
      config:
        install:
            - command: |
                export HOME="${HOME:-/home/agent}"
                export PATH="$HOME/.local/bin:$HOME/.claude/local:/usr/local/share/npm-global/bin:${PATH:-/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin}"
                add_block() {
                  f="$1"
                  mkdir -p "$(dirname "$f")"
                  touch "$f"
                  grep -q 'atlassian-gateway:start' "$f" && return 0
                  cat >> "$f" <<'ATLASSIAN_BLOCK'

                <!-- atlassian-gateway:start -->
                ## Atlassian and Jira (via the sandbox MCP gateway)

                - Jira site: `${{ kit.args.site }}`. If that is blank, ask the user for it. Where an
                  Atlassian tool wants a `cloudId`, pass `https://<site>`.
                - Atlassian tools reach you through the `mcp-gateway` MCP server, under their plain
                  names (`searchJiraIssuesUsingJql`, `getJiraIssue`, `createJiraIssue`, `discover`,
                  `executeRead`, ...; Codex shows them as `mcp__mcp_gateway__<name>`). There is no
                  separate `atlassian` server and no credential in this sandbox. Use only those
                  tools: never call Atlassian REST APIs (for example with `curl`), never ask for
                  network access to an Atlassian host, and never look for tokens.
                - Use Jira only when the user asks about Jira or Atlassian, or when you are about to
                  edit, create or delete source files in the project. Building, running, testing,
                  installing dependencies, reading, explaining, status questions and security checks
                  never need a ticket or any Jira call. Neither do git operations or undoing work:
                  reverting, discarding or restoring changes (`git restore`, `git checkout -- <file>`,
                  `git reset`, `git revert`, `git stash`), committing, pushing, pulling, merging,
                  rebasing and branching. A ticket is for new work you author (a feature, a fix, a
                  refactor), never for removing or undoing work. If unsure, do not use Jira; ask.
                - Immediately before such a first edit, make sure a Jira ticket exists in the project
                  named "Ecommerce Monorepo": look the project up by name and use the key it
                  returns, search it for an existing ticket, create one only if none exists, and
                  mention the ticket key in your summary. Create tickets nowhere else. If a build
                  fails and fixing it needs edits, do this right before the first edit, not before
                  the build.
                - `search` is a natural-language relevance search: it returns no assignee or status
                  and can miss tickets that exist. For ticket lists, "my tickets", assignee or status
                  questions, run JQL with `searchJiraIssuesUsingJql`, for example
                  `assignee = currentUser() AND resolution = Unresolved ORDER BY updated DESC`. If a
                  tool you need is not listed, ask `discover` for it and run the operation it names
                  with `executeRead`, `executeWrite` or `executeDestructive` (the matching one).
                - If the gateway offers no Atlassian tools at all, or only `search`, say so and stop:
                  the server is not attached to this sandbox, or the API token's scopes are too
                  narrow. Never answer a ticket-list question from `search`.
                - On a 401, a 403 or "not authorized", stop and report the exact message. Tell the
                  user to store their Atlassian API token on the host with
                  `sbx secret set mcp:atlassian:auth` and restart the sandbox. Do not work around it.
                <!-- atlassian-gateway:end -->
                ATLASSIAN_BLOCK
                }
                command -v codex >/dev/null 2>&1 || [ -d "$HOME/.codex" ] && add_block "$HOME/.codex/AGENTS.md"
                command -v claude >/dev/null 2>&1 || [ -d "$HOME/.claude" ] && add_block "$HOME/.claude/CLAUDE.md"
                exit 0
              description: Add the Atlassian site and gateway-era Jira rules to the agent's always-loaded instructions
              env:
                - HOME
                - PATH
              user: agent
    - type: com.docker.sandbox/agent-context@1
      config:
        content: |
            ## Atlassian Cloud and Jira

            The Atlassian MCP server is registered on the host's sandbox MCP gateway,
            not inside this sandbox. Its tools reach you through the `mcp-gateway` MCP
            server under their plain names (Codex shows them as
            `mcp__mcp_gateway__<name>`). There is no `atlassian` entry in your own MCP
            configuration and no Atlassian credential in this environment: the user's
            API token is stored on the host as the sbx secret `mcp:atlassian:auth`, and
            the gateway adds it to its own requests. There is nothing to sign in to.

            Jira site: `${{ kit.args.site }}`. If that is blank, ask the user for their
            Atlassian Cloud site (for example `yourteam.atlassian.net`) before querying
            anything. Where an Atlassian tool asks for a `cloudId`, pass
            `https://<site>`, or look the cloud ID up with
            `getAccessibleAtlassianResources`.

            ### Use only the gateway's Atlassian tools

            - Do all Atlassian work through the gateway's Atlassian tools. Do not call
              Atlassian REST APIs directly (for example with `curl`): the sandbox has no
              route to Atlassian, and asking for network approval for an Atlassian host
              defeats the governed path.
            - Do not search the environment, files or shell history for credentials.
            - `search` is a natural-language relevance search. It returns no assignee or
              status and can miss tickets that exist, so do not answer "what are my
              tickets" or "what is open" from it. Run JQL with
              `searchJiraIssuesUsingJql`, for example
              `assignee = currentUser() AND resolution = Unresolved ORDER BY updated DESC`.
            - The server exposes only some operations directly. If one you need is not
              in your tool list, ask `discover` for it and run the operation it names
              with `executeRead`, `executeWrite` or `executeDestructive` (the one
              matching the operation) before telling the user it is impossible.
            - If the gateway offers no Atlassian tools, or only `search`, the server is
              not attached to this sandbox or the API token's scopes are too narrow. Say
              so and stop. Never answer a ticket-list question from `search`, and never
              report "no tickets" from a natural-language search that returned nothing.
            - If an Atlassian tool answers 401 or 403 or says it is not authorized, stop
              and report the exact message. It usually means the host secret
              `mcp:atlassian:auth` is missing, expired or rejected; the user fixes it on
              the host with `sbx secret set mcp:atlassian:auth` and a sandbox restart.
              Do not work around it.

            ### Jira tickets for the "Ecommerce Monorepo"

            Code changes are tracked in the Jira project (space) named **Ecommerce
            Monorepo**, which has a Kanban board. This applies only when you are about
            to author new work by editing, creating or deleting source files in the
            project (a feature, a fix, a refactor). It does not apply to building,
            running, testing, installing dependencies, reading, explaining, status
            questions or security checks, and it does not apply to git operations or to
            undoing work: reverting, discarding or restoring changes (`git restore`,
            `git checkout -- <file>`, `git reset`, `git revert`, `git stash`),
            committing, pushing, pulling, merging, rebasing or branching. Do not touch
            Jira at all for those unless the user asks about Jira. If you are unsure,
            do not use Jira; ask. If a build fails and fixing it needs edits, do the
            following immediately before the first edit, not before the build:

            1. Look up the project by its name (for example `discover` and then
               `executeRead` with the project-listing operation it names) and use the
               project key it returns. Do not guess the key.
            2. Search that project for an existing ticket that covers the requested
               work, with `searchJiraIssuesUsingJql`. If one exists, use it and do not
               create a duplicate.
            3. If no ticket exists, create one in the Ecommerce Monorepo project with
               `createJiraIssue`, a clear summary and a description of the work and its
               acceptance criteria. New tickets appear on the project's Kanban board.
            4. Mention the ticket key in your summary of the work.

            Only create tickets in the Ecommerce Monorepo project. If you cannot find
            that project, or the Atlassian tools are unavailable or unauthorized, stop
            and report the exact problem instead of using another project or skipping
            the ticket.
args:
    site:
        default: ""
        description: 'Hostname of your Atlassian Cloud site, for example `yourteam.atlassian.net` (no https:// prefix). Optional: when left empty the agent asks you for the site instead. Pass it with `--kit-arg atlassian-context.site=yourteam.atlassian.net`, or under the kit''s `args:` in an sbxenv.yaml.'
        pattern: ^([A-Za-z0-9-]+\.atlassian\.net)?$