ima-claude 2.20.0 → 2.26.0

package/plugins/ima-claude/skills/ima-git/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: "ima-git"
+description: "IMA git workflow. Trunk-based development with release branches: main = dev trunk, release/* = release candidate branches, v* tags = production releases. Covers branch promotion, hotfix flow, push cadence for deploy-gate verification, commit atomicity. Use when: creating branches, opening PRs, cutting releases or tags, writing hotfixes, or asked about git workflow, branching strategy, trunk-based development, release process, or when a deploy gate fails because commits weren't pushed."
+---
+
+# IMA Git Workflow
+
+**Strategy:** Trunk-based development with release branches.
+
+## Branch model
+
+| Branch / tag | Role | Source | Deploys to |
+|---|---|---|---|
+| `main` | Dev trunk — latest integrated work | All new work lands here first | Dev environment |
+| `release/<name>` | Release candidate | Fast-forwarded from `main` when ready | Staging environment |
+| `v<version>` (tags) | Production release | Tag cut from a release branch at promotion | Production environment |
+| `hotfix/<name>` | Emergency production fix | Branched off the production tag | Merged back to `main` + new tag cut |
+
+## Core rules
+
+1. **Commits originate on `main`.** Not on release branches. Feature work, bug fixes, refactors — all start on the trunk.
+2. **Release branches only fast-forward from `main`.** Never merge sideways; never commit directly to a release branch.
+3. **Hotfixes branch off the production tag**, not main. After the fix lands, cut a new tag and merge the hotfix back into `main`.
+4. **Tags are immutable.** Rolling back to a prior production state means deploying the prior tag — not force-pushing or retagging.
+
+## Deploy-gate verification cadence
+
+Deploy tools (e.g., `trn-deploy` at `/home/eric/IMA/dev/sites/trn/deploy/`) **clone fresh from the remote** — they do not read the local filesystem. Unpushed commits are invisible to the gate.
+
+**To verify a change:** push to `main` first, then invoke the dry-run.
+
+Between commits in a multi-commit sequence:
+
+1. Commit locally
+2. `git push origin main`
+3. Run `./deploy dev --dry-run`
+4. Confirm exit 0 in `log.jsonl` before the next commit
+
+## Commit atomicity
+
+- **Security fixes: separate commits** from test-only changes and mechanical sweeps. A security change should land in a reviewable, revertable commit of its own.
+- One commit per logical change class. Don't batch "fix XSS + rename variable + reformat whitespace" into one diff.
+- Pure tests-only changes never mix with production code changes in the same commit.
+
+## Commit messages
+
+- Use a HEREDOC to pass multi-line messages: `git commit -m "$(cat <<'EOF' ... EOF)"`.
+- Single-quoted `EOF` marker (`<<'EOF'`) prevents shell expansion — required to keep `$_POST`, `$_GET`, `$variable` etc. unescaped.
+- A message with literal `\$_POST` in the body is a shell-escape artifact — amend before pushing, or treat it as a signal the HEREDOC was wrong.
+
+## Deploy tool exit codes
+
+Shared convention across IMA deploy tools:
+
+| Code | Meaning |
+|---|---|
+| 0 | Success |
+| 1 | Generic failure |
+| 2 | Validation / config error |
+| 3 | Pre-flight failure (tests, lint, clean-state check) |
+| 4 | Remote push failure (WPEngine or similar) |
+
+The authoritative record is the tool's `log.jsonl`: `tail -1 log.jsonl` shows the last run's sha, exitCode, duration. The shell's `$?` may be masked by a pipe (`| tail`), so trust the log over stdout exit.
+
+## Gitea / GitHub
+
+- IMA internal repos live on Gitea: `ssh://git@gitea.theflccc.org:2222/IMA/<repo>.git`
+- Some are mirrored to GitHub for FOSS / public presence.
+- Use `mcp-gitea` for internal repo operations, `mcp-github` or `gh-cli` for public.
+
+## When the deploy gate fails
+
+1. Check `log.jsonl` for the exit code. Don't guess from terminal output.
+2. Exit 3 = pre-flight. Look at the pipeline stage that failed — tests, lint, clean-state, composer check.
+3. Reproduce locally with the project's configured validators (`composer check`, `npm run check`, `make check`, etc.) before touching code.
+4. If a pre-flight failure is tests, invoke the source-quality triage pattern: categorize each failure as test rot, code bug, or design question **before** changing anything.
+
+## Reference
+
+- Qdrant `ima-knowledge` → article "IMA Git Workflow & Pre-flight Deploy Gate" for full detail on the gate architecture and the source-quality triage playbook.
+- Project-specific deploy specifics live in the project's Serena memory (typically named `project-workflow` or similar).

package/plugins/ima-claude/skills/jira-checkpoint/SKILL.md

@@ -12,167 +12,86 @@ description: >-
 
 # Jira Checkpoint - Team Visibility Layer
 
-**"Work gets done. Does the team know?"**
-
-Claude Code makes us 3-5x faster. Jira becomes the bottleneck — not the work, but remembering to update it. This skill adds lightweight checkpoints so team visibility stays current without breaking flow.
-
-## Responsibility Separation
-
 ```
 task-master      = "How do I organize my work?"    (execution, tactical)
 jira-checkpoint  = "Does the team know?"           (visibility, strategic)
 mcp-atlassian    = "How do I talk to Jira's API?"  (implementation, reference)
 ```
 
-**No overlap.** task-master owns TaskList, decomposition, and delegation. jira-checkpoint owns the question "should we sync with Jira?" mcp-atlassian owns the API mechanics. Each skill stays in its lane.
+Each skill stays in its lane. jira-checkpoint never touches TaskList, decomposition, or delegation.
 
 ## The Three Checkpoints
 
-### 1. Before Work (Planning)
-
-**When:** User starts significant work — "let's implement", "build the", "fix the", "work on FNR-".
+### 1. Before Work
 
-**Action:** Ask one question:
+**Trigger**: User starts significant work — "let's implement", "build the", "fix the", "work on FNR-".
 
-> "Should I search Jira (FNR project) for related stories before we start?"
-
-**Decision tree:**
+Ask: `"Should I search Jira (FNR project) for related stories before we start?"`
 
 ```
-Is this significant work (feature, fix, refactor)?
+Significant work (feature, bug fix, multi-file refactor)?
 ├── YES → Ask about Jira search
-│   User says yes → searchJiraIssuesUsingJql with FNR project
-│   User says skip → Proceed, no Jira
-└── NO (trivial utility, config tweak, typo fix) → Stay silent
+│   yes → searchJiraIssuesUsingJql (FNR project)
+│   skip → proceed
+└── NO (utility function, config tweak, lint fix) → stay silent
 ```
 
-**What counts as "significant":**
-- New feature or component
-- Bug fix with user impact
-- Refactor touching multiple files
-- Anything that would reasonably be a Jira story
-
-**What stays silent:**
-- Adding a utility function
-- Config file tweaks
-- Formatting/linting fixes
-- Internal refactors with no external impact
-
-### 2. During Work (Context)
-
-**When:** User references a Jira issue key (e.g., `FNR-123`).
+### 2. During Work
 
-**Action:** Auto-fetch the issue details and surface relevant context:
+**Trigger**: User mentions an issue key (e.g., `FNR-123`).
 
+Auto-fetch and surface:
 ```
 Detected FNR-123. Fetching story context...
-
-→ "As a user, I want to reset my password via email"
-→ Acceptance criteria: [list]
-→ Status: In Progress | Assignee: Eric
+→ Summary
+→ Acceptance criteria
+→ Status | Assignee
 ```
 
-**Implementation:** Use `getJiraIssue` with fields: `summary,description,status,assignee,customfield_10016` (acceptance criteria). See mcp-atlassian skill for field filtering patterns.
-
-**Decision tree:**
-
-```
-Did user mention an issue key (FNR-NNN)?
-├── YES → Auto-fetch, surface summary + acceptance criteria
-│   Already fetched this session? → Skip (don't re-fetch)
-└── NO → Stay silent
-```
-
-### 3. After Work (Sync)
-
-**When:** Work completes and a Jira story was referenced or discovered during the session.
+Use `getJiraIssue` with fields: `summary,description,status,assignee,customfield_10016`. Don't re-fetch if already retrieved this session.
 
-**Action:** Ask one question:
+### 3. After Work
 
-> "We referenced FNR-123 during this work. Want to update its status or add a progress comment?"
+**Trigger**: Work wraps up AND a Jira story was referenced (user says "done"/"finished"/"ship it", commit created, PR ready).
 
-**Decision tree:**
+Ask: `"We referenced FNR-123 during this work. Want to update its status or add a progress comment?"`
 
 ```
-Is work wrapping up AND was a Jira story involved?
+Work wrapping up AND Jira story was involved?
 ├── YES → Ask about status update / comment
-│   User says yes → Use transitionJiraIssue or addCommentToJiraIssue
-│   User says skip → Done, no update
-└── NO story involved → Stay silent
+│   yes → transitionJiraIssue or addCommentToJiraIssue
+│   skip → done
+└── NO story involved → stay silent
 ```
 
-**What "wrapping up" looks like:**
-- User says "done", "finished", "that's it", "ship it"
-- Commit created for the feature/fix
-- PR created or ready
+## Key Tools
 
-## Integration Points
+| Tool | Checkpoint |
+|------|-----------|
+| `searchJiraIssuesUsingJql` | Before Work |
+| `getJiraIssue` | During Work |
+| `transitionJiraIssue` | After Work |
+| `addCommentToJiraIssue` | After Work |
+| `getAccessibleAtlassianResources` | Required bootstrap (cloudId) |
 
-### mcp-atlassian (API Reference)
+See `mcp-atlassian` for field filtering patterns and JQL.
 
-All Jira operations use tools from mcp-atlassian. Do NOT duplicate API docs here — refer to that skill for:
-- Tool catalog and parameters
-- Token-saving field filtering
-- JQL query patterns
-- Comment and transition workflows
+## Project Config
 
-**Key tools used by checkpoints:**
-- `searchJiraIssuesUsingJql` — Before Work search
-- `getJiraIssue` — During Work context fetch
-- `transitionJiraIssue` — After Work status update
-- `addCommentToJiraIssue` — After Work progress comment
-- `getAccessibleAtlassianResources` — Required bootstrap (cloudId)
-
-### task-master (No Overlap)
-
-task-master manages TaskList items and work decomposition. jira-checkpoint never:
-- Creates or modifies TaskList items
-- Changes task decomposition strategy
-- Interferes with delegation patterns
-
-They complement: task-master breaks work down, jira-checkpoint ensures Jira reflects it.
-
-### Vestige (Learning Preferences)
-
-Store user checkpoint preferences via Vestige:
+**Default project**: `FNR`
 
 ```
-User says "skip Jira" repeatedly → smart_ingest preference: "User prefers minimal Jira checkpoints"
-User always updates after work   → smart_ingest preference: "User wants post-work Jira sync prompts"
-User never wants before-work     → smart_ingest preference: "Skip before-work Jira checkpoint"
+JQL: project = FNR AND summary ~ "keyword" ORDER BY updated DESC
 ```
 
-Check Vestige at session start for stored Jira checkpoint preferences.
-
 ## User Control
 
-**Every checkpoint is a question, never a mandate.**
-
-- User can always say "skip Jira", "not now", "no Jira today"
-- Preferences accumulate in Vestige — skill adapts over time
-- No checkpoint ever blocks work from proceeding
-- If user seems annoyed by prompts, reduce frequency and store preference
-
-## Project Configuration
-
-**Default project key:** `FNR`
-
-When searching Jira without a specific issue key, scope to the FNR project:
+Every checkpoint is a question, never a mandate. Store preferences via Vestige `smart_ingest`:
 
 ```
-JQL: project = FNR AND summary ~ "keyword" ORDER BY updated DESC
+"skip Jira" repeatedly         → "User prefers minimal Jira checkpoints"
+always updates after work      → "User wants post-work Jira sync prompts"
+never wants before-work prompt → "Skip before-work Jira checkpoint"
 ```
 
-## Experimental Status
-
-This skill is built for vetting. Expected evolution:
-
-1. **v1 (now):** Three manual checkpoints with questions
-2. **v2 (after feedback):** Adjusted trigger sensitivity based on usage patterns
-3. **v3 (if valuable):** Deeper task-master integration (auto-suggest Jira links for TaskList items)
-
-**Feedback signals to watch:**
-- How often does the user accept vs skip checkpoints?
-- Are before-work searches actually useful?
-- Does after-work sync feel natural or forced?
-- Is the FNR project scope too narrow?
+Check Vestige at session start for stored preferences.