All authors
Claude Skills by Tradebaas
github.com/Tradebaas20 skills0 installs35 views
- ArchitectDesign the system before building it: module boundaries, data model, integration contracts, environments, threat model. Use after stack choice and before the first build session, and again when a change would cross or move a boundary. Produces docs/product/ARCHITECTURE.md and decision records.Votes: 0GitHub stars: 2
- BeginStart a project on Groundwork: the interview (or the owner's PRD, description, idea text or existing code as its input), the filled templates, git and hooks, the first governed commit, one next step. Use when STATE.md says NOT STARTED, when the user says "begin", "start" or "nieuw project", or lays Groundwork over a project that already exists (adopt, retrofit, brownfield).Votes: 0GitHub stars: 2
- CalibratePick the model and effort level before a session starts, matched to the work planned and to token cost. Load when the user asks which model or effort to use, says "calibrate" or "pick a model", or describes the next session's work and wants the cheapest setup that finishes it in one pass. Never mid-session: the prompt cache is per model.Votes: 0GitHub stars: 2
- CheckpointFlush a lean mid-session handoff into STATE.md so the context can be cleared and the same work resumed in a fresh, cheap session. Load at roughly 15% of the context window (urgent past 40%), when a session feels long or slow, or when the user says "checkpoint", "handoff", "save tokens", "fresh session" or "/clear and continue". Transfer to another person is `handover`.Votes: 0GitHub stars: 2
- Code ReviewReview the diff of substantial work after `verify` and before the commit: a gate-weakening scan, then fresh-eyes axes for standards and for spec plus commit-message fidelity, plus a security axis on auth, payments, PII, external input, crypto or uploads, each reported by severity. Use before committing anything bigger than a trivial fix.Votes: 0GitHub stars: 2
- ComplyCompliance review against Dutch and EU law: GDPR/AVG, EU AI Act, accessibility (EAA/WCAG), NIS2, CRA, licensing. Use at project start (begin flags it), before first delivery, when new personal-data or AI processing is added, and at the quarterly audit. Verifies current rules against authoritative sources, never from memory.Votes: 0GitHub stars: 2
- Critical ThinkingThink before agreeing: the counterweight to the pull toward praising and building whatever is asked. Load when the user proposes a feature, approach or "wouldn't it be great if", when begin hands over a fresh idea, when weighing options in scope, spec, architect or design, or when you notice yourself about to agree enthusiastically. Names an alternative and the load-bearing assumption, then commits to the user's call.Votes: 0GitHub stars: 2
- DebugSystematic debugging when a failure's cause is unknown: reproduce first, isolate, fix the root cause once, prove it with a regression test. Use when a bug, crash, failing test or wrong output has no obvious cause, when a fix attempt did not work, or before claiming a stubborn bug fixed. For production incidents: stabilize first per `maintain`, then run this loop.Votes: 0GitHub stars: 2
- DeliverRelease, deploy, or hand over a milestone in a disciplined, repeatable way. Use when shipping to users, deploying to an environment, tagging a release, or closing out a milestone. Nothing ships that verify hasn't passed.Votes: 0GitHub stars: 2
- Design GuardJudgment check on user-facing output the installed design method does not carry: generated documents, e-mails, exports, error and CLI output, and interfaces on platforms it has no guidance for (game engines, console, embedded, print). For a frontend it re-checks the render against its direction contract and finish verdict. Run on what renders, not on the code.Votes: 0GitHub stars: 2
- DesignStand up the design system and voice, and run interface work through impeccable, the installed method: brand intake, the UI foundation, wording, and the owner's three decision points (direction, compositions, finish verdict). Use after the stack choice and before the first UI work, or when the owner wants the look or the voice defined or changed.Votes: 0GitHub stars: 2
- HandoverMake the project fully transferable to another human or agent with zero verbal context. Use at milestones, before breaks, when a new person/tool joins, or when the owner asks "can someone else take this over?". The end of an ordinary session is `checkpoint`, not this.Votes: 0GitHub stars: 2
- IngestConvert a non-Markdown file (PDF, Office, images, audio, HTML, CSV/JSON/XML, ZIP, EPub) to Markdown with markitdown before reading it, so tokens go to content rather than binary bulk. Use when a task needs such a file's contents, when adding reference material to docs/design/reference or a spec, or when the product must parse uploaded documents.Votes: 0GitHub stars: 2
- MaintainKeep a shipped product healthy: monitoring, updates, incidents, debt, periodic audits, retirement. Use after first production release, on a maintenance session, when dependencies need updating, when something broke in production, to harvest defer: markers into the debt ledger, or when a product, environment or integration is being retired and its data and access must actually go.Votes: 0GitHub stars: 2
- Scope GuardJudgment check before calling substantial work done or proposing a commit. Use before "done", before committing more than a trivial change, and whenever you notice yourself building something nobody asked for. The judgment layer above the automated gates, not a duplicate of them.Votes: 0GitHub stars: 2
- ScopeDefine, sharpen, or change project scope, and triage docs/state/INTAKE.md. Use when scope is unclear or contested, when new wishes/feedback arrive, when the owner asks for "more" mid-build, or when work doesn't trace to BRIEF.md. Scope changes only happen here, never silently during a build task.Votes: 0GitHub stars: 2
- Skill AuthorCreate a new project-fitting skill correctly, or decide that none is needed. Use when the project repeatedly needs expert guidance the existing skills don't carry, when the user asks for a new skill, or when the same correction has been given three times.Votes: 0GitHub stars: 2
- SpecRight-size and write the spec before building any change. Use before starting non-trivial work, when the user requests a feature, or when deciding whether something needs a spec at all. Prevents both drift (building unspecified things) and ceremony (specs for bugfixes).Votes: 0GitHub stars: 2
- StackChoose the tech stack or target platform (own servers, Power Platform, ServiceNow, Salesforce, Google, whatever exists by then) and make the project idiomatic for it: docs/standards/<stack>.md and the stack's own gates in CI and hooks. Use when the platform must be decided or those gates wired. Live research only, never stack facts from memory.Votes: 0GitHub stars: 2
- VerifyProve a change actually works before it counts as done. Use after building any non-trivial change, before deliver, and whenever claiming something works. Exercises real behavior end-to-end. Green tools alone are not verification.Votes: 0GitHub stars: 2