ss-feature-development

name	ss-feature-development
description	Default skill for behavior-changing code work in projects that already have Supersigil specs. Use when fixing bugs, adding features, implementing endpoints, updating tests, repairing verification coverage, or completing tasks linked to existing requirement, design, or tasks documents. Works alongside TDD, code review, and language-specific skills.

Feature Development

Use this skill when the spec graph already exists and the job is to build or finish the feature against it. Augment the user's existing implementation methodology; if a TDD or code review skill is available, use it instead of replacing it.

Current Contract

Use the current CLI as the source of truth:

supersigil ls [--format json]
supersigil context <id> [--format json]
supersigil plan [<id_or_prefix>] [--format json]
supersigil verify [--format terminal|json|markdown]
supersigil status [<id>] [--format json]
supersigil affected --since <ref> [--format json]
supersigil verify

Use references/implementation-loop.md for the concrete command loop. Use references/test-tagging.md when adding or repairing VerifiedBy evidence. Use references/status-lifecycle.md for document and task status promotion rules.

If the spec graph is missing, broken, or obviously incomplete, stop and hand the job back to ss-feature-specification instead of improvising new structure during implementation.

Workflow

1. Bound the work to one feature, prefix, or tightly-related task chain. Do not roam across unrelated docs just because plan shows more work.

2. Inspect the current state before coding. Run supersigil status <main-id> to understand the feature's current health. Run supersigil plan <id_or_prefix> to identify outstanding criteria and pending tasks. Run supersigil context <id> on the main requirement or design doc before changing code.

3. Choose the smallest unfinished slice. Prefer one outstanding criterion plus the directly linked task chain. If tasks exist, follow them. If tasks do not exist but the spec is otherwise sound, work against one criterion at a time and note the missing task structure in the handoff.

4. Implement against the existing spec, not around it. Follow the user's implementation skill if one is installed. If test-driven-development is available, use it for every behavior change. Do not add speculative features outside the current slice.

5. Keep the spec graph honest while you work. Update <Task status="..."> only when the real state changes. Edit spec docs only when the implementation reveals a genuine spec change or missing evidence. Run supersigil verify after any spec edit before doing more work.

6. Add or repair verification evidence as part of the implementation. Prefer ecosystem-native evidence helpers where available (e.g., @supersigil/vitest for JS/TS, #[verifies] for Rust); otherwise use manual supersigil: {tag} comment tags. Use strategy="file-glob" when file existence is the best available evidence. Do not leave empty tag, paths, or refs placeholders behind.

7. Promote document statuses when warranted. After marking a task done, check whether all tasks in the tasks doc are now done. If so, set the tasks doc to status: done, the sibling design doc to status: approved, and the sibling requirements doc to status: implemented. If some tasks are done but others remain, set the tasks doc to status: in-progress. Run supersigil verify to confirm — the status_inconsistency rule will warn about any missed promotions.

8. Run supersigil verify before claiming the slice is complete. Treat error-level findings as blockers for the scoped feature. If the user explicitly defers a finding, keep the affected docs in status: draft or otherwise avoid overstating completion.

9. Use supersigil status and supersigil affected to summarize the result. status is the default close-out summary. affected --since <ref> is for cases where changed tracked files may have invalidated nearby docs. --since HEAD is for cases where the user has not yet committed. For each affected doc, check whether they should be updated.

10. End with a concrete handoff. Summarize what criterion or task chain was completed, which tests now back it, the latest verify result, and what plan still shows for the feature.

Authoring Rules

• Work one bounded feature slice at a time.
• Read plan and context before changing code.
• Keep criterion refs, task IDs, and document IDs stable once they are in use.
• Update task statuses honestly: draft for not-ready work, ready for actionable work, in-progress for active work, done only after implementation and supporting evidence both exist.
• Prefer criterion-level progress over "done enough" prose summaries.
• Add supersigil: {tag} comments only in comment styles the scanner understands today. See references/test-tagging.md.
• Do not promote requirement statuses based only on code changes; use verify, status, and human review to justify status changes.

Failure Modes

• Do not implement before reading the current spec state.
• Do not silently rewrite a broken or underspecified feature during implementation; hand it back to ss-feature-specification.
• Do not mark tasks or documents complete because the code "probably" works.
• Do not add tests without reconnecting them to VerifiedBy when the feature depends on verification coverage.
• Do not ignore verify findings just because the code compiles or the local tests pass.

Handoff

If the user discovers the feature was underspecified, suggest ss-feature-specification. If the user has working code but no specs, suggest ss-retroactive-specification. If the user wants the full guided loop for a new feature, suggest ss-spec-driven-development.