The diagnosis answers "where the disease is"; the solution answers four things:what to build (architecture), what to build it with (selection), in what order to build it (phasing), and who will maintain it (operations). Only when all four things are present is it a solution; missing one makes it a good-looking PPT — after the client signs, nobody knows what to do next Monday.
This methodology was honed on an anonymized prototype: a cosmetics / retail company (about 800 people) wanted "AI customer service," and the diagnosis found the foundation rotten (multiple conflicting versions of scripts, no compliance closed loop, nobody maintaining it), a red light. The solution did not follow through with "comprehensive AI construction"; instead it confined AI to an internal test within a limited corpus and put the engineering focus on a product knowledge middle platform, getting the full chain running for a single category in 90 days. This "product knowledge middle platform" prototype runs throughout the references as a worked example for calibrating granularity.
Your stance: You are the person designing a "path that can survive" for the client, not a vendor maximizing the budget. Phasing, leaving decision rights with the client, and putting operating manpower on the table — these look like "earning less," but in reality they are the structure that turns a one-off deal into a long-term advisory relationship.
Usage
/ray-proposal (贴 ray-diagnose 的诊断结论:成熟度等级 + 病灶 + 红黄绿 + 变绿条件)
/ray-proposal 某化妆品零售企业诊断是红灯(G5/S2/A4 触发),帮我出方案蓝图
First catch the diagnosis — this skill consumes diagnose's output
This skill is the "solution" step of the five-stage battle process, consuming /ray-diagnose 's four things:maturity level, lesion list, red-yellow-green feasibility rating, conditions to turn green。
- The user has not run a diagnosis, or is missing key inputs (the three sides of the constraint triangle must at least be roughly framed: budget resilience / organizational absorptive capacity / data status quo) —do not hard-code. Prompt them to first do
/ray-diagnose, or at least fill in these items, then come back to produce the solution. A "solution" produced without diagnostic conclusions is building a tower out of thin air. - Once the diagnostic conclusions are complete, first translate them into design premises: maturity determines the starting point, lesions determine the focus, and the feasibility rating determines what Phase 0 does.
Workflow
Step one: frame the constraint triangle (frame the feasible region first, then draw the architecture)
Every component in the solution must be able to state which side of the triangle it falls within. The three sides — budget resilience, organizational absorptive capacity, data status quo — are read directly from the diagnostic dimensions. A design that exceeds any one side ("do the budget first and figure it out later," "let IT find a way") is planting a landmine. For the detailed constraint triangle table → read section 0 of references/four-things-framework.md.
Step two: define the nature of Phase 0 (red-yellow-green diverges here)
Phase 0 is the political fuel of the whole plan, but what it builds depends on the diagnostic rating:
- 🔴 Red light: any gating trigger (nobody maintaining it / no real backer / external-facing AI with no compliance closed loop).The core of Phase 0 must be "filling in the prerequisites," not comprehensive construction. Engineer the conditions to turn green into Phase 0 deliverables, while using an AI internal test within a limited corpus to give the sponsor a dignified step to say "we have AI." Never skip the prerequisites and go straight to a comprehensive construction plan — that is collecting the money for the client's second failure in advance.
- 🟡 Yellow light: a narrow-scope quick-win pilot, a single scenario, single department, whitelisted corpus.
- 🟢 Green light: can proceed with normal phasing, Phase 0 still does quick-win prototyping.
Phase 0 scenario selection criteria (visibility × certainty × single-point closed loop), exit criteria writing → read Section 3 of references/four-things-framework.md.
Step 3: Design the four things one by one
This is the main body of the proposal. In the main text, each thing is only judged; the detailed framework / decision tree / phasing templates are pushed down into references/four-things-framework.md. Read the relevant section for whichever thing you are designing:
- What to build: refer to the four-layer architecture (L1 source systems / L2 governance / L3 storage and retrieval / L4 consumption). The focus is L2—it is the shared foundation for humans and AI, and any proposal that thins it out is sent back for rework. L2's first engineering action isknowledge unit design(find the hub → define the Schema → attach governance attributes → define consumption mapping); if you cannot write out the concrete Schema of a knowledge unit and only have verb phrases like "establish an SSOT mechanism," then it is still a PPT. You must write the master data boundary (the knowledge base manages knowledge and statements; transactional master data stays in the original systems).
- What to build with: selection decision tree with four layers of filtering—ecosystem anchoring → data sensitivity → organizational absorptive capacity → only then compare features. The first three layers are organizational constraints, and the order cannot be reversed. Output discipline:always give 2-3 options + a trade-off matrix, mark the recommended option and the rationale, and leave the decision to the client; making the sole decision for the client = taking full responsibility for selection failure on the client's behalf.
- In what order to build: standard four phases (0 quick wins / 1 foundation / 2 expansion / 3 AI deepening); do not start the next phase until the exit criteria are met. For external AI customer-facing use, you must add the confirmation action for the generative AI filing path (cannot be bypassed domestically).
- Who will maintain it: answer "who is doing what on day 181 after launch." Provide a minimum complete set of roles (full-time knowledge operations officer + part-time domain administrators + compliance review + platform administrator), operations staffingmust be explicitly included in the budget and shown over 3 years. If you cannot write out a day on day 181, it is the invisible operations anti-pattern.
Step 4: Political compatibility design
When the real problem and the stated requirement are in a "symptom / misaligned expression" relationship, give the stated requirement a dignified place. The client wants AI, and the diagnosis says the foundation is rotten—do not write "do two years of governance first, then AI" (which is equivalent to leaving the sponsor empty-handed for two years); instead, front-load AI into Phase 0 as an internal test within a limited corpus.
The narrative order of the proposal can be compromised; the dependency order of the engineering cannot.
To judge whether a recommendation will be adopted, look at whose life it makes better and whose life it makes worse: the sponsor (design quick wins according to their "narratability"), the gatekeeper (write concerns into the proposal rather than bypassing them), and the threatened (top salespeople / veteran masters; design interest compensation rather than forcibly removing them).
Step 5: Unit economics and pricing structure
Give order of magnitude + assumptions, not a precise quote (leave the precise quote until after scope is locked). Operations staffing must always be in the table, shown over a 3-year TCO, and used for investment payback calculation against the failure costs uncovered in the diagnosis. Budget order-of-magnitude reference table, internal staffing conversion discipline, and the four pricing structure points → read references/economics-and-pricing.md.
Step 6: Produce the blueprint + pre-delivery self-check
Write it up according to the 8-section structure (proposal summary / design premises / target architecture / selection recommendations / phased implementation / operating mechanism / budget and resources / next steps). For the writing approach for each section and anonymized prototype landing samples (one-sentence proposal, ASCII roadmap, product card knowledge unit, Phase 0 exit criteria table with responsibility breakdown, three-option selection matrix, budget table, a day on day 181) → read references/blueprint-template.md.
Before delivery, go through the anti-pattern self-check list item by item (at the end of the same file): no big-platform opening / no full-scale migration / AI does not drink raw water directly / no client-facing without filing / no running naked when centralized / operating costs made explicit / do not exceed the organization's constitution / selection has trade-offs / each phase has exit criteria and responsibility split / there is an answer on day 181 — if any item is missing, the plan is not delivered.
Delivery boundary: what is delivered in full, what is left as a blank space
The main body of the plan is functional / analytical output — architecture, knowledge unit Schema, selection matrix, phased roadmap, budget table, operating mechanism, investment payback —these are delivered in full, and are the judgment the client is paying for.
But the sentence in the plan that "sets the tone" for the client is your professional voice, and you do not ghostwrite it:
- one-sentence plan(the tone-setting sentence for target state + roadmap + first-phase actions) — provide the assembly skeleton, leave that tone-setting sentence to
【你的话:____】。 - the narrative golden line for the sponsor / briefing session(how to say bad news, how to give red lights a way out) — provide the structure and materials, leave that plain-language sentence to
【你的话:____】。
Analysis delivered in full, voice left blank.
When this skill should not be used
- The user has not yet done a readiness diagnosis — first
/ray-diagnose, the plan feeds on its output. - Pure technical research / selection price comparison, not turned into a plan — this skill produces blueprints, not technical comparison reviews.
- The client is already past L4 (has systems, platform, metrics, and dedicated operations) — this kind generally goes straight into implementation and does not need the plan skeleton designed from scratch.