Figma Specs can put designs, written intent, and agent context together. An agent reading a document, however, does not establish an unambiguous acceptance standard. “Support CSV import” can still describe many incompatible implementations. Useful requirements specify input scope, boundaries, failure behavior, and unresolved decisions.

A fictional workpiece-quantity import example below turns one vague sentence into executable boundary cases. It is neither a Figma product test nor a complete importer. The focus is the decisions people need to settle before implementation. 中文版.

Shared context does not make product decisions

Google News surfaced the October 16 DevOps.com report on Figma’s collaboration updates. The October 15 original announcement describes Specs as a collaborative canvas context container with Markdown and references to designs and diagrams. Coding agents can receive its context through MCP. Figma says it is rolling out in open beta for paid plans.

These are context-organization capabilities, not independent evidence of code correctness or delivery speed. Connecting written intent to design objects can reduce scattered material, but it does not automatically decide which version applies, who resolves conflicting instructions, or what completion means.

The practical opportunity is to keep questions beside the work they describe and pass a shared set of decisions to implementers. The writing and validation approach below is this article’s recommendation, not a mandatory vendor document format.

What hides inside “support CSV import”?

Consider three requirements: files must stay below 5M, include an item identifier and quantity, and contain valid quantities. Reasonable implementers can still disagree. Does 5M mean 5,000,000 bytes or 5×1024×1024? Are columns matched by name or position? Is 01 a valid integer or a formatting error?

Without decisions, an agent fills in assumptions. A polished interface and one successful sample import do not show that it chose the intended semantics. Asking the agent to expose ambiguity is useful; silently delegating the business decision postpones disagreement until acceptance.

This example chooses explicit, non-universal rules: positive raw-file size up to 5 MiB inclusive; exactly item_id and quantity in that order; ASCII decimal quantities 1 through 9999 without leading zeros. They are teaching choices, not universal requirements imposed by CSV itself.

Write the boundary and the failure outcome

Expand 5 MiB to 5,242,880 bytes. State that equality is accepted and one byte above is rejected. A byte-count predicate can test that decision without constructing a large file merely to demonstrate arithmetic.

The example header is case-sensitive and does not trim spaces: Item_ID is different from item_id. The header rule decides whether extra columns, order changes, and name changes are accepted. The quantity rule decides how zero, negative numbers, whitespace, full-width digits, and leading zeros behave. Adjacent conflicting examples are more revealing than one ordinary successful sample.

Failure behavior needs decisions too: what error is shown, which row it identifies, whether existing data stays unchanged, and whether correction permits retry. Those behaviors are not smuggled into the predicate tests below; parsing, interface, and storage require their own validation. Rejecting an entire import on one invalid row and skipping only invalid rows are both possible decisions, but they are different product behaviors that must be chosen explicitly.

Twelve cases make the decisions falsifiable

This standard-library Python code checks size, header, and quantity predicates. It does not parse CSV, connect to Figma, upload a file, or alter a database. Its purpose is to turn decisions into inspectable true-or-false judgments.

# Original acceptance predicates; not a full CSV importer or Figma API.
import re
MAX_BYTES = 5*1024*1024  # 5 MiB

def size_allowed(n):
    return type(n) is int and 0<n<=MAX_BYTES

def header_allowed(columns):
    return columns == ["item_id","quantity"]

def quantity_allowed(text):
    # ASCII decimal1..9999, without signs, spaces or leading zeros.
    return isinstance(text,str) and re.fullmatch(r"[1-9][0-9]{0,3}",text) is not None

cases = [
    ("size boundary",size_allowed(MAX_BYTES),True),
    ("size over",size_allowed(MAX_BYTES+1),False),
    ("empty",size_allowed(0),False),
    ("MB is not MiB",size_allowed(5_100_000),True),
    ("header exact",header_allowed(["item_id","quantity"]),True),
    ("header reordered",header_allowed(["quantity","item_id"]),False),
    ("minimum",quantity_allowed("1"),True),
    ("maximum",quantity_allowed("9999"),True),
    ("zero",quantity_allowed("0"),False),
    ("leading zero",quantity_allowed("01"),False),
    ("non-ASCII",quantity_allowed("１２"),False),
    ("too large",quantity_allowed("10000"),False),
]
for label,actual,expected in cases:
    assert actual is expected,label
print("12 acceptance cases passed")

All 12 cases passed locally. A 5,100,000-byte input exceeds a decimal 5 MB limit but fits this example’s 5 MiB limit. That input exposes the unit disagreement more effectively than a small file well below either boundary.

Passing tests only shows agreement with the supplied expectations. If those expectations encode a misunderstanding, tests can reliably confirm the wrong rule. A person responsible for the product decision should review acceptance examples; the same generation process should not be the sole authority for rules, implementation, and expected outcomes.

What remains outside the executable example

A real CSV importer also needs decisions about encoding, BOMs, quoting, separators, line endings, blank rows, duplicate headers, duplicate item identifiers, and invalid-row handling. Green predicate tests do not establish that CSV import is complete.

Give important requirements stable identifiers and distinguish decided, undecided, and verified. Undecided does not mean allow or deny by default; it means ask a question or constrain the implementation scope. If a prototype is intentionally limited, its delivery note should retain those limitations.

These predicates do not establish whether an item exists, whether it is duplicated, or whether the user may import it. Naming the missing checks prevents a later reader from treating local evidence as a complete feature guarantee.

Keep decisions, tests, and implementation aligned

Suppose the next review allows extra columns. The old exactly-two-column rule is now obsolete. Changing only the prose while retaining old tests can make an agent “fix” the new behavior back into the previous contract.

A rule change should explain its reason, affected cases, and implementation paths requiring review. Version identifiers and design references help reviewers see which intent a change implements. The latest canvas is not automatically the content a historical build actually read.

This need not turn every draft into a heavy process. The decisions that define boundaries still need ownership. When parallel drafts, comments, and agent suggestions conflict, record an agreed conclusion instead of putting every text fragment into context and expecting the model to infer authority.

Organize long specifications around decisions

More context is not necessarily better context. A useful paragraph answers an implementation question, references relevant design material, and explains an observable outcome. Repeated background, stale conclusions, and contradictory examples consume attention rather than improving reliability.

Explicit goals and non-goals also constrain unnecessary expansion. A first iteration might validate a local file and show a preview without updating inventory. If persistence is later required, define authorization, rollback, and concurrency separately. One word—import—should not silently authorize every unstated action.

Design references should cover narrow layouts, long error messages, empty states, and failures rather than only a successful screen. The predicates here do not validate those experiences; they require actual rendered pages and interaction evidence.

Ask for a delivery report that can admit incompleteness

Alongside code, ask which rule was implemented, which case checked it, and which behavior remains uncovered. Permit explicit uncertainty rather than rewarding a fluent completion summary that conceals missing decisions.

The earlier completion-claim article traces claims back to execution evidence. Specs addresses an earlier boundary: what should have been completed in the first place? Clear intent and clear evidence make an agent delivery assessable.

If these boundary examples help turn an ambiguous request into reviewable decisions, voluntary support through the section below is welcome.

Sources and validation scope

Discovery followed the Google News listing of the October 16 report, then the October 15 original Figma announcement. Both diagrams, the fictional import rules, and code are original teaching material. No Figma-service or complete-importer test was performed.