Release v3.28.0

.changelogs/v3.28.0.md

@@ -0,0 +1,23 @@
+# Release v3.28.0
+
+Released: 2026-08-13
+
+## Highlights
+
+- **New `/do:goals --prd` mode (and `/do:prd` shorthand)** generates a detailed `PRD.md` instead of the strategic `GOALS.md` — functional requirements, non-functional requirements, and explicit negative requirements ("must not") grouped by feature area, each with a stable ID and acceptance criteria, plus personas, out-of-scope, assumptions, success metrics, and open questions.
+- **Interactive mode now resolves risks and open questions with you directly** — judgment calls are asked and folded into the document, while purely factual items (like whether a referenced tracker issue is still open) are checked automatically instead of asked.
+- **No fabricated metrics**: numeric success metrics are never invented — where the codebase doesn't evidence a concrete target, it's left as an open question rather than a made-up number.
+- **Contributing**: added `CONTRIBUTING.md` covering project structure, local dev/test workflow, and commit/PR conventions.
+
+## Product requirements documents (`/do:goals --prd`, `/do:prd`)
+- `/do:goals` now supports `--prd`, which generates a detailed `PRD.md` instead of the strategic `GOALS.md` — functional requirements, non-functional requirements, and explicit negative requirements ("must not") grouped by feature area, each with a stable ID and acceptance criteria, plus personas, out-of-scope, assumptions, success metrics, and open questions.
+- `/do:prd` is a shorthand for `/do:goals --prd`.
+- In `--interactive` mode, risks and open questions surfaced during generation are now resolved with you directly: judgment calls are asked and folded into the document, while purely factual items (like whether a referenced tracker issue is still open) are checked automatically instead of asked.
+- Numeric success metrics are never invented — where the codebase doesn't evidence a concrete target, it's left as an open question rather than a fabricated number.
+
+## Contributing
+- Added `CONTRIBUTING.md` covering project structure, local dev/test workflow, and commit/PR conventions.
+
+## Full Changelog
+
+**Full Diff**: https://github.com/atomantic/slashdo/compare/v3.27.1...v3.28.0

CONTRIBUTING.md

@@ -0,0 +1,39 @@
+# Contributing to slashdo
+
+Thanks for considering a contribution. slashdo is a small, actively-maintained project — issues and PRs are welcome.
+
+## Before you start
+
+- **Bugs and feature ideas**: [open an issue](https://github.com/atomantic/slashdo/issues). For anything beyond a trivial fix, opening an issue first (or commenting on an existing one) before writing code avoids duplicated effort — the project tracks its roadmap as `plan`-labeled issues rather than in `PLAN.md`.
+- **Small, obvious fixes** (typos, broken links, a clearly wrong flag description): a PR without a prior issue is fine.
+
+## Project structure
+
+- `commands/do/*.md` — the source of truth for every `/do:*` command, written in Claude Code's native format
+- `lib/*.md` — shared partials referenced from multiple commands
+- `src/*.js` — the installer/transformer that converts `commands/do/` and `lib/` into each target environment's native format (Claude Code, OpenCode, Antigravity CLI, Codex, Grok Build)
+- `install.sh` / `uninstall.sh` — the no-npm curl-based install path; their `COMMANDS`/`LIBS` arrays must stay in sync with `commands/do/` and `lib/` (`test/curl-installer-allowlist.test.js` enforces this in CI)
+- `test/*.test.js` — the test suite, run with `node --test`
+
+## Making a change
+
+1. Fork and clone the repo. There are no npm dependencies to install — the package has none, and the test suite runs on Node's built-in test runner.
+2. Edit the relevant `commands/do/*.md` or `lib/*.md` source file. If you touch environment-specific behavior, wrap it in `<!-- if:teams -->…<!-- else -->…<!-- /if:teams -->` (or the matching capability flag in `src/environments.js`) rather than hard-coding for one environment.
+3. If you add or rename a command or lib file, update the `COMMANDS`/`LIBS` arrays in both `install.sh` and `uninstall.sh` — CI will fail the drift check otherwise.
+4. Verify locally:
+   - `node bin/cli.js --list` — confirm the command shows up correctly
+   - `node bin/cli.js --dry-run` — preview what install would do
+   - `npm test` — run the full test suite
+5. If your change affects behavior covered by an existing test, update it; if it adds new behavior worth locking in, add a test under `test/`.
+
+## Commit and PR conventions
+
+- Commit subjects are specific sentences, not vague tags — `fix: guard empty array expansion in review-loop bash 3.2 path`, not `fix bug`.
+- Conventional prefixes (`fix:`, `feat:`, `docs:`, `chore:`, `refactor:`) are used but not strictly enforced by tooling — match the style in `git log`.
+- Keep PRs scoped to one logical change. A doc fix and a behavior change should be separate PRs.
+- CI runs the full test suite, a `shellcheck` pass on `install.sh`/`uninstall.sh`, and validates every command's frontmatter across Node 18/20/22 — make sure it's green before requesting review.
+- No AI-attribution footers or co-author trailers in commits or PR descriptions, regardless of what tooling you used to help write the change.
+
+## License
+
+By contributing, you agree your contribution is licensed under the project's [MIT License](./LICENSE).

GOALS.md

@@ -13,19 +13,19 @@ slashdo is a curated library of slash commands that automate the software develo
 ## Core Goals
 
 ### 1. Multi-Environment Support
-Provide a single source of truth for commands that works across Claude Code, OpenCode, Antigravity CLI, and Codex. Each environment gets commands in its native format with zero manual conversion.
+Provide a single source of truth for commands that works across Claude Code, OpenCode, Antigravity CLI, Codex, and Grok Build. Each environment gets commands in its native format with zero manual conversion.
 
 ### 2. Automate DevSecOps Workflows
-Provide one-command security auditing, code quality analysis, and automated remediation. `/do:better` scans across 7 dimensions, remediates findings in an isolated worktree, and delivers clean PRs.
+Provide one-command security auditing, code quality analysis, and automated remediation. `/do:better` scans across up to 10 dimensions (8 core agents, plus a UX Consistency agent for UI-bearing projects and a Structural Ambition agent in strict mode), remediates findings in an isolated worktree, and delivers clean PRs.
 
 ### 3. Standardize Development Rituals
 Enforce consistent commit practices, SemVer versioning, and changelog management across projects. `/do:push` ensures every commit follows conventional commit prefixes and updates changelogs.
 
 ### 4. Orchestrate AI-Powered Code Review
-Integrate Copilot review loops with automated thread resolution into the PR workflow. `/do:pr` and `/do:rpr` handle the full cycle from PR creation through review iteration.
+Integrate multi-reviewer review loops — GitHub Copilot, CLI reviewers (Codex, Claude, Antigravity, Grok, Ollama), or any GitHub login — with automated thread resolution into the PR workflow. `/do:pr` and `/do:rpr` handle the full cycle from PR creation through review iteration.
 
 ### 5. Maintain Project Governance Documentation
-Keep planning and standards documents current and well-structured. `/do:replan` manages the tactical backlog, `/do:goals` generates strategic goal documents, and `/do:omd` audits and optimizes markdown files (CLAUDE.md, README.md, AGENTS.md, etc.).
+Keep planning and standards documents current and well-structured. `/do:replan` manages the tactical backlog, `/do:goals` generates strategic goal documents (or, with `--prd`, a detailed PRD.md of product requirements), and `/do:omd` audits and optimizes markdown files (CLAUDE.md, README.md, AGENTS.md, etc.).
 
 ### 6. Be Project-Agnostic
 Auto-detect tech stacks and adapt build commands, test runners, version bumping, and audit strategies accordingly. Commands should work on any codebase without manual configuration.

PLAN.md

@@ -1,6 +1,6 @@
 # Development Plan
 
-For project mission, goals, and non-goals, see [GOALS.md](./GOALS.md).
+For project mission, goals, and non-goals, see [GOALS.md](./GOALS.md). For detailed product requirements, see [PRD.md](./PRD.md).
 
 ## Work tracking