mafftopia Verify a Trade Story
Follow ${CLAUDE_SKILL_DIR}/../../story-skills.md and
${CLAUDE_SKILL_DIR}/../../reading-stories.md.
Step 1 — mechanical checks
Print Checking grammar, then run:
node "${CLAUDE_SKILL_DIR}/../../../dsl/src/verify.js" <path>
Always run it. Step 1 errors come from verify.js and nowhere else — never work
one out by reading the story yourself, however obvious it looks.
Report every error in errors. If there is at least one, stop — do not start
step 2. If there are none, print ✅ Checked grammar. and go on to step 2. That
is the only success line this step has: the report's belongs to the whole skill,
and printing it here claims the story passed before it has been read.
hints are not errors. Print a hint only when its line falls inside a clause an
error names: verbatim, as a fourth line under that error, prefixed Hint: .
Step 2 — trade setup
Only if step 1 returned no errors. Print Checking trade setup details, then
check every merged clause in merged against What makes a story unusable
in ${CLAUDE_SKILL_DIR}/../../../dsl/domain-rules.md, reporting each as
Reporting an unusable clause in ${CLAUDE_SKILL_DIR}/../../reading-stories.md
says. Report nothing until each has been
checked. Unlike step 1, this step has no early exit: finding an error is not a
reason to stop looking for the next.
Report
Print each line once. The progress lines are printed as the work happens — never repeat one when reporting, never print a line of your own alongside them.
No errors:
✅ All good.
An error carrying a line — the line number, the offending line alone even if it
belongs to a block, then the verifier's message verbatim:
Error on line 12:
Taking- 50% for TP1 then 50% for TP2
"Taking-" not recognised.
An error carrying no line, such as a missing clause, drops the first two lines.
The word before the colon is Error and nothing else:
Error: "Until" clause is missing.
A keyword named in an error is always quoted, in step 2 as in step 1 — "When" clause, never When clause. It is a keyword, not the English word.
Close the list with one status line. The count is not the point, so word it as work to be done — one, two, or more than two:
❌ Something to fix:
❌ A couple of things to fix:
❌ Some things to fix:
Then one short sentence naming the cause of each error whose cause you can name,
and a single AskUserQuestion offering Yes, No and Elaborate:
Looks like a typo for Taking. Shall I fix it?
That file is still the blank template rather than a story. Shall I fix it?
The sentence names the cause and stops. Do not add which lines you would change, what you would change them to, or what you cannot do for the user — that is what Elaborate is for.
Ask even when you can name no cause — then the bare question, Shall I fix these?.
Yes means show the exact proposed change first — the line as it stands and as it would read — and ask to go ahead. Then write exactly what was shown, and re-run from step 1. Never edit a story before the trader has been prompted to review the change.
As it would read keeps the trader's own words as the clause's first line, with the detail that makes it testable indented beneath, as a block. A fix adds mechanism; it never replaces intent. This holds however the fix was arrived at, including when the trader has said in their own words what they want.
Where the error is about missing information, offer concrete options with the conventional one named as such, and always one more for an answer of their own. Proposing "invented" values that way is ok because the trader has asked for help improving the story, AND they get to review the change before it's made.
Elaborate explains each cause and what to change, then asks again with Yes and No.