shode-house

Plugin shode-house from marketplace shode-house in shode666/shode-house. Commands read from the repo's manifest — 12 days ago.

Skills (20)

• domain-core

  Shared contract for domain expert personas, requiring an AI persona disclaimer and primary-source citations for any claim about a regulation, standard or protocol, and explicit marking when a source cannot be verified. It governs domain claims, not general project evidence or which expert is needed.

• review-checklist

  Coordinate independent review of an implemented change by code, runtime, spec, security and domain with severity and merge gates, not self-approval.

• shode-house-deliverable

  Output and completion contract for anyone producing a deliverable - durable artifact, re-checkable evidence for every claim, no placeholders, no completion claim without real tool output. Not how work is routed or reviewed.

• shode-house-discipline

  Baseline conduct for team members: evidence, scope, language and handoff. Not phase order, ownership or the safety floor (see ask).

• shode-house-routing

  Decide who owns a request, covering type of work, responsible role, conflict resolution, parallel versus sequential execution, and whether a domain specialist is needed because the work requires a domain rule decision rather than merely using domain vocabulary. Phase order and approvals are not deci

• shode-house-workflow

  Coordinate multi-phase delivery with phase gates, recorded approvals, run recovery and drift detection, governing how work proceeds, not who owns it.

• drain

  Batch-drain ready tickets with isolated workers, independent review, serial merge and evidenced closure (จัดงานที่พร้อม, ปิดงานค้าง). For work not split into concrete, independent tickets, use decompose.

• incident

  Respond to active production impact such as an outage, degradation, data loss or breach by assigning severity and mitigating first, then a blameless postmortem. Not for bugs not currently hurting production users, nor planned maintenance.

• secure

  Threat model and review a design or change that crosses a meaningful security boundary, such as authentication, authorization, secrets, cryptography, personal or payment data, untrusted input or public exposure. Not for a live incident or unrelated local refactors.

• slo

  Define reliability targets for a production service, covering service level indicators and objectives, error budget policy and burn-rate alerting. Not for responding to a live outage, nor for internal tools or one-off batch jobs.

• caveman

  Switch to an ultra-compressed reply style that drops filler but keeps technical terms, code, numbers and security warnings verbatim, only when the user explicitly asks for terse output. It is never the default and ends when the user asks for normal prose.

• ui-test

  Automated browser-level end-to-end, visual regression and accessibility testing of a changed, rendered user interface, plus the UI quality rules every frontend change follows. Not for backend-only changes, unrendered designs, or site performance audits.

• web-q

  Audit and improve a public-facing website across Core Web Vitals, performance budgets, SEO, structured data and security headers against agreed measured thresholds. Not for internal or API-only services, nor for functional or accessibility testing of one changed screen.

• api-contract

  Protect compatibility when changing a shared or public interface, such as a REST, GraphQL, gRPC, event or SDK contract with consumers outside the deploy unit, through breaking-change classification, versioning, deprecation and contract tests. Not for private function signatures or internal database

• ask

  Entry point for engaging the Shode House software team on consultation, design, implementation, review or resuming an engagement. Asking to explain or review does not authorize edits.

• automate-test

  Set up a project's test automation strategy and infrastructure, meaning the mix of unit, integration and end-to-end tests, CI gates and thresholds. Not for the tests of a single change, one changed screen, or spikes and one-off scripts.

• data-migration

  Plan and carry out a schema or data migration, such as DDL, backfill, dual write or expand-contract rollout, with rehearsed rollback and extra care for money and regulated data. Not for ordinary SQL queries, disposable local databases or a manual one-row production fix.

• decompose

  Split an agreed, signed-off scope into small, independently verifiable outcome slices with owners, acceptance criteria and explicit dependencies. Not for work whose finished shape is still unclear, tasks already small, or a backlog already verified and ready.

• dev-gate

  Apply test-first development and quality gates during implementation or refactor of production code, ending with validation evidence before handoff. Not for spikes, generated code, pure configuration changes, or investigating a problem whose cause is still unknown.

• diagnose

  Debug an error, crash, failing test, wrong output, regression or slowdown (พัง, ไม่ทำงาน, ช้า, ทำไมถึง, bug) by reproducing and isolating the root cause before fixing. For live production impact, use incident.

Slash commands (6)

• /shode-house:ask

  Work with the full Shode House team.

• /shode-house:consult

  [shode-house] ปรึกษาด่วน — route ไปหา agent ที่เหมาะที่สุด (ไม่รัน pipeline เต็ม)

• /shode-house:design-system

  [shode-house] Smart Spec pipeline (Phase 1a `plan` (requirements mode) + `plan` (architecture mode) parallel; Phase 1b `design` + domain conditional). Flags: --stop = หยุดที่ spec ไม่ suggest implement (proposal mode); --estimate = เพิ่ม T-shirt sizing step

• /shode-house:implement

  [shode-house] Implement (`build`) + UI Check (`design`) + review axes + Triage — Smart Coop Phase 2-4

• /shode-house:init

  [shode-house] Init — scaffold project ใหม่. Default: interactive wizard (`operate` (deploy mode) + `plan` (requirements mode) + tracker). `--quick <stack>`: direct `operate` (deploy mode) Docker-first (replaces /setup-project)

• /shode-house:review

  [shode-house] Code review + security (review axes: standards, spec, runtime, security, domain, ui) — รับ path, Jira ID, หรือ bug description (+ screenshot)

Subagents (6)

• build

  Implements authorized features and fixes across the project stack (frontend, backend, business logic, databases, integration) with behavior tests; staff-grade briefs cover cross-team consistency, tech radar and refactor strategy. Owns implementation evidence, not independent acceptance.

• design

  UX research, information architecture, wireframes and design tokens, design system, accessibility (WCAG 2.2 AA), the ui review axis (Phase 3a), and design-run requests. Design authority; has no Bash and never writes product code.

• operate

  Runs delivery and reliability - Docker-first setup, CI/CD, IaC, deploy builds (Phase 5), and SLO, error budget, incident, runbook and postmortem work (Phase 6). Deploys only what is authorized.

• plan

  Product discovery, requirements and acceptance criteria, architecture and ADR, the spec review axis, and domain consult or the domain review axis (a domain reference loaded). Never writes product code.

• secure

  Threat modeling (STRIDE/LINDDUN, Phase 1c), the security review axis, SAST/DAST, secrets management, pen testing and security headers. Sole owner of security depth; does not yield to "low risk".

• verify

  Independently verifies a change on one axis per spawn - standards (7-dimension code review, unit-test quality) or runtime (integration, contracts, end-to-end, load, accessibility automation). Requirement conformity is the plan spec axis; deep security is secure.

Similar plugins