sdd-manager

Use when designing or reviewing a chosen architecture, design pattern, component boundary, API, module, refactor, Phase → Milestone → Task hierarchy, task breakdown, hosted task mapping, repository hosting-token storage or authentication recovery, workflow branch identities and artifact locations, review/revision campaign records, Markdown document style, or code change; also use during code review and when comparing design options. Assess cohesion, dependencies, testability, complexity, and SOLID, DRY, and KISS where relevant.

Use when exploring a software project or feature, forming architecture decisions, developing a component decomposition, or creating and revising docs/dev/PROJECT.md, ARCHITECTURE.md, DECOMPOSITION.md, and scoped architectural change documents before specification.

Use when creating, reviewing, or maintaining professional module and API documentation, aligning README and standalone guides with an SDD project's supported implementation, checking documentation examples and links, or auditing documentation after code changes or across the project.

Use when projecting software-development phases, milestones, and tasks to a hosted repository; creating or reconciling GitHub labels, milestones, and task issues; finding an issue for a task ID; or closing verified task issues and milestones, reopening invalidated milestones, or recovering interrupted hosted transitions. Also use for provider-independent Git release highlights and incremental release-note drafts, GitHub release package assessment, release workflow preparation or dispatch, release creation and interrupted release recovery. GitHub is the available backend. Ordinary local Git and SDD work does not require hosting access.

Use when selecting an executable task range, or executing or resuming a bounded SDD implementation workflow driven by TASKS or FEATURE-TASKS, completing pending task work, coordinating tests and documentation, verifying results, marking completion, committing and pushing each task, or stopping at a requested checkpoint.

Use when incorporating accepted feature or change documents into the main PROJECT, ARCHITECTURE, DECOMPOSITION, SPEC, PLAN, or layout documents, or reconciling TASKS and FEATURE-TASKS from accepted feature deltas, including optional incorporation of FEATURE-TASKS into TASKS. Reconcile one selected document or a bounded set without requiring task-list changes.

Coordinate Git release highlights, release package/workflow preparation and GitHub releases alongside SDD workflows for initial development, feature preparation, bounded or resumed task implementation, human-directed checkpoint amendments, accepted feature integration, focused review or maintenance, and hosted task synchronization. Use for multi-stage project requests, shared prerequisites, branch management and phase transitions, workflow transitions, stopping boundaries, recovering shell authentication, or supplying hosting credentials to sdd-forge.

Use when locating and inspecting a software project's repository before SDD work, checking Git worktree and interrupted-task state, discovering governing instructions and development documents, or handing a scoped project orientation to an orchestrating agent. Read-only; report whether a proposed mutation has the required Git and authority baseline.

Use when planning delivery phases, milestones, dependencies, or exit gates, or when designing or reviewing a software project's repository layout, directory and package structure, and physical ownership of code, tests, and documentation. Produces or revises PLAN.md, FEATURE-PLAN.md, layout.md, and focused children before executable TASKS or FEATURE-TASKS are derived.

Use when drafting a task issue, Git commit message, pull request description, or evidence-backed task, milestone, phase or final implementation report, review/revision campaign plan or report, package preparation result, curated Git release highlights, release notes or release outcome for an SDD project. Adapt the summary to feature, bug, code health, performance, security, testing, documentation, integration, or compatibility work without inventing results.

Use when creating, reviewing, or revising docs/dev/SPEC.md, focused specification children, or FEATURE-SPEC.md; defining required software behavior, interfaces, data contracts, error semantics, invariants, and objective acceptance for a new or existing system.

Use when the human defines a focused amendment at a checkpoint during partial SDD task-list implementation, especially reducing previously implemented functionality, and requests impact assessment or amendment implementation across existing development documents, code, tests, and documentation. Stop after reporting; do not resume sdd-implement.

Use when deriving or reviewing executable software-development tasks from an accepted design, SPEC, PLAN, and layout; creating docs/dev/TASKS.md or scoped docs/dev/FEATURE-TASKS.md; or reviewing task status and dependencies.

Use when defining an SDD project's testing strategy, deriving test scenarios from accepted contracts, writing or reviewing tests, reproducing a bug, or guiding a test-first red-green-refactor cycle for a selected implementation task.

Use when selecting and running checks for an SDD task, selected change, milestone, phase, or project; assessing acceptance and exit-condition coverage; classifying observed failures; performing read-only milestone/phase implementation code review, checking Git release-highlight ranges and drafts, release package contents, release workflows, CI outputs and hosted asset integrity; or returning verification evidence and remaining gaps before completion.