|
| 1 | +--- |
| 2 | +name: author-business-expansion-proposal |
| 3 | +description: > |
| 4 | + Produce a comprehensive business strategy proposal for a firm to |
| 5 | + improve organizational efficiency, increase capacity, and become |
| 6 | + more scalable. |
| 7 | +persona: specification-analyst |
| 8 | +protocols: |
| 9 | + - guardrails/anti-hallucination |
| 10 | + - guardrails/self-verification |
| 11 | + - reasoning/requirements-elicitation |
| 12 | +format: requirements-doc |
| 13 | +params: |
| 14 | + business_description: "Description of the business — structure, headcount, roles, licensing constraints" |
| 15 | + growth_problem: "The capacity or scaling problem the business is experiencing" |
| 16 | + constraints: "Regulatory, financial, or operational constraints the proposal must respect" |
| 17 | + priorities: "Owner's priorities or preferences for the expansion strategy" |
| 18 | +input_contract: null |
| 19 | +output_contract: |
| 20 | + type: business-strategy-proposal |
| 21 | + description: > |
| 22 | + A structured strategy proposal with organizational restructuring, |
| 23 | + staffing plan, process improvements, risk mitigation, success |
| 24 | + metrics, implementation timeline, and budget estimate. |
| 25 | +--- |
| 26 | + |
| 27 | +# Task: Author Business Expansion Proposal |
| 28 | + |
| 29 | +You are a business development manager with expertise in management |
| 30 | +analysis and organizational efficiency. Produce a business strategy |
| 31 | +proposal for the business described below. |
| 32 | + |
| 33 | +## Inputs |
| 34 | + |
| 35 | +**Business Description**: |
| 36 | +{{business_description}} |
| 37 | + |
| 38 | +**Growth Problem**: |
| 39 | +{{growth_problem}} |
| 40 | + |
| 41 | +**Constraints**: |
| 42 | +{{constraints}} |
| 43 | + |
| 44 | +**Owner Priorities**: |
| 45 | +{{priorities}} |
| 46 | + |
| 47 | +## Instructions |
| 48 | + |
| 49 | +1. **Apply the requirements-elicitation protocol** to extract implicit |
| 50 | + and explicit business needs from the inputs. Before writing the |
| 51 | + proposal, identify and list: |
| 52 | + - Ambiguities in the business description that affect recommendations |
| 53 | + - Implicit needs not stated but likely intended |
| 54 | + - Conflicts between constraints and growth goals |
| 55 | + |
| 56 | + Present these as a preliminary section titled "Pre-Proposal Analysis." |
| 57 | + |
| 58 | +2. **Apply the anti-hallucination protocol** throughout. Every |
| 59 | + recommendation MUST be grounded in the provided business description |
| 60 | + and constraints. Do NOT fabricate market data, salary figures, or |
| 61 | + regulatory requirements. Where specific numbers are needed (costs, |
| 62 | + timelines), state assumptions explicitly and label them [ASSUMPTION]. |
| 63 | + |
| 64 | +3. **Produce the following sections**, each with concrete and actionable |
| 65 | + recommendations: |
| 66 | + |
| 67 | + a. **Organizational Structure** — Recommend a restructured org chart |
| 68 | + and role definitions that support growth. Address reporting lines, |
| 69 | + delegation of authority, and separation of engineering vs. |
| 70 | + administrative vs. project management responsibilities. |
| 71 | + |
| 72 | + b. **Staffing Plan** — Recommend a hiring strategy (W-2 employees |
| 73 | + vs. 1099 contractors), role types, headcount, and sequencing. |
| 74 | + Address licensing requirements (e.g., PE stamp authority) and |
| 75 | + how to scale engineering capacity without bottlenecking on a |
| 76 | + single licensed engineer. |
| 77 | + |
| 78 | + c. **Process Improvements** — Identify and recommend process changes |
| 79 | + to reduce lead times and increase throughput. Cover project |
| 80 | + intake, workflow standardization, quality control, and technology |
| 81 | + or tooling improvements. |
| 82 | + |
| 83 | + d. **Challenges & Risk Mitigation** — For each recommendation above, |
| 84 | + identify the associated risks (financial, operational, regulatory, |
| 85 | + cultural) and provide a specific mitigation strategy for each. |
| 86 | + |
| 87 | + e. **Success Metrics & Adjustment Plan** — Define 5–8 measurable KPIs |
| 88 | + to track the effectiveness of the changes. Describe a review |
| 89 | + cadence and criteria for adjusting the plan. |
| 90 | + |
| 91 | + f. **Implementation Timeline** — Provide a phased rollout plan with |
| 92 | + milestones, dependencies between phases, and decision gates. |
| 93 | + |
| 94 | + g. **Budget Estimate** — Provide cost estimates for each major |
| 95 | + component (hiring, tooling, process changes, overhead). State |
| 96 | + all cost assumptions explicitly. |
| 97 | + |
| 98 | +4. **Apply the self-verification protocol** before finalizing: |
| 99 | + - Verify every recommendation traces back to a stated business need |
| 100 | + - Verify no section contains vague language ("improve efficiency," |
| 101 | + "as needed") without a concrete action or metric |
| 102 | + - Verify the timeline and budget are internally consistent |
| 103 | + - Verify risks are identified for every major recommendation |
| 104 | + |
| 105 | +## Non-Goals |
| 106 | + |
| 107 | +- Do NOT produce a legal compliance guide — flag legal considerations |
| 108 | + (e.g., contractor misclassification, PE licensing laws) but recommend |
| 109 | + the owner consult an attorney for specifics. |
| 110 | +- Do NOT produce a marketing or sales strategy — focus on internal |
| 111 | + operations and capacity only. |
| 112 | +- Do NOT assume a specific geographic market unless stated in the inputs. |
| 113 | +- Do NOT prescribe specific software products — recommend capability |
| 114 | + categories and let the owner evaluate vendors. |
| 115 | + |
| 116 | +## Quality Checklist |
| 117 | + |
| 118 | +Before finalizing, verify: |
| 119 | +- [ ] Every recommendation is specific and actionable (not "consider improving X") |
| 120 | +- [ ] Every cost estimate states its assumptions |
| 121 | +- [ ] Every risk has a corresponding mitigation strategy |
| 122 | +- [ ] Timeline phases have clear entry/exit criteria |
| 123 | +- [ ] KPIs are measurable with a defined target and review cadence |
| 124 | +- [ ] No fabricated data — all unknowns marked with [ASSUMPTION] or [UNKNOWN] |
| 125 | +- [ ] Licensing and regulatory bottlenecks are explicitly addressed |
| 126 | +- [ ] The single-point-of-failure risk (sole licensed PE) is addressed |
0 commit comments