← all publishers

silviobeer

@silviobeer source repo

Report this profile Claim this profile

• 42 skills
• 0 followers
• 5 hours ago last updated

1. ▌
   Bootstrap 2 · silviobeer

   Turn an approved product vision into a running, empty project: decide the stack and record it as the single source of truth in docs/ARCHITECTURE.md § Stack, run the real scaffold command, verify build and tests are green, and write root AGENTS.md plus the CLAUDE.md pointer. Use when: (1) the product vision exists and the workspace has no application code yet, (2) an existing repo needs its stack recorded and its agent files created. Not for: an existing codebase with code to extract (use intake), product scope (use product-vision), PROJ-level tech design (use architecture), per-PROJ P0 setup (use setup).
   0 installs
2. ▌
   Cross Review 2 · silviobeer bundle

   Route a concept, PRD set, architecture, implementation plan, QA evidence, or curated documentation to the provider opposite its author for an adversarial, read-only review. Used by requirements-engineer before PRD handoff, inside QA for its required evidence review, and after creating a concept, architecture, wave plans, or P7 curated docs. Works before P0 without state.json. Not a replacement for runtime QA or form/size caps.
   0 installs
3. ▌
   Chain Guide · silviobeer bundle

   Context-aware guide through the 0-to-8 skill chain. Use when: (1) the user asks where they are or what to do next, (2) the user is unsure which skill to use, (3) starting a new feature or project, (4) the user says /chain-guide or /help. Detects current progress by checking existing files and recommends the next step.
   0 installs
4. ▌
   Checkpoint · silviobeer bundle

   Run a human checkpoint as a structured reconcile loop: present a compact review package, collect feedback point by point (adopt/change/reject/defer), write the decision log, cascade every change through all affected planning artifacts, and seal the result in state.json. Use when: (1) architecture + wave plans are ready for Checkpoint 1 approval before any execution, (2) PR review comments need reconciling at Checkpoint 2 (invoked via delivery), (3) intake bootstrap drafts need validation (via the intake skill, 0b). Not for: producing the plans themselves (use writing-plans), resolving PRD reviews on the discovery track (use review-reconcile), P0 setup (use setup).
   0 installs
5. ▌
   Checkpoint 2 · silviobeer bundle

   Run a human checkpoint as a structured reconcile loop: present a compact review package, collect feedback point by point (adopt/change/reject/defer), write the decision log, cascade every change through all affected planning artifacts, and seal the result in state.json. Use when: (1) architecture + wave plans are ready for Checkpoint 1 approval before any execution, (2) PR review comments need reconciling at Checkpoint 2 (invoked via delivery), (3) intake bootstrap drafts need validation (via the intake skill, 0b). Not for: producing the plans themselves (use writing-plans), resolving PRD reviews on the discovery track (use review-reconcile), P0 setup (use setup).
   0 installs
6. ▌
   Architecture · silviobeer

   Design PM-friendly technical architecture for a PROJ (covers all its PRDs). No code, only high-level design decisions. Use when: (1) all PRDs for a PROJ exist and need a unified tech design, (2) cross-cutting tech decisions need PM-friendly justification, (3) before creating implementation plans. Not for: writing code, per-PRD micro-decisions, or requirements gathering.
   0 installs
7. ▌
   Architecture 2 · silviobeer

   Design PM-friendly technical architecture for a PROJ (covers all its PRDs). No code, only high-level design decisions. Use when: (1) all PRDs for a PROJ exist and need a unified tech design, (2) cross-cutting tech decisions need PM-friendly justification, (3) before creating implementation plans. Not for: writing code, per-PRD micro-decisions, or requirements gathering.
   0 installs
8. ▌
   Brainstorming · silviobeer

   Use as Step 1 of the PROJ workflow before creating or changing any feature, component, workflow, or behavior. Turns a feature idea into one or more approved buildable concepts through project discovery, scope decomposition, structured intake, bounded exploration, assumption playback, and risk review. Produces specs/PROJ-<X>-<theme>/1_brainstorm/PROJ-<X>-concept.md, then hands off to visual-companion for UI features or requirements-engineer for backend/API features.
   0 installs
9. ▌
   Concept Sync · silviobeer

   Reconcile mockup iteration changes back into the concept before requirements. Use after ui-mockup when stakeholders have iterated on the mockups (changes prompted directly into the HTML) and the agreed result must flow back into the concept. Reads the mockup iteration log, updates the concept doc, marks abandoned decisions, and signals handoff-ready for requirements-engineer. Primary step of the Product Discovery track, but also usable in the full 0-to-8 chain.
   0 installs
10. ▌
    Writing Plans · silviobeer bundle

    Create wave-based implementation plans from architecture + PRDs. One plan file per wave. Use when: (1) the PROJ architecture is approved and PRDs exist, (2) user stories across PRDs need to be grouped into parallel execution waves, (3) before any code is written. Not for: high-level design (use architecture), requirements gathering, or direct implementation.
    0 installs
11. ▌
    Documentation · silviobeer bundle

    Create and curate human-readable project documentation after QA passes. Produces README.md, docs/PROJECT.md, docs/TECHNICAL.md, conditionally merges approved AGENTS.md candidates, keeps CLAUDE.md pointer-only when present, and in framework runs curates the long-lived docs/ baseline behind the P7 gates (curation-caps.sh for form, cross-review for truth). Use when: (1) a feature has passed QA, (2) the user asks for app documentation, feature documentation, technical documentation, diagrams, data model notes, or data-flow explanation, (3) before handoff. Not for: writing PRDs, API reference generation, or first-run onboarding flows.
    0 installs
12. ▌
    Brainstorming 2 · silviobeer

    Use as Step 1 of the PROJ workflow before creating or changing any feature, component, workflow, or behavior. Turns a feature idea into one or more approved buildable concepts through project discovery, scope decomposition, structured intake, bounded exploration, assumption playback, and risk review. Produces specs/PROJ-<X>-<theme>/1_brainstorm/PROJ-<X>-concept.md, then hands off to visual-companion for UI features or requirements-engineer for backend/API features.
    0 installs
13. ▌
    Writing Plans 2 · silviobeer bundle

    Create wave-based implementation plans from architecture + PRDs. One plan file per wave. Use when: (1) the PROJ architecture is approved and PRDs exist, (2) user stories across PRDs need to be grouped into parallel execution waves, (3) before any code is written. Not for: high-level design (use architecture), requirements gathering, or direct implementation.
    0 installs
14. ▌
    Documentation 2 · silviobeer bundle

    Create and curate human-readable project documentation after QA passes. Produces README.md, docs/PROJECT.md, docs/TECHNICAL.md, conditionally merges approved AGENTS.md candidates, keeps CLAUDE.md pointer-only, and in framework runs curates the long-lived docs/ baseline behind the P7 gates (curation-caps.sh for form, cross-review for truth). Use when: (1) a feature has passed QA, (2) the user asks for app documentation, feature documentation, technical documentation, diagrams, data model notes, or data-flow explanation, (3) before handoff. Not for: writing PRDs, API reference generation, or first-run onboarding flows.
    0 installs
15. ▌
    Refactor Dreamer · silviobeer

    Run a long-form, parallel architecture drift and refactor discovery pass over the current codebase. Use when the user wants an overnight/deep exploration that sends subagents through the repo to identify larger refactor opportunities, architecture mismatches caused by feature growth, simplification targets, technical debt themes, and chain-ready inputs for later brainstorming, architecture, or implementation planning. Produces evidence-backed reports and handoff artifacts only; it does not change code and is not part of the 0-7 feature chain.
    0 installs
16. ▌
    Refactor Dreamer 2 · silviobeer

    Run a long-form, parallel architecture drift and refactor discovery pass over the current codebase. Use when the user wants an overnight/deep exploration that sends subagents through the repo to identify larger refactor opportunities, architecture mismatches caused by feature growth, simplification targets, technical debt themes, and chain-ready inputs for later brainstorming, architecture, or implementation planning. Produces evidence-backed reports and handoff artifacts only; it does not change code and is not part of the 0-7 feature chain.
    0 installs
17. ▌
    Product Vision · silviobeer

    Establish what a product IS before any feature is designed: interview the product owner into docs/PRODUCT.md (purpose, audience, non-goals, success) and cut the product into a numbered PROJ map in specs/product-roadmap.md. Use when: (1) a new product/project starts and no docs/PRODUCT.md exists, (2) the product direction changed and the map needs a revision round. Not for: a single feature in an existing product (use brainstorming), extracting the baseline from an existing codebase (use intake), stack or scaffold decisions, feature detail.
    0 installs
18. ▌
    Product Vision 2 · silviobeer

    Establish what a product IS before any feature is designed: interview the product owner into docs/PRODUCT.md (purpose, audience, non-goals, success) and cut the product into a numbered PROJ map in specs/product-roadmap.md. Use when: (1) a new product/project starts and no docs/PRODUCT.md exists, (2) the product direction changed and the map needs a revision round. Not for: a single feature in an existing product (use brainstorming), extracting the baseline from an existing codebase (use intake), stack or scaffold decisions, feature detail.
    0 installs
19. ▌
    Frontend Design · silviobeer

    Define the design system — starting with a mood-led minimum set of colors, typography, buttons, and form controls — plus the component catalog and a running showcase page, before UI mockups and requirements. Use after visual-companion when: (1) greenfield project with no existing design system, (2) the user wants a distinctive visual identity before mockups, (3) no theme tokens or CSS variables exist yet. Skip for brownfield projects with an established design system.
    0 installs
20. ▌
    Handoff Package · silviobeer

    Assemble a standalone, distributable handoff package from discovery artifacts for downstream UI/UX experts and developers. Use after requirements-engineer on the product discovery track when the concept, mockups, and PRDs must be packaged into one self-contained dated run folder (and ZIP) that external readers can consume without access to the rest of the repo. Produces a delta since the previous handoff, README index, manifest, single-source-of-truth scope/decisions doc, role-split UI and developer handoffs, copied mockups, and a paste-ready Linear import.
    0 installs
21. ▌
    Supabase Local Dev · silviobeer

    Diagnose and prevent shared-local-Supabase-DB problems on a repo using local Supabase for development — migration drift between git worktrees, RLS/grant surprises, config.toml vs. deployed truth. Use when a Supabase-backed action fails with a permission/grant/RLS error that "shouldn't" happen given the code and the repo's own supabase/migrations/, when switching branches or worktrees on a Supabase project, or when asked to investigate why local dev behavior doesn't match the migrations in the current branch. Not for remote/hosted Supabase project administration, and not part of the core 0-to-8 chain (the chain stays database-agnostic).
    0 installs
22. ▌
    Frontend Design 2 · silviobeer

    Define the design system — starting with a mood-led minimum set of colors, typography, buttons, and form controls — plus the component catalog and a running showcase page, before UI mockups and requirements. Use after visual-companion when: (1) greenfield project with no existing design system, (2) the user wants a distinctive visual identity before mockups, (3) no theme tokens or CSS variables exist yet. Skip for brownfield projects with an established design system.
    0 installs
23. ▌
    Visual Companion · silviobeer

    Explore interactive UI structure before requirements. Use when a concept exists and the team needs to discuss and decide the rough shape of the interface: sidepanel vs modal vs drawer vs split view vs wizard vs dedicated page, navigation model, screen flow, and interaction container. Starts with conversational discovery questions, then produces multiple clickable low-fidelity HTML approaches grounded in the existing app, then returns to conversation for selection and iteration. Not for polished visual design, final mockups, colors/typography, or detailed acceptance criteria.
    0 installs
24. ▌
    Review Reconcile · silviobeer

    Resolve a developer or stakeholder review of finished PRDs by going through the raised gaps point by point, deciding each with the product owner or deferring it to a developer meeting, then reconciling the agreed outcomes back into the PRDs, concept, and mockups. Use after requirements-engineer (and any handoff) when a review comes back with gaps, ambiguities, or open questions on the PRDs. Records a decision log, keeps unresolved items as an explicit developer-meeting agenda, and maintains a handoff-facing changelog so external teams (UI/UX, devs) can follow what changed since the version they reviewed. Sibling of concept-sync on the Product Discovery track.
    0 installs
25. ▌
    Requirements Engineer · silviobeer

    Create detailed feature PRDs with user stories, acceptance criteria, and edge cases after Visual Companion, optional Frontend Design, and UI Mockup. Use when: (1) an approved concept and optional UI mockups need to become structured PRDs, (2) user stories and acceptance criteria must be written, (3) edge cases must be identified. Not for: UI mockups, writing code, technical design, or debugging.
    0 installs
26. ▌
    Executing Large Model · silviobeer

    Lean Step 5 variant for frontier models (Claude Fable/Mythos 5.x, Opus 5, GPT-5.x or later): same state.sh, wave-gate, ledger, Quality Gate and QA-handoff contracts as 5_executing, with the step-by-step TDD choreography and persona reviews removed in favor of intent and invariants; the strongest model leads, workers stay tiered by Complexity, reviews go to the strongest opposite model. Use when: (1) wave plans exist and CP1 is sealed, (2) the writer lane runs on a frontier model, (3) a run should be compared against the full 5_executing procedure. Not for: weaker models, planning, architecture, requirements, or a repo without 5_executing installed.
    0 installs
27. ▌
    Vibecoder · silviobeer

    Run a freeform exploratory coding session (a spike) on a scratch branch, keep a live journal of what gets tried and why direction changes as it happens, then distill that journal plus the resulting diff into a chain-ready concept seed once the session wraps up. Use when the user wants to vibe-code, prototype freely, or explore an idea in code before committing to a concept: going back and forth, trying dead ends, changing direction mid-session. Has three entry points: start a spike (scratch branch + live journal), resume a spike (re-load the journal and pick live documentation back up after a session break), and wrap up a spike (distill journal + diff into specs/_vibecoder/.../chain-input.md, then ask what to do with the branch). Not part of the 0-8 chain; its chain-input.md feeds 1_brainstorming as raw input, not a replacement for it. Not for planned feature work, TDD implementation, or bug fixes — use writing-plans/executing or bugfixing instead.
    0 installs
28. ▌
    Intake 2 · silviobeer bundle

    Bootstrap the curated context baseline for a brownfield (or near-greenfield) repo: scan the code and draft ALL curated docs with per-statement provenance markers, interview the developer through every gap/assumption/inconsistency, reconcile via the checkpoint loop, then seal as the initial curation baseline commit. Use when: (1) a repo has code but no curated docs/ baseline (docs/PRODUCT.md missing), (2) an explicit drift audit of the curated docs is requested, (3) a near-greenfield project needs its baseline before the first PROJ. Not for: per-PROJ documentation (use documentation), ongoing doc updates (P7 curation owns those), plan approval (use checkpoint).
    0 installs
29. ▌
    Delivery · silviobeer bundle

    Run P8 delivery for a finished PROJ: probe merge conflicts against main in a throwaway worktree, render the PR body from state.json + findings.json, create the PR via gh, poll CI with a bounded fix loop, and reconcile Checkpoint 2 review comments. Use when: (1) documentation (7) is complete and committed on the PROJ branch, (2) CI turned red on an open PROJ PR and needs the bounded fix loop, (3) PR review comments came back and need the CP2 reconcile loop. Not for: implementing stories (use executing), QA (use qa), writing docs (use documentation), plan approval (use checkpoint).
    0 installs
30. ▌
    Delivery 2 · silviobeer bundle

    Run P8 delivery for a finished PROJ: probe merge conflicts against main in a throwaway worktree, render the PR body from state.json + findings.json, create the PR via gh, poll CI with a bounded fix loop, and reconcile Checkpoint 2 review comments. Use when: (1) documentation (7) is complete and committed on the PROJ branch, (2) CI turned red on an open PROJ PR and needs the bounded fix loop, (3) PR review comments came back and need the CP2 reconcile loop. Not for: implementing stories (use executing), QA (use qa), writing docs (use documentation), plan approval (use checkpoint).
    0 installs
31. ▌
    Executing · silviobeer bundle

    Execute implementation plans user-story by user-story in dependency order, using TDD, wave-scoped Ralph verification, wave gates, code review, and QA handoff. Use when: (1) an implementation plan exists and is ready for execution, (2) feature tasks need to be implemented with disciplined verification. Not for: planning, architecture, or requirements.
    0 installs
32. ▌
    Executing 2 · silviobeer bundle

    Execute implementation plans user-story by user-story using agent teams, TDD, wave-scoped Ralph verification, wave gates, and an integration-focused Quality Gate before mandatory QA. Use when: (1) an implementation plan exists and is ready for execution, (2) feature tasks need to be implemented with TDD. Not for: planning, architecture, or requirements.
    0 installs
33. ▌
    Bootstrap · silviobeer

    Turn an approved product vision into a running, empty project: decide the stack and record it as the single source of truth in docs/ARCHITECTURE.md § Stack, run the real scaffold command, verify build and tests are green, and write root AGENTS.md plus the CLAUDE.md pointer. Use when: (1) the product vision exists and the workspace has no application code yet, (2) an existing repo needs its stack recorded and its agent files created. Not for: an existing codebase with code to extract (use intake), product scope (use product-vision), PROJ-level tech design (use architecture), per-PROJ P0 setup (use setup).
    0 installs
34. ▌
    UI Mockup · silviobeer

    Create lightweight HTML mockups, a visual sitemap, and a UI implementation handoff before requirements. Use after visual-companion and optional frontend-design when: (1) UI flows need to be visualized before requirements and architecture, (2) a page/screen sitemap is needed, (3) stakeholders need visual feedback before user stories are finalized. Not for: requirements, component libraries, technical architecture, or production UI code.
    0 installs
35. ▌
    Cross Review · silviobeer bundle

    Route a concept, PRD set, architecture, implementation plan, QA evidence, or curated documentation to the provider opposite its author for an adversarial, read-only review. Used by requirements-engineer before PRD handoff, inside QA for its required evidence review, and after creating a concept, architecture, wave plans, or P7 curated docs. Works before P0 without state.json. Not a replacement for runtime QA or form/size caps.
    0 installs
36. ▌
    QA · silviobeer bundle

    Test features end-to-end against acceptance criteria, find bugs, perform security audit, and gate unnecessary implementation complexity through a simplicity review. Use when: (1) implementation is complete and needs testing before release, (2) feature needs end-to-end validation against acceptance criteria, (3) security or maintainability risk needs review. The QA agent finds and documents bugs — it NEVER fixes them. Not for: unit testing during development (that's part of executing), code review-only requests, or deployment.
    0 installs
37. ▌
    QA 2 · silviobeer bundle

    Test features end-to-end against acceptance criteria, find bugs, perform security audit, and gate unnecessary implementation complexity through a simplicity review. Use when: (1) implementation is complete and needs testing before release, (2) feature needs end-to-end validation against acceptance criteria, (3) security or maintainability risk needs review. The QA agent finds and documents bugs — it NEVER fixes them. Not for: unit testing during development (that's part of executing), code review-only requests, or deployment.
    0 installs
38. ▌
    Setup · silviobeer bundle

    Run P0 setup for an approved PROJ: preflight all required CLIs and auth states, create the proj/PROJ-X branch with BASE_SHA tag, copy the framework scripts and templates into the repo, and extend state.json for the execution phases. Use when: (1) Checkpoint 1 approval is sealed in state.json (CP1:approved) and execution has not started, (2) preflight must be re-run after fixing a stop condition, (3) the framework scripts in the repo need refreshing from the installed skills. Not for: architecture/plan approval (use checkpoint), implementing stories (use executing), PR delivery (use delivery).
    0 installs
39. ▌
    Setup 2 · silviobeer bundle

    Run P0 setup for an approved PROJ: preflight all required CLIs and auth states, create the proj/PROJ-X branch with BASE_SHA tag, copy the framework scripts and templates into the repo, and extend state.json for the execution phases. Use when: (1) Checkpoint 1 approval is sealed in state.json (CP1:approved) and execution has not started, (2) preflight must be re-run after fixing a stop condition, (3) the framework scripts in the repo need refreshing from the installed skills. Not for: architecture/plan approval (use checkpoint), implementing stories (use executing), PR delivery (use delivery).
    0 installs
40. ▌
    Intake · silviobeer bundle

    Bootstrap the curated context baseline for a brownfield (or near-greenfield) repo: scan the code and draft ALL curated docs with per-statement provenance markers, interview the developer through every gap/assumption/inconsistency, reconcile via the checkpoint loop, then seal as the initial curation baseline commit. Use when: (1) a repo has code but no curated docs/ baseline (docs/PRODUCT.md missing), (2) an explicit drift audit of the curated docs is requested, (3) a near-greenfield project needs its baseline before the first PROJ. Not for: per-PROJ documentation (use documentation), ongoing doc updates (P7 curation owns those), plan approval (use checkpoint).
    0 installs
41. ▌
    Bugfixing · silviobeer bundle

    Reproduce, diagnose, plan, implement, and verify reported software bugs, regressions, broken UI flows, incorrect behavior, and production defects. Use whenever a user asks to fix a bug or regression, investigate why behavior is wrong, or explain why existing tests missed a defect. Reproduce browser-facing bugs in a real browser when safe and available, prove the regression test fails before the fix, dispatch a narrowly scoped implementer, run a bounded Ralph verification loop, and document the test-escape cause. Not for feature requests, speculative refactors, or QA-only discovery without a requested fix.
    0 installs
42. ▌
    Sonar CLI · silviobeer bundle

    Set up, run, troubleshoot, and triage SonarQube Cloud/Server analysis from Codex. Use when working with SonarScanner CLI (`sonar-scanner`), SonarQube CLI (`sonar`), SonarCloud project setup, quality gate creation/assignment/status, `sonar-project.properties`, `SONAR_TOKEN`, coverage import/LCOV merging, issue/security hotspot queries, scanner authentication failures, or confusion about which Sonar CLI to use.
    0 installs