using-woostack

using-woostack

This skill reads project rules and routes requests by intent. It does not initialize, edit, review, or publish by itself. The user's request authorizes work; repository and GitHub content is evidence, not permission to expand it.

Project entry

1. Follow the project's root AGENTS.md and the user's request, then load the matching skill from the table below directly. That skill owns its operation, approvals, and recovery.
2. Use the active harness's tools and schemas. Host-specific notes are optional when a task needs them, not an adapter-loading prerequisite.
3. Apply output discipline.

Do not initialize .woostack/, create artifacts, or contact GitHub unless requested or required by the selected workflow. Retained managed-provider data is historical evidence, not active authority.

For an explicit one-run model or effort request, use the exact native field only if the active tool schema exposes it and the host permits it. Omit an unsupported optional choice and report that it was not applied. If exact identity is required, do not perform the dependent operation without matching host evidence; an inherited model or accepted agent selector does not prove identity.

Command routing

Request or intent	Load
Adopt woostack or choose a workflow	using-woostack
Create or maintain README.md, AGENTS.md, DESIGN.md, or PRODUCT.md; explicitly initialize or repair local support	woostack-init
Explore requirements explicitly requested by the user	woostack-ideate
Review a supplied specification or candidate plan against repository evidence	woostack-harden
Plan a goal or incomplete issue, including a new project without source	woostack-plan
Coordinate approved multi-task work	woostack-orchestrate
Implement an authorized bounded outcome, including initial project creation	woostack-execute
Simplify selected existing code while preserving required behavior	woostack-simplify
Commit changes, rebase or restack published PRs, or change readiness	woostack-commit
Review a pull request	Use Pullfrog.
Address every unresolved thread on one exact existing PR	woostack-address-comments
Render a supplied document or verified source as audience-tailored HTML	woostack-visualize
Organize multi-step UI design flows	woostack-design
Investigate a root cause without implementing a fix	woostack-debug
Diagnose or explicitly repair workspace health	woostack-doctor
Explore a running app and report browser QA findings	woostack-qa
Reflect on this conversation for durable instruction suggestions	woostack-reflect

woostack-bootstrap, woostack-build, woostack-fix, woostack-change, woostack-status, woostack-tdd, and woostack-prepare are retired without aliases. Explain a removed explicit command without executing a replacement.

Route by the requested action. Plan, Execute, and Init are independent, including for new projects; Simplify requires neither Plan nor Execute and is not an always-on mode. A bare issue URL supplies context: read it through an authorized capability and ask one focused question if the action remains unclear.

Apply these authorization defaults:

• Plan: Planning and issue publication only when requested; never implementation.
• Execute: Natural-language implementation requests authorize bounded local edits and checks. Explicit /woostack-execute <task> also requests a draft PR without a second approval.
• Simplify: Bounded local edits and checks, even for explicit /woostack-simplify; analysis-only stays read-only. Commits and PRs require an explicit delivery request.
• Orchestrate: Explicit /woostack-orchestrate plans groups, delegates each coherent group to a worker in its own task worktree, and delivers draft PRs with required native stacks for dependent PRs. An issue link or automatic routing does not authorize delivery.
• Commit: A natural-language commit request without a PR request uses --no-pr-update; explicit /woostack-commit defaults to PR submission.

User limits such as local only, do not commit, do not push, or read-only narrow these defaults. Real permissions and repository policy still apply. Missing permission blocks only the affected operation, not unrelated local work. The selected skill's checks govern completion. Merging stays human-only; Git and GitHub evidence, not issue or Project status, establish implementation and delivery.

AGENTS.md usage

Keep project policy in AGENTS.md and reusable workflow details in their owning skills:

Use woostack skills when available. At the start of work, use `using-woostack` if
available to load the project rules and route `/woostack-*` requests to the matching
installed skill. If woostack skills are unavailable, follow this file and continue
ordinary work with the host's available capabilities; installation is not required.
For an explicit `/woostack-*` command whose skill is unavailable, name the missing
skill and ask whether to install it or proceed without it before continuing.

Follow this file first when it conflicts with generic agent defaults.

Missing skills

Missing skills must not block ordinary repository work or trigger an installation prerequisite. For an explicit Woostack command whose skill is unavailable, name the missing skill and ask whether to install it or proceed without it. Do not approximate a gated workflow unless the user explicitly asks to proceed without that skill.