@su-record/vibe 4.1.10 → 4.1.11
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude-plugin/marketplace.json +2 -2
- package/.claude-plugin/plugin.json +1 -1
- package/.codex-plugin/plugin.json +1 -1
- package/README.md +5 -3
- package/agents/design-art-director.md +27 -0
- package/agents/design-markup-reviewer.md +28 -0
- package/agents/en-chief-editor.md +3 -0
- package/agents/en-copy-editor.md +3 -0
- package/agents/ko-chief-editor.md +6 -0
- package/agents/ko-copy-editor.md +7 -0
- package/dist/core/checks/packs.js +27 -0
- package/dist/core/checks/packs.js.map +1 -0
- package/dist/core/checks/review.js +50 -28
- package/dist/core/checks/review.js.map +1 -1
- package/dist/core/checks/source.js +51 -0
- package/dist/core/checks/source.js.map +1 -0
- package/dist/core/scenarios.js +3 -0
- package/dist/core/scenarios.js.map +1 -1
- package/dist/install/plugin.js +19 -13
- package/dist/install/plugin.js.map +1 -1
- package/package.json +1 -1
- package/reviewers/design/1-markup-reviewer.md +21 -0
- package/reviewers/design/2-art-director.md +20 -0
- package/reviewers/en/{copy-editor.md → 1-copy-editor.md} +3 -0
- package/reviewers/en/{chief-editor.md → 2-chief-editor.md} +3 -0
- package/reviewers/ko/{copy-editor.md → 1-copy-editor.md} +7 -0
- package/reviewers/ko/{chief-editor.md → 2-chief-editor.md} +6 -0
- package/skills/antislop-design/SKILL.md +231 -0
- package/skills/antislop-design/references/catalogue.md +42 -0
- package/skills/antislop-design/references/plan.md +131 -0
- package/skills/antislop-en/SKILL.md +50 -0
- package/skills/antislop-en/references/editorial-review.md +1 -1
- package/skills/antislop-ko/SKILL.md +88 -0
- package/skills/antislop-ko/references/editorial-review.md +1 -1
- package/skills/vibe-scope/SKILL.md +2 -1
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"plugin.js","sourceRoot":"","sources":["../../src/install/plugin.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,SAAS,CAAC;AACzB,OAAO,EAAE,MAAM,SAAS,CAAC;AACzB,OAAO,IAAI,MAAM,WAAW,CAAC;AAC7B,OAAO,EAAE,WAAW,EAAE,MAAM,kBAAkB,CAAC;AAC/C,OAAO,EAAE,SAAS,EAAE,QAAQ,EAAE,WAAW,EAAE,SAAS,EAAE,MAAM,kBAAkB,CAAC;AAC/E,OAAO,EAAE,UAAU,EAAE,MAAM,WAAW,CAAC;AAEvC;;;;;;GAMG;AACH,MAAM,WAAW,GAAG,CAAC,MAAM,EAAE,eAAe,EAAE,YAAY,EAAE,YAAY,EAAE,YAAY,EAAE,cAAc,CAAU,CAAC;AACjH,MAAM,CAAC,MAAM,gBAAgB,GAAG,YAAY,CAAC;AAQ7C,qIAAqI;AACrI,MAAM,UAAU,WAAW,CAAC,OAAe,EAAE,CAAC,OAAO,EAAE;IACrD,OAAO;QACL,IAAI;QACJ,IAAI,EAAE,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,SAAS,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,CAAC;QAC1D,WAAW,EAAE,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,SAAS,EAAE,SAAS,EAAE,kBAAkB,CAAC;KACvE,CAAC;AACJ,CAAC;AAED,yHAAyH;AACzH,MAAM,UAAU,sBAAsB,CAAC,OAAe,EAAE,CAAC,OAAO,EAAE;IAChE,MAAM,MAAM,GAAG,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,OAAO,EAAE,QAAQ,CAAC,CAAC;IAClD,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,MAAM,CAAC;QAAE,OAAO,EAAE,CAAC;IACtC,EAAE,CAAC,MAAM,CAAC,MAAM,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC;IACpD,MAAM,OAAO,GAAG,CAAC,MAAM,CAAC,CAAC;IACzB,MAAM,OAAO,GAAG,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,OAAO,CAAC,CAAC;IACzC,IAAI,EAAE,CAAC,WAAW,CAAC,OAAO,CAAC,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACzC,EAAE,CAAC,MAAM,CAAC,OAAO,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC;QACrD,OAAO,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;IACxB,CAAC;IACD,OAAO,OAAO,CAAC;AACjB,CAAC;AAED,0GAA0G;AAC1G,MAAM,UAAU,aAAa;IAC3B,MAAM,GAAG,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,EAAE,QAAQ,CAAC,CAAC;IAC/C,OAAO,EAAE,CAAC,UAAU,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,WAAW,CAAC,GAAG,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,UAAU,CAAC,WAAW,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;AACvG,CAAC;AAED,MAAM,KAAK,GAAG,GAAG,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC;AAE5B,SAAS,UAAU,CAAC,IAAY;IAC9B,MAAM,OAAO,GAAG,IAAI,CAAC,OAAO,CAAC,KAAK,EAAE,MAAM,CAAC,CAAC,OAAO,CAAC,IAAI,MAAM,CAAC,KAAK,EAAE,GAAG,CAAC,EAAE,WAAW,CAAC,CAAC;IACzF,OAAO,CAAC,KAAK,EAAE,OAAO,EAAE,KAAK,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAC5C,CAAC;AAED
|
|
1
|
+
{"version":3,"file":"plugin.js","sourceRoot":"","sources":["../../src/install/plugin.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,SAAS,CAAC;AACzB,OAAO,EAAE,MAAM,SAAS,CAAC;AACzB,OAAO,IAAI,MAAM,WAAW,CAAC;AAC7B,OAAO,EAAE,UAAU,EAAc,MAAM,yBAAyB,CAAC;AACjE,OAAO,EAAE,WAAW,EAAE,MAAM,kBAAkB,CAAC;AAC/C,OAAO,EAAE,SAAS,EAAE,QAAQ,EAAE,WAAW,EAAE,SAAS,EAAE,MAAM,kBAAkB,CAAC;AAC/E,OAAO,EAAE,UAAU,EAAE,MAAM,WAAW,CAAC;AAEvC;;;;;;GAMG;AACH,MAAM,WAAW,GAAG,CAAC,MAAM,EAAE,eAAe,EAAE,YAAY,EAAE,YAAY,EAAE,YAAY,EAAE,cAAc,CAAU,CAAC;AACjH,MAAM,CAAC,MAAM,gBAAgB,GAAG,YAAY,CAAC;AAQ7C,qIAAqI;AACrI,MAAM,UAAU,WAAW,CAAC,OAAe,EAAE,CAAC,OAAO,EAAE;IACrD,OAAO;QACL,IAAI;QACJ,IAAI,EAAE,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,SAAS,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,CAAC;QAC1D,WAAW,EAAE,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,SAAS,EAAE,SAAS,EAAE,kBAAkB,CAAC;KACvE,CAAC;AACJ,CAAC;AAED,yHAAyH;AACzH,MAAM,UAAU,sBAAsB,CAAC,OAAe,EAAE,CAAC,OAAO,EAAE;IAChE,MAAM,MAAM,GAAG,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,OAAO,EAAE,QAAQ,CAAC,CAAC;IAClD,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,MAAM,CAAC;QAAE,OAAO,EAAE,CAAC;IACtC,EAAE,CAAC,MAAM,CAAC,MAAM,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC;IACpD,MAAM,OAAO,GAAG,CAAC,MAAM,CAAC,CAAC;IACzB,MAAM,OAAO,GAAG,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,OAAO,CAAC,CAAC;IACzC,IAAI,EAAE,CAAC,WAAW,CAAC,OAAO,CAAC,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACzC,EAAE,CAAC,MAAM,CAAC,OAAO,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC;QACrD,OAAO,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;IACxB,CAAC;IACD,OAAO,OAAO,CAAC;AACjB,CAAC;AAED,0GAA0G;AAC1G,MAAM,UAAU,aAAa;IAC3B,MAAM,GAAG,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,EAAE,QAAQ,CAAC,CAAC;IAC/C,OAAO,EAAE,CAAC,UAAU,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,WAAW,CAAC,GAAG,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,UAAU,CAAC,WAAW,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;AACvG,CAAC;AAED,MAAM,KAAK,GAAG,GAAG,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC;AAE5B,SAAS,UAAU,CAAC,IAAY;IAC9B,MAAM,OAAO,GAAG,IAAI,CAAC,OAAO,CAAC,KAAK,EAAE,MAAM,CAAC,CAAC,OAAO,CAAC,IAAI,MAAM,CAAC,KAAK,EAAE,GAAG,CAAC,EAAE,WAAW,CAAC,CAAC;IACzF,OAAO,CAAC,KAAK,EAAE,OAAO,EAAE,KAAK,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAC5C,CAAC;AAED,+GAA+G;AAC/G,MAAM,UAAU,cAAc,CAAC,IAAY,EAAE,KAAY;IACvD,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,KAAK,CAAC,IAAI,CAAC;QAAE,OAAO,IAAI,CAAC;IAC5C,MAAM,IAAI,GAAG,EAAE,CAAC,YAAY,CAAC,KAAK,CAAC,IAAI,EAAE,OAAO,CAAC,CAAC,IAAI,EAAE,CAAC;IACzD,MAAM,IAAI,GAAG,SAAS,KAAK,CAAC,KAAK,IAAI,KAAK,CAAC,IAAI,CAAC,OAAO,CAAC,IAAI,EAAE,GAAG,CAAC,EAAE,CAAC;IACrE,MAAM,IAAI,GAAG,SAAS,CAAC,IAAI,EAAE,KAAK,CAAC,CAAC;IACpC,OAAO,sCAAsC,IAAI,IAAI,KAAK,CAAC,KAAK,IAAI,KAAK,CAAC,IAAI,aAAa,IAAI,oBAAoB,IAAI,mBAAmB,IAAI,8BAA8B,IAAI,IAAI,IAAI,sHAAsH,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC;AACrU,CAAC;AAED,kHAAkH;AAClH,MAAM,UAAU,SAAS,CAAC,IAAY,EAAE,KAAY;IAClD,OAAO,GAAG,IAAI,IAAI,KAAK,CAAC,IAAI,EAAE,CAAC;AACjC,CAAC;AAED,SAAS,cAAc;IACrB,OAAO,QAAQ,CAAsB,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,EAAE,cAAc,CAAC,CAAC,EAAE,OAAO,IAAI,OAAO,CAAC;AACrG,CAAC;AAED,8FAA8F;AAC9F,MAAM,UAAU,cAAc,CAAC,IAAY;IACzC,EAAE,CAAC,MAAM,CAAC,IAAI,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC;IAClD,SAAS,CAAC,IAAI,CAAC,CAAC;IAChB,MAAM,OAAO,GAAa,EAAE,CAAC;IAC7B,MAAM,OAAO,GAAG,cAAc,EAAE,CAAC;IACjC,MAAM,SAAS,GAAG,UAAU,EAAE,CAAC;IAC/B,WAAW,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,eAAe,EAAE,aAAa,CAAC,EAAE,SAAS,CAAC,2BAA2B,CAAE,CAAC,CAAC;IACtG,OAAO,CAAC,IAAI,CAAC,2BAA2B,CAAC,CAAC;IAC1C,KAAK,MAAM,IAAI,IAAI,CAAC,GAAG,WAAW,EAAE,GAAG,aAAa,EAAE,CAAC,EAAE,CAAC;QACxD,MAAM,IAAI,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,EAAE,QAAQ,EAAE,IAAI,CAAC,CAAC;QACtD,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,IAAI,CAAC;YAAE,SAAS;QACnC,EAAE,CAAC,MAAM,CAAC,IAAI,EAAE,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,QAAQ,EAAE,IAAI,CAAC,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;QACtE,OAAO,CAAC,IAAI,CAAC,UAAU,IAAI,EAAE,CAAC,CAAC;IACjC,CAAC;IACD,KAAK,MAAM,KAAK,IAAI,aAAa,EAAE,EAAE,CAAC;QACpC,MAAM,IAAI,GAAG,KAAK,CAAC,OAAO,CAAC,WAAW,EAAE,EAAE,CAAC,CAAC;QAC5C,KAAK,MAAM,KAAK,IAAI,UAAU,CAAC,IAAI,CAAC,EAAE,CAAC;YACrC,MAAM,IAAI,GAAG,cAAc,CAAC,IAAI,EAAE,KAAK,CAAC,CAAC;YACzC,IAAI,CAAC,IAAI;gBAAE,SAAS;YACpB,MAAM,IAAI,GAAG,GAAG,SAAS,CAAC,IAAI,EAAE,KAAK,CAAC,OAAO,CAAC;YAC9C,WAAW,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,QAAQ,EAAE,IAAI,CAAC,EAAE,IAAI,CAAC,CAAC;YACnD,OAAO,CAAC,IAAI,CAAC,UAAU,IAAI,EAAE,CAAC,CAAC;QACjC,CAAC;IACH,CAAC;IACD,WAAW,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,OAAO,EAAE,kBAAkB,CAAC,EAAE,SAAS,CAAC,wBAAwB,CAAE,CAAC,CAAC;IAChG,OAAO,CAAC,IAAI,CAAC,wBAAwB,CAAC,CAAC;IACvC,KAAK,MAAM,IAAI,IAAI,CAAC,WAAW,EAAE,YAAY,CAAC,EAAE,CAAC;QAC/C,EAAE,CAAC,YAAY,CAAC,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,EAAE,OAAO,EAAE,IAAI,CAAC,EAAE,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,OAAO,EAAE,IAAI,CAAC,CAAC,CAAC;QACzF,OAAO,CAAC,IAAI,CAAC,SAAS,IAAI,EAAE,CAAC,CAAC;IAChC,CAAC;IACD,EAAE,CAAC,aAAa,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,WAAW,CAAC,EAAE,UAAU,OAAO,6KAA6K,EAAE,OAAO,CAAC,CAAC;IACxP,OAAO,CAAC,IAAI,CAAC,WAAW,CAAC,CAAC;IAC1B,OAAO,OAAO,CAAC;AACjB,CAAC;AAQD,iHAAiH;AACjH,MAAM,UAAU,gBAAgB,CAAC,KAAkB;IACjD,MAAM,GAAG,GAAmB,QAAQ,CAAiB,KAAK,CAAC,WAAW,CAAC,IAAI,EAAE,CAAC;IAC9E,GAAG,CAAC,IAAI,KAAK,gBAAgB,CAAC;IAC9B,GAAG,CAAC,SAAS,KAAK,EAAE,WAAW,EAAE,cAAc,EAAE,CAAC;IAClD,MAAM,OAAO,GAAG,KAAK,CAAC,OAAO,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,CAAC;IAC9D,MAAM,KAAK,GAAG;QACZ,IAAI,EAAE,MAAM;QACZ,MAAM,EAAE,EAAE,MAAM,EAAE,OAAO,EAAE,IAAI,EAAE,KAAK,IAAI,CAAC,QAAQ,CAAC,KAAK,CAAC,IAAI,EAAE,KAAK,CAAC,IAAI,CAAC,CAAC,OAAO,CAAC,KAAK,EAAE,GAAG,CAAC,EAAE,EAAE;QACnG,MAAM,EAAE,EAAE,YAAY,EAAE,WAAW,EAAE,cAAc,EAAE,YAAY,EAAE;QACnE,QAAQ,EAAE,iBAAiB;KAC5B,CAAC;IACF,MAAM,KAAK,GAAG,OAAO,CAAC,SAAS,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,EAAE,IAAI,KAAK,MAAM,CAAC,CAAC;IAC3D,IAAI,KAAK,KAAK,CAAC,CAAC;QAAE,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;;QACjC,OAAO,CAAC,KAAK,CAAC,GAAG,KAAK,CAAC;IAC5B,GAAG,CAAC,OAAO,GAAG,OAAO,CAAC;IACtB,SAAS,CAAC,KAAK,CAAC,WAAW,EAAE,GAAG,CAAC,CAAC;IAClC,OAAO,EAAE,IAAI,EAAE,KAAK,CAAC,WAAW,EAAE,eAAe,EAAE,GAAG,CAAC,IAAI,EAAE,CAAC;AAChE,CAAC;AAWD,MAAM,UAAU,aAAa,CAAC,IAAa;IACzC,MAAM,KAAK,GAAG,WAAW,CAAC,IAAI,CAAC,CAAC;IAChC,sBAAsB,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;IACnC,MAAM,KAAK,GAAG,cAAc,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;IACzC,MAAM,EAAE,eAAe,EAAE,GAAG,gBAAgB,CAAC,KAAK,CAAC,CAAC;IACpD,OAAO;QACL,IAAI,EAAE,KAAK,CAAC,IAAI;QAChB,WAAW,EAAE,KAAK,CAAC,WAAW;QAC9B,eAAe;QACf,KAAK;QACL,OAAO,EAAE,cAAc,EAAE;QACzB,IAAI,EAAE;YACJ,gCAAgC,KAAK,CAAC,IAAI,EAAE;YAC5C,yBAAyB,eAAe,EAAE;YAC1C,qFAAqF;SACtF;KACF,CAAC;AACJ,CAAC;AAED,gHAAgH;AAChH,SAAS,iBAAiB,CAAC,KAAkB,EAAE,KAA0C;IACvF,MAAM,GAAG,GAAG,KAAK,EAAE,MAAuC,CAAC;IAC3D,OAAO,OAAO,GAAG,EAAE,IAAI,KAAK,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,OAAO,CAAC,KAAK,CAAC,IAAI,EAAE,GAAG,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC;AACnF,CAAC;AAaD,MAAM,UAAU,YAAY,CAAC,IAAa;IACxC,MAAM,KAAK,GAAG,WAAW,CAAC,IAAI,CAAC,CAAC;IAChC,MAAM,MAAM,GAAG,EAAE,CAAC,UAAU,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;IACzC,MAAM,eAAe,GAAG,QAAQ,CAAuB,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,eAAe,EAAE,aAAa,CAAC,CAAC,EAAE,OAAO,IAAI,IAAI,CAAC;IAC/H,MAAM,OAAO,GAAG,cAAc,EAAE,CAAC;IACjC,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,QAAQ,CAAC,CAAC;IAClD,MAAM,MAAM,GAAG,EAAE,CAAC,UAAU,CAAC,SAAS,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,WAAW,CAAC,SAAS,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,KAAK,MAAM,IAAI,CAAC,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,CAAC;IACpI,MAAM,KAAK,GAAG,EAAE,CAAC,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,OAAO,EAAE,kBAAkB,CAAC,CAAC,IAAI,EAAE,CAAC,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,OAAO,EAAE,WAAW,CAAC,CAAC,CAAC;IAC9I,MAAM,KAAK,GAAG,QAAQ,CAAiB,KAAK,CAAC,WAAW,CAAC,EAAE,OAAO,EAAE,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,EAAE,IAAI,KAAK,MAAM,CAAC,CAAC;IACpG,MAAM,UAAU,GAAG,KAAK,KAAK,SAAS,CAAC;IACvC,MAAM,QAAQ,GAAG,iBAAiB,CAAC,KAAK,EAAE,KAAK,CAAC,CAAC;IACjD,MAAM,KAAK,GAAa,EAAE,CAAC;IAC3B,IAAI,CAAC,MAAM;QAAE,KAAK,CAAC,IAAI,CAAC,iDAAiD,CAAC,CAAC;IAC3E,IAAI,MAAM,IAAI,eAAe,KAAK,OAAO;QAAE,KAAK,CAAC,IAAI,CAAC,YAAY,eAAe,IAAI,MAAM,cAAc,OAAO,EAAE,CAAC,CAAC;IACpH,IAAI,MAAM,IAAI,MAAM,KAAK,WAAW,CAAC,MAAM;QAAE,KAAK,CAAC,IAAI,CAAC,UAAU,MAAM,MAAM,WAAW,CAAC,MAAM,EAAE,CAAC,CAAC;IACpG,IAAI,MAAM,IAAI,CAAC,KAAK;QAAE,KAAK,CAAC,IAAI,CAAC,eAAe,CAAC,CAAC;IAClD,IAAI,CAAC,UAAU;QAAE,KAAK,CAAC,IAAI,CAAC,4CAA4C,CAAC,CAAC;IAC1E,IAAI,UAAU,IAAI,QAAQ,KAAK,KAAK,CAAC,IAAI;QAAE,KAAK,CAAC,IAAI,CAAC,yBAAyB,QAAQ,IAAI,SAAS,EAAE,CAAC,CAAC;IACxG,OAAO,EAAE,IAAI,EAAE,KAAK,CAAC,IAAI,EAAE,MAAM,EAAE,eAAe,EAAE,cAAc,EAAE,OAAO,EAAE,MAAM,EAAE,KAAK,EAAE,UAAU,EAAE,KAAK,EAAE,CAAC;AAClH,CAAC"}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@su-record/vibe",
|
|
3
|
-
"version": "4.1.
|
|
3
|
+
"version": "4.1.11",
|
|
4
4
|
"description": "An AX/FDE harness for Claude Code, Codex CLI and ChatGPT desktop. Say what you need, approve the scenarios once; the harness proves the work by running the checks itself. Memory in plain files, human tokens for irreversible actions, a ledger instead of claims.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
You are a front-end lead seeing this source for the first time. Judge defects only — do not rewrite the source.
|
|
2
|
+
|
|
3
|
+
The caller gives you the design brief as the editorial contract (who uses this, how often, the task, and any stated brand tokens or constraints), the evidence ledger (real data sources, real copy, confirmed brand values, and what is unconfirmed or placeholder), the full source under `## Source` (each file numbered line by line), and optionally `## Screenshot` naming a rendered image path. If the brief or key evidence is missing from these, do not pretend to review — output one line, `NEEDS-HUMAN`, and list only what is missing.
|
|
4
|
+
|
|
5
|
+
What to check:
|
|
6
|
+
- Semantic structure and landmarks: headings in one logical order, lists as `<ul>`/`<ol>`, buttons as `<button>`, links as `<a>` with a real `href`, regions marked with `<nav>`/`<main>`/`<header>`/`<footer>` rather than unlabelled `<div>`s
|
|
7
|
+
- Form inputs each paired with a `<label>` (or `aria-label`), and a sensible tab/focus order matching the visual order
|
|
8
|
+
- Images and icons carrying meaningful `alt` text, or `alt=""` when purely decorative
|
|
9
|
+
- Contrast of stated or computed text and background colours against the 4.5:1 threshold for normal text
|
|
10
|
+
- The catalogue markers in `references/catalogue.md` of the `antislop-design` skill: a strong marker (gradient hero plus three cards, emoji icons, invented stats, fake testimonials, vague-verb CTA copy) flagged alone; a weak marker (rounded corners, a shadow, centred text, uniform spacing) flagged only when two or more overlap in the same component or passage
|
|
11
|
+
- Copy defects: placeholder text left in ("Lorem ipsum," "Your Company," a bracketed `[TODO]`), generic verbs with no specific referent, a button label that does not name its actual action
|
|
12
|
+
- Invented data: a statistic, count, testimonial or username not traceable to the evidence ledger
|
|
13
|
+
|
|
14
|
+
Output rules:
|
|
15
|
+
- If there are no defects, output exactly one line, `PASS`, with no surrounding explanation.
|
|
16
|
+
- If there are defects, write `REJECT` on the first line, then one line per item in the form `file:line | what | why it hurts the reader/user | what would fix it`. Fill in all four fields.
|
|
17
|
+
- You may end the list with up to three lines in the form `KEEP | <span> | <reason>` naming spans that must not be touched while fixing the rejected items.
|
|
18
|
+
- Do not flag a difference that is purely a matter of taste. Do not flag a problem you cannot pin to a location and a user effect.
|
|
19
|
+
- Do not flag a single weak marker alone; only flag it where two or more overlap.
|
|
20
|
+
- Do not add content the evidence does not contain, and do not write replacement markup or CSS.
|
|
21
|
+
- Do not treat a brand-mandated colour, typeface or logo usage stated in the brief as a defect.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
You are an art director seeing this work for the first time. Judge only whether the design is fit to ship — do not rewrite it.
|
|
2
|
+
|
|
3
|
+
The caller gives you the design brief as the editorial contract (who uses this, how often, the task, and any stated brand tokens or constraints), the evidence ledger (real data sources, real copy, confirmed brand values, and what is unconfirmed or placeholder), and the full source, already passed by the markup reviewer, under `## Source`. If `## Screenshot` names a file, open it with your file reader before judging and base your judgment on the rendered result; otherwise judge the source directly and say so is what you are doing. If the brief or key evidence is missing, do not pretend to review — output one line, `NEEDS-HUMAN`, and list only what is missing.
|
|
4
|
+
|
|
5
|
+
What to check:
|
|
6
|
+
- Hierarchy: what is seen first, and whether that is what the stated task in the brief needs seen first
|
|
7
|
+
- Specificity to the brief and its content: whether this design would move unchanged to a different product, brand or brief — the portability test for design; a design that passes that test unmodified is not specific to this one
|
|
8
|
+
- Density fit for how often and how briefly the stated user looks at this
|
|
9
|
+
- Whether the states the brief implies (empty, loading, error, long text, many items, one item, narrow viewport) are visibly accounted for, not only the populated average-length case
|
|
10
|
+
- Distinctiveness that comes from a decision, not decoration: reaching for one of the five named aesthetic clusters (warm minimal, dark neon, broadsheet, SaaS card kit, template chrome) counts as generic unless the brief specifically calls for that look
|
|
11
|
+
- Motion: whether any animation serves a purpose the user would miss if it were removed, versus applied uniformly as default polish
|
|
12
|
+
- Copy voice: whether headings, labels and button text are specific to the action and the audience, not generic filler
|
|
13
|
+
|
|
14
|
+
Output rules:
|
|
15
|
+
- If there is no defect that would block shipping, output exactly one line, `PASS`, with no surrounding explanation.
|
|
16
|
+
- If there is a defect, write `REJECT` on the first line, then one line per item in the form `file:line | what | why it hurts the reader/user | what would fix it`. Fill in all four fields. When judging from a screenshot, use the screenshot path in place of a line number.
|
|
17
|
+
- You may end the list with up to three lines in the form `KEEP | <span> | <reason>` naming spans that must not be touched while fixing the rejected items.
|
|
18
|
+
- Do not rewrite the design, and do not impose a personal aesthetic preference as if it were the brief's standard.
|
|
19
|
+
- Do not invent a brand rule that is not in the brief and use it as grounds for rejection.
|
|
20
|
+
- Do not demand a change that conflicts with the evidence ledger. If the evidence itself looks doubtful (an unsourced stat, a placeholder image left as if final), name that in the reason for rejection.
|
|
@@ -11,9 +11,12 @@ What to check:
|
|
|
11
11
|
|
|
12
12
|
For a usage question that needs a ruling, do not rely on memory — verify against a named dictionary and the stated style guide's current entries. When more than one form is acceptable, follow the editorial contract's formatting rule and the document's own internal consistency.
|
|
13
13
|
|
|
14
|
+
A weak tell alone is not grounds for a REJECT item: a single hedge, a single hyphenated compound, one passive clause with no actor worth naming, or one bolded phrase. Flag it only when two or more such tells overlap in the same passage. A tell that already changes what the reader can trust on its own, such as a dropped fact, a broken agreement or a wrong reference, is grounds for REJECT by itself.
|
|
15
|
+
|
|
14
16
|
Output rules:
|
|
15
17
|
- If there are no defects, output exactly one line, `PASS`, with no surrounding explanation.
|
|
16
18
|
- If there are defects, write `REJECT` on the first line, then one line per item in the form `location | original | impact | fix condition`. Fill in all four fields.
|
|
17
19
|
- Do not flag a difference that is purely a matter of taste. Do not flag a problem you cannot pin to a location and a reader effect.
|
|
18
20
|
- Do not add content the evidence does not contain, and do not write a full replacement sentence.
|
|
19
21
|
- Do not treat a character's dialogue, a quotation, or a deliberate non-standard usage in the manuscript as a defect.
|
|
22
|
+
- The REJECT list may end with up to three lines in the form `KEEP | <span> | <reason>`, naming a specific span the writer must not touch while fixing the findings above. Use it only for a span worth protecting from an overcorrection; do not pad the list to three when there is nothing to protect.
|
|
@@ -11,9 +11,12 @@ What to check:
|
|
|
11
11
|
- Whether there is a sentence or paragraph that could be deleted without changing the information, the argument or the emotional arc
|
|
12
12
|
- Whether a counter-argument is distorted, or the reader is asked to take something on faith without a chance to verify it
|
|
13
13
|
|
|
14
|
+
A weak tell alone is not grounds for a REJECT item: a single hedge, a single hyphenated compound, one passive clause with no actor worth naming, or one bolded phrase. Flag it only when two or more such tells overlap in the same passage. A tell that already changes what the reader can trust on its own, such as a stale cliché carrying a false claim of significance or an unsupported tricolon standing in for evidence, is grounds for REJECT by itself.
|
|
15
|
+
|
|
14
16
|
Output rules:
|
|
15
17
|
- If there is no defect that would block publication, output exactly one line, `PASS`, with no surrounding explanation.
|
|
16
18
|
- If there is a defect, write `REJECT` on the first line, then one line per item in the form `location | reason | reader impact | pass condition`. Fill in all four fields.
|
|
17
19
|
- Do not rewrite the manuscript, and do not impose a personal preference as if it were the outlet's standard.
|
|
18
20
|
- Do not invent an editorial policy that is not in the editorial contract and use it as grounds for rejection.
|
|
19
21
|
- Do not demand a change that conflicts with the evidence ledger. If the evidence itself looks doubtful, state that in the reason for rejection.
|
|
22
|
+
- The REJECT list may end with up to three lines in the form `KEEP | <span> | <reason>`, naming a specific span the writer must not touch while fixing the findings above. Use it only for a span worth protecting from an overcorrection; do not pad the list to three when there is nothing to protect.
|
|
@@ -14,6 +14,11 @@
|
|
|
14
14
|
규범 판단이 필요한 말은 기억에 기대지 말고 국립국어원 어문 규범과 표준국어대사전의 현재 용례를
|
|
15
15
|
확인한다. 허용 표기가 여럿이면 편집 계약의 표기 원칙과 문서 안의 일관성을 따른다.
|
|
16
16
|
|
|
17
|
+
약한 표지와 강한 표지를 구분하라. 줄표 하나, 번역투 조사구 하나처럼 그 자체로는 흔한
|
|
18
|
+
습관인 약한 표지는 같은 대목에 다른 표지와 둘 이상 겹칠 때만 REJECT 항목으로 올려라.
|
|
19
|
+
근거 없는 도입·결말, 실제 대조 없는 `A가 아니라 B다`처럼 강한 표지는 한 번만 나와도
|
|
20
|
+
REJECT 항목으로 올려라.
|
|
21
|
+
|
|
17
22
|
출력 규칙:
|
|
18
23
|
- 오류가 없으면 앞뒤 설명 없이 `PASS` 한 줄만 출력하라.
|
|
19
24
|
- 오류가 있으면 첫 줄에 `REJECT`를 쓰고, 다음 줄부터 항목마다 한 줄씩
|
|
@@ -21,3 +26,5 @@
|
|
|
21
26
|
- 취향만 다른 표현은 지적하지 마라. 위치와 독자 영향을 특정할 수 없는 문제는 지적하지 마라.
|
|
22
27
|
- 근거에 없는 내용을 추가하거나 수정문 전체를 작성하지 마라.
|
|
23
28
|
- 원고의 인물 대사, 인용, 의도적인 비표준 표현은 결함으로 보지 마라.
|
|
29
|
+
- `REJECT` 목록의 끝에는 필자가 손대면 안 되는 대목을 최대 세 줄까지 `KEEP | 구간 | 이유`
|
|
30
|
+
형식으로 덧붙일 수 있다. 목소리나 리듬을 살리려고 남겨 둔 대목일 때만 쓴다.
|
|
@@ -13,6 +13,10 @@
|
|
|
13
13
|
- 삭제해도 정보·논지·감정선이 달라지지 않는 문장이나 문단이 있는가
|
|
14
14
|
- 반론을 왜곡하거나 독자가 사실 확인 없이 믿어야 하는 대목이 있는가
|
|
15
15
|
|
|
16
|
+
약한 표지와 강한 표지를 구분하라. 줄표 하나, 번역투 조사구 하나처럼 그 자체로는 흔한
|
|
17
|
+
습관인 약한 표지는 같은 대목에 다른 표지와 둘 이상 겹칠 때만 반려 사유로 올려라. 진부한
|
|
18
|
+
시대 선언, 근거 없는 삼단 나열·최상급처럼 강한 표지는 한 번만 나와도 반려 사유로 올려라.
|
|
19
|
+
|
|
16
20
|
출력 규칙:
|
|
17
21
|
- 게재를 막을 결함이 없으면 앞뒤 설명 없이 `PASS` 한 줄만 출력하라.
|
|
18
22
|
- 결함이 있으면 첫 줄에 `REJECT`를 쓰고, 다음 줄부터 항목마다 한 줄씩
|
|
@@ -20,3 +24,5 @@
|
|
|
20
24
|
- 원고를 대신 쓰거나 개인 취향을 매체 기준인 것처럼 강요하지 마라.
|
|
21
25
|
- 편집 계약에 없는 편집 방침을 꾸며내어 반려 사유로 삼지 마라.
|
|
22
26
|
- 근거 장부와 충돌하는 수정을 요구하지 마라. 근거 자체가 의심스러우면 그 사실을 반려 사유에 적어라.
|
|
27
|
+
- `REJECT` 목록의 끝에는 필자가 손대면 안 되는 대목을 최대 세 줄까지 `KEEP | 구간 | 이유`
|
|
28
|
+
형식으로 덧붙일 수 있다. 목소리나 논지를 살리려고 남겨 둔 대목일 때만 쓴다.
|
|
@@ -0,0 +1,231 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: antislop-design
|
|
3
|
+
description: A design skill that strips generic-AI visual patterns and writes, diagnoses, revises and converts the design of anything a person will look at — web UI, screens, components, dashboards, landing pages, slides, card news, posters, email layouts — in HTML, CSS, React, Vue, Svelte or SVG. Use it before writing markup or styling for a new interface, when judging or fixing an existing one, and whenever a visual layout needs to fit a specific brief instead of a default template.
|
|
4
|
+
metadata:
|
|
5
|
+
tags: [design, ui, frontend, editing]
|
|
6
|
+
category: content
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Design Writing Skill (antislop-design)
|
|
10
|
+
|
|
11
|
+
`antislop-design` is a **general-purpose design skill**. It does not impose
|
|
12
|
+
one visual style. It chooses structure, type, colour and motion that fit the
|
|
13
|
+
brief, the user and the medium at hand — the same way `antislop-en` and
|
|
14
|
+
`antislop-ko` choose prose that fits purpose, reader and genre rather than
|
|
15
|
+
one house voice.
|
|
16
|
+
|
|
17
|
+
## When to Use
|
|
18
|
+
|
|
19
|
+
- Writing a new screen, page, component, dashboard, slide, card or poster from scratch.
|
|
20
|
+
- Diagnosing an existing design without changing it.
|
|
21
|
+
- Revising only what needs to change while preserving function, data and brand.
|
|
22
|
+
- Converting a template into something specific to one brief, or moving a design from one medium to another.
|
|
23
|
+
|
|
24
|
+
Apply it by default to any request that creates or fixes something a person
|
|
25
|
+
will look at on a screen or a printed page. Do not apply it to backend logic,
|
|
26
|
+
data pipelines or prose with no visual layout — those belong to other skills.
|
|
27
|
+
|
|
28
|
+
Treat "build" or "design" as authoring, "look this over" as diagnosis, "fix"
|
|
29
|
+
or "polish" as revision, and "make this specific" or "turn this into a
|
|
30
|
+
poster" as conversion. Do not attach a diagnostic table the user did not ask
|
|
31
|
+
for; lead with the finished design.
|
|
32
|
+
|
|
33
|
+
## Quality Priority
|
|
34
|
+
|
|
35
|
+
Judge in the following order. Do not damage an earlier condition to gain a
|
|
36
|
+
later advantage.
|
|
37
|
+
|
|
38
|
+
1. **Function and data**: the design does what it must do, with real content and real states, nothing invented.
|
|
39
|
+
2. **Fit for the user and task**: the person who uses this, how often, and what they look for first, are visibly served.
|
|
40
|
+
3. **Hierarchy and structure**: what is seen first is what matters first; layout encodes information, not decoration.
|
|
41
|
+
4. **Accessibility**: contrast, semantic structure, keyboard access and labels hold for every state.
|
|
42
|
+
5. **Type and colour choices**: deliberate, named, traceable to the brand or the content.
|
|
43
|
+
6. **Motion and polish**: present only where it serves a purpose, never as default flourish.
|
|
44
|
+
|
|
45
|
+
## What Design Slop Is
|
|
46
|
+
|
|
47
|
+
Design slop is a visual choice that could be dropped into any product,
|
|
48
|
+
company or brief unchanged and would still "look right." It is the visual
|
|
49
|
+
equivalent of a sentence that fits any topic. The test is not whether a
|
|
50
|
+
pattern appears — a rounded card or a gradient can be correct — but whether
|
|
51
|
+
the choice was made for this brief or is the generic default a model
|
|
52
|
+
produces when nobody decided otherwise.
|
|
53
|
+
|
|
54
|
+
### Generic clusters that show up on sight
|
|
55
|
+
|
|
56
|
+
A model left to its own defaults converges on a small set of looks. Each is
|
|
57
|
+
fine as one deliberate choice for the right brief; each is slop when it is
|
|
58
|
+
simply what appeared because nothing else was decided.
|
|
59
|
+
|
|
60
|
+
- **Purple/indigo gradient hero over three rounded feature cards.** A `linear-gradient` hero banner, a bold headline, and exactly three cards below it, each with an icon, a heading and one line of copy — the shape of a demo, not a product.
|
|
61
|
+
- **Glass panels with backdrop blur.** Frosted, semi-transparent panels (`backdrop-filter: blur(...)`) laid over an image or gradient, used for decoration rather than to show real layering (a modal above content, a sticky header over scroll).
|
|
62
|
+
- **Emoji as icons.** 👋, 🚀, ✨, 📊 standing in for a real icon set or no icon at all, especially in headings, buttons and list markers.
|
|
63
|
+
- **"Welcome back 👋" greetings.** A friendly, familiar tone asserted by copy instead of earned by the product's actual relationship with the user.
|
|
64
|
+
- **Stat tiles with invented numbers.** "10,000+ users," "99.9% uptime," "4.9★" with no source — a number that exists to look like proof rather than to report one.
|
|
65
|
+
- **Fake testimonials.** A quote attributed to "Jane D., Product Manager" that is illustrative rather than sourced.
|
|
66
|
+
- **Sparkles.** The ✨ glyph or a sparkle icon marking a feature as "AI" or "new" with no other signal.
|
|
67
|
+
- **Fade-and-slide-up on every section, hover-lift on every card.** A scroll-triggered entrance animation applied uniformly, and a `translateY` lift on `:hover` for every card regardless of whether the card is interactive.
|
|
68
|
+
- **One typeface for everything.** Inter or the system font stack used for display headings, body copy and captions alike, with no second voice for contrast.
|
|
69
|
+
- **Everything centred.** `text-align: center` and centred flex layouts applied to headings, paragraphs and forms alike, flattening the reading path.
|
|
70
|
+
- **Gray-on-gray low contrast.** Body text and secondary text both landing in a narrow band of grays that fails contrast rather than being pushed to a deliberate darker or lighter value.
|
|
71
|
+
- **Uniform 16/24px spacing with no rhythm.** Every gap the same one or two values, so nothing signals grouping, and dense and sparse content look the same.
|
|
72
|
+
- **Copy that says seamlessly, unlock, effortless, empower.** The visual-design counterpart of AI-cliché prose (see `antislop-en`'s catalogue) — vague verbs standing in for a specific benefit.
|
|
73
|
+
- **"Get started" CTAs everywhere.** The same button label repeated for actions that are not the same action, because no one named what each button actually does.
|
|
74
|
+
|
|
75
|
+
### The five named aesthetic clusters
|
|
76
|
+
|
|
77
|
+
Beyond the generic-default shapes above, a model asked for "something
|
|
78
|
+
distinctive" tends to reach for one of five named looks, applied as a skin
|
|
79
|
+
rather than a decision:
|
|
80
|
+
|
|
81
|
+
1. **Warm minimal**: a warm cream background, a high-contrast serif display face, a terracotta or warm-clay accent.
|
|
82
|
+
2. **Dark neon**: a near-black background with a single bright acid-green or vermilion accent.
|
|
83
|
+
3. **Broadsheet**: hairline rules, zero border-radius, dense newspaper-like columns.
|
|
84
|
+
4. **SaaS card kit**: content chopped into identical rounded cards, one border-radius and one soft grey shadow applied regardless of hierarchy.
|
|
85
|
+
5. **Template chrome**: tracked-out ALL-CAPS eyebrow labels above every heading, meta strings joined with middle dots, labels built as "WORD — fragment."
|
|
86
|
+
|
|
87
|
+
Any of the five is a legitimate choice when the brief calls for it — a
|
|
88
|
+
newspaper-style broadsheet look for an actual publication, a dark-neon look
|
|
89
|
+
for a security dashboard. It is slop when it is reached for because it reads
|
|
90
|
+
as "designed" rather than because the brief asked for it.
|
|
91
|
+
|
|
92
|
+
### How to see these in markup and CSS
|
|
93
|
+
|
|
94
|
+
The catalogue markers have concrete signatures in source: a `linear-gradient`
|
|
95
|
+
value with two stop colours in the purple/indigo range, `backdrop-filter:
|
|
96
|
+
blur(...)` on a panel with no functional layering reason, emoji code points
|
|
97
|
+
inside `<h1>`–`<h3>` or `<li>` markers, `font-family: Inter` (or no
|
|
98
|
+
`font-family` at all, falling back to the system stack) with no second
|
|
99
|
+
family declared anywhere, `text-align: center` repeated across unrelated
|
|
100
|
+
elements, a single `border-radius` and `box-shadow` pair repeated on every
|
|
101
|
+
card, `letter-spacing` and `text-transform: uppercase` on short labels, `·`
|
|
102
|
+
or `—` as a metadata separator, and an animation class (`fade-up`,
|
|
103
|
+
`animate-in`, `hover:-translate-y-1`) applied to every section or every card
|
|
104
|
+
rather than to the one element that needs it. The full table of markers,
|
|
105
|
+
their code signatures and the alternative is in
|
|
106
|
+
[references/catalogue.md](references/catalogue.md).
|
|
107
|
+
|
|
108
|
+
## The Decisions a Specific Design Makes First
|
|
109
|
+
|
|
110
|
+
Before writing markup or styling, fix the following as internal working
|
|
111
|
+
ground. This is the design-plan step — do it in prose and an ASCII sketch,
|
|
112
|
+
not in code, and revise the plan itself before building from it.
|
|
113
|
+
|
|
114
|
+
1. **Who uses this, and how often.** A charge nurse checking a roster twenty times a shift needs a different density than a visitor reading a landing page once.
|
|
115
|
+
2. **The task, and what they look for first.** Name the one piece of information or action that matters most on this screen, and make sure it is what the eye lands on first.
|
|
116
|
+
3. **Density.** A screen used often and briefly should show more at once with less chrome; a screen used rarely should explain more and show less.
|
|
117
|
+
4. **Hierarchy.** What is largest, boldest or first should be what matters most — not what was easiest to make prominent.
|
|
118
|
+
5. **Type.** One or two typefaces, chosen for a reason (a display face for identity, a text face for legibility at the sizes the content actually needs), not a default.
|
|
119
|
+
6. **Colour.** Four to six named tokens drawn from the brand or the content itself — not a palette chosen because it looks "designed." Name each token by role (background, surface, text, accent, danger, success), not only by hex value.
|
|
120
|
+
7. **Structure that encodes information, not decoration.** Grouping, spacing and borders should tell the reader what belongs together; a card, a rule or a gap is a claim about relationship, not a stylistic default.
|
|
121
|
+
8. **Motion only with a purpose.** An animation should confirm an action, guide attention to a change, or ease a state transition — never run on every element because it is available.
|
|
122
|
+
9. **The states.** Design for empty, loading, error, long text, many items, one item and a narrow viewport — not only the populated, average-length, ideal-count screenshot state.
|
|
123
|
+
10. **Contrast and keyboard access.** Text and meaningful UI against its background should read at least 4.5:1, and every interactive element should be reachable and operable by keyboard alone.
|
|
124
|
+
11. **Copy inside the design.** Headings, labels, button text and body copy follow the antislop pack of whatever language they are written in — `antislop-en` or `antislop-ko` — so the words are not a second source of slop next to the layout.
|
|
125
|
+
|
|
126
|
+
The design-plan template in
|
|
127
|
+
[references/plan.md](references/plan.md) walks through these in order,
|
|
128
|
+
ending with a check: state plainly what about the plan would make it generic,
|
|
129
|
+
and either fix that part or state why it is the right choice here anyway.
|
|
130
|
+
|
|
131
|
+
## The Four Tasks
|
|
132
|
+
|
|
133
|
+
### Write
|
|
134
|
+
|
|
135
|
+
1. Fill out the design plan (references/plan.md): brief, users and frequency, task, density, hierarchy, type, colour tokens, layout sketch in ASCII, states, motion, copy voice.
|
|
136
|
+
2. Review the plan itself: for each choice, ask whether it is what this brief calls for or what any similar brief would get. Revise the part that would not change if the subject changed.
|
|
137
|
+
3. Only then build. Implement structure first (semantic HTML, real content, all listed states), then type and colour tokens, then motion last and only where planned.
|
|
138
|
+
4. Check the result against the plan and against [Verification](#verification) before calling it done.
|
|
139
|
+
|
|
140
|
+
### Diagnose
|
|
141
|
+
|
|
142
|
+
Do not change the source. Answer in this order.
|
|
143
|
+
|
|
144
|
+
- What to preserve (working function, real data, existing brand tokens, accessibility that already holds).
|
|
145
|
+
- Findings: marker or defect, exact location, effect on the user, reason to change it.
|
|
146
|
+
- What a human must decide.
|
|
147
|
+
- Overall verdict.
|
|
148
|
+
|
|
149
|
+
Separate a stylistic preference from a defect. Do not flag a marker you
|
|
150
|
+
cannot pin to a location and a user effect; do not flag a single weak marker
|
|
151
|
+
alone (see [Strength Tiers](#strength-tiers)).
|
|
152
|
+
|
|
153
|
+
### Revise
|
|
154
|
+
|
|
155
|
+
Hold a preservation contract. Do not add, remove or alter the following
|
|
156
|
+
while fixing what was flagged:
|
|
157
|
+
|
|
158
|
+
- **Function**: what each control does, what each interaction triggers.
|
|
159
|
+
- **Data**: real content, real numbers, real copy — do not replace a fixed defect with an invented one.
|
|
160
|
+
- **Accessibility**: any contrast, labelling or keyboard behaviour that already passes.
|
|
161
|
+
- **Brand tokens**: an established colour, typeface or logo usage that the brief or an existing style guide fixes.
|
|
162
|
+
- **Routes and handlers**: URLs, form actions, event handlers, API calls and their shapes.
|
|
163
|
+
|
|
164
|
+
Be able to state the problem each change solves. Do not swap a shadow for a
|
|
165
|
+
different shadow, or a border-radius value for another one, only to look
|
|
166
|
+
different. Stop at `needs-human` when the brief or the brand ground is too
|
|
167
|
+
unclear to safely settle a change.
|
|
168
|
+
|
|
169
|
+
### Convert
|
|
170
|
+
|
|
171
|
+
- **Template to specific**: take a generic starting point (a component library default, a boilerplate landing page) and rebuild its type, colour, copy and structure around one real brief, using the design plan to force every generic choice into a decided one.
|
|
172
|
+
- **One medium to another**: moving a design from web UI to slide, poster or card news (or back) keeps the information hierarchy and brand tokens, but density, type scale and interaction all change with the medium — a hover state has no meaning on a printed poster, and a slide has no scroll.
|
|
173
|
+
|
|
174
|
+
## Strength Tiers
|
|
175
|
+
|
|
176
|
+
Not every marker is equally damning. Judge by tier.
|
|
177
|
+
|
|
178
|
+
- **Strong markers act alone.** One instance is enough to flag: a gradient hero paired with exactly three rounded feature cards, an emoji standing in for an icon, an invented statistic, a fake testimonial, or copy using "seamlessly"/"unlock"/"effortless"/"empower" with no specific referent.
|
|
179
|
+
- **Weak markers act only when two or more overlap in the same passage or component.** A rounded corner alone is not slop; a rounded corner, a soft grey shadow and a centred headline together, on a card that looks like every other SaaS card kit, is. A centred heading alone is not slop; centring applied to headings, body copy and a form all at once is.
|
|
180
|
+
|
|
181
|
+
Do not run the catalogue as a checklist of banned properties. `border-radius`
|
|
182
|
+
and `box-shadow` are ordinary tools; the question is always whether this use,
|
|
183
|
+
in this brief, is a decision or a default.
|
|
184
|
+
|
|
185
|
+
## Verification
|
|
186
|
+
|
|
187
|
+
- Does the design do what it must, with real content and every required state shown?
|
|
188
|
+
- Is what the user sees first what the task actually needs first?
|
|
189
|
+
- Is density right for how often and how briefly this gets used?
|
|
190
|
+
- Do type and colour choices trace to a stated reason, not a default?
|
|
191
|
+
- Does contrast hold at 4.5:1 or better for text and meaningful UI, and can every control be reached by keyboard?
|
|
192
|
+
- Is structure (grouping, spacing, borders) telling the reader something true about relationship, not just decorating?
|
|
193
|
+
- Does any motion serve a purpose the user would notice if it were removed?
|
|
194
|
+
- Would this design move unchanged to a different product, brand or brief? If yes, what makes it specific has not been found yet.
|
|
195
|
+
- Are any strong markers present — a gradient-hero-plus-three-cards shape, emoji icons, invented numbers, fake testimonials? A single strong marker is enough to flag.
|
|
196
|
+
- Do two or more weak markers overlap in the same place — rounded corners, soft shadow and centred text together, for instance?
|
|
197
|
+
- Does copy inside the design follow the antislop pack for its language, free of vague-verb filler and manufactured urgency?
|
|
198
|
+
- For a revision: does the preservation contract hold — same function, same data, same accessibility, same brand tokens, same routes and handlers?
|
|
199
|
+
|
|
200
|
+
## Editorial Review
|
|
201
|
+
|
|
202
|
+
Do not close out a design meant for a real audience — a shipped screen, a
|
|
203
|
+
deck someone will present, a poster someone will print — on the writer's own
|
|
204
|
+
judgment alone. Bind a `review` check to the design in a scenario:
|
|
205
|
+
|
|
206
|
+
```yaml
|
|
207
|
+
- id: dashboard-review
|
|
208
|
+
then: the dashboard passes the markup reviewer and the art director
|
|
209
|
+
check: { type: review, pack: design, path: out/dashboard.html, contract: out/brief.md, screenshot: out/dashboard.png }
|
|
210
|
+
```
|
|
211
|
+
|
|
212
|
+
- `path` is the file or directory under review; `contract` is the design brief; `screenshot` is optional and, when given, is a rendered image of the result.
|
|
213
|
+
- The harness runs `reviewers/design/1-markup-reviewer.md` first, and only on a pass runs `reviewers/design/2-art-director.md`. A stage passes only when the entire response is exactly one line, `PASS`.
|
|
214
|
+
- **The harness renders nothing.** It has no browser and no screenshot tool. A screenshot, when the review needs one, is produced by the project's own tooling (a build step, a headless-browser script, a design tool export) in an earlier scenario, and handed to the check by path. Without a screenshot, the art director judges the source directly.
|
|
215
|
+
- If the same failure repeats twice, stop at `needs-human` rather than guessing at a fix the reviewer did not ask for.
|
|
216
|
+
|
|
217
|
+
This mirrors the two-stage independent review in `antislop-en`'s
|
|
218
|
+
[Independent Editorial Review](../antislop-en/references/editorial-review.md) —
|
|
219
|
+
a different agent judges, the writer does not self-certify, and a reviewer
|
|
220
|
+
returns only `PASS` or a `REJECT` list, never a rewrite.
|
|
221
|
+
|
|
222
|
+
## Pitfalls
|
|
223
|
+
|
|
224
|
+
- Do not treat a design plan as a formality to write after the fact to justify code already written. Write it first; let it change what you build.
|
|
225
|
+
- Do not ban a CSS property. A gradient, a rounded corner and a shadow are tools; the catalogue names the *pattern of default use*, not the property.
|
|
226
|
+
- Do not skip states to ship faster. A design with no error state or no empty state is not finished, even if the populated screenshot looks right.
|
|
227
|
+
- Do not add a stat, a testimonial or a number to "fill out" a design. An empty space is honest; an invented number is not.
|
|
228
|
+
- Do not apply motion uniformly because a library makes it one line to add. Every animation should be traceable to a purpose a user would miss if it were gone.
|
|
229
|
+
- Do not let the art director judge a screenshot that was never actually produced. If no screenshot is given, say the review judged source only.
|
|
230
|
+
- Do not confuse "distinctive" with "one of the five named aesthetic clusters." Warm minimal, dark neon, broadsheet, SaaS card kit and template chrome are looks, not proof of a decision — they are slop exactly as often as the generic-default shapes are.
|
|
231
|
+
- Do not let a revision's preservation contract be an excuse to leave an accessibility or contrast defect in place; "preserve function and data" does not mean "preserve every existing property untouched."
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
# Design Slop Catalogue
|
|
2
|
+
|
|
3
|
+
One row per marker. "Strength" follows the skill's tiers: a strong marker is
|
|
4
|
+
enough on its own; a weak marker only counts when two or more overlap in the
|
|
5
|
+
same passage or component. Do not run this as a list of banned properties —
|
|
6
|
+
each alternative names what to decide instead, not a substitute default.
|
|
7
|
+
|
|
8
|
+
| Marker | What it looks like | How it shows in markup/CSS | Strength | Alternative |
|
|
9
|
+
|---|---|---|---|---|
|
|
10
|
+
| Purple/indigo gradient hero + three cards | A full-width gradient banner headline over exactly three identical rounded feature cards | `background: linear-gradient(135deg, #667eea, #764ba2)` on a hero, followed by a three-up grid of cards with matching `border-radius` and `box-shadow` | Strong | Pick a hero built from the actual content (a product screenshot, a real number, a specific claim) and let the feature count and layout follow what there actually is to say, not a fixed three. |
|
|
11
|
+
| Gradient text | Headline text filled with a gradient instead of a solid colour | `background: linear-gradient(...); -webkit-background-clip: text; -webkit-text-fill-color: transparent;` | Strong | A solid brand colour or the default text colour, sized and weighted for hierarchy instead. |
|
|
12
|
+
| Glass panels | Frosted, translucent panels floating over a background | `backdrop-filter: blur(...)` or `-webkit-backdrop-filter` on a panel with no real content behind it to blur | Weak (strong if the blur has no functional layering reason at all) | A solid or lightly tinted surface token; reserve blur for an actual overlay (a modal above real scrolling content). |
|
|
13
|
+
| Emoji as icons | 👋 🚀 ✨ 📊 standing in for an icon set | Emoji code points inside `<h1>`–`<h3>`, `<button>`, or `<li>` markers | Strong | A real icon set (SVG sprite or icon font) sized and coloured to match the type, or no icon at all. |
|
|
14
|
+
| "Welcome back 👋" greeting | Familiar tone asserted by copy instead of earned by relationship | Literal string in a heading or banner component | Strong | A greeting that states something the product actually knows (last visit's actual result, an actual pending item) or no greeting at all. |
|
|
15
|
+
| Stat tiles with invented numbers | "10,000+ users," "99.9% uptime," "4.9★" with no source | A stat-tile or metric-card component populated with placeholder numbers not wired to real data | Strong | Wire the tile to a real number, or leave the section out until there is one to show. |
|
|
16
|
+
| Fake testimonials | A quote attributed to a generic name and title | A blockquote or card with `"Jane D., Product Manager"` or similar invented attribution | Strong | A sourced quote with permission, or no testimonial section. |
|
|
17
|
+
| Sparkles | ✨ marking a feature as "AI" or "new" | The sparkle glyph or icon next to a label, with no other signal of novelty | Strong | State plainly what changed or what the feature does; let the copy carry the claim. |
|
|
18
|
+
| Fade-and-slide-up on every section | Every section animates in on scroll, identically | A class like `animate-fade-up`, `data-aos="fade-up"`, or an IntersectionObserver applied uniformly to all `<section>` elements | Strong (when applied to every section with no distinction) | Reserve entrance motion for the one or two moments where it helps orientation (a hero, a state change); let the rest render at rest. |
|
|
19
|
+
| Hover-lift on every card | Every card rises and gains shadow on hover, whether or not it is interactive | `hover:-translate-y-1` (Tailwind) or `transform: translateY(-4px)` on `:hover` applied to non-interactive cards | Weak (strong if applied to a card that is not clickable at all) | Apply a hover state only to elements that respond to a click or a link; a static display card gets no hover treatment. |
|
|
20
|
+
| One typeface for everything | Inter or the system stack used for display, body and caption alike | A single `font-family` declaration (or none, falling back to `-apple-system, ...`) with no second family anywhere in the file | Weak | One or two typefaces chosen for a reason — a display face for identity, a distinct text face for long-form legibility. |
|
|
21
|
+
| Everything centred | Headings, paragraphs and forms all `text-align: center` | `text-align: center` repeated across unrelated element types, or a centred flex/grid container used for body copy | Weak | Left-align body copy and forms for reading flow; reserve centring for short, standalone elements (a hero headline, an empty state). |
|
|
22
|
+
| Gray-on-gray low contrast | Body and secondary text both land in a narrow mid-gray band | Two `color` values within a few percentage points of lightness, e.g. `#9CA3AF` next to `#A1A1AA` | Strong (it is a contrast failure, not a taste question) | Push text colour to a value that measures at least 4.5:1 against its background; reserve the lighter gray for genuinely de-emphasised metadata only. |
|
|
23
|
+
| Uniform spacing with no rhythm | Every gap is the same one or two values regardless of grouping | A design system or utility classes using only `gap-4`/`gap-6` (16px/24px) everywhere, no larger gap between unrelated groups | Weak | A small set of spacing tokens used deliberately — a larger gap between sections than between related items within one. |
|
|
24
|
+
| Slop CTA copy | "Get started" repeated for buttons that do different things | Multiple `<button>`/`<a>` elements sharing the same label across a page | Weak (strong if the buttons trigger different actions) | Name what each button actually does: "Create your first roster," "View last week," and so on. |
|
|
25
|
+
| Vague-verb copy | "seamlessly," "unlock," "effortless," "empower" with no specific referent | Marketing copy inside headings or subheads | Strong | State the specific benefit and to whom, the way `antislop-en`'s catalogue treats vague-verb filler in prose. |
|
|
26
|
+
| Tracked all-caps eyebrow labels | Small uppercase label above every heading | `letter-spacing: 0.1em; text-transform: uppercase;` on a short label element, repeated site-wide | Weak | Use a label only where it classifies content the reader needs classified; vary its treatment instead of stamping it everywhere. |
|
|
27
|
+
| Middle-dot metadata | Metadata joined with `·` or em dashes | Literal `·` or `—` characters joining date, author, category strings | Weak | A layout (separate fields, an icon, whitespace) that shows the same grouping without relying on one punctuation glyph as the whole design system. |
|
|
28
|
+
| Uniform card-kit radius and shadow | Every card shares one `border-radius` and one soft shadow regardless of hierarchy | A single `rounded-2xl shadow-lg` (or equivalent) utility pair applied to every card-like container in the file | Weak (strong if it is the *only* structural device the layout uses to show grouping) | Vary radius and elevation by role — a primary surface, a nested item, an inline chip — or drop the shadow and let spacing do the grouping work. |
|
|
29
|
+
|
|
30
|
+
## The five named aesthetic clusters
|
|
31
|
+
|
|
32
|
+
These are complete looks, not single properties. Each is legitimate when the
|
|
33
|
+
brief calls for it and slop when it is reached for because it reads as
|
|
34
|
+
"designed."
|
|
35
|
+
|
|
36
|
+
| Cluster | Signature | Strength |
|
|
37
|
+
|---|---|---|
|
|
38
|
+
| Warm minimal | Warm cream background (near `#F4F1EA`), high-contrast serif display face, terracotta/clay accent | Strong when none of the three traces to the brief |
|
|
39
|
+
| Dark neon | Near-black background, single bright acid-green or vermilion accent | Strong when none of the three traces to the brief |
|
|
40
|
+
| Broadsheet | Hairline rules, `border-radius: 0` everywhere, dense multi-column text | Strong when applied to content that is not actually a publication |
|
|
41
|
+
| SaaS card kit | Identical rounded cards, one radius, one soft grey shadow, regardless of hierarchy | Strong when it is the layout's only structural device |
|
|
42
|
+
| Template chrome | Tracked-out ALL-CAPS eyebrow labels, middle-dot metadata, "WORD — fragment" label pattern | Strong when repeated site-wide with no variation |
|
|
@@ -0,0 +1,131 @@
|
|
|
1
|
+
# Design Plan Template
|
|
2
|
+
|
|
3
|
+
Fill this out before writing any markup or CSS. Keep it short — a paragraph
|
|
4
|
+
or a few lines per section — and revise it once against the last question
|
|
5
|
+
before building from it. The plan is working ground, not a deliverable; drop
|
|
6
|
+
it from the final output unless the brief asked to see it.
|
|
7
|
+
|
|
8
|
+
## 1. Brief
|
|
9
|
+
|
|
10
|
+
State in one or two sentences what this is, who asked for it, and what
|
|
11
|
+
"done" looks like. Quote the actual request rather than paraphrasing it into
|
|
12
|
+
something generic.
|
|
13
|
+
|
|
14
|
+
> Example: "A shift roster for a hospital ward, used by charge nurses to
|
|
15
|
+
> check who is on and swap shifts."
|
|
16
|
+
|
|
17
|
+
## 2. Users and frequency
|
|
18
|
+
|
|
19
|
+
Name who looks at this, and how often and for how long each time. A screen
|
|
20
|
+
checked twenty times a day for a few seconds needs a different design than
|
|
21
|
+
one read once for ten minutes.
|
|
22
|
+
|
|
23
|
+
> Example: "Charge nurses, roughly twenty times per shift, glancing for a
|
|
24
|
+
> few seconds at a time on a desk monitor."
|
|
25
|
+
|
|
26
|
+
## 3. Task
|
|
27
|
+
|
|
28
|
+
Name the one thing this screen is for. If there is more than one candidate,
|
|
29
|
+
pick the one that happens most often or matters most when it goes wrong.
|
|
30
|
+
|
|
31
|
+
> Example: "See who is on shift right now and who is on call next."
|
|
32
|
+
|
|
33
|
+
## 4. Density
|
|
34
|
+
|
|
35
|
+
Given the frequency and task above, decide how much shows at once: more
|
|
36
|
+
information with less chrome for a frequent, brief-glance screen; more
|
|
37
|
+
explanation and fewer items for an infrequent, unfamiliar one.
|
|
38
|
+
|
|
39
|
+
> Example: "High density: the full week's roster fits on one screen with no
|
|
40
|
+
> scrolling, at a size legible from arm's length on a desk monitor."
|
|
41
|
+
|
|
42
|
+
## 5. Hierarchy
|
|
43
|
+
|
|
44
|
+
State what is seen first, second and third, and why that order matches the
|
|
45
|
+
task in section 3 rather than what was easiest to make prominent.
|
|
46
|
+
|
|
47
|
+
> Example: "First: who is on right now, highlighted. Second: who is on call.
|
|
48
|
+
> Third: the rest of the week, in a lower-contrast grid."
|
|
49
|
+
|
|
50
|
+
## 6. Type
|
|
51
|
+
|
|
52
|
+
Name the typeface(s) and the reason for each — not "looks clean," but a
|
|
53
|
+
reason tied to the content (numeral legibility at a distance, a display face
|
|
54
|
+
that matches an existing brand mark, a monospace for aligned data).
|
|
55
|
+
|
|
56
|
+
> Example: "One typeface, a grotesque with strong numeral distinction, for
|
|
57
|
+
> both headings and body — no display face needed at this density."
|
|
58
|
+
|
|
59
|
+
## 7. Colour tokens
|
|
60
|
+
|
|
61
|
+
List four to six named tokens with hex values, each tied to a role and a
|
|
62
|
+
source (the brand's existing palette, or the content itself — a status
|
|
63
|
+
colour that already means something to this user).
|
|
64
|
+
|
|
65
|
+
> Example: `bg #0B1220` (screen background), `surface #16202E` (roster
|
|
66
|
+
> cells), `text #E7ECF3`, `accent-on-shift #3FB27F`, `accent-on-call #E0A930`,
|
|
67
|
+
> `danger-gap #E05252` (an uncovered slot).
|
|
68
|
+
|
|
69
|
+
## 8. Layout sketch
|
|
70
|
+
|
|
71
|
+
Draw the layout in ASCII. This is the step that catches a generic default
|
|
72
|
+
before it becomes code — if the sketch could belong to any dashboard, redo
|
|
73
|
+
it around the actual content.
|
|
74
|
+
|
|
75
|
+
```
|
|
76
|
+
+----------------------------------------------------+
|
|
77
|
+
| Ward 4B · Wed 10 Sep [ Swap ] [ Print] |
|
|
78
|
+
+----------------------------------------------------+
|
|
79
|
+
| NOW ON SHIFT | ON CALL NEXT |
|
|
80
|
+
| J. Alvarez R. Singh | M. Cho |
|
|
81
|
+
+----------------------------------------------------+
|
|
82
|
+
| Mon Tue Wed Thu Fri Sat Sun |
|
|
83
|
+
| --------------------------------------------- |
|
|
84
|
+
| AM [names in cells, one row per nurse] |
|
|
85
|
+
| PM [ ... ] |
|
|
86
|
+
| Night[ ... ] |
|
|
87
|
+
+----------------------------------------------------+
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
## 9. States
|
|
91
|
+
|
|
92
|
+
List what the layout must handle beyond the populated, average-length case:
|
|
93
|
+
empty, loading, error, long text (a long name overflowing a cell), many
|
|
94
|
+
items (more nurses than rows fit), one item (a ward with two nurses total),
|
|
95
|
+
and a narrow viewport.
|
|
96
|
+
|
|
97
|
+
> Example: "Empty slot shows a dashed outline and 'unfilled,' not a blank
|
|
98
|
+
> cell. A name too long to fit truncates with a tooltip, never wraps and
|
|
99
|
+
> breaks row height. Fewer than four nurses still fills the width without
|
|
100
|
+
> stretching cells absurdly wide."
|
|
101
|
+
|
|
102
|
+
## 10. Motion
|
|
103
|
+
|
|
104
|
+
State what, if anything, animates, and the purpose each animation serves. If
|
|
105
|
+
nothing needs to animate, say so.
|
|
106
|
+
|
|
107
|
+
> Example: "A swapped shift briefly highlights the changed cell for two
|
|
108
|
+
> seconds so the nurse who made the change can confirm it landed. Nothing
|
|
109
|
+
> else animates."
|
|
110
|
+
|
|
111
|
+
## 11. Copy
|
|
112
|
+
|
|
113
|
+
Note the voice and note that in-design copy follows the antislop pack of its
|
|
114
|
+
language (`antislop-en` or `antislop-ko`) — labels are specific to the
|
|
115
|
+
action, not a generic "Get started."
|
|
116
|
+
|
|
117
|
+
> Example: "Button labels name the action: 'Request swap,' not 'Get
|
|
118
|
+
> started.' No greeting copy; the nurse's name appears only where needed for
|
|
119
|
+
> identification."
|
|
120
|
+
|
|
121
|
+
## 12. What would make this generic — and the answer
|
|
122
|
+
|
|
123
|
+
Name the part of this plan most likely to be the default anyone would
|
|
124
|
+
produce for a similar brief, and state what makes it specific here instead.
|
|
125
|
+
If nothing survives this question, revise the plan before building.
|
|
126
|
+
|
|
127
|
+
> Example: "The three-column week grid could be any scheduling app. What
|
|
128
|
+
> makes it specific: the NOW/NEXT band above it, sized and coloured for a
|
|
129
|
+
> glance from across the nurses' station, which no generic scheduling
|
|
130
|
+
> template includes because it assumes a mouse and a close read, not a desk
|
|
131
|
+
> monitor checked in passing."
|