All authors
Claude Skills by manoldonev
github.com/manoldonev27 skills0 installs61 views
- Writing TestsUse when adding or changing a test in this repo — the tier map (where a new guard goes), the scenario-first rule, the no-prose-presence-guards and no-mirror-harnesses rules, and the mjs-seam grep exception.Votes: 0GitHub stars: 2
- Audit HistoryCross-session aggregator for the audit ledger. Walks every .claude/audit/*.jsonl in the recent N-day window and surfaces visibility signals for manual review. Observability only.Votes: 0GitHub stars: 2
- AuditRead-only query of the current Claude Code session's tool-call ledger. Surfaces what tools Claude actually invoked (vs. what Claude claims it invoked). Observability only — a visibility signal for manual review.Votes: 0GitHub stars: 2
- Design Faithful SpecNormalize a Claude Design handoff into a faithful frontend spec for the repo — completeness inventory, behavioral/state contract, and design→real-stack component map. Use to turn a screen-level design handoff into an implementable FE spec before writing code. Dispatched by the intake router''s design-handoff route, or by a session''s choice.Votes: 0GitHub stars: 2
- Design FaithfulImplement a screen/component in the repo''s FE app with high visual fidelity to a Claude Design handoff — mirror the nearest analog, reuse the repo''s primitives and tokens, then live-render self-verify against the bundled screenshot and commit. Use to turn a design-faithful-spec (or a handoff) into committed FE code. Dispatched by a session''s choice under the outcome-gated lane.Votes: 0GitHub stars: 2
- Figma Faithful SpecTranscribe an existing Figma design + ticket into a faithful FE spec — verbatim Copy Index, component identity, state coverage, BE-field map. Use when a Figma design already exists; not for shaping a feature that is still undecided. Requires the figma design provider (config `design.provider: "figma"`).Votes: 0GitHub stars: 2
- Figma FaithfulFaithful Figma-to-code implementation for FE work — enforces token extraction, layout-context reading, real-component resolution, and self-verification so spacing/copy/components are measured, not guessed. Use when building a screen/component from a Figma design. Requires the figma design provider (config `design.provider: "figma"`).Votes: 0GitHub stars: 2
- Figma IterateFast interactive Figma-to-code iteration for a consumer FE repo iterating quickly in alpha — takes Figma node URL(s) + optional override notes and produces a structurally faithful implementation via the figma-faithful discipline, resolving any Figma/reality discrepancies at one batched confirmation instead of blocking. Interactive-only; leaves the tree dirty (never commits); no ticket/reviewer ceremony. Requires the figma design provider (config `design.provider: "figma"`).Votes: 0GitHub stars: 2
- BuildThe interactive BUILD — the build half of /dev-pipeline:run, run in THIS session so the operator can steer it. run.sh claims the ticket, cuts the worktree, commits the intake record as the branch's first commit and hands over the same build prompt an unattended run spawns; you build to a draft PR, then /dev-pipeline:review grades it and marks it ready on an approve from a fresh session. Expects the same paid-off intake as /dev-pipeline:run.Votes: 0GitHub stars: 2
- ReviewThe REVIEW half of the pipeline — review an open pipeline PR from a fresh top-level session, score every row of its decision record, and post one verdict comment for the human who decides the merge. The manual form of what /dev-pipeline:run's review session does; use it when a run ends review-unbound, or to review a lane PR by hand.Votes: 0GitHub stars: 2
- RunThe pipeline''s front door — one ticket in, a merge-ready PR out. Drives run.sh, a scheduler that claims the ticket, commits its intake record, and spawns fresh build and review sessions until a review approves the current head or a budget is spent; you author nothing. Expects a ticket with paid-off intake: an intake record, plus the queue label on GitHub (under jira there is no label to check, so launching is the operator''s attestation).Votes: 0GitHub stars: 2
- Decomposition ReviewerReviews a set of already-scoped sub-issues for cross-ticket consistency, convention adherence, operational implications, and coverage gaps. Use after intake-orchestrator has produced tickets.Votes: 0GitHub stars: 2
- Grill MeInterview the user relentlessly about a plan or design and record each resolution in the artifact's Decision Ledger, with its provenance. Use when the user wants a plan stress-tested, asks to be grilled on a design, or says "grill me".Votes: 0GitHub stars: 2
- Intake InterviewerInterviews the user on an unstructured bug report or rough feature idea until the output would pass spec-reviewer (feature) or is reproducible (bug). Emits a GitHub-issue-ready body.Votes: 0GitHub stars: 2
- Intake OrchestratorOrchestrates spec review + scope decomposition for the dev-pipeline. Dispatches sub-agents, evaluates findings critically, decides whether to split work into parallel or sequential sub-issues.Votes: 0GitHub stars: 2
- IntakeManually triggered via /intake-toolkit:intake — the front door to the elicitation surface. Give it anything (a GitHub issue number, a pasted blob, a rough idea, an existing plan, a design handoff) and it classifies the scenario and routes to the right skill. Dispatch-only; contains no elicitation protocol of its own. Do not auto-select this skill; the routed skills carry their own triggers.Votes: 0GitHub stars: 2
- Interviewing BaselineShared interviewing protocol for all intake-role skills (intake-interviewer, plan-interview, grill-me, intake-orchestrator escalations). Provides the interview loop rules and the Decision Ledger contract — schema, provenance enum, explicit-empty form.Votes: 0GitHub stars: 2
- Plan InterviewUse BEFORE writing any implementation plan for behavior-changing work — plan mode, a direct feature/fix ask, or pre-flight for a dev-pipeline ticket. Surfaces the load-bearing design decisions to the engineer while the plan is forming and emits the Decision Ledger the plan gates require. Not for typo/mechanical fixes.Votes: 0GitHub stars: 2
- Review LeadReviewer selection happens in-session: choose from the effective reviewer registry — the plugin-shipped panel (review-toolkit:security-reviewer, review-toolkit:performance-reviewer, review-toolkit:db-reviewer) plus/minus the consumer config deltas — and pass the selected agentType[] as args.reviewers.Votes: 0GitHub stars: 2
- Review LeadReviewer selection happens in-session: choose from the effective reviewer registry — the plugin-shipped panel (review-toolkit:security-reviewer, review-toolkit:performance-reviewer, design-toolkit:design-faithful-reviewer) plus/minus the consumer config deltas — and pass the selected agentType[] as args.reviewers. Every panel entry is written QUALIFIED — `review-toolkit:` for this root's own agents, `design-toolkit:` for the sibling's — which is what failure class (e) requires, and which pins...Votes: 0GitHub stars: 2
- Review LeadReviewer selection happens in-session: choose from the effective reviewer registry — the plugin-shipped panel (review-toolkit:security-reviewer, review-toolkit:performance-reviewer) plus/minus the consumer config deltas — and pass the selected agentType[] as args.reviewers.Votes: 0GitHub stars: 2
- Mutation ReviewPropose→execute mutation-review protocol for co-located unit tests — mock-boundary discipline, assertion-strength anti-patterns, the propose/execute split, and the blocker-mutant emission contract. Runner commands and repo-specific blocker mutants come from the consumer config and extension files.Votes: 0GitHub stars: 2
- Review LeadOrchestrates parallel code review across specialized reviewers. Use when reviewing code changes, PRs, or before committing.Votes: 0GitHub stars: 2
- Reviewer BaselineShared review protocol for all code reviewer agents. Provides confidence scoring, finding classification, suppressed findings format, and standardized output structure.Votes: 0GitHub stars: 2
- DoctorVerify this repo's second-shift install/config state against the committed lockfile - prerequisites, settings/lockfile ref lockstep, never-installed, enabled-but-not-installed, version drift (behind AND ahead), project-scope records a user-scope one makes redundant, ref-less marketplace shadowing, skill/agent shadow collisions, a review-toolkit older than the plugins that read its fan-out, opt-outs (informational), whether the default branch requires the second-shift/review status (informatio...Votes: 0GitHub stars: 2
- Local Dev RefreshRefresh THIS MACHINE's second-shift plugin state - update the second-shift marketplace catalog, then every plugin installed from it ('plugin update' is the verb that actually upgrades - 'install' no-ops as "already installed"), realign the current repo's project-scope stragglers - reporting rather than refreshing the ones a user-scope record already makes redundant - print the before/after version delta, remind to restart. Scoped to the second-shift marketplace only - other marketplaces on th...Votes: 0GitHub stars: 2
- OnboardOnboard the current repo onto the second-shift marketplace - detects tracker/commands with provenance, drafts the configVersion 3 config for one accept-or-edit review, writes settings pin + config + lockfile + the consent doc (and, on request, the unclaim workflow), validates with config-lint. Run from the target consumer repo. Requires jq, gh (authenticated), git, claude.Votes: 0GitHub stars: 2