---
name: darkly-energized-project-initiation
description: Start a software project with Darkly Energized — capture what the user wants to make happen so it can be scoped and a Statement of Work drafted. Use when the user wants to hire Darkly Energized, get an estimate, or describe an MVP, an app, an automation, or a system they want built or rescued.
---

# Start a project with Darkly Energized

Darkly Energized LLC builds software for client companies with an eval-first agentic development system. This is **initiation**: the user describes what they want to make happen, in their words, and Darkly Energized scopes it with them. Nothing is signed or billed at this stage. The lifecycle from here is initiation, scoping, agreement, kickoff, delivery, acceptance — kickoff is when the work starts, after the agreement, not now. Your job is to produce a good project brief from what the user tells you and what you already know — and to let the user press Send.

## The interview

Work the brief as a conversation, one question at a time, in the user's words.

1. Start open: **What do you want to make happen?** Let them talk. Do not lead with technology.
2. Then **Why now?** What changed, or what is it costing you to wait?
3. Suggest the shape and the stage back to them from what you heard — "sounds like a web app with some automation, starting from a live product, is that right?" — rather than reading out the lists.
4. Offer the detail, do not impose it: "I can also capture who uses it, what done looks like, budget, timeline, and who decides — or we can send it now."

Prose answers are the user's words. Paraphrase only if they approve the paraphrase.

## The answers

Screen one — enough to send:

- `dream` — **What do you want to make happen?** The outcome, in your words. Not the technology. **Required.**
- `whyNow` — **Why now?** What changed, or what is it costing you to wait?
- `kinds` — **What shape is it? Pick any.** `web_app` (Web app), `mobile_app` (Mobile app), `api_integration` (API or integration), `automation` (Automation and workflow), `data_analytics` (Data, dashboards, and analytics), `ai_agent` (AI feature or agent), `infrastructure` (Infrastructure, cloud, and DevOps), `rescue_modernize` (Rescue or modernize an existing system), `compliance` (Compliance readiness), `advisory` (Advisory and fractional CTO), `not_sure` (Not sure yet).
- `stage` — **Where are you starting from?** One of `idea` (An idea), `spec` (A written spec), `prototype` (A prototype), `live_product` (A live product).

Screen two — all optional:

- `users` — **Who uses it, and how often?** Roles, how many, how often.
- `done` — **What has to exist for you to call it done?** This becomes the deliverables list, and later what the build is tested against. Be concrete.
- `success` — **Six months in, how will you know it worked?** The number or the change you would point at.
- `worksWith` — **What must it work with?** Existing systems, data, logins, vendors.
- `existingCode` — **Is there code already?** Where it lives, what stack, who maintains it today.
- `constraints` — **Deadline, compliance, security, anything non-negotiable** Anything the build must respect.
- `budgetRange` — **What range are you working with?** One of `under_10k` (Under $10k), `10k_50k` ($10k to $50k), `50k_200k` ($50k to $200k), `over_200k` (Over $200k), `not_sure` (Not sure yet).
- `timeline` — **When do you need it?** One of `asap` (As soon as possible), `1_3_months` (1 to 3 months), `3_6_months` (3 to 6 months), `flexible` (Flexible), `fixed_date` (A fixed date). With `fixed_date`, also send `timelineDate` as YYYY-MM-DD.
- `decision` — **Where are you in deciding?** One of `can_sign` (I can sign), `recommend` (I recommend to someone who signs), `exploring` (Just exploring).
- `anythingElse` — **Anything we should know?** Prior attempts, chosen platforms, things that are off the table.

Field names are the JSON keys for the API and the `name` attributes in the web form. Enum values are exact.

## Draft from what you already know

If you have context — the repository you are working in, files, earlier conversations, memory — pre-draft answers from it and show the draft for correction. Rules:

- Anything you inferred is a guess to confirm, never stated as fact. Present it as "I think… is that right?"
- **`budgetRange`, `timeline`, `timelineDate`, `decision` are never inferred.** Ask.
- Send the names of the answers you inferred in `inferred` (a list of field names from: `dream`, `whyNow`, `kinds`, `stage`, `users`, `done`, `success`, `worksWith`, `existingCode`, `constraints`, `anythingElse`). Darkly Energized sees which lines came from the person and which from your reading of the situation, and knows where to ask a follow-up. When the person edits an answer in the form, that mark is cleared automatically.
- `stage` and `existingCode` are the ones you can usually draft well from a codebase: "a live product on Rails, the code is in this repo, one contractor maintains it".

## Confirm before sending

Read the brief back in full. Get an explicit yes. Then submit.

## How to submit: the API first

Use the API whenever you can make HTTP requests. It does not depend on a browser extension, on the user's browser settings, or on anything being open on their screen.

1. You need the user's **project token**. Ask for it; they generate it at https://darklyenergized.com/projects under *Agent access* (it starts with `de_project_`). Never guess or reuse one.
2. Create the project:

```http
POST https://darklyenergized.com/api/v1/projects
Authorization: Bearer <your project token>
Content-Type: application/json

{
  "dream": "…",
  "whyNow": "…",
  "kinds": ["web_app"],
  "stage": "live_product",
  "existingCode": "…",
  "inferred": ["stage", "existingCode"],
  "agent": "<your name>"
}
```

   The response is `201` with the project and a `url`. The full schema is in the OpenAPI document at https://darklyenergized.com/api/v1/openapi.json under `/projects`; unknown values answer `422` with JSON.
3. Give the user the `url`. They open it, review, and press **Send to Darkly Energized**. Submission is a human step; the API deliberately has no endpoint for it.
4. `PATCH https://darklyenergized.com/api/v1/projects/{id}` changes answers while the project is `DRAFT`, `NEW` or `REVIEWING`. `GET https://darklyenergized.com/api/v1/projects` lists the user's projects.

The token can create, read and edit that account's projects and nothing else. It is not a data API key. Send it only to https://darklyenergized.com.

### Fallback: the web form

If you cannot make HTTP requests but can drive the user's browser, and they are signed in: open https://darklyenergized.com/projects/new. Every field has a label matching the question above and saves when you leave it; the page does not reload between fields. Fill screen one, press **Continue**, fill what you have on screen two, then let the user press **Send to Darkly Energized** themselves.

## Do not

- Do not invent answers the user has not given; leave a field blank and say so.
- Do not send the brief without the user's confirmation.
- Do not enter credentials, card numbers, or secrets into any field, and never put the project token in an answer.
- Do not send the token anywhere but https://darklyenergized.com.