Docs: xlsx SKILL.md never mentions `add --from` (row/column cloning) — agents re-specify formatting cell by cell

[giprime]

What's missing

The xlsx SKILL.md never mentions add --from (row/column cloning). Grepping the three shipped skills for --from returns 0 hits in all of them.

That command is the one-liner answer to the most common editing task there is: append a row to a sheet that already has formatting. Without it, an agent's only path is to re-specify every cell property by hand, which is where it goes wrong.

Related: the "Reading & Analysis" section teaches view outline / view text as the way to orient in an existing file. Neither returns any formatting, so an agent that follows the skill faithfully never has the source formatting in context when it writes the edit.

Why it matters

Observed with sonnet-5 on v1.0.146. An agent was asked to add four rows to an existing formatted worksheet. It ran view outline && view text (as the skill instructs), got values only, and wrote a batch of set --prop value= calls. The new rows landed with no font, no borders, no alignment.

When told the formatting was missing, it recovered by reading get "<range>" --json and emitting per-cell property batches — but it only covered 18 of the 36 cells and reported the task complete, because validate passed. A second correction round was needed for the remaining rows.

With add --from in the skill, none of that happens: it is one call and the formatting is carried by the CLI.

Reproduction

Formatting is not inherited without --from. This part is expected — add is documented as structural-only — it just isn't discoverable from the skill:

officecli create repro.xlsx
officecli set repro.xlsx /Sheet1/A1 --prop value=row1 --prop bold=true \
  --prop border.left=thin --prop border.bottom=thin --prop alignment.horizontal=center
officecli set repro.xlsx /Sheet1/A2 --prop value=row2 --prop bold=true \
  --prop border.left=thin --prop border.bottom=thin --prop alignment.horizontal=center

officecli add repro.xlsx /Sheet1 --type row --after "/Sheet1/row[1]" --prop cols=1 --prop c1=inserted
officecli get repro.xlsx "/Sheet1/A1:A3" --json

/Sheet1/A1  text='row1'      format={type, font.bold, font.size, font.name, border.left, border.bottom, alignment.horizontal}
/Sheet1/A2  text='inserted'  format={type}                       <-- bare
/Sheet1/A3  text='row2'      format={type, font.bold, ...}

add --from does exactly the right thing, and this is what the skill should be teaching:

officecli add repro2.xlsx /Sheet1 --type row --from "/Sheet1/row[2]" --after "/Sheet1/row[2]"
officecli get repro2.xlsx "/Sheet1/A1:A3" --json

/Sheet1/A3  text='row2'  format={font.bold, font.size, font.name, border.left, border.bottom, alignment.horizontal, numFmtId, numberformat}   <-- all 8 carried

Suggested fix

Two additions to skills/officecli-xlsx/SKILL.md:

1. A row/column cloning recipe under "Creating & Editing" — add --type row --from "/Sheet1/row[K]" --after "/Sheet1/row[K]", framed as the default way to extend an existing formatted table, with the "add is structural-only, formatting props are Set-only" asymmetry stated next to it. remove "/Sheet1/row[N]" deserves a line in the same place; the skill currently shows remove only for charts and sheets, so agents blank cell values instead of deleting rows and leave a gap behind.

2. A line in the editing workflow noting that view outline / view text return values only, and that get <range> --json (or dump) is what you run before editing a file whose look must be preserved. The existing "Preserve existing templates" bullet states the goal but not the procedure.

Scope note: --from exists for xlsx row and column. docx add paragraph|table and pptx add slide|shape do not advertise it, so this is an xlsx-skill issue only.

Verified on v1.0.146 (officecli-mac-arm64, sha256 fdad1c51…3161).

[goworm]

Thanks — confirmed the behaviour you describe: add --type row without --from lands a bare row (only type in format), while its neighbours keep fonts/borders/alignment. That asymmetry is intended (add is structural; formatting props are Set-only) and --from is the way around it.

The workaround, in one call:

# append a row that carries row 7's formatting
officecli add "$FILE" /Sheet1 --type row --from "/Sheet1/row[7]" --after "/Sheet1/row[7]"

# same for a column
officecli add "$FILE" /Sheet1 --type col --from "/Sheet1/col[C]" --after "/Sheet1/col[C]"

--from carries fonts, borders, alignment and number formats, and delta-shifts relative formula refs to the new anchor (Excel "Insert Copied Cells" parity). Deleting is symmetric — remove "/Sheet1/row[9]" closes the gap, whereas blanking values leaves an empty band.

Two corrections to the report, in case they save you time:

1. --from is not xlsx-only. I verified it on the other formats too:
   • add p.pptx / --from "/slide[1]" → Copied to /slide[2]
   • add p.pptx "/slide[1]" --from "/slide[1]/shape[1]" → Copied to /slide[1]/shape[@id=…]
   • add d.docx /body --from "/body/p[1]" → Copied to /body/p[2]
   • add d.docx /body --from "/body/table[1]" → Copied to /body/tbl[2]
2. It is already documented outside the format skills — officecli add --help lists --from (with a pptx example), and skills/officecli/SKILL.md carries it. Combined with the Help-First Rule at the top of every skill ("when a flag is uncertain, consult help before guessing"), that is the intended discovery path, so I am not adding a per-flag recipe to the format skills.

On the deeper point your write-up surfaces — that the agent shipped 18 of 36 cells formatted and still reported done because validate passed — that one is real and separate from discoverability. Worth tracking on its own; --from avoids the situation entirely, but a partially-formatted result passing the delivery gate is a gap in its own right. Leaving this open for that thread.