{"id":20964,"plugin_id":"plugins_6aaae97ad4248191891feaa88258c9b1","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:16:41.582Z","digest":"038f1ad99a3d34e43e6cd75e6dc0335298fa4f66fb885e360708821b412b5fa0","against":null,"payload":{"name":"purpose-first-redesign","description":"Redesign an existing software page or workflow when the user grants broad creative freedom and wants to discuss how it should work. Map the page's real purpose, users, data, actions, and downstream flows first; use GitNexus when available. Treat the current layout as evidence, not a constraint, and do not implement until the user asks.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":259}],"skill_md_contents":"---\nname: purpose-first-redesign\ndescription: Redesign an existing software page or workflow when the user grants broad creative freedom and wants to discuss how it should work. Map the page's real purpose, users, data, actions, and downstream flows first; use GitNexus when available. Treat the current layout as evidence, not a constraint, and do not implement until the user asks.\n---\n<!-- Copyright 2026 ArcanEdge AI. Licensed under Apache-2.0; preserve this notice when redistributing. Source: https://github.com/ArcanEdge-AI/intuitive-software-design -->\n\n# Purpose-First Redesign\n\nUse this skill when an existing page may need more than incremental cleanup and the user wants to rethink how it should work before implementation.\n\nThe objective is to design around the user's job, not around the current component tree, database model, or visual layout.\n\n## Required foundation\n\nBefore drafting, read the standard's [design process](../intuitive-software-design/references/intuitive-software-design-standard.md#39-design-process) and [recovery and validation contract](../intuitive-software-design/references/intuitive-software-design-standard.md#recovery-and-validation-contract); they are this workflow's required reading. Apply the contract to the proposed experience: the brief's states and validation items below summarize it, and [the Intuitive Software Design Standard](../intuitive-software-design/references/intuitive-software-design-standard.md) controls if they differ. Read [the examples](../intuitive-software-design/references/examples.md) when they help distinguish task structure from visual treatment, and consult the rest of the standard when a question is not settled here.\n\nThis is a `DESIGN` workflow informed by evidence from an existing product. Existing behavior is observable evidence; the proposed redesign remains a design hypothesis until validated with intended users.\n\n## 1. Establish the redesign frame\n\nIdentify or reasonably infer:\n\n- intended user and relevant domain experience;\n- job the page should help them complete;\n- starting point and successful end state;\n- frequency, consequence, permissions, device, and time-pressure constraints;\n- evidence available and important evidence still missing.\n\nAsk only when a missing fact would materially change the product model. Do not start with components, cards, tables, or visual trends.\n\n## 2. Map the page's real purpose\n\nWhen GitNexus is available and the codebase is indexed, use it before proposing the redesign:\n\n1. Read the repository context and check index freshness.\n2. Query for the page, route, and the user job it supports.\n3. Inspect the primary screen symbol and important callers/callees.\n4. Read relevant process traces.\n5. Verify implementation-relevant findings in current source and tests.\n\nTrace this minimum product map:\n\n```text\nRoute and entry points\n  -> screen composition\n  -> data sources and derived state\n  -> visible and hidden actions\n  -> downstream destinations and workflows\n  -> role and permission gates\n  -> loading, empty, failure, partial, and recovery states\n```\n\nAlso inspect the rendered page when available. Exercise only safe, reversible interactions needed to understand behavior. A screenshot alone does not prove flow, responsiveness, keyboard operation, or recovery.\n\nIf GitNexus is unavailable, stale, or missing the repository, say so and use repository search, source inspection, tests, documentation, and runtime evidence instead. Never invent a process trace.\n\n## 3. Separate purpose from inheritance\n\nWhen domain objects, relationships, or lifecycle meaning are unclear, use [Product Mental Model](../product-mental-model/SKILL.md) to compare the user's inferred concepts with the implementation map. When work crosses actors or external systems, use [Multi-Role Workflow](../multi-role-workflow/SKILL.md) to identify ownership, shared states, and handoff boundaries before proposing structure.\n\nCreate two explicit inventories:\n\n- **Must preserve:** domain contracts, consequential actions, permissions, data requirements, safe recovery, and proven useful behavior.\n- **Free to rethink:** layout, grouping, navigation model, information hierarchy, interaction pattern, progressive disclosure, and visual composition.\n\nTreat the current layout as evidence of what exists, not a requirement for what comes next. Do not preserve a table, card grid, dashboard, wizard, or side panel merely because it is already implemented.\n\n## 4. Define the user's operating loop\n\nDescribe the intended sequence through:\n\n```text\nOrient -> Recognize -> Predict -> Act -> Confirm -> Continue\n```\n\nFor the page, identify:\n\n- the question the user is trying to answer on arrival;\n- the first meaningful action;\n- the information required before acting;\n- the result and feedback after acting;\n- the next useful destination or action;\n- how context, filters, selection, and work survive return or interruption.\n\nInventory meaningful decisions and reduce Decision Density by deferring only choices that can safely wait.\n\nUse [User-Task Walkthrough](../user-task-walkthrough/SKILL.md) to ground this loop in the intended person's knowledge and visible decision cues before proposing the product model. Trace the important existing journey and relevant continuation/recovery, then distinguish it from the proposed journey. Implementation knowledge from the purpose map must not silently become user knowledge.\n\nWhen the page depends on saved work, identity, or a task continuing across devices, platforms, products, or services, use [Connected Experience Design](../connected-experience-design/SKILL.md) for those boundaries. Keep the redesign centered on the user's outcome; do not turn a product map into a request for universal sync or an architecture rewrite.\n\n## 5. Propose the strongest product model\n\nRecommend one coherent direction, not a pile of interchangeable mockups. Include alternatives only when they represent materially different workflows or tradeoffs.\n\nDefine:\n\n- information architecture and primary hierarchy;\n- direct actions and navigation behavior;\n- beginner recognition and expert efficiency;\n- default, loading, empty, pending, success, failure, partial, permission, and recovery states that actually apply;\n- responsive and keyboard interaction contracts;\n- what should remain visible versus progressively disclosed;\n- measurable acceptance criteria.\n\nCreative freedom does not waive evidence discipline. Novelty must reduce operating effort or improve task confidence. Do not state a business rule—timing, price, eligibility, entitlement, or another policy outcome—that the evidence does not establish, even in proposed copy; use a placeholder and list it for confirmation.\n\nFor consequential choices, use [Decision-Support Design](../decision-support-design/SKILL.md). Load [findability](../intuitive-software-design/references/findability.md), [UI language](../intuitive-software-design/references/ui-language.md), or [experience progression](../intuitive-software-design/references/experience-progression.md) only when those concerns affect this redesign.\n\n## 6. Hold a design discussion before implementation\n\nReturn a discussion-ready brief containing:\n\n1. **Purpose map** — what the page owns and where it leads.\n2. **Primary diagnosis** — the earliest broken Intuitive Software Loop stage and main friction source.\n3. **Recommended experience** — how the page should work from arrival through continuation.\n4. **Screen structure** — a concise text wireframe or flow only when it clarifies relationships.\n5. **Key decisions and tradeoffs** — choices that materially affect the product.\n6. **States and recovery** — for each consequential action: the pending, success, failure, and partial states that apply; failure that keeps entered work and choices with a clear way to continue or try again; the branches the evidence names, such as eligibility windows; and a confirmation of the actual resulting state that states only what the evidence establishes.\n7. **Validation** — a functional check of the resulting state and a check with intended users that states their goal without naming the control, plus the observable result that would show the redesign works. Do not invent targets or findings; lagging signals such as support volume only supplement these checks.\n8. **Discussion prompt** — the smallest set of decisions the user should confirm, including every business rule the proposed experience depends on that the evidence does not establish.\n\nDo not edit source, generate implementation files, or launch a build during this discovery/design pass unless the user explicitly asks for implementation in the same request.\n\n## Quality gate\n\nBefore returning, verify that:\n\n- the recommendation follows the user's job rather than technical architecture;\n- GitNexus or the stated fallback evidence supports the purpose map;\n- UI, Flow, and Feel are separated where evidence allows;\n- observations, inferences, and design hypotheses are distinguishable;\n- the current layout has not silently constrained the proposal;\n- necessary risk controls and recovery remain intact;\n- states, recovery, and validation meet the recovery and validation contract;\n- proposed copy states no business rule the evidence does not establish;\n- the result is specific enough to discuss and later implement.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}