howarewoo
20 verified skills
woostack-bootstrap
Use when bootstrapping a new web, mobile, or API project from scratch — scaffolding a fresh monorepo, gathering requirements, dynamically researching industry-standard frameworks/services and their latest versions, and setting up the app/feature/infrastructure package slice architecture.
development
woostack-dream
Use to curate the .woostack/ knowledge store. Reflects over the static memory store + docs (no session mining), then proposes a gated changeset that merges duplicate notes, replaces stale/contradicted ones, drops dead/orphaned notes, resolves conflicts, surfaces consolidated insights, and recommends evidence-guarded documentation edits. Nothing mutates before explicit approval; ends on a summary + iterate loop. Local-only memory (no commit); doc edits land in the working tree. Never commits or merges. Invoke via /woostack-dream [instructions].
testing
woostack-address-comments
Use when addressing the unresolved review threads on a pull request — fix or push back on each finding, reply, resolve, and push. Never merges.
documentation
commit
Commit staged changes using Graphite. Checks if on trunk and creates a new branch if needed. Updates PR title and summary after each commit.
testing
woostack-visualize
Use when you want an HTML visualization of any source — a spec, plan, file, directory, or concept — tailored to a target audience (engineer, non-technical, investor, or any free-form reader). Reads the real source and writes one self-contained, offline-viewable HTML file; never the source of truth.
development
woostack-harden
Use to harden a plan, spec, or design by relentless interview — walk every branch of the decision tree, resolve each open question one at a time with a recommended answer, and amend the artifact in place until no new questions remain. This is the harden phase of the woostack build loop (woostack-build steps 3 and 6 — first the spec, then the plan); also usable standalone to stress-test or "grill me" on a design before committing to it.
development
woostack-ideate
Use as the ideate phase of the woostack build loop — turn a feature idea into an approved design through collaborative dialogue, then stop. Explores intent, constraints, and approaches; presents a design and gets explicit approval. Writes no files and chains no skill; the caller (woostack-build) owns the spec and plan. Usable standalone to design before implementation.
development
woostack-execute-overnight
Use to execute an approved woostack plan UNATTENDED overnight — one autonomous run with no user input after launch that drives every increment to a reviewed stack, swapping woostack-execute's stop-and-ask gates for resolve-or-log-and-continue (woostack-debug on stuck verifications; bounded auto-address on a blocking review; halt-the-track on anything unsafe or ambiguous), honoring optional `## Track:` grouping in the plan (independent, fault-isolated tracks run sequentially), and writing a morning report under .woostack/overnight/ for a human to test in the morning. It is the third choice at woostack-build's execution-handoff gate (Go / Hand off / Run overnight); also usable standalone via /woostack-execute-overnight <plan-path> [--inline|--subagent]. One plan per spec, multiple PRs per plan. Never merges; never relaxes safety for autonomy.
development
woostack-tdd
woostack's canonical test-driven-development home and on-demand test-adder. The single source for the TDD kernel — Red→Green→Refactor, test-first, cover happy/error/edge/success+failure, framework-aware, no-runner→concrete verification — that woostack-plan, woostack-execute, woostack-debug, and bootstrap patterns.md §7 should link to instead of restating. Also the 14th public command: /woostack-tdd <target> adds appropriate tests to an existing code block, PR, spec, or plan — one verb, target-routed (code→colocated *.test files, PR→tests for the gh pr diff surface, spec→strengthen §7 acceptance criteria, plan→fill failing-test steps) — with a characterization carve-out for existing code (new code is red-first; existing code pins current behavior). Writes tests to the working tree and hands to woostack-commit; never commits, merges, or authors status:/branch:; owns no approval gate.
development
woostack-debug
Use as woostack's systematic-debugging phase — find the root cause of a bug, test failure, or unexpected behavior before any fix. Retells the four-phase method (root-cause investigation → pattern analysis → hypothesis/test → handback) with the Iron Law (no fix without root cause), wired to the .woostack/memory store (recall known gotchas at start). Invoke via /woostack-debug <target>; it runs the four-phase root-cause analysis automatically and hands the findings back. Investigative only — autonomous is its sole mode (no flag), and it never writes code, commits, or merges.
development
woostack-init
Use when initializing, scaffolding, or repairing the .woostack/ workspace — creates the memory store, specs and plans directories, config.json, and .gitignore from canonical templates, then runs the index builder and store linter. Invoke at project setup (brownfield) or from woostack-bootstrap (greenfield).
development
woostack-review
Managed agentic PR reviews with parallel matrix execution and skeptical validation.
data-ai
using-woostack
Use when starting work in a project that references woostack from its root AGENTS.md, or when deciding whether a woostack skill or command applies before answering, editing, scaffolding, reviewing, or addressing PR feedback.
testing
woostack-build
Use when building a feature with the full woostack development loop — ideate a design, harden it, plan it, harden the plan, ship the spec and plan as their own PR, then implement it. Chains woostack-ideate, woostack-harden, woostack-plan, woostack-commit, and woostack-execute in a fixed, gated order; writes markdown specs and plans under .woostack/.
development
woostack-execute
Use to execute an approved woostack plan as a sequence of PR-sized, stacked increments via an inline or subagent-driven driver (--inline/--subagent, smart default) — implement each increment with TDD, tick the plan's checkboxes in place, commit via woostack-commit on its own Graphite branch, review each task with spec+quality checks (inline by the controller, or via subagents with tier routing), distill durable learnings, then continue. This is the execute phase of the woostack build loop (woostack-build step 8); also usable standalone via /woostack-execute <plan-path> [--inline|--subagent]. One plan per spec, multiple PRs per plan. Never merges.
development
woostack-commit
Commit the current session-relevant changes, create a feature branch first when needed, push with Graphite, and update the current PR title/body with a goal, concise summary, and structured (automated + manual) test plan. Use for /woostack-commit, "commit this", "commit the current changes", "update the PR", or when finishing a woostack change before review.
development
woostack-status
Use to show the derived woostack feature board — for every spec in .woostack/specs/ and fix in .woostack/fixes/, its reconciled phase, plan progress, increment-PR state, owner, age, and the single next action, plus flags for any drift between the authored status field and the artifacts on disk. Read-only; never fetches, commits, or pushes. Use for /woostack-status, "what's in flight", or "what should I do next".
testing
woostack-plan
Use to write the implementation plan for an approved woostack spec — a comprehensive, bite-sized TDD plan structured as PR-sized increments, saved frontmatter-free to .woostack/plans/<spec-basename>.md, opening with a `**Source:**` line that joins it 1:1 to the spec, and setting the spec's status: planning. This is the plan phase of the woostack build loop (woostack-build step 4); also usable standalone via /woostack-plan <spec-path>. One plan per spec. Writes the plan and hands back — never executes, commits, or merges.
development
woostack-fix
Use to resolve small technical issues (bugs, hotfixes, refactors) through a unified execution loop — diagnose root cause with woostack-debug, author a fix plan under .woostack/fixes/, harden, get explicit user approval, then delegate execution to woostack-execute (TDD per task, task review, commit via woostack-commit, distill).
development
woo-stack
Use when bootstrapping a new web, mobile, or API project from scratch — scaffolding a fresh monorepo, choosing which frameworks/hosting/data layer to use, or setting up architecture, CI, and conventions for a new full-stack app at current framework versions.
development