implement-staff

Introduce new modules, new public interfaces, and new package dependencies in service of an approved spec. Every change traces back to a spec line. Staff does not revise the spec. Use when the spec explicitly names new architectural territory (a new module, a new API, a new dep) and someone has to build it. Do NOT use when the work fits inside an existing module (route to `/safer:implement-junior`) or when the plan is multi-module but stays within existing modules (route to `/safer:implement-senior`).

Safety Notice

This listing is imported from SkillsMP metadata and should be treated as untrusted until upstream source review is completed.

Copy this and send it to your AI assistant to learn

Install skill "implement-staff" with this command: npx skills add chughtapan/skillsmp-chughtapan-chughtapan-implement-staff

No markdown body

This source entry does not include full markdown content beyond metadata.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Open in GitHub

Related Skills

Related by shared tags or category signals.

General

implement-senior

Cross-module coordination WITHIN an approved architect plan. May refactor internals across modules, add private helpers that span modules, and reorganize file layouts when the plan authorizes it. May NOT introduce new modules, new architectural patterns, new public contracts outside the plan, or new deps. Use when the architect plan explicitly covers multi-module work and the implementer needs to coordinate across them. Do NOT use for one-module work (route to `/safer:implement-junior`) or for introducing new modules/deps (route to `/safer:implement-staff`).

Repository SourceNeeds Review

-0chughtapan

General

spec

Turn an ambiguous intent into a spec document: goals, non-goals, invariants, acceptance criteria, and open questions. Produces a written artifact that every downstream modality (architect, implement-*, verify) can read and execute against without needing the original conversation. Use when an intent is under-specified, when acceptance criteria are implicit, or when multiple reasonable interpretations exist and need to be narrowed. Do NOT use for architecture choices, library choices, or implementation work.

Repository SourceNeeds Review

-0chughtapan

General

implement-junior

Fill in the internals of ONE module against a clear acceptance criterion. No public surface changes. No new deps. No cross-module reach. Use when the work is either (a) backed by an architect design doc that names the module and leaves only the body to write, or (b) an obvious-scope change like a bug fix, small feature, or added test that touches one module's internals. Do NOT use for refactors across modules (route to `/safer:implement-senior`), new modules or new public surface (`/safer:implement-staff`), or work without an approved plan.

Repository SourceNeeds Review

-0chughtapan

General

verify

Run the repo test suite and lint, check each acceptance criterion from the sub-issue against the diff and the test output, and emit a ship or hold verdict with evidence. Use immediately after a PR has passed senior review and before merge. Do NOT use to fix failing tests; fixing is a separate implement-* modality. Verify reads, runs, and reports.

Repository SourceNeeds Review

-0chughtapan