The Chain of Thought

Each link becomes a tagged message, and the handover is explicit: wrap the previous answer in a tag like <swot_analysis> and put the new instruction last, since the final instruction is what gets followed most reliably. That makes the chain robust even across sessions - you can start Link 3 in a fresh chat as long as the earlier output is in a tag. For a chain you return to, a Project holds the shared brief so every link inherits it without restating, and Artifacts are the right home for the link where a real document or script appears.

• Wrap the previous link's output in its own tag.
• New instruction always last, reference material first.
• Carry forward only what this link needs.
• Keep the shared brief in a Project, not in every link.
• Ask for an Artifact at the link that produces a document.

**Why a chain here:** three different specialists, and your approval needed between each. Send as three messages. Put the shared brief in a Project so you do not retype the business idea at every link.

---

**LINK 1 - THE FOUNDATION**

<role>
A market research analyst.
</role>

<business_idea>
A home-delivery service for authentic, home-cooked Hyderabadi meals, aimed at busy professionals in Gachibowli.
</business_idea>

<task>
A SWOT analysis of this specific concept. Three to four points per quadrant.
</task>

<constraints>
- Concrete to this business in this location. Anything that would be equally true of a food delivery startup anywhere does not belong.
- Under Threats, name the cloud kitchens and quick-commerce players already operating in Gachibowli.
- End with one line: which single Weakness kills this business first if unaddressed.
</constraints>

---

**LINK 2 - THE FIRST FLOOR**

<swot_analysis>
[Paste the SWOT from Link 1 here - this is reference material, not an instruction]
</swot_analysis>

<role>
A marketing strategist.
</role>

<task>
Three distinct channels to reach busy professionals in Gachibowli, each built on a specific Strength or Opportunity from the SWOT above.
</task>

<for_each_channel>
- How it works in practice.
- Which SWOT point it exploits, named.
- Rough monthly cost in rupees.
- How I know within four weeks whether it works.
</for_each_channel>

<constraints>
The three must differ in kind, not be three variants of Instagram. At least one should work because of where this business is - the office parks, the tech campuses - rather than being something any food brand anywhere could run.
</constraints>

---

**LINK 3 - THE SECOND FLOOR**

<marketing_channels>
[Paste the three channels from Link 2 here]
</marketing_channels>

<role>
A financial planner.
</role>

<task>
A six-month marketing budget across the three channels above. Month-by-month table in rupees, with the reasoning for each split. Front-load testing; shift spend toward whatever the Link 2 success measures would surface.
</task>

<also_give_me>
1. The total, and what it assumes about order volume.
2. The cheapest version that still tests all three channels - what I need if I start small.
3. Which figures are estimates you cannot verify.
</also_give_me>

<how_to_handle_uncertainty>
Delivery commissions, Hyderabad ad costs and acquisition costs move constantly and you are working from training data, not a price list. Do not present a recalled figure as current. Mark every number as either arithmetic from my inputs or an estimate I must verify, and say which quotes I should get before committing.
</how_to_handle_uncertainty>

**Why a chain here:** the chapter is built on the character, so the character has to be right before a word of prose exists. Three messages.

---

**LINK 1 - CHARACTER CREATION**

<role>
My creative writing partner.
</role>

<premise>
A detective novel. He is a disgraced former police officer in Hyderabad, now a private investigator.
</premise>

<task>
A detailed character profile: name, backstory, what the disgrace was and whether he deserved it, his motivation now, his greatest flaw.
</task>

<constraints>
- The flaw must create plot rather than describe him - something that will make him do the wrong thing at a specific moment.
- Make the disgrace more interesting than a bribe.
- Three small physical specifics: what he eats, what he drives, where he sleeps. These are what put a character on the page.
</constraints>

---

**LINK 2 - PLOT OUTLINE**

<character_profile>
[Paste the profile from Link 1 here]
</character_profile>

<task>
A five-point plot outline. He is hired to find a missing piece of the Nizam's jewellery; the trail leads into the city's old smuggling underworld.
</task>

<constraints>
- For each beat: what happens, and what it costs him.
- His flaw, as established above, must be why the middle of the story goes wrong. An outline that would work with any detective in it is not using the character we built.
- Before I commit: tell me which of the five beats is weakest.
</constraints>

---

**LINK 3 - WRITING THE OPENING**

<character_profile>
[Paste the profile here]
</character_profile>

<plot_outline>
[Paste the outline here]
</plot_outline>

<task>
Write the opening chapter, roughly 700 words, as an Artifact.
</task>

<requirements>
- Introduce him in his element and arrive at the inciting incident from the outline.
- Use at least two of the physical details from the profile. Show them; do not list them.
- Hyderabad in the specifics, not in the adjectives.
- An Artifact because this is the one link producing something I will revise line by line rather than read once.
</requirements>

<note>
The reference material comes first and the instruction last on purpose. A 600-word character profile pasted above a one-line request is the right order; put the request first and the profile starts reading like a new brief.

**Why a chain here:** pseudocode you can read is logic you can check. Three messages.

---

**LINK 1 - THE LOGIC**

<task>
Settle the logic for a Python script. No code yet.
</task>

<requirement>
A function taking a list of website URLs. For each, try to connect. On success - HTTP 200 - the URL goes on a "successful" list. On failure, onto a "failed" list.
</requirement>

<output_format>
Numbered plain-English pseudocode.
</output_format>

<then>
Before I approve it, list what I have not specified: what counts as failure besides a non-200 status, whether there is a timeout, what happens on a redirect, whether a 301 or a 403 is success for my purposes. Those belong in the pseudocode, not discovered later in a stack trace.
</then>

---

**LINK 2 - THE CODE**

<approved_pseudocode>
[Paste the pseudocode from Link 1 here]
</approved_pseudocode>

<task>
Translate exactly the pseudocode above into a working Python script, as an Artifact.
</task>

<constraints>
- Use the requests library.
- A comment above each block naming which numbered pseudocode step it implements, so I can check the translation rather than just read the code.
- Set a timeout; say what value and why.
- Nothing beyond the pseudocode. No logging framework, no concurrency, no config file.
</constraints>

<how_to_handle_uncertainty>
If you think the script needs something we did not specify, write it underneath as a note rather than adding it to the code. An unrequested addition inside the script is the thing I will not notice.
</how_to_handle_uncertainty>

---

**LINK 3 - THE REFINEMENT**

<current_script>
[Paste the script, or edit the Artifact in place]
</current_script>

<task>
Add error handling.
</task>

<requirements>
- try/except catching requests.exceptions.RequestException, printing a clear message naming the URL and the failure.
- A failed URL lands on the failed list with its reason rather than vanishing.
- One bad URL must not stop the rest of the list.
</requirements>

<then>
What would still break it: an empty list, a malformed URL that fails before the request is made, a server that accepts the connection and never responds. For each, whether the current code survives. That list is worth more than the error handling - it tells me which failures I have actually covered and which I only think I have.
</then>