iggmasterdev
- 10 skills
- 0 followers
- 6 hours ago last updated
- ▌ Example Mapping · iggmasterdev bundleTurn a raw user story or feature request into a shared, testable specification BEFORE coding starts: clarifying questions, concrete examples, acceptance criteria as Given/When/Then, conditions of satisfaction, a ripple-effect impact list, and a "ready / not ready" verdict. Use this whenever someone is refining, grooming, or kicking off a story; writing or reviewing acceptance criteria; preparing a three-amigos / example-mapping session; checking a Definition of Ready; or asking "what should this feature actually do" or "is this story ready to build". Trigger even if the user only pastes a story and asks for tests or scenarios — the right first move is to map examples, not jump to test cases.
- ▌ Bug Triage Advisor · iggmasterdev bundleTriage a bug using a clear decision model: is it a defect or a feature/change request? should it be logged at all, or just discussed? fix now, later, or never? and which medium — defect tracker, task card, a failing test, or nothing? Use this whenever someone is deciding what to do with a bug, asks "should I log this", "is this a bug or a feature", "fix now or later", how to handle a defect found mid-iteration vs in regression vs in production, or how to set up a lightweight bug policy / zero-bug approach. It adapts to your team's policy if you provide one, and otherwise uses sensible defaults. Trigger even when the user just describes a bug and asks "what do I do with this".
- ▌ Exploratory Charter · iggmasterdev bundleGenerate session-based exploratory testing charters for a feature, area, or build — each with a mission, timebox, test ideas, heuristics and oracles, personas to adopt, a soap-opera scenario, data setup needs, and a session sheet to record results. Use this whenever someone wants to do exploratory testing, asks for a test charter, asks "what should I poke at" or "how should I explore this feature", mentions session-based testing, persona testing, or soap-opera testing, or wants structured-but-unscripted testing beyond their automated checks. Trigger even when the user just says "I need to test this new feature and don't know where to start" — charters are the structured way in.
- ▌ Testing Quadrants Mapper · iggmasterdev bundleMap a feature, story, release, or system to the four Agile Testing Quadrants and produce a concrete test-coverage plan — what to test, who owns it, automated vs manual, when, and with which modern tools — that deliberately surfaces the test types teams forget (Quadrant 3 exploratory/UAT/usability and Quadrant 4 performance/security/reliability). Use this whenever someone asks what tests a feature needs, plans test coverage or a test strategy for a story or release, asks "am I missing any kinds of testing", wonders how to balance unit vs functional vs exploratory, or mentions the testing quadrants. Trigger even when the user only describes a feature and asks "how should I test this" — the quadrants are the right lens for a complete answer.
- ▌ Rca Ishikawa · iggmasterdevRuns an Ishikawa / fishbone contributing-factors sweep across five categories — Process · People · Tooling · Requirements · Environment — so an RCA doesn't tunnel on the single obvious cause. Use for the Contributing-factors step of a SEV1/rollback RCA session, when a root cause feels too simple, or when you want to check "what else made this more likely." Only records categories that actually apply; keeps "People" blameless (systemic conditions, not fault). Called by rca-session-facilitator; usable standalone.
- ▌ Rca Five Whys · iggmasterdevDrives a 5 Whys root-cause dig on a critical bug down to a SYSTEMIC cause you can act on — a process or design gap, never "a person made a mistake." Use when running the Root-Cause step of a SEV1/rollback RCA session, when someone asks "why did this actually break", when a proposed root cause still reads like a symptom, or when a team stops digging too early. Rejects person-blame and symptom-stopping; prompts one more "why" until the answer is a gap in the system. Called by rca-session-facilitator; usable standalone.
- ▌ Rca Record Writer · iggmasterdevEmits the finished RCA + Prevention Record as a .md file in a fixed template, and enforces the record's done-bar: systemic root cause, exactly one concrete prevention, a failure-class tag, and the "fix is not Done until root cause + prevention exist" rule. Use to write or finalize an RCA + Prevention Record, to check a record is complete before closing a SEV1/rollback ticket, or to format captured RCA findings into the shippable artifact. Called by rca-session-facilitator; usable standalone.
- ▌ Rca Prevention Design · iggmasterdevConverts a systemic root cause into EXACTLY ONE concrete, buildable guard — a test, validation, checklist item, or gate — with a named owner, a home ("where it lives"), and a build-now/follow-up call. Use for the Prevention step of a SEV1/rollback RCA session, when turning a root cause into a safeguard, or when a proposed prevention is vague ("be more careful", "review better"). Rejects wish-lists and unbuildable preventions; picks the single guard that kills the whole failure class. Called by rca-session-facilitator; usable standalone.
- ▌ Rca Knowledge Grounding · iggmasterdevOn request, states the established best-practice principle behind any RCA step (5 Whys, blameless framing, contributing factors, prevention design, the feedback loop), and always separates the PRINCIPLE (why the step is sound) from the APPLICATION (how it maps to your team's context). Use when a facilitator or team asks "why do we do this step", "what's the reasoning", "is this best practice", or wants the rationale behind a recommendation. Grounds only in principles it can stand behind — it never invents a source or a citation. Called by rca-session-facilitator; usable standalone.
- ▌ Rca Session Facilitator · iggmasterdevOrchestrates a full Root-Cause + Prevention session end-to-end for a SEV1 or rollback, unaided: intake the incident (ticket, SEV, origin label) → drive 5 Whys to a systemic cause → sweep contributing factors → design exactly one prevention → write the .md Record. Keeps it blameless and timeboxed (~30–45 min) and adapts to any team while holding one shared format. Use when a team needs to run an RCA/postmortem on a critical bug, "do a root-cause session", or turn a SEV1/rollback into a written prevention record. Calls the rca-* sub-skills; grounds on demand.