Fresh arch
A curated collection of reusable agent skills for design, research, browser automation, and developer tooling.
npx -y skills add archibate/agent-skills --skill fresh-archAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 16 days oldThe repository was created 16 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Architecture design reasoned forward from requirements. Use when the user wants a fresh-mind design pass — "design an architecture for", "how would you build", "redesign from scratch" — or when repeated follow-up patches accumulate on the same module. Repeated follow-up patches landing on the same module (~3rd) → stop patching, invoke this skill to re-derive from the full requirement set.
SKILL.md
1.9 KB, as published. Nobody here has run it
Design an architecture for the topic above by reasoning forward from requirements. If a codebase exists, you may Read/Grep it — but only as evidence to evaluate, not as a frame to fit the new design into.
Mindset
Catch yourself in any of these and stop — they are migration concerns smuggled in as design concerns:
- "the current code does X, so the new design should look similar"
- "we need to stay backward-compatible with X"
- "let's stick to the existing module boundaries / pattern / abstractions"
- "let's not be too aggressive / disruptive / far from what the team knows"
- "X is already wired up, so reuse it"
If a current pattern survives, it survives on merit — because it is the right answer when reasoned forward from requirements — not because it is already there.
Output
- Problem — 1-3 lines, what the system must do (not how).
- Components — 3-7 boxes, each with a one-sentence responsibility. Justify why these and not fewer/more.
- Contracts — interfaces / message shapes between components.
- Data & state — what's stored where, consistency model, lifecycle.
- Rejected alternatives — at least one different shape you considered and why this one wins.
- Critique of the current design (if a codebase exists) — judged against the design above. What the current system gets wrong, what it accidentally gets right, what is load-bearing vs. incidental. Not a migration plan; migration is a separate problem.