Imported from kwhorne/elyra-skills (skills/using-elyra-skills/SKILL.md). Install upstream with npx skills add kwhorne/elyra-skills --skill using-elyra-skills. Copyright stays with the author (MIT).

Using Elyra Skills

A map of the registry: which skill to load when, how they chain, and how to combine them without tripping over each other.

When to use

• Unsure which skill fits the current task
• A task spans multiple phases (idea → ship) and needs a sequence
• The user asks "what skills do you have?" or "how do these fit together?"
• Kicking off a large feature where the right opening move matters

Selection rules

1. Match the task's phase, not its noun. "Fix the payment API" might be debugging (it's broken), resilience-patterns (it's flaky), or deprecation-migration (it's being replaced). Ask what's actually happening before loading.
2. One primary skill at a time. A primary skill drives the process and the output format; others are consulted for their checklists, not their workflow.
3. Vague input → discovery skill first. When the request can't be restated as a verifiable outcome, start with idea-refine (new ideas) or codebase-exploration (unfamiliar code) — never with implementation.
4. No skill fits → no skill. Skills encode workflows; trivial tasks don't need one. Loading a skill for a one-line fix is overhead.

The lifecycle map

DEFINE            PLAN             BUILD              VERIFY           SHIP             OPERATE          MAINTAIN
idea-refine   →   task-breakdown → incremental-     → debugging      → ci-cd-pipeline → observability  → tech-debt-triage
spec-writing                       implementation     test-writing     release-         incident-        refactoring
threat-modeling                    codebase-          code-review      checklist        response         dependency-update
api-design                         exploration        security-audit   feature-flag-    runbook-author   deprecation-migration
architecture-                      error-handling     accessibility-   rollout          cost-            
review                             caching-strategy   review           changelog        optimization     
adr-author                         resilience-        i18n-review      conventional-                     
                                   patterns           performance-     commits                           
                                   database-          budget           pr-description                    
                                   migration          data-privacy-    git-workflow                      
                                   llm-feature-       review                                             
                                   design             code-style-guide                                   

Cross-cutting (any phase): context-engineering, onboarding-doc, git-workflow.

Stack-specific skills

Stack skills are selected in addition to the phase skill, never instead of it. The phase skill drives the workflow; the stack skill supplies the framework-specific rules and checklists for the steps.

Examples of the pairing:

• Slow Laravel page → debugging (primary, owns the loop) + laravel-eloquent-performance (the stack checklist inside steps 2–4)
• New TALL feature → task-breakdown → incremental-implementation (primary) + livewire-component-design / flux-ui-patterns consulted per task
• Testing phase in a Laravel app → test-writing for what to test, laravel-testing for how to test it here

Detect the stack from manifests (composer.json, package.json) before assuming — don't load Laravel skills into a Django repo because the user said "backend".

Standard chains

New feature, end to end: idea-refine → spec-writing → task-breakdown → incremental-implementation → code-review → release-checklist Skip idea-refine when the problem is already crisp; skip spec-writing for tasks under ~1 hour.

Sensitive feature (auth, money, PII): insert threat-modeling during spec — its mitigations become acceptance criteria — and security-audit + data-privacy-review at review.

Bug in production: incident-response (if users are hurting now) → debugging (root cause) → test-writing (regression test). Postmortem actions may spawn resilience-patterns or observability work.

Inherited/unfamiliar codebase: codebase-exploration → tech-debt-triage → then the normal feature chain, with context-engineering to write down what you learned.

Replacing something old: codebase-exploration (blast radius) → deprecation-migration (the plan) → database-migration / dependency-update for the mechanics.

Combining without conflict

• The primary skill owns the output format. If incremental-implementation is driving and a step needs a migration, apply database-migration's rules inside that step's boundaries — don't switch report formats mid-task.
• Review skills (code-review, security-audit, accessibility-review, i18n-review) stack cleanly: run as separate passes, merge findings into one severity-ranked list.
• When two skills disagree (e.g. refactoring says "small steps", deadline says "big bang"), surface the trade-off to the user — don't silently pick.

Output format

When recommending skills for a task:

**Task as I understand it:** …
**Primary skill:** `<name>` — why.
**Supporting:** `<name>` (used for: …)
**Chain (if multi-phase):** `a` → `b` → `c`, with handoff points.
**Not loading:** `<name>` — why not (e.g. overlap, overkill).

Anti-patterns

• ❌ Loading three skills and blending their workflows into mush — one primary, others consult
• ❌ Skipping discovery (idea-refine/codebase-exploration) because the user sounded confident
• ❌ Forcing a skill onto a trivial task for ceremony's sake
• ❌ Following a skill's letter against the project's reality — skills encode defaults, the codebase wins
• ❌ Running the full lifecycle chain on a bugfix — match weight to the task