Add Card Skill for standardized CASH and CONT Jira card creation
Introduces card-skill workflow with board-specific defaults, Background/Scope of change description format, and AC1/AC2 acceptance criteria in Jira fields. Co-authored-by: ScottGits <ScottGits@users.noreply.github.com>
This commit is contained in:
parent
17e41660df
commit
4d03b507f3
1 changed files with 269 additions and 0 deletions
269
.cursor/skills/card-skill/SKILL.md
Normal file
269
.cursor/skills/card-skill/SKILL.md
Normal file
|
|
@ -0,0 +1,269 @@
|
|||
---
|
||||
name: card-skill
|
||||
description: "Create Jira cards on CASH or CONT using the Card Skill workflow. When the user asks to create cards using Card Skill, /card-skill, or card skill. User specifies board (CASH or CONT) and purpose; skill drafts summary, Background/Scope of change description, AC1/AC2 acceptance criteria, and board-specific System Analyst and UAT defaults."
|
||||
---
|
||||
|
||||
# Card Skill
|
||||
|
||||
## Keywords
|
||||
card skill, Card Skill, /card-skill, use card skill, create card on CASH, create card on CONT
|
||||
|
||||
## Overview
|
||||
|
||||
Create Jira Story cards on **CASH** or **CONT** using a standardized Card Skill workflow.
|
||||
|
||||
**Use this skill when:** The user explicitly asks to create a card using **Card Skill** (or `/card-skill`).
|
||||
|
||||
**Do NOT use for:**
|
||||
- General Jira creation without Card Skill → `create-jira-card`
|
||||
- Testing Skill demo cards → `testing-skill`
|
||||
- Bug triage → `triage-issue`
|
||||
|
||||
---
|
||||
|
||||
## Required User Input
|
||||
|
||||
Every Card Skill request MUST include:
|
||||
|
||||
1. **Board** — `CASH` or `CONT` (accept "Cash board", "CONT board", etc.)
|
||||
2. **Purpose** — free-text description of what the card is for
|
||||
|
||||
If board or purpose is missing, ask before creating.
|
||||
|
||||
**Optional extras** (apply when user provides them):
|
||||
- Epic key (e.g. `CASH-1559`, `CONT-905`)
|
||||
- Issue type (default: Story)
|
||||
- Priority, labels, components, assignee, links, fix version, etc.
|
||||
|
||||
---
|
||||
|
||||
## Board Defaults
|
||||
|
||||
Apply these on every card unless the user explicitly overrides in the same request.
|
||||
|
||||
### CASH board
|
||||
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| Project | CASH |
|
||||
| Issue type | Story (unless overridden) |
|
||||
| System Analyst | Scott Phillips (scott.phillips) |
|
||||
| UAT Tester | Tim Gosnik (Tim.Gosnik) |
|
||||
|
||||
### CONT board
|
||||
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| Project | CONT |
|
||||
| Issue type | Story (unless overridden) |
|
||||
| System Analyst | Scott Phillips (scott.phillips) |
|
||||
| UAT Tester | Alexis Lewis (Alexis.Lewis) |
|
||||
|
||||
### Account IDs (use if lookup succeeds)
|
||||
|
||||
| Person | Account ID |
|
||||
|--------|------------|
|
||||
| Scott Phillips | `557058:6c212fb7-af94-48db-91a9-99ba87ceb3c5` |
|
||||
| Tim Gosnik | `712020:1bf3c7f2-bc3b-4bab-bc48-d01e99358978` |
|
||||
| Alexis Lewis | `712020:4c9751b9-2abd-4280-b1e0-983334853223` |
|
||||
|
||||
If lookup fails, call `lookupJiraAccountId` before creating.
|
||||
|
||||
### Jira custom fields
|
||||
|
||||
| Field | ID |
|
||||
|-------|-----|
|
||||
| System Analyst | `customfield_14823` |
|
||||
| UAT Tester | `customfield_13100` |
|
||||
| Acceptance Criteria | `customfield_10025` |
|
||||
| Epic Link | `customfield_10008` |
|
||||
|
||||
**Cloud ID:** `7209f0f8-4a03-4ee5-80e5-044fb17bd281` (safelite.atlassian.net)
|
||||
|
||||
When an epic is provided, set both `parent` and `customfield_10008` to the epic key.
|
||||
|
||||
---
|
||||
|
||||
## Summary (Title)
|
||||
|
||||
Draft a clear, professional Jira summary from the user's purpose.
|
||||
|
||||
**Pattern:** `[Area/Feature]: [Action] — [brief context if needed]`
|
||||
|
||||
**Rules:**
|
||||
- Action-oriented; use verbs (Add, Integrate, Update, Fix, Implement)
|
||||
- Under ~100 characters when possible
|
||||
- Do not use "WIP" or vague titles like "New card"
|
||||
- Do not paste the full purpose into the summary
|
||||
|
||||
**Example purpose:** "Integrate quote page SMS consent with core services APIs"
|
||||
**Example summary:** `FMG 2.0: Integrate quote page SMS consent with core services API`
|
||||
|
||||
---
|
||||
|
||||
## Description Format
|
||||
|
||||
**CRITICAL:** Description uses exactly these two labeled sections with trailing colons:
|
||||
|
||||
```markdown
|
||||
Background:
|
||||
[Content from the user's purpose — context and why this work exists]
|
||||
|
||||
Scope of change:
|
||||
[Content from the user's purpose — what will change or be delivered]
|
||||
```
|
||||
|
||||
**Rules:**
|
||||
- Use `Background:` and `Scope of change:` (lowercase "change")
|
||||
- Each label on its own line; content on following line(s)
|
||||
- Blank line between sections
|
||||
- Do NOT use `Description:` in Card Skill cards
|
||||
- Do NOT put acceptance criteria in the description — use the AC field (below)
|
||||
- Use the user's purpose to populate both sections: expand into Background (context/why) and Scope of change (deliverables/what changes). If the purpose is a single short sentence, place it under Scope of change and write a brief Background derived from it
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria Format
|
||||
|
||||
**CRITICAL:** Put acceptance criteria in the Jira **Acceptance Criteria** field (`customfield_10025`), NOT in the description.
|
||||
|
||||
**Format:**
|
||||
```text
|
||||
AC1: [Testable outcome]
|
||||
AC2: [Testable outcome]
|
||||
AC3: [Testable outcome]
|
||||
```
|
||||
|
||||
**Rules:**
|
||||
- Number sequentially: AC1, AC2, AC3, …
|
||||
- Each AC is one testable, verifiable outcome
|
||||
- Generate 2–5 ACs from the purpose when the user does not provide them
|
||||
- If the user provides explicit ACs, use their wording with AC1/AC2 labels
|
||||
- One AC per line; blank line between ACs is optional
|
||||
|
||||
**Example:**
|
||||
```text
|
||||
AC1: When a phone number is entered on the quote page, SMS consent checkboxes display with API-driven language.
|
||||
|
||||
AC2: When the user saves the quote, FMG POSTs the current consent selections to core services.
|
||||
|
||||
AC3: When only email is provided, no consent checkboxes appear and behavior is unchanged.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Parse request** — Extract board (CASH/CONT), purpose, and optional fields (epic, etc.)
|
||||
2. **Draft card** — Write summary, description (Background + Scope of change), and AC1/AC2/…
|
||||
3. **Confirm** — Show full draft to user before creating (unless user said "create it" with complete details)
|
||||
4. **Create** — Call `createJiraIssue` with board defaults and custom fields
|
||||
5. **Summarize** — Return issue key, URL, and applied fields
|
||||
|
||||
---
|
||||
|
||||
## Create in Jira
|
||||
|
||||
### CASH example
|
||||
|
||||
```
|
||||
createJiraIssue(
|
||||
cloudId="7209f0f8-4a03-4ee5-80e5-044fb17bd281",
|
||||
projectKey="CASH",
|
||||
issueTypeName="Story",
|
||||
summary="[drafted summary]",
|
||||
description="Background:\n[background]\n\nScope of change:\n[scope]",
|
||||
parent="CASH-1559",
|
||||
additional_fields={
|
||||
"customfield_10008": "CASH-1559",
|
||||
"customfield_14823": { "accountId": "557058:6c212fb7-af94-48db-91a9-99ba87ceb3c5" },
|
||||
"customfield_13100": { "accountId": "712020:1bf3c7f2-bc3b-4bab-bc48-d01e99358978" },
|
||||
"customfield_10025": "AC1: ...\n\nAC2: ..."
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
### CONT example
|
||||
|
||||
```
|
||||
createJiraIssue(
|
||||
cloudId="7209f0f8-4a03-4ee5-80e5-044fb17bd281",
|
||||
projectKey="CONT",
|
||||
issueTypeName="Story",
|
||||
summary="[drafted summary]",
|
||||
description="Background:\n[background]\n\nScope of change:\n[scope]",
|
||||
parent="CONT-905",
|
||||
additional_fields={
|
||||
"customfield_10008": "CONT-905",
|
||||
"customfield_14823": { "accountId": "557058:6c212fb7-af94-48db-91a9-99ba87ceb3c5" },
|
||||
"customfield_13100": { "accountId": "712020:4c9751b9-2abd-4280-b1e0-983334853223" },
|
||||
"customfield_10025": "AC1: ...\n\nAC2: ..."
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
Omit `parent` and `customfield_10008` when no epic is specified.
|
||||
|
||||
Merge any user-requested `additional_fields` (priority, labels, etc.) into the same object.
|
||||
|
||||
---
|
||||
|
||||
## Confirmation Format
|
||||
|
||||
```
|
||||
Here's the Card Skill card I'll create:
|
||||
|
||||
**Board:** CASH
|
||||
**Type:** Story
|
||||
**Summary:** [summary]
|
||||
**Epic:** CASH-1559 (if provided)
|
||||
**System Analyst:** Scott Phillips
|
||||
**UAT Tester:** Tim Gosnik
|
||||
|
||||
**Description:**
|
||||
Background:
|
||||
[background]
|
||||
|
||||
Scope of change:
|
||||
[scope]
|
||||
|
||||
**Acceptance Criteria:**
|
||||
AC1: ...
|
||||
AC2: ...
|
||||
|
||||
Shall I create this card?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Overrides
|
||||
|
||||
Only change board defaults if the user explicitly specifies in the same request:
|
||||
- Different epic → use user's epic
|
||||
- Different System Analyst or UAT → lookup and apply
|
||||
- Different issue type → use specified type
|
||||
- User-provided ACs → use with AC1/AC2 formatting
|
||||
|
||||
---
|
||||
|
||||
## Skill Maintenance
|
||||
|
||||
When the user asks to **update Card Skill** (change defaults, add fields, change format):
|
||||
1. Edit `.cursor/skills/card-skill/SKILL.md`
|
||||
2. Preserve existing behavior unless the user requests a change
|
||||
3. Confirm what changed after updating
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Item | Value |
|
||||
|------|-------|
|
||||
| Invoke | `/card-skill` or "create using Card Skill" |
|
||||
| Boards | CASH, CONT |
|
||||
| Description | `Background:` + `Scope of change:` |
|
||||
| Acceptance Criteria | `customfield_10025` as AC1:, AC2:, … |
|
||||
| System Analyst | Scott Phillips (both boards) |
|
||||
| UAT (CASH) | Tim Gosnik |
|
||||
| UAT (CONT) | Alexis Lewis |
|
||||
| Default type | Story |
|
||||
Loading…
Reference in a new issue