CtrlK
BlogDocsLog inGet started
Tessl Logo

evilissimo/modular-software-design

Use before implementing or refactoring software when the task requires designing module boundaries, APIs, layers, abstractions, services, repositories, adapters, or architecture. Helps coding agents reduce total system complexity by creating deep modules, hiding implementation knowledge, avoiding leakage and pass-through APIs, comparing alternative designs, documenting interfaces before coding, and critiquing existing architecture.

93

1.13x
Quality

94%

Does it follow best practices?

Impact

93%

1.13x

Average score across 5 eval scenarios

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

criteria.jsonevals/scenario-1/

{
  "context": "Tests design-before-coding workflow and deep module design for a non-trivial refactor.",
  "type": "weighted_checklist",
  "checklist": [
    {
      "name": "Design brief first",
      "description": "Includes a compact design brief before or alongside implementation rather than only code.",
      "max_score": 8
    },
    {
      "name": "Complexity goal",
      "description": "States a total-complexity goal involving reduced change amplification, cognitive load, hidden coupling, or future discount changes.",
      "max_score": 8
    },
    {
      "name": "Two alternatives",
      "description": "Compares at least two candidate designs.",
      "max_score": 10
    },
    {
      "name": "Comparison dimensions",
      "description": "Compares alternatives using at least four of: module depth, public surface, leakage, pass-throughs, layer fit, change impact, caller burden.",
      "max_score": 10
    },
    {
      "name": "Interface contract",
      "description": "Documents the chosen module interface with purpose, operations, inputs, outputs, errors or invariants, side effects, caller responsibilities, hidden knowledge, and non-goals.",
      "max_score": 12
    },
    {
      "name": "Deep module",
      "description": "Chooses a module that hides discount sequencing/rules behind a small caller-facing operation.",
      "max_score": 10
    },
    {
      "name": "No temporal split",
      "description": "Does not split the design mainly into parser/validator/processor-style steps for the discount workflow.",
      "max_score": 6
    },
    {
      "name": "Minimal API",
      "description": "Exposes few intention-revealing operations rather than many tiny methods matching each internal rule.",
      "max_score": 8
    },
    {
      "name": "Centralizes special cases",
      "description": "Centralizes or designs away discount special cases instead of leaving them duplicated in handlers.",
      "max_score": 8
    },
    {
      "name": "Design gates",
      "description": "Answers mandatory gates including deepest module, hidden knowledge, leakage/pass-through risk, and easier future change.",
      "max_score": 12
    },
    {
      "name": "Result report",
      "description": "Reports complexity hidden, interfaces changed/created, alternatives rejected, and remaining tradeoffs.",
      "max_score": 8
    }
  ]
}

evals

scenario-1

criteria.json

task.md

README.md

SKILL.md

tile.json