philipobenito
- 11 skills
- 0 followers
- 1 day ago last updated
- ▌ Work Tdd · philipobenito bundleRuns the red-green-refactor cycle. Writes a failing test, verifies it fails for the right reason, writes minimal code to pass, then refactors while green. Enforces the iron law that no production code is written without a failing test first.
- ▌ Work Swarm · philipobenito bundleImplements an approved design by sizing it against six evidence criteria, decomposing it into file-disjoint tasks, and running implementation, per-task review and verification concurrently through the workflow script shipped with this skill, with the lead keeping sole authority over commits, the checkpoint drain and the final feature-level review. Offered as one of the options whenever implementation of an approved design begins, and triggered directly by an explicit orchestration request, the user asking to swarm the work, to parallelise the implementation across agents, or to run the orchestrated implementation process. Requires an approved design in hand; without one, capture the design first. Stops and reports when a required capability is unavailable.
- ▌ Design Review · philipobenitoReviews a consolidated design summary for completeness, consistency, clarity, scope, and YAGNI by dispatching a fresh reviewer subagent against the summary text alone. Invoked by `design-dialogue` and `design-committee` once the design is consolidated and before final user approval; the inline design path below the design threshold deliberately does not use it. Returns an approved summary, the open decisions the design never made, or an escalation once its three-dispatch budget is spent. Not a standalone entry point; a design summary handed straight to Claude for review belongs to the design skill that owns it.
- ▌ Design Handoff · philipobenito bundlePersists an approved design into an artefact a future session can recover it from: tickets under a single parent whose body carries the full design, or a structured Markdown document when no ticketing system is available. Invoked by the design skills when the user chooses to create tickets after approving a design, and whenever the user asks to create tickets, file issues, break a design or plan into tickets, or set up a backlog. Handles GitHub Issues, Jira, GitLab and Linear. Requires an approved design already in hand; it does not invent one, and picking persisted work back up is the recovery skill's job, not this one's.
- ▌ Design Dialogue · philipobenitoTurns an idea into an approved design through interactive dialogue: explores the affected code, asks one question at a time, proposes one approach and argues against it, presents the design in sections, has the consolidated summary design-reviewed, and takes explicit approval before any hand-off. Offered as an option whenever design work above the design threshold begins, and triggers directly on an explicit request for interactive design: to design it together, to be walked through the design, to have an idea grilled or pressure-tested, or for you to push back on your own proposal. Scales from quickly capturing a design the user already holds to walking a newcomer through the area while designing. Not for bugs (debug-investigation takes its own fix approval), not for tickets already carrying an approved design, not for trivial changes below the design threshold, and not when the user asks for hands-off deliberation, which is design-committee's job.
- ▌ Design Recovery · philipobenito bundleRe-enters work from a persisted design: a ticket the user references by number or key ('work on #42', 'pick up PROJ-123', 'implement issue 7', 'start on the export epic'), or a design document they point at ('implement docs/export-design.md', 'pick up the backlog file'). Fetches the artefact, recovers the design from it or its parent, reads the current state of the code, presents the scope for confirmation, and starts implementation with the recovered design as the approved input. Use this rather than a fresh design session when the design already exists on the artefact. Without a specific reference it does not apply, and a question about what to work on next is triage rather than recovery.
- ▌ Design Committee · philipobenito bundleTurns an idea into an approved design through hands-off deliberation: three lens agents (Pragmatist, Architect, Advocate) state independent positions, cross-examine each other, and a synthesiser resolves each decision on evidence, all run as control flow by the workflow script shipped with this skill. Use when the user wants to be hands-off during design: 'committee', 'you decide', 'don't ask me design questions', 'come back when it's done'. The user confirms the brief, then sees nothing until the finished design is presented, design-reviewed, and put to them for explicit approval. Needs at least two meaningful design decisions; smaller work belongs to the interactive design dialogue.
- ▌ Work Verification · philipobenitoRuns the gate function that produces fresh verification evidence before a completion claim. Identifies the proving command, runs it fresh in the current message, reads the output, and only states the claim with cited evidence.
- ▌ Debug Investigation · philipobenitoRuns a disciplined, evidence-driven investigation to reproduce a bug, identify its root cause, and deliver a minimal verified fix. You MUST use this before touching any code in response to a bug, an error, a crash, a failing or flaky test, a regression, or anything described as not working, including one-line fixes and changes that look like an obvious typo: the hard gate (no fix without a reproduction and an identified root cause) applies however simple the fix looks. Enforces scope discipline, the investigation budget, and the minimal fix principle, and takes its own approval for the fix approach so bugs do not go through the design step.
- ▌ Work Review Receive · philipobenitoTurns code review feedback into verified, implemented changes: verifies each item against the codebase, pushes back with technical reasoning where the reviewer is wrong, and implements what survives in severity order. Use this whenever review feedback arrives from any source, whether a pull request comment, a reviewer subagent, a bot, or your human partner telling you what is wrong with the code, and whenever the user pastes review comments and asks you to address them. Invoked by `work-review-request` to act on its reviewer's findings. Enforces the ban on performative agreement and the requirement to push back rather than silently implement a suggestion you believe is wrong.
- ▌ Work Review Request · philipobenitoDispatches a code reviewer subagent against the work under review, applies severity discipline to its verdict, and owns the fix-and-re-review loop until no Critical or Important issue remains. Use this whenever a change is about to be committed to main, opened as a pull request, handed back as complete, or declared done, and whenever the user asks for a branch, a diff, or their changes to be looked over before shipping. Invoked by `work-swarm` for the feature-level review and by `debug-investigation` after a fix. No change is exempt for being small, simple, obvious, or locally tested.