konvoulgaris/soong

Take a Notion roadmap item and build its whole task stack as stacked pull requests, one pull request per task, asking any questions the task cards leave open before writing code. Use when the user runs /develop, or asks to implement a roadmap item, build out a stack of tasks, or start development from prepared task cards. Requires the repo to be configured via soong-setup first.

Use for any work on a pull request — writing or rewriting its title and description when creating or editing a PR, and responding to reviewers on your own open PR. Enforces the Conventional-Commits-with-scope title format, an optional Notion ticket id suffix, and a simple-prose description style. Runs the polish skill on the branch before opening or editing a PR. Walks unresolved review threads one-by-one with the user, then posts all replies in one batch after approval. Forbids generated-by footers and Claude attribution tags on both. Also persists a project/branch -> notion card + last commit record outside the repo for later querying. Triggers on "open a PR", "create a pull request", "write the PR title/description", "address the PR feedback", "reply to the reviewers", "go through the review comments", "respond to the PR comments", or any gh pr create / gh pr edit / gh pr comment.

Merge a base branch into the current feature branch and push the result, resolving conflicts file-by-file. Use when the user asks to "merge", "merge back", catch a feature branch up with its base, or pull base-branch changes into the current branch. "Base" most likely means the branch the feature was cut from or the PR's base branch, not necessarily a branch literally named "development".

Run a code review with autofix, then a simplification pass, then commit the result. Use when the user runs /polish, or asks to review and clean up the current changes in one shot, autofix the review findings, or "review and simplify and commit". Runs unattended - it applies fixes and commits without asking.

Rebase the current feature branch onto a new base branch, keeping only the changes made on the feature branch and dropping any commits inherited from the old base. Use when the user asks to "rebase", change a feature branch's base, move a branch onto a different base, or re-point a branch at a new base branch without carrying over the previous base's history.

Record what this repo needs for soong's skills to run - whether it uses Notion at all and which roadmap and task databases it maps to, and whether its commits carry a Conventional Commits scope. Use when the user runs /soong-setup, when another skill reports the repo is not configured, or when the user wants to change what a repo is configured for. A repo can record that it does not use Notion, which settles that capability for good. Stops without writing anything if the user says the repo uses Notion but does not supply valid databases.

Use when asked to sync a branch's changes into its linked Notion card, or to update the Notion ticket for a PR. Looks up the card from the PR record written by manage-pr (keyed by project and branch), asks the user for the card if none is recorded, then writes a high-level architecture-style description of the branch's changes to the card via the write-notion-content skill. Never edits code, tests, or verification steps. Triggers on "sync the PR to notion", "update the notion card for this branch", "describe these changes on notion".

Style and format rules for writing content to Notion. Use whenever creating or editing any Notion content (pages, ticket bodies, comments). Governs how the text reads, not status fields or MCP plumbing. Enforces template adherence, brevity, lists over prose, and no em-dashes.

Applies ASD-STE100 Simplified Technical English to technical documentation. Use when writing or editing READMEs, API docs, runbooks, ADRs, migration guides, code comments, and error or log messages. Enforces one instruction per sentence, active voice, present tense, and consistent terminology. Does not cover commit messages, PR descriptions, or Notion content.