Arclight Feasibility Planner

View saved version →

---
name: assess-healthcare-demand
description: Assess local demand, competitors, substitutes, payer context, and referral access for a proposed U.S. healthcare service using public or aggregate information. Use for market and access questions within healthcare feasibility planning.
---

# Assess demand and access

Read [working rules](../../references/working-rules.md) and the relevant [source guidance](../../references/sources-and-fees.md).

Define geography by actual reach: drive-time bands/route opportunities for mobile services, travel access and referral patterns for fixed sites. Clearly label town-center estimates; do not claim isochrones or verified routes without mapping evidence. Separate near/core/outer scenarios.

Build a demand funnel with compatible denominators: relevant population → service need → clinically appropriate and payer-eligible population → geographic reach → referral access → uptake. Use only necessary non-overlapping factors. State whether each figure is a prevalence stock, annual incident flow, unique patients, or episodes. Never multiply prevalence by annual visits without an explicit care-pattern assumption.

Favor aggregate actual referrals and completed visits over unsupported market share. Distinguish patient beneficiaries, referring professionals, payer, and organizational decision maker. Identify substitutes, including existing clinics, hospital services, home health, facility staff, and travel to another area. Record service, location, payer acceptance, capacity/wait evidence, and verification date; missing evidence is not absence of competition.

Prepare a short interview plan without contacting anyone: ask what happened to recent referrals, which patients could not access care and why, current alternatives, observed waits, rejected payers, and approximate aggregate volume. Do not treat statements of hypothetical interest as committed referrals.

Produce a demand/alternatives table, downside/base/upside reachable-patient scenarios, an encounter translation with explicit units, and the three to five assumptions most worth validating. Pass unconstrained demand to operations; do not equate demand with deliverable volume. If the user only wants a market screen, stop there rather than generating an unsupported financial forecast.

Referenced files: 1

View saved version →

---
name: define-healthcare-service
description: Scope a U.S. healthcare service feasibility study or practice expansion, establish its assumptions, and coordinate demand, payment, operations, financial, and pilot planning. Use for a full feasibility request or an unclear service concept.
---

# Define a healthcare service

Read [working rules](../../references/working-rules.md). Use the information already supplied before asking questions.

Establish the decision, service, geography, delivery setting, clinician roles, payer scope, planning year, existing-practice versus standalone context, and investment or access objectives. Ask the most consequential missing questions together. Do useful preliminary work while uncertain inputs remain clearly marked.

Create a one-page service definition and [assumption register](../../assets/assumption-register.csv). Define annual unique patients, episodes, visits, and active census separately. Identify resources already available and what capacity they can absorb. Separate a clinic's economics from those of an outside implementation/service company. A public-health access objective may require an explicit subsidy scenario rather than an assumed profit objective.

For a full study, follow the applicable workflow references in order; do not require the user to invoke six skills individually:

1. [Assess demand](../assess-healthcare-demand/SKILL.md): demographics, alternatives, referral access, reachable activity.
2. [Plan payment assumptions](../plan-healthcare-payment/SKILL.md): official-resource guidance and amount provenance.
3. [Design operations](../design-healthcare-operations/SKILL.md): capacity, service patterns, labor, equipment, routes/rooms.
4. [Model finances](../model-healthcare-finances/SKILL.md): unit economics, constrained activity, cash and scenarios.
5. [Decide and pilot](../plan-healthcare-pilot/SKILL.md): recommendation, validation priorities, implementation conditions.

Read only the references needed for a narrower request. When mobile wound care is the user's service, consult the [worked example](../../references/mobile-care-example.md) for method, never as local market or clinical evidence. Write the executive recommendation after the analysis using the [decision brief](../../assets/decision-brief.md). Deliver preliminary findings even if a missing input prevents a final recommendation, and state which input would change the decision.

Referenced files: 1

View saved version →

---
name: design-healthcare-operations
description: Model staffing, travel or room capacity, equipment, supplies, and incremental operating costs for a healthcare service expansion or startup. Use when operational constraints or labor costs drive a feasibility decision.
---

# Design operations and capacity

Read [working rules](../../references/working-rules.md). Establish care patterns from qualified clinical input; label unvalidated hypothetical patterns. Exclude routine encounters furnished by other organizations from this service's visits, cost, and revenue unless it actually furnishes and bears them.

Use mutually exclusive encounter profiles for different service combinations. Multiple service lines during one encounter consume encounter time once; combine them into a profile with separately justified payment assumptions rather than counting two visits. Use completed encounters consistently and account for cancellations in capacity or demand once.

Calculate workable clinician minutes after administrative/nonclinical duties, leave, training, and other commitments. Per-encounter minutes include care, documentation, travel/turnover, and appropriate allowances. For a fixed site, separately check room/device bottlenecks. For mobile care, model actual route clusters, travel minutes and miles, facility access, and lost throughput. Do not substitute mileage cost for travel time.

Prepare an itemized cost ledger: clinician compensation, employer burden or contractor terms, supplies, mileage, equipment/maintenance, billing, insurance, software, scheduling, and other genuinely incremental costs. BLS wages need local recruiting validation and applicable benefits/taxes. A salaried clinician's paid time belongs in fixed costs, while incremental per-visit compensation belongs in variable costs; do not put the same labor in both. Already available staff may have no new cash cost but still have opportunity costs and limited capacity.

Identify growth steps: extra scheduler hours, clinician sessions, vehicles, rooms, or equipment. Compare separate scenarios across each capacity/cost threshold. Show capital outlay, recurring operating costs, and accounting depreciation separately. If product waste is modeled, define whether waste is a percentage of purchased or used units; those denominators imply different cost formulas.

Return staffing and capacity tables, cost assumptions with quotes/proxies, constrained visit forecasts, and the binding bottleneck. For the packaged calculator, convert verified operational constraints into monthly available minutes; if a room or another resource binds first, use the corresponding conservative equivalent capacity or an expanded independently checked model. Explain the simplification.

Referenced files: 1

View saved version →

---
name: model-healthcare-finances
description: Calculate healthcare service unit economics, capacity-constrained volume, operating results, delayed collections, and startup funding with explicit assumptions. Use for financial feasibility, break-even, cash-flow, and expansion-versus-startup comparisons.
---

# Model healthcare finances

Read [working rules](../../references/working-rules.md) and the [calculator specification](references/calculator.md). Input facts, proxies, and scenarios must remain distinguishable in the [assumption register](../../assets/assumption-register.csv).

Use `scripts/feasibility_model.py` with a new user-workspace JSON input when Python execution is available. It is standard-library-only and makes no network calls. Follow the schema in the specification and use `assets/synthetic-mobile-care.json` only as a structurally complete synthetic example. Execute with `python <skill-folder>/scripts/feasibility_model.py <input.json> --output-dir <new-output-directory>`. Confirm successful execution and inspect `summary.json`, `monthly.csv`, and `service-economics.csv` before citing results. Do not claim an executed result when only a formula was supplied.

Model collected revenue per completed encounter using an explicit amount basis, then deduct direct variable costs and billing fees. Apply demand and capacity consistently before computing totals. Show first-year expected earned collections separately from cash received, year-end receivables, recurring operating result, prelaunch expenses, capital spending, and cash funding needs. The helper reports a planning estimate, not GAAP statements or a payment prediction.

Compare coherent downside/base/upside and existing-practice/standalone scenarios. Include a no-expansion baseline where relevant. Preserve service mix and resource constraints in break-even analysis; negative contribution has no volume-only remedy. Fixed-cost and capacity steps require distinct scenarios. Check the helper's monthly break-even qualification rather than presenting it as an exact launch-year recovery target.

Keep downstream clinic contribution separate from direct service economics and include only clinically appropriate, sourced assumptions with associated costs and available capacity. Model a service company's expenses/fees independently. Do not count a management fee as both eliminated clinic cost and new outside revenue. Use a separate expanded model for debt, taxes, grants, inventory/vendor timing, multi-year forecasts, or multiple constrained resources; state limitations if these determine the recommendation.

Deliver editable inputs, executed outputs or clearly unexecuted formulas, source/assumption register, key sensitivities, and a concise explanation of what changes the decision. Do not overwrite source inputs, silently fill unknowns with zero, or equate a positive scenario with a recommendation to invest.

Referenced files: 4

View saved version →

---
name: plan-healthcare-payment
description: Build numerical healthcare payment and collection assumptions using official fee-schedule guidance, provenance, payer context, and user-supplied amounts. Use for feasibility reimbursement planning; this is not a code lookup, coding recommendation, or coverage determination.
---

# Plan payment assumptions

Read [working rules](../../references/working-rules.md) and [sources and fees](../../references/sources-and-fees.md), including the guided-lookup and rights boundaries.

Guide the user to the applicable official fee-schedule resource. The user or billing specialist performs code selection and any licensed lookup there; bring back numerical amounts and metadata using [payment assumptions](../../assets/payment-assumptions.csv). Do not bundle, retrieve in bulk, import, or reconstruct a CPT catalog, descriptors, or code crosswalk. This workflow remains useful when the amount is unknown: identify the missing lookup and compare explicitly hypothetical amounts.

For each original service label, record payer, year, location, setting, clinician, rate source, amount basis, adjustments already applied, and the coverage/billing dependencies. Separate fee-for-service, private payer contracts, capitation, and bundled payment. A per-visit model is inappropriate for capitation unless a separately explained allocation is merely an analytical scenario.

Build the collection waterfall using explicit assumptions. Do not automatically discount product payment by a clinician payment percentage. Do not confuse claim-payment probability with payer cost-sharing. Denials ultimately recovered belong in both the appropriate probability and timing, without double counting the same loss. If only net collected revenue per encounter is provided, model it as that basis and do not apply the payment waterfall again.

Deliver a sourced amount matrix, a collection/timing explanation, and unresolved eligibility or contract questions. A fee-schedule listing never establishes medical necessity, coverage, permissible same-day combinations, or profitability. Do not choose treatments or encounter frequency to achieve financial goals.

Referenced files: 1

View saved version →

---
name: plan-healthcare-pilot
description: Turn a healthcare service feasibility analysis into a decision brief, validation priorities, and a pilot with measurable proceed, narrow, or stop conditions. Use after a model or when deciding what evidence to gather before investing.
---

# Decide and design a pilot

Read [working rules](../../references/working-rules.md). Use the completed assumptions and outputs; do not invent missing analysis or pretend that a report proves demand.

Explain whether the evidence supports proceeding, narrowing the scope, testing a pilot, deferring, or stopping. Separate the value of solving an access gap from the ability to fund the proposed operation. Include a smaller geographic/service scope or doing nothing as a relevant alternative.

Rank uncertainties by their ability to reverse the recommendation and the effort needed to resolve them: referral access, payer eligibility/collections, recruitment, route throughput, equipment costs, or working capital. For each, state the available evidence, missing observation, proposed validation method, decision threshold, and next decision. Owners and deadlines are proposed unless agreed.

Design a bounded pilot using aggregate measures: actual inquiries/referrals, eligible referrals, scheduled/completed encounters, clinician time, miles, route density, costs, claims paid, collections lag, cash, and relevant aggregate quality/access measures selected by clinical leadership. Cohorts must mature before drawing conclusions about collections or outcomes. Avoid patient-level data and invented clinical targets. Do not reward unnecessary downstream procedures or referrals.

Use [decision-brief.md](../../assets/decision-brief.md) for a full report. A short decision request may need only the recommendation, supporting scenario table, and next validation steps. Provide the useful result without an unsolicited service pitch. Record whether calculation, source review, local validation, or real-world pilot execution actually occurred.

Referenced files: 1