jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/ui-ux-pro-max/scripts/search.py

@@ -0,0 +1,114 @@
+#!/usr/bin/env python3
+# -*- coding: utf-8 -*-
+"""
+UI/UX Pro Max Search - BM25 search engine for UI/UX style guides
+Usage: python search.py "<query>" [--domain <domain>] [--stack <stack>] [--max-results 3]
+       python search.py "<query>" --design-system [-p "Project Name"]
+       python search.py "<query>" --design-system --persist [-p "Project Name"] [--page "dashboard"]
+
+Domains: style, color, chart, landing, product, ux, typography, icons, react, web
+Stacks: html-tailwind, react, nextjs, astro, vue, nuxtjs, nuxt-ui, svelte, swiftui, react-native, flutter, shadcn, jetpack-compose
+
+Persistence (Master + Overrides pattern):
+  --persist    Save design system to design-system/<project-slug>/MASTER.md
+  --page       Also create a page-specific override file in design-system/<project-slug>/pages/
+"""
+
+import argparse
+import sys
+import io
+from core import CSV_CONFIG, AVAILABLE_STACKS, MAX_RESULTS, search, search_stack
+from design_system import generate_design_system
+
+# Force UTF-8 for stdout/stderr to handle emojis on Windows (cp1252 default)
+if sys.stdout.encoding and sys.stdout.encoding.lower() != 'utf-8':
+    sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8')
+if sys.stderr.encoding and sys.stderr.encoding.lower() != 'utf-8':
+    sys.stderr = io.TextIOWrapper(sys.stderr.buffer, encoding='utf-8')
+
+
+def format_output(result):
+    """Format results for Claude consumption (token-optimized)"""
+    if "error" in result:
+        return f"Error: {result['error']}"
+
+    output = []
+    if result.get("stack"):
+        output.append(f"## UI Pro Max Stack Guidelines")
+        output.append(f"**Stack:** {result['stack']} | **Query:** {result['query']}")
+    else:
+        output.append(f"## UI Pro Max Search Results")
+        output.append(f"**Domain:** {result['domain']} | **Query:** {result['query']}")
+    output.append(f"**Source:** {result['file']} | **Found:** {result['count']} results\n")
+
+    for i, row in enumerate(result['results'], 1):
+        output.append(f"### Result {i}")
+        for key, value in row.items():
+            value_str = str(value)
+            if len(value_str) > 300:
+                value_str = value_str[:300] + "..."
+            output.append(f"- **{key}:** {value_str}")
+        output.append("")
+
+    return "\n".join(output)
+
+
+if __name__ == "__main__":
+    parser = argparse.ArgumentParser(description="UI Pro Max Search")
+    parser.add_argument("query", help="Search query")
+    parser.add_argument("--domain", "-d", choices=list(CSV_CONFIG.keys()), help="Search domain")
+    parser.add_argument("--stack", "-s", choices=AVAILABLE_STACKS, help="Stack-specific search (html-tailwind, react, nextjs)")
+    parser.add_argument("--max-results", "-n", type=int, default=MAX_RESULTS, help="Max results (default: 3)")
+    parser.add_argument("--json", action="store_true", help="Output as JSON")
+    # Design system generation
+    parser.add_argument("--design-system", "-ds", action="store_true", help="Generate complete design system recommendation")
+    parser.add_argument("--project-name", "-p", type=str, default=None, help="Project name for design system output")
+    parser.add_argument("--format", "-f", choices=["ascii", "markdown"], default="ascii", help="Output format for design system")
+    # Persistence (Master + Overrides pattern)
+    parser.add_argument("--persist", action="store_true", help="Save design system to design-system/MASTER.md (creates hierarchical structure)")
+    parser.add_argument("--page", type=str, default=None, help="Create page-specific override file in design-system/pages/")
+    parser.add_argument("--output-dir", "-o", type=str, default=None, help="Output directory for persisted files (default: current directory)")
+
+    args = parser.parse_args()
+
+    # Design system takes priority
+    if args.design_system:
+        result = generate_design_system(
+            args.query, 
+            args.project_name, 
+            args.format,
+            persist=args.persist,
+            page=args.page,
+            output_dir=args.output_dir
+        )
+        print(result)
+        
+        # Print persistence confirmation
+        if args.persist:
+            project_slug = args.project_name.lower().replace(' ', '-') if args.project_name else "default"
+            print("\n" + "=" * 60)
+            print(f"✅ Design system persisted to design-system/{project_slug}/")
+            print(f"   📄 design-system/{project_slug}/MASTER.md (Global Source of Truth)")
+            if args.page:
+                page_filename = args.page.lower().replace(' ', '-')
+                print(f"   📄 design-system/{project_slug}/pages/{page_filename}.md (Page Overrides)")
+            print("")
+            print(f"📖 Usage: When building a page, check design-system/{project_slug}/pages/[page].md first.")
+            print(f"   If exists, its rules override MASTER.md. Otherwise, use MASTER.md.")
+            print("=" * 60)
+    # Stack search
+    elif args.stack:
+        result = search_stack(args.query, args.stack, args.max_results)
+        if args.json:
+            import json
+            print(json.dumps(result, indent=2, ensure_ascii=False))
+        else:
+            print(format_output(result))
+    # Domain search
+    else:
+        result = search(args.query, args.domain, args.max_results)
+        if args.json:
+            import json
+            print(json.dumps(result, indent=2, ensure_ascii=False))
+        else:
+            print(format_output(result))

package/.github/skills/use-case-canvas-builder/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: use-case-canvas-builder
+description: 'Turn a rough AI, agent, workflow, or automation idea into a full use case canvas covering the user, problem, workflow, data, AI role, value, risks, and MVP boundary. Use this whenever the user has an early concept that needs to be shaped into a concrete use case before prioritization, PRD writing, proposal language, or solution design.'
+metadata:
+  argument-hint: 'Describe the rough idea, target users, workflow, and any known constraints or goals.'
+---
+
+# Use Case Canvas Builder
+
+## Positioning
+
+Use this skill to take an underdefined idea and turn it into a decision-useful use case canvas. The output should give the team enough structure to discuss whether the idea is worth pursuing, what would need to be true for an MVP, and which next artifact should come after the canvas.
+
+## When To Use This
+
+- The user has a rough AI or automation concept that needs structure.
+- A workshop idea needs to become a clearer use case before scoring or scoping.
+- The team needs to define the user, workflow, data, and value in one place.
+- A seller, facilitator, or architect needs to turn vague enthusiasm into a concrete candidate MVP.
+
+## Typical Need Shapes
+
+- "Take this loose idea for an internal claims copilot and turn it into a proper use case canvas."
+- "We have a rough workshop concept but need the user, workflow, data, and MVP spelled out."
+- "Turn this early AI idea into a one-page canvas we can use for prioritization and follow-on scoping."
+
+## When Not To Use This
+
+- Do not use it when the main need is to rank already-defined use cases. Route to `use-case-prioritization`.
+- Do not treat the canvas as a PRD or implementation commitment. Route to `agent-prd-writer` or `solution-architecture-patterns` after the concept is shaped.
+- Do not invent detailed business rules when the workflow logic is the real unknown. Route to `business-logic-extractor` if the process needs deeper rule extraction.
+
+## Required Inputs
+
+- Rough idea, problem statement, or workshop note
+- Known or suspected users
+- Any known workflow, data, system, or policy context
+
+## Evidence And Boundary Discipline
+
+Separate confirmed facts from assumptions and open questions. A strong canvas is concrete enough to support a next decision without pretending the concept is implementation-ready. If the user provides only a partial idea, complete the canvas with labeled hypotheses rather than invented certainty.
+
+## Workflow
+
+1. Clarify the target user, job, and pain point.
+2. Define the workflow boundary, trigger, and desired outcome.
+3. Identify the data, systems, and human roles involved.
+4. Describe the AI or automation role without overselling autonomy.
+5. Articulate value, risks, dependencies, and MVP scope.
+6. End with open questions and the best next step after the canvas.
+
+## Output Structure
+
+1. Use case name and summary
+2. Primary user and stakeholders
+3. Problem and current-state friction
+4. Workflow and trigger
+5. Data, systems, and inputs
+6. AI role and human-in-the-loop boundary
+7. Expected value and success signals
+8. Risks, assumptions, and unknowns
+9. MVP boundary and recommended next step
+
+## Reference Files
+
+- Use [canvas-pattern.md](./references/canvas-pattern.md) for the default canvas structure, field definitions, and example prompts.
+- Use [../../../05-reference/the-jumpstart-workshops.md](../../../05-reference/the-jumpstart-workshops.md) when the idea comes from a Jump Start workshop and the next step needs to stay aligned with that motion.
+- Use [../../../05-reference/prototype-to-Production.md](../../../05-reference/prototype-to-Production.md) when the canvas needs to distinguish MVP scope from production expectations.
+
+## Common Pitfalls
+
+### Pitfall 1: Writing A Pitch Instead Of A Canvas
+
+Bad: emphasizing excitement and benefits without defining the user, workflow, data, and boundary.
+
+Better: make the operating context explicit so the canvas can support prioritization or scoping.
+
+### Pitfall 2: Treating AI As The User
+
+Bad: centering the canvas on the model instead of the human workflow it supports.
+
+Better: start with the user, job to be done, decision points, and where AI meaningfully helps.
+
+### Pitfall 3: Hiding MVP Limits
+
+Bad: describing a broad future vision without separating first release from later expansion.
+
+Better: state what the MVP does, what it does not do yet, and what must be validated next.
+
+## Quality Bar
+
+- Make the canvas usable in prioritization, workshop recap, or follow-on scoping.
+- Keep the user, workflow, data, and value connected.
+- Show where the AI role needs human review, approvals, or fallback behavior.
+- Name assumptions and unanswered questions instead of smoothing them over.

package/.github/skills/use-case-canvas-builder/references/canvas-pattern.md

@@ -0,0 +1,106 @@
+# Use Case Canvas Pattern
+
+Use this pattern when an idea is still rough but needs enough structure for workshop refinement, prioritization, or scoped follow-on planning.
+
+## Default Canvas Fields
+
+Use these fields unless the user asks for a different structure:
+
+1. Use case name
+2. Primary user
+3. Supporting stakeholders
+4. Problem or friction
+5. Trigger and workflow moment
+6. Current-state process
+7. Proposed AI or automation role
+8. Data and systems involved
+9. Human review and control points
+10. Expected value
+11. Risks and constraints
+12. MVP boundary
+13. Open questions
+14. Recommended next step
+
+## Field Guidance
+
+| Field | What Good Looks Like |
+| --- | --- |
+| Use case name | short, specific, and tied to a workflow rather than a generic AI theme |
+| Primary user | the person or role whose work changes |
+| Supporting stakeholders | approvers, SMEs, operators, owners, or impacted teams |
+| Problem or friction | the pain, delay, quality issue, or decision bottleneck being addressed |
+| Trigger and workflow moment | when the use case starts and where it sits in the real process |
+| Current-state process | how work happens today, at the right level of detail for the canvas |
+| Proposed AI or automation role | summarize, draft, classify, recommend, route, retrieve, or assist without overstating autonomy |
+| Data and systems involved | documents, systems, APIs, reports, and ownership or access constraints |
+| Human review and control points | where a person must approve, correct, escalate, or override |
+| Expected value | cost, speed, quality, risk reduction, customer experience, or decision quality |
+| Risks and constraints | policy, security, governance, change management, data quality, integration, or adoption issues |
+| MVP boundary | the smallest useful version that proves value without implying full production scope |
+| Open questions | the unknowns that matter most to the go or no-go decision |
+| Recommended next step | prioritization, workshop module, PRD, architecture design, or narrower discovery |
+
+## Default Output Shape
+
+### 1. Use Case Summary
+
+- `Use case:`
+- `Outcome:`
+- `Why this matters now:`
+
+### 2. User And Problem
+
+- `Primary user:`
+- `Other stakeholders:`
+- `Problem to solve:`
+- `Current friction:`
+
+### 3. Workflow Context
+
+- `Trigger:`
+- `In-scope workflow:`
+- `Out-of-scope workflow:`
+
+### 4. Data And Systems
+
+- `Data needed:`
+- `Systems touched:`
+- `Known access or quality concerns:`
+
+### 5. AI Role And Human Boundary
+
+- `AI role:`
+- `Human review or approval points:`
+- `Fallback or escalation path:`
+
+### 6. Value, Risks, And MVP
+
+- `Expected value:`
+- `Success signals:`
+- `Key risks or constraints:`
+- `MVP scope:`
+- `Not in MVP yet:`
+
+### 7. Open Questions And Next Step
+
+- `Top unknowns:`
+- `Recommended next step:`
+
+## Example Read
+
+Example:
+
+- Rough idea: "Use AI to help claims adjusters answer policy questions faster."
+- Good canvas framing:
+  - Primary user: claims adjuster
+  - Trigger: adjuster is reviewing a claim and needs policy interpretation
+  - AI role: retrieve policy language, summarize relevant clauses, draft a recommendation for reviewer confirmation
+  - Human boundary: adjuster or supervisor approves any final claim decision
+  - MVP: one policy family, internal users only, no automatic claim decisioning
+
+## Common Failure Modes
+
+- Writing an abstract innovation statement instead of a workflow-grounded use case.
+- Skipping data and system realities because they are inconvenient.
+- Describing AI autonomy more broadly than the workflow or controls support.
+- Calling something an MVP without naming what is intentionally excluded.

package/.github/skills/use-case-dependency-mapper/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: use-case-dependency-mapper
+description: 'Map data, systems, process, security, people, and change dependencies for proposed AI or automation use cases. Use this whenever the user needs to understand what must be in place before a use case can be built or delivered, surface hidden blockers, or create a dependency view for scoping, readiness assessment, or delivery planning in Jump Start or AI Innovation Pod work. Trigger even when the user asks things like "what does this use case depend on", "what blockers should we expect", "what do we need to have in place before we build this", or "map out the dependencies" for one or more use cases.'
+---
+
+# Use Case Dependency Mapper
+
+## Positioning
+
+Use this skill to surface what must be true, ready, or resolved before a use case can move into delivery. The output is a dependency map — not a risk register, not a roadmap — that helps teams answer a focused question: what are we actually depending on for this to work?
+
+Map dependencies across six dimensions: data, systems, process, security, people, and change. Each dimension captures a different class of dependency that shapes feasibility, sequencing, and delivery risk. The goal is to make hidden blockers visible early, before scope commitments are made.
+
+## When To Use This
+
+- A use case shortlist exists and the team needs to understand what each use case actually depends on before scoping or committing.
+- A Pod delivery or Jump Start follow-on needs dependency visibility before sprint planning.
+- A sales or architecture conversation needs honest dependency exposure to protect scope and delivery confidence.
+- The team suspects hidden dependencies are inflating feasibility scores or masking real blockers.
+- A readiness conversation is happening and the stakeholders need to see what they actually own.
+
+## Typical Need Shapes
+
+- "Map the dependencies for these three candidate use cases before we decide which to prototype first."
+- "Show what data, systems, and governance our top use case depends on so we can scope the integration work."
+- "Extract all the dependencies from this discovery output so we can assess readiness."
+- "Build a dependency matrix for these use cases to prepare for the pilot kickoff."
+- "We're heading into delivery — what do we still need to resolve before we can start?"
+
+## When Not To Use This
+
+- Do not use this as a risk register. Dependencies are inputs to risk analysis, not risks themselves. Route to `risk-assumption-register` when the goal is risk, assumption, and mitigation language.
+- Do not use this as a delivery roadmap. Dependencies explain what must exist, not when to build things. Route to `phased-roadmap` when sequencing is the primary goal.
+- Do not use this if the use cases themselves are still undefined. Clarify use cases first.
+
+## Required Inputs
+
+- One or more proposed use cases (even rough descriptions are usable)
+- Optional: system inventory, data notes, team or stakeholder list, security constraints, known integration context
+
+## Dependency Dimensions
+
+Map each use case across six dimensions. Read `references/dependency-categories.md` for detailed definitions, discovery prompts, and examples per category when more depth is needed.
+
+### Data
+What data must be available, accessible, clean, and trusted for this use case to function?
+- Source systems, data types, formats, refresh frequency
+- Data quality and completeness requirements
+- Access rights, consent, and governance approvals
+- Data contracts or SLAs that do not yet exist
+
+### Systems
+What systems, platforms, APIs, or services must be available or integrated?
+- Source and target systems
+- APIs that must exist, be exposed, or be built
+- Middleware, orchestration, or infrastructure requirements
+- Versioning, compatibility, or deprecation concerns
+
+### Process
+What business or operational processes must change, exist, or be designed before this use case can operate?
+- Upstream and downstream handoffs the use case depends on
+- Approval or review workflows that must exist or be redesigned
+- Operational runbooks, escalation paths, or exception handling
+- Process owners who must actively engage
+
+### Security
+What security controls, policies, compliance requirements, or governance approvals must be in place?
+- Authentication, authorization, and access management
+- Data residency, classification, and handling rules
+- Regulatory, audit, or legal requirements
+- Threat model, privacy impact, or AI governance considerations
+
+### People
+What human roles, skills, availability, and decision-making authority must exist?
+- Subject matter experts, data stewards, and process owners
+- Roles that must be staffed, reassigned, or trained
+- Decision-makers who must sponsor or approve the use case
+- Cross-team or vendor dependencies on named individuals or teams
+
+### Change
+What organizational change, adoption readiness, or enablement must happen for the use case to land?
+- User adoption requirements and change impacts on current workflows
+- Training, communication, and rollout dependencies
+- Change resistance risks specific to this use case
+- Stakeholder alignment gaps that could block launch
+
+## Evidence and Boundary Discipline
+
+Distinguish confirmed dependencies from inferred ones. Label each dependency as:
+
+- **Confirmed** — the team has evidence this dependency exists and its resolution path is understood
+- **Inferred** — the dependency is likely given the use case shape, but not yet validated with the client or stakeholders
+- **Unknown** — the team cannot determine whether this dependency applies without additional discovery
+
+Inferred and unknown dependencies are where delivery risk lives. Surface them explicitly rather than treating the map as complete when those gaps exist.
+
+## Workflow
+
+1. Normalize vague use cases into one-sentence working descriptions before mapping — this anchors the dependency analysis.
+2. Map dependencies per dimension for each use case, drawing on any discovery, notes, or context provided.
+3. Label each dependency as confirmed, inferred, or unknown.
+4. Identify which dependencies are shared across use cases — shared dependencies often represent sequencing opportunities or shared risk.
+5. Flag dependencies that are high-effort, long-lead, or gating for delivery start.
+6. Recommend next validation steps for unresolved dependencies, with suggested owners where possible.
+
+## Output Structure
+
+1. **Use case summary** — one-line description per use case
+2. **Dependency map per use case** — one section per dimension (data, systems, process, security, people, change)
+3. **Cross-use case dependency summary** — shared dependencies, sequencing signals, and consolidation opportunities
+4. **High-priority dependencies** — gating items requiring immediate validation before delivery commitment
+5. **Next steps and validation owners**
+
+Prefer a side-by-side table or matrix format when comparing multiple use cases. Use labeled bullets per dimension when going deep on a single use case. Either way, make the confidence level (confirmed / inferred / unknown) visible throughout.
+
+## Reference Files
+
+- Use [references/dependency-categories.md](./references/dependency-categories.md) for detailed category definitions, discovery prompts, and worked examples per dimension.
+- Use [../use-case-prioritization/references/matrix-pattern.md](../use-case-prioritization/references/matrix-pattern.md) when the dependency output needs to feed a prioritization decision.
+- Use [../risk-assumption-register/references/register-pattern.md](../risk-assumption-register/references/register-pattern.md) when dependency findings should be converted into a formal risk and assumption register.
+
+## Common Pitfalls
+
+### Pitfall 1: Treating Inferred as Confirmed
+
+Bad: listing every likely dependency as a known fact because it seems obvious from the use case description.
+
+Better: label each item with its confidence level and name what would confirm or rule it out. Inferred items should prompt a specific discovery question, not a claim.
+
+### Pitfall 2: Stopping at the First Layer
+
+Bad: noting "we need data from the CRM" without tracing the dependency further — quality, access rights, schema stability, refresh frequency, and governance approval all matter.
+
+Better: trace each dependency to its resolution condition — what would need to be true for this dependency to stop being a blocker?
+
+### Pitfall 3: Ignoring People and Change
+
+Bad: mapping only technical dependencies because data and systems feel more concrete and enumerable.
+
+Better: treat people and change dependencies with equal rigor. The highest-risk delivery blockers are often human, not technical — missing process owners, absent sponsors, or unaddressed change resistance derail pilots just as often as missing APIs.
+
+### Pitfall 4: Generic Lists Without Use Case Specificity
+
+Bad: producing a standard dependency checklist that would apply to any use case.
+
+Better: tie every dependency to the specific use case context, system landscape, and organizational situation the team has described. A dependency map that could apply to any project is not useful.
+
+## Quality Bar
+
+- Every high-priority dependency should have a suggested owner or a note on who would own it.
+- Inferred and unknown items should be clearly visible — they drive the validation plan.
+- The map should be usable in a delivery kickoff, a readiness conversation, or a scoping discussion without modification.
+- Do not produce generic checklists. Ground each dependency in the use case and context provided.

package/.github/skills/use-case-dependency-mapper/evals/evals.json

@@ -0,0 +1,23 @@
+{
+  "skill_name": "use-case-dependency-mapper",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We have three use cases shortlisted from our Jump Start workshop: (1) AI-assisted contract review that flags non-standard clauses for legal, (2) automated invoice matching that reconciles purchase orders in the ERP against received invoices, and (3) a customer churn prediction model that scores accounts weekly and surfaces them to the account management team. Map the data, systems, process, security, people, and change dependencies for each use case so we can decide which to take into Pod delivery first.",
+      "expected_output": "A structured dependency map for all three use cases across all six dimensions (data, systems, process, security, people, change), with each dependency labeled as confirmed, inferred, or unknown. Should include a cross-use case summary identifying shared dependencies, a high-priority dependency section flagging gating blockers, and next steps with suggested owners.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "We're scoping a single use case: an AI assistant that helps field service technicians look up equipment manuals, troubleshooting steps, and parts information using natural language queries on a mobile device. We're going into sprint planning next week. What are the dependencies we need to resolve before we can start building?",
+      "expected_output": "A focused dependency map for the field service AI assistant use case across all six dimensions, with emphasis on gating dependencies that would block sprint start. Should call out data (manual and parts data availability and quality), systems (mobile infrastructure, document storage, vector/search layer), process (technician workflow integration), security (device and data access controls), people (content owners, field ops stakeholders), and change (technician adoption and training). Should produce a clear list of what must be resolved before sprint planning.",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "Here are our discovery notes from a client in the insurance sector. They want to build an automated claims triage system that classifies incoming claims by type and complexity, routes simple claims to straight-through processing, and flags complex or potentially fraudulent claims for human review. Discovery notes: The client has a legacy claims management system (Guidewire) with a REST API. Claims data is stored in a data warehouse (Snowflake). The team has 2 claims operations managers available. The compliance team has not been briefed. There is a union agreement covering claims adjusters. Extract the dependencies and flag which ones are the most critical to resolve before we can commit to a delivery scope.",
+      "expected_output": "A dependency map that uses the discovery notes as confirmed evidence where possible and labels gaps as inferred or unknown. Should surface the union/labor relations dependency under Change as high-priority, the compliance and regulatory dependencies under Security as high-priority, data quality and schema dependencies under Data as inferred, and the Guidewire API details under Systems as partially confirmed. Should produce a clear high-priority dependency section and recommended next steps.",
+      "files": []
+    }
+  ]
+}