Purpose fit design
Skill perhapsspy/project-legibility/plugins/project-legibility/skills/purpose-fit-design
Keep long-running repository work coherent and easy to resume.
npx -y skills add perhapsspy/project-legibility --skill purpose-fit-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 26 days oldThe repository was created 26 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.
- 5 stars5 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
Use to set an early design or implementation-planning direction from user/domain purpose, explicit constraints, current evidence, and verifiable success conditions. Apply to new features, reuse decisions, and temporary implementations when existing code, precedent, defaults, or urgency could steer the choice. Direct source discovery, settled implementation work, and clear specialist problems to their owning workflows.
SKILL.md
3.6 KB, as published. Nobody here has run it
Purpose-Fit Design
Job
Set an early direction that fits the user/domain purpose, explicit constraints, current evidence, and the minimum observable success. Treat existing implementation and precedent as evidence, not automatic authority.
End with a provisional direction, the smallest useful check, or one question that blocks the choice. Keep implementation scope tied to the chosen purpose and confirmed contracts.
Fit Check
Answer only what affects the decision. A small task may need one paragraph.
- Purpose: state the user/domain outcome and minimum observable success.
- Constraints: state explicit corrections, rejected concepts, and limits on the choice.
- Evidence: identify what is confirmed, unknown, or merely suggested by existing code, precedent, or defaults. Treat urgency as a delivery constraint, not evidence of fit.
- Direction: choose a provisional direction and name the evidence or smallest check that could change it.
Investigate or ask one focused question when a missing fact changes the choice. Keep the gap explicit until evidence resolves it.
Compare alternatives only for a material choice: one that changes responsibility, persistent state, policy, dependency, lifecycle, public contract, compatibility, or hard-to-reverse coupling.
Treat explicit user corrections as binding. Apply them at the reach implied by the request, preserve unaffected constraints, and keep rejected concepts outside the direction.
A technical default, fallback, or security/consistency claim is a design choice when it changes user-visible behavior, domain meaning, or policy. Otherwise, keep it as a technical detail.
For a temporary implementation, choose the smallest useful slice that preserves purpose and constraints. Require a credible way to verify and reverse it, but add an adapter, wrapper, or rollback boundary only when it materially helps.
Specialist Handoff
Use a specialist directly when the problem is already clear. While checking an unresolved direction, hand off when a missing fact blocks the choice:
- source ownership when the governing contract is unknown;
- semantic boundaries when one meaning may differ across layers;
- interactive state flow when intent, async work, presentation, or freshness are mixed;
- structure-first after direction is settled and code shape or verification is the remaining problem.
Red Flags
- Reusing something because it already exists, without checking purpose and constraints.
- Adding policy or structure from a vague security, consistency, or future-use claim.
- Reintroducing an explicitly rejected concept under another name or layer.
- Treating "copy now, clean later" as sufficient without a verification and reversal story.
Final Check
Before implementation or final recommendation, confirm:
- The direction fits the purpose, constraints, and observable success.
- Existing code and precedent were treated as evidence rather than default authority.
- Explicit corrections and rejected concepts remain respected.
- The choice has a useful verification or a clearly named unknown.
- The process weight matches the size and reversibility of the choice.