Add design plugin: prototypes (base-controls composition) + acceptance-tests (Gherkin from AC) - #6
Draft
david-hudec-networg wants to merge 8 commits into
Draft
Conversation
First skill for the planned design scope: acceptance criteria stay the single source of truth; scenarios are generated into the companion tests repo per TALXIS/docs-patterns-practices and tools-testkit-ui. v1 — enrichment from live project findings to follow on this draft. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…stop-rule, T18 - descriptions now state the boundary: scenario content only; test-project scaffolding/execution belongs to the implement plugin's test skill - a missing binding stops scenario authoring (report + tag blocked) instead of authorizing binding work here - the two pattern-repo pointers move to references/pattern-sources.md with a Remove-when naming new TOOLING-BACKLOG T18 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…int run Twelve field-tested rules as a reference file, each learned from a real defect or a false finding across ~160 scenarios: fixture-integrity checking as the fifth self-validation (and a CI gate), parsing AC HTML with a real parser, relative date windows, calendar anchors, personas that can fail, no fake mechanisms in fixtures, schema-vs-AC vocabulary split, test-user provisioning, declared exclusions, explicit duration text, tag whitespace, and assertion- strength triage. SKILL.md gains the fifth self-validation check and one invariant: story comments are not AC - requirements found there get promoted into the story, never quietly encoded in a scenario. All content scrubbed of customer, project and environment specifics per the sensitive-knowledge boundary. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The design plugin's own README listed "screen prototypes" as its planned next skill. This lands it, with one thesis: a prototype is a composition of controls that already exist, not a drawing of controls that might. Why this needed writing down at all — @talxis/base-controls appears zero times anywhere in this repo, including implement/frontend and its references/pcf-controls.md, which is the file an agent reads immediately before scaffolding a control. So the library that already covers every Dataverse column type, the dataset/grid surfaces, and whole-form rendering is invisible at exactly the moment it should decide the design. Teams that follow the rule follow it from memory; agents don't have that memory. The skill's spine is an escalation ladder lifted from the storybook's own section structure — form context, replace a renderer, custom content cells, layout only, one control, bespoke — with the instruction to stop at the first rung that works. Rung 4 (layout) is called out because it is the one teams skip: most "we need a custom component" requests are layout requests wearing a costume. Rung 6 is never silent; it must name the closest control, the missing capability, and whether the honest fix is bespoke code or a change request against the library. Visual consistency, reusability and stability are stated as invariants with their mechanism rather than as adjectives: consistency is inherited (and drifts silently once hand-built), reusability is decided at prototype time rather than refactor time, and stability is the library absorbing platform change everywhere except rung 6. The inventory deliberately does not live in SKILL.md. The library ships on its own release train (165 versions; a release landed the day this was written), so the reference names three authorities to read in order and carries the snapshot only to show breadth, marked verify-never-cite. That read-the-storybook step is a tooling gap, filed as T19. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
david-hudec-networg
changed the title
Both skills were already reuse-shaped and neither said so. prototypes had one ladder (how is this composed from base controls); acceptance-tests had "never invent a step phrase". Neither asked the question that comes first and kills most requests: should this exist at all? prototypes now carries two explicitly stacked ladders. Ladder A — needed at all, does the customer's industry already do this, does TALXIS already ship it, does the palette cover it, only then bespoke. Ladder B is the existing composition ladder, and only runs on what survives A. Splitting them keeps "should this exist" from being conflated with "replace the tabs renderer"; they are different questions and the first one is cheaper to get right. Rung 2 is the one worth defending: a workflow the customer's people already recognise beats a better one they have to learn. Novelty is a cost charged to the user, so it gets spent where the differentiation is and nowhere else. Added the matching invariant — reuse is checked, not assumed. "Nothing exists for this" is a claim that needs a search behind it, and an unsearched gap is the most expensive output either skill can produce. acceptance-tests gets the same rule pointed at fixtures and step definitions, where duplication rots quietly: a duplicate fixture is a future contradiction, a second phrase for an existing step is a binding that will rot. The discipline is ponytail's, applied to design rather than code. It is cited, not vendored — it is a general code-discipline plugin on its own release train, this repo owns Power Platform intent, and a copy would be stale the week it was made. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The rung previously told an agent to "look across TALXIS products and delivered projects". Delivery repos are not public, so in a public skill that was an instruction pointing at something the reader cannot open — and it leaked the shape of a private inventory to make its point. Generalised rather than deleted: the instruction is universal, only the inventory was private, and the inventory was never in the skill. It now names what is publicly executable — published packages (TALXIS.Controls.*) and what the workspace already references — then asks the generic question about the reader's own organisation without assuming they have an index for it. The closing clause is the part that carries weight: where no catalog exists, ask the people who would know rather than treating absence of a catalog as absence of prior art. That is the honest instruction, because no catalog is the normal case and a missing index is exactly how a component gets built twice. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Combines two previously unpushed commits so no customer-identifiable detail enters the public history. The journey decomposition rule and its evidence keep their force, stated as proportions rather than one engagement's exact scenario counts, entity name and certification scheme. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The skill left the location to the project ("a companion tests repo and a
tests/ directory in the app repo are both in use"). That was under-committed:
txc ships two component types for this — pp-test-ui scaffolds src/Tests.UI and
pp-test-ui-feature writes the stub into src/Tests.UI/Features — and the
implement plugin's test skill already instructs scaffolding under src/ and
adding the project to the solution. Where the product has decided, a skill
that stays neutral sends two skills in one marketplace to two places.
The companion tests repo is now stated as predating the component type, to be
followed only where a project already has one. Step 1 routes a missing project
to implement/test rather than to a pattern-repo template, so the scaffold has
one owner. README and pattern-sources drop the tests-repo scaffold as a
convention the pattern repo supplies.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fills the planned
designstub with its first two skills. Plugin0.2.0.prototypes— model components from the base-controls paletteThe stub's own README named "screen prototypes" as the next skill; this is it.
@talxis/base-controls, not a drawing of controls that might. Bespoke UI is allowed only when named — closest existing control, missing capability, and whether the honest fix is bespoke code or a change request against the library.@talxis/base-controlsappears zero times anywhere in this repo, includingimplement/frontendand itsreferences/pcf-controls.md— the file an agent reads immediately before scaffolding a control. The library that already covers every Dataverse column type is invisible at exactly the moment it should decide the design.SKILL.md(the library ships on its own release train — a release landed the day this was written); the reference names three authorities to read in order and marks its snapshot verify-never-cite. That read-the-storybook step is filed as T19.acceptance-tests— Gherkin from acceptance criteriatxc docs list.e76c5d3):references/production-learnings.mdholds 12 learnings from running this skill end-to-end on a live engagement — 18 user stories across 24 feature files, generated from real acceptance criteria and then put through a retroactive AC audit and a test-quality pass. They are the failure modes the method actually hit: fixture integrity rather than step bindings, acceptance-criteria HTML needing a real parser, no time-travel dates, naming the calendar anchor, picking the persona that can fail, never encoding a fake mechanism in a fixture, schema-over-AC for logical names, and test users that cannot be fixtures. Two of them also tightenedSKILL.md— a self-validation step, and the invariant that story comments are not acceptance criteria.Marketplace note: adds only its own entry (trivial pairwise conflict with sibling PRs).
generate-manifests.mjs --checkandvalidate.mjspass on this branch.🤖 Generated with Claude Code