Kiuyan Wong / Bloomberg:
Hong Kong grants its first stablecoin issuer licenses to HSBC and Standard Chartered from a pool of 36 applicants; they are set to issue stablecoins in H2 2026  —  Hong Kong has granted its inaugural stablecoin issuer licenses to HSBC Holdings Plc and a joint venture of Standard Chartered Plc …

Bloomberg:
Documents: Shenzhen-based computing company Sharetronic bought hundreds of Super Micro systems containing banned Nvidia H100 and H200 chips in 2025, worth ~$92M  —  Hours after the United States charged a Super Micro Computer Inc. co-founder with illegally smuggling billions of dollars' worth …

I’m not good at blank canvases. Unfortunately that’s where feature specs always start. When I have a bunch of notes, transcripts, screenshots, and ideas to consolidate on an empty piece of paper, it can be hard to get going and stay in flow.

I write specs in three steps:

1. Collect all input
2. Consolidate a cohesive list of requirements
3. Review & edit

Lately, I’ve added a few tools to my workflow to guide me through the process.

Collecting input

First, I gather every piece of input I can find: my own notes, Slack threads, Linear tickets… One of my most useful resources is Granola, which transcribes and summarizes every meeting I have. I organize projects into folders there, and before writing a spec, I’ll ask Granola to pull together everything it knows about the topic.

(All snippets in this post are based on the output I had writing a spec yesterday. I can't share it since it's client work, but I've reworked the examples to revolve around an invoice builder feature.)

Give me a detailed list of specifications of everything you know of the invoice builder.

I also use Monologue, a voice-to-text tool for Mac and iOS, to add extra ramblings.

Consolidating everything with a thinking model

Once I have everything in one place, I open my coding agent and attach everything. (Currently defaulting to Codex GPT 5.4 High for these kinds of tasks.)

A few things I’ve learned to always include in the prompt:

• Be explicit about who the spec is for. A spec for a designer should focus on UI patterns and how the feature fits existing conventions in the app. A spec for a developer should go deeper on the data model, potential abstractions, and how this interacts with existing parts of the system.
• Ask to compare notes and surface discrepancies. Notes accumulated over months are full of contradictions. One meeting says to build it one way; another says something different. I ask the model to flag these and grill me on them until the ambiguity is resolved.
• Ask to explicitly list what is in & out of scope. As I read notes I often skim over things that are implicitly out of scope for the project. But what I consider out of scope, someone else might have assumed was part of the project. AI is good at being critical about these small details.
• Reference the codebase. Look at what already exists for patterns we could reuse, and identify potential pitfalls based on existing functionality.

Some of these checks might seem obvious, but the more explicit you are towards the agent about your own process, the better your results.

If all goes well, you’ll be slammed with a few rounds of questions by the agent to refine the requirements and generate a final specification document.

This was my prompt yesterday:

I want to write a specification document for our designer to determine the UI and UX of the invoice builder. I want you to read all three documents I gave you. Grill me about anything that is unclear about the features or things across the document or even in the same document that contradicts each other. Grill me about anything that seems related to invoicing that is listed in documents but might not be part of this feature so we can decide to leave them out of the specs for now. Let's build a specification document together. Also look through the existing codebase and interface to understand the way products are set up and research potential pitfalls we could have implementing this in the existing system.

(text-to-speech, who needs newlines?)

Here’s a snippet of the output:

# Invoice Builder UI/UX Spec

## Purpose

Define the UI and UX for configuring and reviewing invoice templates, line items, and tax calculations within the invoice builder.

This document covers three surfaces:

- Organization-level setup
- Invoice-level review and override
- Discrepancy review and bulk reapply

This document is intended for product, design, and engineering alignment. It describes the behavior the interface must support, not the technical implementation details.

## Scope

### In scope

- Organization-level setup of tax rules, line item defaults, and payment terms
- Invoice-level display of the itemized breakdown associated with an order
- Invoice-level snapshotting from the organization template
- Invoice-level manual editing after snapshotting
- Visibility rules for clients, bookkeepers, and admins
- Discrepancy review UI for tax rate and line item drift
- Batch reapply flow from the current organization template to selected invoices

### Out of scope

- Payment processing or reconciliation
- Refunds
- Revenue recognition timing or accrual logic
- Report-generation workflows beyond discrepancy review
- Currency-specific tax logic
- Arbitrary reusable custom pricing objects
- Auditing payment term discrepancies

## Core Concepts

### Tax Calculation

Tax calculation is the applicable tax percentage for an organization in a given region or jurisdiction scope.

- Tax calculation belongs on the organization as a template
- Tax calculation is copied to the invoice when the invoice is created
- After the invoice is created, the invoice tax calculation is managed independently
- Clients should always be able to see their own tax breakdown
- Seeing the tax details of others requires a specific permission, which in practice is reserved for bookkeepers and admins
…

The content looks good on first sight but I don’t like the way it’s structured & formatted. Time to edit.

Reviewing & editing

At this point, I take a break from the AI tooling and re-read and edit everything in iA Writer. Most importantly, I ensure everything is correct & complete. Then I ensure the document is generally structured the way I want it to flow, cut noise & repetition, and ensure everything’s as clear as can be.

Then I throw it in Spiral for another edit. I like how Spiral lets you edit with AI without AI taking over your writing. Spiral allows you to define “styles”. I created a style based on previous specs I’ve written in the past so the specs can be re-edited into something closer to my voice.

Depending on who or what I’m writing the specs for, I sometimes prefer a “document style”, and sometimes a “single indented list” style. In Spiral, I have some predefined prompts to toggle between the two formats.

- In scope
    - Organization-level setup of tax rules, line item defaults, and payment terms
    - Invoice-level display of the itemized breakdown associated with an order
    - Invoice-level snapshotting from the organization template
    - Invoice-level manual editing after snapshotting
    - Visibility rules for clients, bookkeepers, and admins
    - Discrepancy review UI for tax rate and line item drift
    - Batch reapply flow from the current organization template to selected invoices
- Out of scope
    - Payment processing or reconciliation
    - Refunds
    - Revenue recognition timing or accrual logic
    - Report-generation workflows beyond discrepancy review
    - Currency-specific tax logic
    - Arbitrary reusable custom pricing objects
    - Auditing payment term discrepancies
- Core concepts
    - Tax Calculation
        - Applicable tax percentage for an organization in a given region or jurisdiction scope
        - Belongs on the organization as a template; copied to the invoice at creation
        - After creation, managed independently from the organization record
        - Clients can always see their own tax breakdown
        - Seeing another client's tax details requires a specific permission
…

When I’m done editing, I do one final review in iA Writer and it’s good to go.

Has AI made my output better?

Three or four months ago, without a model to consolidate & guide me with questions, writing this spec probably would have taken 3–4 hours. It took me about an hour and a half yesterday.

But the quality of my output hasn’t really changed much. AI models are good at surfacing small details that might otherwise be overlooked, but at that level of detail it makes things slightly better, not orders of magnitude.

What’s changed is that I’m never staring at a blank document. The tools give me structure to work reactively and keep working in flow.

Microsoft is starting to remove "unnecessary" Copilot buttons from its Windows 11 apps. In the latest version of the Notepad app for Windows Insiders, Microsoft has removed the Copilot button in favor of a "writing tools" menu. The Copilot button in the Snipping Tool app also no longer appears when you select an area to […]

Matt Pocock shared a /grill me agent skill:

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree resolving dependencies between decisions one by one.

If a question can be answered by exploring the codebase, explore the codebase instead.

For each question, provide your recommended answer.

Incredibly simple, but the times I’ve used it so far it has been incredibly effective. (Almost annoyingly considering the amount of follow up questions you get; for a good cause!)