Reduce the Atlassian skills to Jira, and fix eight broken modules - #1101
Draft
johnml1135 wants to merge 5 commits into
Draft
Reduce the Atlassian skills to Jira, and fix eight broken modules#1101johnml1135 wants to merge 5 commits into
johnml1135 wants to merge 5 commits into
Conversation
confluence_comments, confluence_labels, confluence_pages, jira_agile, jira_links, jira_projects, jira_workflow and jira_worklog all raised NameError on import: Optional or AtlassianCredentials was referenced by a surviving function signature but missing from the import lines. Eight of the twelve read-only modules were therefore unreachable, and callers had to fall back to the write skill for reads. The read-only variant looks generated from the write variant by stripping write functions, with the stripper also pruning those two names. The fix restores them and nothing else. It is an upstream bug and a re-sync will reintroduce it until reported. Verified: all twelve modules in both skills now import, and jira_get_transitions returns live data through the read-only skill. Both skills gain a PROVENANCE.md recording the upstream repository, the MIT declaration, the local modifications, and the Data Center behaviours that upstream's Cloud-oriented docstrings get wrong. Upstream declares MIT in its README but ships no LICENSE file and no copyright line, so the frontmatter reference to LICENSE dangles there as well as here; it is left unchanged to keep this copy diffable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
johnml1135
marked this pull request as draft
August 21, 2026 15:41
atlassian-readonly-skills/SKILL.md restated all 48 function signatures that REFERENCE.md already documents in the same folder, 237 lines of it, copied from the write variant. It now carries a module-to-function table naming every function the variant has, and points at REFERENCE.md for signatures. 560 lines to 265. The delegation is narrower than it first looked. Only Response Data Structures, Error Handling and Dependencies are byte-identical between the two variants and safe to document once; Configuration, Core Workflow and Philosophy differ, because the write variant carries write examples. Those first two are kept here verbatim rather than delegated, and the file says which is which. Verified: every one of the 48 functions named here is documented in REFERENCE.md, and the list is generated from the scripts themselves rather than from the prose it replaces. Refs LT-22723
This comment has been minimized.
This comment has been minimized.
johnml1135
force-pushed
the
atlassian-skills-fix
branch
from
August 21, 2026 15:54
672dc33 to
dcd60dd
Compare
PROVENANCE.md said this skill had deliberately not been compressed. It has been, in the commit before this one, so the note now records what changed and warns that a re-sync must re-apply it alongside the import fix and the SIL section. The read-only note also cites the upstream issue for the import bug now that one exists: langpingxue/atlassian-skills#14. Refs LT-22723 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
johnml1135
force-pushed
the
atlassian-skills-fix
branch
from
August 21, 2026 15:55
dcd60dd to
26a90ea
Compare
FieldWorks uses Jira and nothing else. Nothing in the repository referenced a Confluence or Bitbucket helper, yet both skills carried full support for them: eight script modules each, their documentation, their configuration blocks, and their plumbing in _common.py. Removed across both variants: the confluence_* and bitbucket_* modules, their SKILL.md and REFERENCE.md sections, the CQL query reference, the partial-service configuration guidance, and in _common.py the dataclass fields, is_*_available checks, get_*_client factories and the service branches in AtlassianConfig.from_credentials. Streamlined what remained rather than leaving holes. Configuration is now two short modes, SIL Data Center first, with Jira Cloud kept only for completeness. Core Workflow, the agent-mode example and the credentials reference were rewritten around Jira instead of having their other two thirds cut out. Both frontmatter descriptions claimed Confluence and Bitbucket support, so they are rewritten too. A description that overstates what a skill does is how the wrong skill gets loaded. Verified: zero Confluence or Bitbucket references remain outside the provenance notes. All 9 modules in each skill import, and a live read against SIL Jira through the read-only skill still works. Refs LT-22723
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1101 +/- ##
==========================================
+ Coverage 38.33% 38.36% +0.02%
==========================================
Files 1507 1507
Lines 350580 350634 +54
Branches 40293 40304 +11
==========================================
+ Hits 134410 134505 +95
+ Misses 186941 186897 -44
- Partials 29229 29232 +3 🚀 New features to boost your workflow:
|
johnml1135
added a commit
that referenced
this pull request
Aug 29, 2026
The previous commit repaired all twelve broken modules in both vendored Atlassian variants. That was the wrong call twice over, and this reverts it. PR #1101 is open on branch atlassian-skills-fix and already fixes this. It goes further: it deletes the Bitbucket and Confluence modules outright, reducing both variants to Jira, and adds a PROVENANCE.md to each. Eleven of the fifteen files the previous commit touched are files #1101 removes, so the repair was work against a deletion, and would have conflicted on merge. The stated cause was also wrong. The names were not pruned locally when we vendored. Upstream introduced the bug in cdd1823f6 (2025-12-20) and fixed it in 0fafb48e7, "Fix missing imports in readonly variant scripts" (2026-02-10). Our copy is byte-identical to the pre-fix upstream state, and d1a9bc6 vendored it in 2026-06-11 -- four months after upstream had fixed it. So this is a stale snapshot, and the correct remedy is a re-sync from upstream rather than hand-patching, which is close to what #1101 does. Kept from the reverted commit: one line in the read-only jira_projects.py, which also lost NotFoundError. It is raised at :179, inside a function body, so importing the module successfully does not prove it works -- and this branch does claim to fix that module, because it deletes the documented workaround for it. The other fourteen files are back to their vendored state. This branch now touches exactly two vendored files, jira_workflow.py and jira_projects.py, which is the minimum for deleting a workaround that named them. Those two lines overlap #1101; whichever merges second takes a two-line conflict.
Three corrections to this branch, one of them code. jira_projects raised NotFoundError at :179 without importing it. Unlike the eight modules this branch already fixed, that one does not fail at import time, so "all nine modules import" was true and still insufficient: the module broke only when a project was absent. Ablation confirms the import is load-bearing -- removing it again turns a clean NotFoundError response into "NameError: name 'NotFoundError' is not defined". Found with pyflakes, which is now named in PROVENANCE.md as the check that catches this class of bug. Also dropped ValidationError from jira_issues, where stripping the write functions left nothing to raise it. The recorded cause was wrong. Both PROVENANCE.md files blamed a generator here that prunes imports while stripping write functions -- hedged as "appears to be", and never verified. What actually happened is that upstream shipped the bug in cdd1823f6 (2025-12-20) and fixed it in 0fafb48e7, "Fix missing imports in readonly variant scripts" (2026-02-10). Our files are byte-identical to upstream at cdd1823f6, and d1a9bc6 vendored that pre-fix state on 2026-06-11, four months after the fix existed. So this was a stale snapshot, and the note claiming "a re-sync will reintroduce it" had it backwards: a re-sync would have fixed it. Upstream issue #14 was filed against the stale copy and is closed as already-fixed. What does still hold upstream is the relative import in the four bitbucket modules, which is moot here now that they are gone. Two local modifications were unlisted, in a section that opens by asking for them to be listed. _common.py turns TLS verification off in three places where upstream leaves it on -- deliberate, because jira.sil.org's certificate chain does not validate here, so the reason is now recorded rather than left as a silent diff. And the write variant claimed "no script changes" while this branch strips Confluence and Bitbucket plumbing out of its _common.py and __init__.py. Verified: pyflakes reports nothing at all across both variants, all sixteen modules import, and jira_get_project_versions was called against live Jira for both a real project and an absent one.
johnml1135
added a commit
that referenced
this pull request
Aug 31, 2026
Agent-authored LT tickets put good analysis in the wrong shape. The reference failure opens with a heading, runs past a thousand words, and states that it contains four separate user-visible problems, so a triager scanning a queue cannot act on it. Jira Data Center has no expand macro, so nothing in a description can be folded away. The skill keeps the description short and moves the depth into the first comment. The skill interviews for who, when, where and how under a cap of six questions, hunts duplicates before drafting rather than before posting, and gets a three-line lede approved before anything else is written. Unknowns are recorded rather than guessed, and nothing enters a description that the reporter did not say or that we did not verify. compact-style.md is a shared reference adapting the MIT-licensed i-have-adhd skill from chat turns to written artifacts. pr-pitch now points at it and gains a Start here line, numbered verification steps, a closing Next line, an optional status line for long-lived PRs, and the pre-send check. jira-bugfix gains the LT-XXXXX-short-slug branch convention, a relaxed worktree rule that asks rather than refuses, and a note that it is entered at Step 3 when jira-issue hands off. Evidence and screenshot handling is deliberately absent; it follows in a stacked branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Skip ticket sections that do not apply to the subject Not every LT ticket is about FLEx the product. One about developer tooling, an agent skill, the build or documentation has no FLEx version, no project file, no menu path and nothing to reproduce inside the application. Phase 0b now decides what kind of thing the ticket is about before the interview starts, and maps that to the environment questions worth asking. Asking which FLEx build was running, for a ticket about a Markdown reference file, spends one of six questions and signals that the ticket was generated rather than written. The output rule is the same: never emit a section that does not apply. A template dutifully filled with N/A costs the reader the same scan and returns nothing, so the heading goes instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Move the design record from the tree into the PR body The design document was a working artifact, not something a future maintainer needs in order to change this code correctly. Under the pr-pitch triage it is RESEARCH: a one-time investigation whose conclusions are now carried by the skill itself. Its content survives in the pull request body, where the decisions, the rejected alternatives and the reasoning stay recoverable without shipping scaffolding into the repository. Refs LT-22723 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Require Affects Version FW 9.3 on every new ticket Every new LT ticket carries Affects Version FW 9.3, with no exception. It is a filing convention that keeps the queue filterable rather than a claim about which build the reporter was running, so the Phase 0b relevance rule does not exempt a tooling, build or documentation ticket from it. A specific point release the reporter names is added alongside FW 9.3, never in place of it. Neither jira_create_issue nor jira_update_issue exposes the versions field, so it goes through custom_fields. The same applies to assignee, which those helpers send as a Cloud-style accountId that SIL's Data Center rejects; both fallbacks are now written down where the publish step needs them. Refs LT-22723 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Point the worked example at the tickets it actually produced The example carried placeholder keys for the four symptom tickets that splitting LT-22715 would create. Those tickets now exist, filed on 2026-08-21 as LT-22724 through LT-22727 and linked back with Issue split, so the example names them. A worked example that cites real tickets can be checked by a reader. One that cites LT-AAAAA cannot, and quietly invites the reader to treat the whole example as hypothetical. Refs LT-22715, LT-22723 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Halve the always-loaded skill and record the traps that bit us SKILL.md goes from 224 lines to 95. It is the only file loaded every time the skill triggers, so every line it holds is context spent whether or not the reader needs it. Mechanics move to references, which load when the phase that needs them is reached. Moved out: the four duplicate-search passes to a new duplicates.md, the publish calls to publish.md, the relevance table to format.md. What stays is the phase table, the two gates, the budgets and the traps. Recorded from the retroactive rewrite of 28 tickets: - Link types must be read, never guessed. There is no Relates in this Jira, and falling back to the first name in the list produced four bogus Cloners links between a cause ticket and its children. - resolution cannot be set by an update, only by a transition. - The read-only skill's jira_workflow.py and jira_projects.py raise NameError on import; use the atlassian-skills copies. - A private Gmail or Drive URL in a description is broken evidence. - Rewriting a ticket posts the original as a comment first. Task-type tickets gain their own lede labels. Two of the rewritten tickets were Tasks and had to improvise them. Refs LT-22723 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Add evidence framework for screenshots in PRs and Jira issues A visible change should ship with a picture, and the repo already has the hard half: headless Skia capture for Avalonia, MCP capture for WinForms, and an Output/ManualEvidence naming convention. What was missing is the last mile -- trimming, captioning, provenance labelling, and any route at all from a PNG to a PR body or a ticket. The rule evidence.md turns on is that the test is the evidence and the screenshot is the courtesy. A control-level headless capture is not a screenshot of the product, and every image now says which it is. Publishing probes three routes and reports the one it used: native gh attach once it ships, gh image where a session cookie is reachable, and an orphan evidence branch with sha-pinned raw URLs otherwise. Only the third works under an Actions token, which is why it stays. jira_add_attachment uploads to Jira. It drives client.session directly because AtlassianClient.post sends JSON only, while multipart needs the XSRF header and no Content-Type. Its validation paths are exercised; the upload path has not yet been run against a live issue. A screenshot of a live project is a data disclosure exactly as a project file is, so the permission gate covers both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Fix a reference path that does not resolve from its own file evidence.md sits in .claude/references/ and pointed at fieldworks-avalonia-ui/references/visual-snapshot-testing.md as if it were a sibling. The file is under .claude/skills/, so the pointer resolved from nowhere. Made absolute from the repo root. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Drop the orphan evidence branch from the publish routes The third upload route proposed creating a never-merged orphan branch to host screenshots and referencing them by sha-pinned raw URL. It was speculative, nothing had been built, and it solved a problem lasting one review by putting binaries in history permanently. Route three is now the honest one: when no upload path is available, say which was tried and hand the file to the author to drag in. The skill also states plainly that images are not committed to the repository and no side branch is created to host them. Refs LT-22723 Compress the three workflow skills that carry the most prose jira-bugfix, pr-preflight and pr-pitch drop from 1107 lines to 374, about two thirds. A SKILL.md is loaded whole every time its skill triggers, so every line it holds is context spent whether the reader needs it or not. Procedure that only one phase needs now lives in a reference that loads when that phase is reached. Moved out: the review-summary template, the accordion catalogue, and the publish-and-verify mechanics. Deduplicated rather than shortened in place. jira-bugfix carried its own copy of the JIRA API calls, the assignee and version workarounds, and the transition rules; it now points at the jira-issue skill's publish.md. It also delegates commit messages, PR creation and test coverage to the skills that own them instead of restating them. Nothing about the guidance changed. The pitch structure, the triage buckets, the four analysis passes, the interview discipline and every gate survive verbatim or tightened. Refs LT-22723 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Repoint nine skill references that resolved from nowhere Nine cross-references in the Avalonia migration and WinApp skills were written relative to the skill root while the citing file lives inside references/, so they resolved to references/references/<name>.md and pointed at nothing. Every target exists; only the paths were wrong. Seven become plain sibling names, which is what a file inside references/ needs to reach the file next to it. Two genuinely cross skill boundaries and become repo-root paths: winforms-avalonia-parity cites parity-evidence in the migration skill, and architecture-patterns cites style-system in the Avalonia UI skill. Nothing else changed. No prose, no guidance, no file moved or renamed. Verified by resolving every reference in every .claude markdown file from the directory it is written in: nine dangling before, none after. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Repair two read-only Jira scripts and correct five skill claims Review of this PR raised seven items. Six were confirmed against the tree and are fixed here; the seventh was backwards and is answered instead. jira_workflow.py and jira_projects.py under atlassian-readonly-skills were missing two names their own signatures use, Optional and AtlassianCredentials, so both raised NameError on import. The class is already defined in the read-only _common.py -- the vendoring generator dropped it from each module's import list. Both now import, and were run against live Jira. The workaround telling jira-issue to route around them is deleted: it contradicted AGENTS.md, which names the read-only scripts as the route for reads. Ten further read-only modules still fail to import, from the same generator bug plus a relative-import class in the bitbucket ones. They are left to the Atlassian transport PR that this branch already defers to. Also: pr-preflight names the review model again, so the summary template's field has an owner, and is told never to invent a co-author trailer; pr-pitch hoists the Start here line to the top of the body, where its own checklist already required it; jira-issue counts three gates rather than two, because Phase 5 permission is equally a hard stop; and the assignee username and Affects Version are derived from the prefs file and Src/MasterVersionInfo.txt rather than frozen as one developer's name and one release. Worktree paths in jira-bugfix and dependabot-consolidation now point at Worktree-CreateFromBranch.ps1 instead of naming a directory. The review placed worktrees under .claude/worktrees; that path does not exist, and all twelve on disk are under .tmp/worktrees, so no fixed path written here stays true. Repair all twelve broken Atlassian modules in both skill variants The previous commit fixed the two modules a skill documented a workaround for. Checking the rest found twelve of sixteen read-only modules failing to import, so this finishes the job and records where the breakage came from. It came from us. Upstream langpingxue/atlassian-skills is correct: its read-only jira_workflow.py imports both Optional and AtlassianCredentials. Our copies arrived in one commit, d1a9bc6 (PR #935), with names deleted from the import lists -- the signature of an automated unused-import pass that did not understand names used only inside annotations. Nine modules lost AtlassianCredentials, five also lost Optional, and jira_projects.py lost NotFoundError, which import alone does not catch because it is raised inside a function body. Eight modules are restored to upstream's imports verbatim; the diff against upstream is now empty for all of them. The four bitbucket modules are a different defect, and this one is upstream's: they use "from ._common import", a relative import, in both variants. That can never resolve under the invocation every SKILL.md documents, which inserts the scripts directory on sys.path and imports the module directly. They now use the absolute import and the path shim that the other fourteen modules already use. This diverges from upstream deliberately, and is worth sending back to them. Verified: all 33 modules across both variants import, pyflakes reports no undefined name in either, and five modules that previously raised NameError on import -- jira_workflow, jira_links, jira_projects, jira_worklog, jira_agile -- were called against live Jira and returned data. Only Jira is configured in this environment, so the Confluence and Bitbucket modules are verified statically rather than end to end. Left alone deliberately: _common.py sets ssl_verify to False where upstream sets True. That is a local change, not vendoring damage, and reverting it without knowing why it was made would break every call this repo makes. Revert the wider Atlassian repair, which PR #1101 already covers The previous commit repaired all twelve broken modules in both vendored Atlassian variants. That was the wrong call twice over, and this reverts it. PR #1101 is open on branch atlassian-skills-fix and already fixes this. It goes further: it deletes the Bitbucket and Confluence modules outright, reducing both variants to Jira, and adds a PROVENANCE.md to each. Eleven of the fifteen files the previous commit touched are files #1101 removes, so the repair was work against a deletion, and would have conflicted on merge. The stated cause was also wrong. The names were not pruned locally when we vendored. Upstream introduced the bug in cdd1823f6 (2025-12-20) and fixed it in 0fafb48e7, "Fix missing imports in readonly variant scripts" (2026-02-10). Our copy is byte-identical to the pre-fix upstream state, and d1a9bc6 vendored it in 2026-06-11 -- four months after upstream had fixed it. So this is a stale snapshot, and the correct remedy is a re-sync from upstream rather than hand-patching, which is close to what #1101 does. Kept from the reverted commit: one line in the read-only jira_projects.py, which also lost NotFoundError. It is raised at :179, inside a function body, so importing the module successfully does not prove it works -- and this branch does claim to fix that module, because it deletes the documented workaround for it. The other fourteen files are back to their vendored state. This branch now touches exactly two vendored files, jira_workflow.py and jira_projects.py, which is the minimum for deleting a workaround that named them. Those two lines overlap #1101; whichever merges second takes a two-line conflict.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Start here:
.claude/skills/atlassian-skills/SKILL.md— the Configuration and Core Workflow sections show the shape of the whole change.The two Atlassian skills supported Jira, Confluence and Bitbucket. FieldWorks uses Jira. Confluence and Bitbucket are gone — 4,362 deletions against 293 insertions — and nine modules that never worked are fixed.
Where to look:
NameErroron import, so any read through them failed and callers reached into the write skill to do a read. The ninth,jira_projects, imported cleanly and raised an unimportedNotFoundErroronly when a project was absent — a successful import is not evidence a module works.cdd1823f6(2025-12-20) and was fixed in0fafb48e7(2026-02-10);d1a9bc66dvendored the pre-fix state on 2026-06-11. Our files are byte-identical to upstream atcdd1823f6— a stale snapshot, so a re-sync would have fixed this, not reintroduced it. Upstream LT-21672: Add Tables to Word Export #14 is closed as already-fixed._common.py. Zero references outsidePROVENANCE.md. What remained was rewritten rather than left with holes, and the read-only variant lost 237 lines of function signatures thatREFERENCE.mdalready documents.PROVENANCE.mdrecords two local modifications that were unlisted: TLS verification is off in three places, becausejira.sil.org's certificate chain does not validate here, and the write variant's "no script changes" was untrue.Deliberately not here:
_common.pykeepscheck_available_skillseven though only one service can now be unavailable — load-bearing for the credentials path, cheap to leave.Verification:
pyflakesreports nothing across both variants and all 16 modules import. Live through the read-only skill:jira_get_issue('LT-22723'),jira_get_transitions, andjira_get_project_versionsfor both a real and an absent project — the last is what the ninth fix buys, and ablating that one import turns it back into aNameError.gitlintclean. Nobuild.ps1/test.ps1: Python utilities outside the build.Next: review and merge. Independent of #1098/#1099/#1102; #1100 now overlaps by two lines in
jira_workflow.pyandjira_projects.py, so whichever merges second takes a trivial conflict.Size before and after
atlassian-skills(md + py)atlassian-readonly-skills(md + py)SKILL.mdspecifically: write variant 741 → 382 lines, read-only 560 → 148.What the licence investigation found
Both skills carry
license: Complete terms in LICENSEin frontmatter, which is what stopped an earlier pass from touching them at all. Checking properly:LICENSEfile upstream?LICENSEfile here?MIT permits modification, so the earlier caution was unnecessary. The attribution it does ask for was missing and now exists as
PROVENANCE.mdin each skill. Since upstream names no copyright holder, a verbatim MIT text could not honestly be authored on their behalf; the provenance files record the declaration and its gaps instead.This is now a hard fork. A re-sync is no longer a merge — upstream becomes a source to cherry-pick Jira fixes from.
PROVENANCE.mdsays so.Data Center gotchas captured while investigating
Upstream's docstrings describe Jira Cloud; SIL's instance is Data Center. Three that silently disagree, now in
atlassian-skills/PROVENANCE.md:assigneewants a username, not anaccountId.jira_create_issueandjira_update_issueboth send{"accountId": ...}, which Data Center rejects. Passcustom_fields={"assignee": {"name": "<username>"}}.custom_fields={"versions": [{"name": "FW 9.3"}]}.resolutioncannot be set by an update — not on the edit screen; only a transition sets it.Each was found by hitting it. They are duplicated into
jira-issue/references/publish.mdon #1098, where someone working an LT ticket looks first.This change is