iikit-07-implement

name	iikit-07-implement
description	Execute the implementation plan by coding each task from tasks.md — writes source files, runs tests, verifies assertion integrity, and validates output against constitutional principles. Use when ready to build a feature from a tasks.md plan, start coding against an Intent Integrity Kit implementation plan, develop from the task list, resume a partially completed implementation, or run the implement phase of the iikit workflow.
license	MIT
metadata	{"version":"1.6.4"}

Intent Integrity Kit Implement

Process steps in order. Do not skip ahead.

Execute the implementation plan by processing all tasks in tasks.md.

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Windows: Replace bash …/iikit-core/scripts/bash/*.sh with pwsh …/iikit-core/scripts/powershell/*.ps1 (same flags, -PascalCase).

Constitution Loading

Load constitution per constitution-loading.md (enforcement mode — extract rules, declare hard gate, validate before every file write).

Prerequisites Check

1. Run: bash .tessl/plugins/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/check-prerequisites.sh --phase 07 --json
2. Parse for FEATURE_DIR and AVAILABLE_DOCS. If missing tasks.md: ERROR.
3. If JSON contains needs_selection: true: present the features array as a numbered table (name and stage columns). Follow the options presentation pattern in conversation-guide.md. After user selects, run:

   bash .tessl/plugins/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/set-active-feature.sh --json <selection>
   

   Then re-run the prerequisites check (item 1 of this section).

Commit Strategy

Ask the user to choose a commit strategy before starting:

Strategy	Description
A) Per-task (default)	One git commit per completed task. Clean, bisectable history mapping each commit to a task ID.
B) Batch	Commits per phase (Setup, Foundational, each User Story, Polish) — typically 4–6 commits. Faster; commits don't map 1:1 to task IDs.

Default to A if user doesn't respond. Apply the chosen strategy throughout.

Pre-Implementation Validation

Bugfix detection: if every unchecked task has a T-B prefix, this is a bugfix-only run — relaxed gates below.

Standard mode: Verify artifact completeness (constitution, spec, plan, tasks, checklists), cross-artifact consistency (FR-XXX → tasks, tech stack → file paths), and checklist completion (all 100% or ask user). Report READY or BLOCKED.

Bugfix mode: Only require tasks.md (T-B tasks) and bugs.md (matching BUG-NNN). Skip spec/plan/checklist gates. BDD chain (Step 3) still applies if .feature files exist.

Dashboard

Suggest the user open the dashboard to watch implementation progress in real time:

Dashboard: file://$(pwd)/.specify/dashboard.html (resolve the path) — updates live as tasks complete

Step 1 — Load Context

Read tasks.md + plan.md (standard) or tasks.md + bugs.md (bugfix). Optional: data-model.md, contracts/, research.md, quickstart.md, tests/features/.

Proceed immediately to Step 2.

Step 2 — TDD Support Check

If tests/features/ directory exists (contains .feature files), verify assertion integrity:

bash .tessl/plugins/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/testify-tdd.sh comprehensive-check "FEATURE_DIR/tests/features" "CONSTITUTION.md"

Parse JSON response: PASS (proceed), BLOCKED (halt, show remediation), WARN (proceed with caution).

If TDD mandatory but tests/features/ missing or empty: ERROR with Run: /iikit-04-testify.

Proceed immediately to Step 3.

Step 3 — Execute BDD Verification Chain

When .feature files exist, apply this chain to each implementation task:

1. Write step definitions in tests/step_definitions/ binding Gherkin steps to application calls.
2. RED phase: run BDD tests — they MUST fail. Confirms tests are meaningful.
3. Write production code implementing the behavior.
4. GREEN phase: run BDD tests — they MUST pass. Fix production code if they fail; never modify tests or .feature files.
5. Verify BDD chain:

   bash .tessl/plugins/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/verify-bdd.sh --json "FEATURE_DIR/tests/features" "FEATURE_DIR/plan.md" "FEATURE_DIR/tests/step_definitions" "<language>"
   

   Parse JSON for steps.status (coverage) and quality.status (assertions). Both must be PASS before marking task complete. If BLOCKED: fix the flagged step definitions.

Feature File Immutability — .feature files MUST NOT be modified during implementation. They are generated by /iikit-04-testify and hash-locked. Only step definitions and production code may be modified. If a .feature file needs changes, re-run /iikit-04-testify.

Test Execution Enforcement — Tests MUST be run, not just written. Run immediately after writing (expect red); run again after implementing (expect green). Fix code, not tests. Never mark a test task [x] without execution output.

bash .tessl/plugins/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/verify-test-execution.sh verify "FEATURE_DIR/tests/features" "$(cat test-output.log)"

Block on any status other than PASS.

Task Completion Gate — A task is NOT complete until:

1. verify-steps.sh returns PASS (all steps defined)
2. BDD tests pass (GREEN phase confirmed)
3. verify-step-quality.sh returns PASS (no empty/trivial assertions)

Do NOT mark [x] in tasks.md until all three gates pass.

Proceed immediately to Step 4.

Step 4 — Setup (Dependencies, Tiles, Scaffolding)

Before writing source code:

1. Install dependencies from plan.md Technical Context (detect package manager, add runtime + dev deps, commit manifest + lockfile)
2. Install Tessl tiles for each major dependency: tessl search <pkg> then tessl install <tile>. Query tile docs before writing library code. See tessl-integration.md.
3. Scaffold project if needed. For existing directories, use force/overwrite flags. See ignore-patterns.md for gitignore patterns.

Proceed immediately to Step 5.

Step 5 — Execute Tasks

Task extraction: parse tasks.md for phase, completion status ([x] = skip), dependencies, [P] markers, [USn] labels. Build in-memory task graph.

Execution strategy (read parallel-execution.md BEFORE proceeding): If tasks.md contains [P] markers, you MUST use the Task tool to dispatch parallel batches as concurrent subagents (one worker per task). Only fall back to sequential execution if the runtime has no subagent dispatch mechanism. Report mode per formatting-guide.md (Execution Mode Header).

Phase-by-phase:

1. Collect eligible tasks (dependencies satisfied)
2. Build parallel batches from [P] tasks with no mutual dependencies
3. Dispatch — parallel: launch one Task tool subagent per [P] task in the batch; sequential: one at a time
4. Collect results, checkpoint [x] in tasks.md per batch, then commit per Task Commits below
5. Repeat until phase complete

Cross-story parallelism: independent stories can run as parallel workstreams after Phase 2 (verify no shared file modifications).

Rules: complete Step 4 (dependencies and Tessl tiles) before writing code, query tiles before library code, tests before code if TDD, run tests after writing them, only orchestrator updates tasks.md.

Failure handling: let in-flight siblings finish, mark successes, report failures, halt phase. Constitutional violations in workers: worker stops, reports to orchestrator, treated as task failure.

Task Commits: Apply the user's chosen commit strategy.

Per-task (strategy A): After each task is marked [x], stage its changed files (git add specific files, NOT -A) and commit:

# Subject + trailers template
feat(<feature-id>): <task-id> <task description>
iikit-feature: <feature-id>
iikit-task: <task-id>

# Bugfix tasks use fix(…) instead of feat(…)
# <feature-id> = FEATURE_DIR with specs/ prefix and trailing / stripped (e.g. 001-user-auth)
# Skip if no files changed; for parallel batches commit each task individually after batch completes

Batch (strategy B): Write code continuously, mark tasks [x] as they complete, commit once per phase:

# Subject template
feat(<feature-id>): <phase-name>
# e.g. feat(001-user-auth): Phase 3 - User Story 1

# Stage all changed files for the phase at once
# Still mark each task [x] in tasks.md as it completes (for progress tracking)

For both strategies, regenerate the dashboard after commits:

bash .tessl/plugins/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/generate-dashboard-safe.sh

Proceed immediately to Step 6.

Step 6 — Output Validation

Before writing ANY file: review against constitutional principles. On violation: STOP, explain, suggest alternative.

Proceed immediately to Step 7.

Step 7 — Progress Tracking

Report after each task/batch. Mark completed [x] in tasks.md. Halt on failure.

Proceed immediately to Step 8.

Step 8 — Post-Fix GitHub Integration (Bug Fix Tasks)

After completing bug fix tasks (tasks with T-B prefix pattern):

1. Check if FEATURE_DIR/bugs.md exists
2. For each completed bug (all T-BNNN tasks for a BUG-NNN marked [x]):
   • Read the GitHub Issue field from the bug's entry in bugs.md
   • If a GitHub issue is linked (e.g., #42):
     • Close via commit: include Fixes #<number> in the last task's commit message (per Task Commits in Step 5)
     • Post a comment: post a comment to the linked issue using whichever tool is available. Comment content: root cause from bugs.md, completed fix tasks, and fix reference.
   • If no GitHub issue is linked: skip silently

Proceed immediately to Step 9.

Step 9 — Completion

All tasks [x], features validated against spec, test execution enforcement (Step 3) satisfied, Tessl usage reported.

Finish here.

Error Handling

Missing artifacts: STOP with run instructions. Constitution violations: STOP, explain, suggest alternative. Checklist incomplete: ask user. Task/parallel failure: report + halt (per Failure handling in Step 5). Tests not run: STOP. Tests failing: fix code, re-run.

Dashboard & Next Steps

After all tasks are complete (or on halt), refresh the dashboard and compute the next step. The post-phase script handles both in a single call — it runs generate-dashboard-safe.sh to regenerate the HTML dashboard, then runs next-step.sh --phase 07 --json to determine the next workflow step based on feature completion state:

bash .tessl/plugins/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/post-phase.sh --phase 07

Windows: pwsh .tessl/plugins/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/powershell/post-phase.ps1 -Phase 07

Note: implement handles its own git commits per the chosen strategy (Task Commits in Step 5), so post-phase is called without --commit-files.

Parse next_step from JSON:

• If next_step is /iikit-07-implement (feature incomplete): suggest resuming
• If next_step is null (feature complete): congratulate, list alt_steps
• Include model_tier per model-recommendations.md

Push commits to remote if available: git push. If on a feature branch, offer to merge:

• A) Merge locally: git checkout main && git merge <branch>
• B) Create PR: open a pull request on the project's tracker using whichever tool is available, or report the steps for the user to open it manually
• C) Skip: user will handle it

Implementation complete!
Next: [/clear → ] <next_step or "All tasks done!">
[- <alt_step> — <reason> (model: <tier>)]
- Dashboard: file://$(pwd)/.specify/dashboard.html