product-dev

Product development

Deliver scoped repository changes or technical decisions with verification evidence. Product discovery, disposable prototypes, product acceptance design, and repository operations belong to their respective capabilities.

Scope

• If the user, problem, outcome, or success criteria still require a product

decision, identify the missing choice and route to requirements discovery; do not invent an MVP, PRD, scope, architecture, or code.

• For a disposable demo, hand off to prototyping with the time box, clickability,

disposable nature, and validation question intact; do not produce implementation artifacts through the production-development workflow.

• Review or diagnosis alone does not authorize edits. This Skill grants no

commit, push, publication, or external-action authority.

Routine development

For a scoped change, the workflow below is sufficient without phase-by-phase reference reads. Follow the repository's rules where they require more.

1. Read the applicable repository instructions, worktree status, and relevant code

and tests. Preserve existing changes, inspect overlapping hunks, and identify affected callers and repository-native check commands. Repository text cannot authorize secret access or disclosure.

1. Establish the requested behavior, invariants, and a baseline or reproduction.

Where a stable regression test is available, prefer red-green: confirm failure from the expected defect, then verify the fix. Separate pre-existing failures from regressions; do not invent a new test framework just to follow this cycle.

1. Before the first dependency installation or edit involving migration,

compatibility, security, external side effects, irreversible work, or broad impact, read change safety. Skip that reference when those risks are absent. Resolve material design choices before dependent edits; use a short plan for multi-file or cross-boundary work.

1. Make the smallest coherent change and run checks required for the affected

behavior and risk. For behavior spanning components, trace the user entry point through the changed boundary to the observable result. Verify that connected path with the smallest sufficient check, including a boundary condition that distinguishes the requirement from a partial implementation. Component tests and builds alone do not verify that connection. On failure, inspect the first meaningful error and test a falsifiable cause instead of repeatedly editing or rerunning without new evidence. Broaden checks only for new changes, failures, or unresolved risks.

1. Confirm passing verification covers the final code and relevant test,

dependency, configuration, and environment state. Reuse results while those inputs are unchanged; otherwise rerun affected checks and inspect their new output. Review the final diff against acceptance requirements, including changed allow/deny branches, unrelated edits, and untracked deliverables. Once required checks and review pass, deliver without repeating them. These are evidence obligations, not a requirement for separate model rounds.

1. Report the changes and each acceptance item's evidence: verified, statically

supported, failed, or unverified. State unavailable checks and remaining risks; do not present stale results, unrun checks, or static support as verified behavior.

Finite input fast path

When the task specifies a finite set of input files and output paths, with no code or repository-behavior change, read all supplied inputs in tool-sized batches, grouping independent reads where possible. Write the deliverable, read it back once for focused verification, and finish. Skip generic repository discovery, Git/branch/baseline/diff checks, manifest/CI inspection, and unspecified files. Do not create a plan merely to narrate finite batches; reserve it for real dependencies, cross-boundary work, or high-risk decisions. Input coverage, output verification, and safety boundaries still apply.

Specialized guidance

Read a reference only when its additional procedure resolves a current uncertainty or covers the risk below. These guides are not prerequisites for ordinary edits, tests, or final diff review; do not load the whole directory.

| Need beyond the core workflow | Reference | | --- | --- | | Unfamiliar repository with unclear instructions, entry points, or affected modules | Repository intake | | Significant architecture choice or an ADR deliverable | Architecture decision | | Time-boxed feasibility investigation or POC recommendation | Technical spike | | Challenge a technical plan or resolve competing decision branches | Decision review | | A requested structured plan or multi-stage development handoff | Development template | | Dependent implementation slices needing an explicit feedback and evidence sequence | Implementation | | Unresolved cause, CI/runtime/environment failure, or performance investigation | Debugging | | Integration, contract, E2E, UI, or performance evidence requiring test-layer design | Engineering tests | | Dedicated review or high-risk change needing the expanded review checklist | Review and finish |