iikit-03-plan

Create technical implementation plan from feature specification

16 stars

Best use case

iikit-03-plan is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Create technical implementation plan from feature specification

Teams using iikit-03-plan should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/iikit-03-plan/SKILL.md --create-dirs "https://raw.githubusercontent.com/diegosouzapw/awesome-omni-skill/main/skills/product/iikit-03-plan/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/iikit-03-plan/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How iikit-03-plan Compares

Feature / Agentiikit-03-planStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Create technical implementation plan from feature specification

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Intent Integrity Kit Plan

Execute the implementation planning workflow using the plan template to generate design artifacts.

## User Input

```text
$ARGUMENTS
```

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

## Constitution Loading (REQUIRED)

Before ANY action, load and internalize the project constitution:

1. Read constitution:
   ```bash
   cat CONSTITUTION.md 2>/dev/null || echo "NO_CONSTITUTION"
   ```

2. If file doesn't exist:
   ```
   ERROR: Project constitution not found at CONSTITUTION.md

   Cannot proceed without constitution.
   Run: /iikit-00-constitution
   ```

3. Parse all principles, constraints, and governance rules.

4. **Extract Enforcement Rules**:
   - Find all lines containing "MUST", "MUST NOT", "SHALL", "SHALL NOT", "REQUIRED", "NON-NEGOTIABLE"
   - Build an enforcement checklist from these rules
   - Example extraction:
     ```
     CONSTITUTION ENFORCEMENT RULES:
     [MUST] Use TDD - write tests before implementation
     [MUST NOT] Use external dependencies without justification
     [REQUIRED] All code must have error handling
     ```

5. **Validation commitment:** Every output will be validated against each principle before being written.

6. **Hard Gate Declaration**: State explicitly:
   ```
   CONSTITUTION GATE ACTIVE
   Extracted X enforcement rules
   ANY violation will HALT planning with explanation
   ```

## Prerequisites Check

1. Run setup script (choose based on platform):

   **Unix/macOS/Linux:**
   ```bash
   bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/setup-plan.sh --json
   ```

   **Windows (PowerShell):**
   ```powershell
   pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/powershell/setup-plan.ps1 -Json
   ```

2. Parse JSON for:
   - `FEATURE_SPEC` - path to spec.md
   - `IMPL_PLAN` - path to plan.md
   - `SPECS_DIR` - feature directory
   - `BRANCH` - current branch name

3. If error or missing spec.md:
   ```
   ERROR: spec.md not found in feature directory.

   Run: /iikit-01-specify <feature description>
   ```

## Smart Validation

**BEFORE proceeding to planning, perform semantic validation:**

### Spec Quality Gate

Read the spec.md and validate:

1. **Requirement Count Check**:
   - Count functional requirements (FR-XXX patterns)
   - If fewer than 3 requirements:
     ```
     WARNING: Spec may be underspecified (found X requirements, recommend 3+).
     ```
   - If 0 requirements:
     ```
     ERROR: Cannot plan without requirements.

     The spec.md has no functional requirements (FR-XXX).
     Run: /iikit-01-specify to add requirements, or manually add FR-XXX items to spec.md
     ```

2. **Measurable Success Criteria Check**:
   - Scan Success Criteria section for numeric values, percentages, or time measurements
   - If no measurable criteria found:
     ```
     WARNING: No measurable success criteria found.

     Recommendation: Add metrics like "under 3 seconds", "95% uptime", "10,000 users".
     ```

3. **Unresolved Clarification Check**:
   - Search for `[NEEDS CLARIFICATION]` markers
   - If found, list each one and ask: "Resolve these before planning, or proceed with assumptions?"
   - If user says proceed, document assumptions explicitly in plan.md

4. **User Story Coverage Check**:
   - Verify each user story has at least one acceptance scenario
   - If any story lacks scenarios:
     ```
     WARNING: User Story X has no acceptance criteria.

     Recommendation: Add acceptance scenarios to validate the story is complete.
     ```

5. **Cross-Reference Validation**:
   - Check that requirements reference user stories (or vice versa)
   - If orphan requirements exist:
     ```
     WARNING: Orphan requirement detected (FR-XXX not linked to any user story).

     Recommendation: Link requirements to user stories for traceability.
     ```

### Quality Score Report

Calculate and display:
```
+---------------------------------------------+
|  SPEC QUALITY REPORT                        |
+---------------------------------------------+
|  Requirements:     X found (min: 3)    [Y/N]|
|  Success Criteria: X found (min: 3)    [Y/N]|
|  User Stories:     X found (min: 1)    [Y/N]|
|  Measurable:       X criteria have metrics  |
|  Clarifications:   X unresolved             |
|  Coverage:         X% requirements linked   |
+---------------------------------------------+
|  OVERALL SCORE: X/10                        |
|  STATUS: [READY/NEEDS WORK]                 |
+---------------------------------------------+
```

**If score < 6**: Recommend running `/iikit-02-clarify` first
**If score >= 6**: Proceed with planning

## Execution Flow

### 1. Setup

- Run setup script to get paths and copy plan template
- Read `FEATURE_SPEC` and constitution
- Load `IMPL_PLAN` template

### 2. Execute Plan Workflow

Follow the structure in IMPL_PLAN template to:

1. **Fill Technical Context** (mark unknowns as "NEEDS CLARIFICATION"):
   - Language/Version
   - Primary Dependencies
   - Storage
   - Testing
   - Target Platform
   - Project Type
   - Performance Goals
   - Constraints
   - Scale/Scope

2. **Fill Constitution Check section** from constitution principles

3. **Evaluate gates** - ERROR if violations cannot be justified

### 3. Tessl Tile Discovery (MANDATORY if Tessl installed)

**Purpose**: Discover, install, and catalog Tessl tiles for all technologies in the Technical Context. Tiles provide documentation, rules, and skills that improve implementation quality.

#### 3.1 Check Tessl Availability

**Platform Detection**:
- Unix/Linux/macOS: `command -v tessl >/dev/null 2>&1`
- Windows PowerShell: `Get-Command tessl -ErrorAction SilentlyContinue`

**If Tessl NOT Available**:
Display once and continue without tile operations:
```
ℹ️ Tessl not installed. Tile-based documentation unavailable.
   Install Tessl for enhanced library documentation: https://tessl.io
```

**If Tessl Available**: Proceed with tile discovery.

#### 3.2 Check Tessl Status

```
mcp__tessl__status()
```

This shows authentication status and any existing tiles.

#### 3.3 Extract Technologies from Technical Context

From the drafted Technical Context, extract:
- Language/Version (e.g., "Python 3.12", "TypeScript 5.x")
- Primary Dependencies (e.g., "Click", "Express", "React")
- Storage (e.g., "SQLite", "PostgreSQL", "MongoDB")
- Testing (e.g., "pytest", "Jest", "Vitest")
- Any other frameworks/libraries mentioned

#### 3.4 Search and Install Tiles for Each Technology

For each technology identified:

1. **Search for tiles**:
   ```
   mcp__tessl__search(query="<technology>")
   ```

2. **For each tile found, identify type**:
   - **Documentation tile**: Contains library usage specs (has `describes` field)
   - **Rules tile**: Contains behavioral guidelines (has `rules` section)
   - **Skills tile**: Contains invocable AI commands (has `skill` section)

3. **Install relevant tiles**:
   ```
   mcp__tessl__install(packageName="<workspace/tile-name>")
   ```

4. **Document in research.md** (Tessl Tiles section):
   ```
   ## Tessl Tiles

   ### Installed Tiles

   | Technology | Tile | Type | Version |
   |------------|------|------|---------|
   | Python | tessl/python | Documentation | 1.2.0 |
   | Click | tessl/click | Documentation | 0.8.0 |
   | pytest | tessl/pytest | Documentation + Rules | 1.0.0 |

   ### Available Skills

   The following skills are available from installed tiles:
   - `/<skill-name>` - Description of what the skill does

   ### Technologies Without Tiles

   - <technology>: No tile found in registry
   ```

5. **If no tiles found for a technology**:
   - Note in research.md: "No Tessl tile available for <technology>"
   - Continue without tile for that technology

#### 3.5 Query Installed Documentation Tiles for Best Practices

For each installed documentation tile, query for best practices:

```
mcp__tessl__query_library_docs(query="best practices for <library>")
```

Incorporate findings into research.md decisions section.

#### 3.6 Catalog Installed Skill Tiles

List all available skills from installed tiles:
- Record skill name and purpose
- Note in research.md: "Available skills: /<skill-1>, /<skill-2>, ..."
- Skills become available for use in subsequent phases (especially `/iikit-08-implement`)

#### 3.7 Handle Failures Gracefully

- **Network issues**: Log warning, continue without affected tiles
- **Registry unavailable**: Log warning, continue without tiles
- **Authentication required**: Prompt user to run `tessl login`, continue without tiles
- **Search returns no results**: Note in research.md, continue

### 4. Phase 0: Outline & Research (includes Tessl findings)

1. **Extract unknowns from Technical Context**:
   - For each NEEDS CLARIFICATION -> research task
   - For each dependency -> best practices task
   - For each integration -> patterns task

2. **Research each unknown** and document findings

3. **Consolidate findings** in `research.md`:
   - Decision: [what was chosen]
   - Rationale: [why chosen]
   - Alternatives considered: [what else evaluated]

**Output**: `research.md` with all NEEDS CLARIFICATION resolved (includes Tessl Tiles section if Tessl available)

### 5. Phase 1: Design & Contracts

**Prerequisites:** `research.md` complete

1. **Extract entities from feature spec** -> `data-model.md`:
   - Entity name, fields, relationships
   - Validation rules from requirements
   - State transitions if applicable

2. **Generate API contracts** from functional requirements:
   - For each user action -> endpoint
   - Use standard REST/GraphQL patterns
   - Output OpenAPI/GraphQL schema to `/contracts/`

3. **Create quickstart.md** with test scenarios

4. **Agent context update** (choose based on platform):

   **Unix/macOS/Linux:**
   ```bash
   bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/update-agent-context.sh claude
   ```

   **Windows (PowerShell):**
   ```powershell
   pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/powershell/update-agent-context.ps1 -AgentType claude
   ```

   This updates CLAUDE.md with the new technology stack using the [agent-file-template.md](../iikit-core/templates/agent-file-template.md).

**Output**: `data-model.md`, `/contracts/*`, `quickstart.md`, updated agent file

### 6. Constitution Check (Post-Design)

Re-evaluate the Constitution Check after design phase:

- Verify all technical decisions align with principles
- If ANY violation detected:
  - STOP immediately
  - State: "CONSTITUTION VIOLATION: [Principle Name]"
  - Explain what specifically violates the principle
  - Suggest compliant alternative approach
  - DO NOT proceed with "best effort" or workarounds

### 7. Phase Separation Validation (REQUIRED)

Before finalizing, scan the draft plan for governance content that belongs in `/iikit-00-constitution`:

**Check for violations - plan MUST NOT contain:**
- Project governance principles or "laws"
- Non-negotiable development rules (e.g., "always use TDD", "code review required")
- Quality standards that apply project-wide (e.g., "100% test coverage")
- Amendment procedures or versioning policies
- Compliance or audit requirements
- Team workflow rules (e.g., "PRs must be approved by 2 reviewers")
- Coding standards that aren't technology-specific

**Plan SHOULD contain** (these are appropriate here):
- Technology stack decisions (languages, frameworks, databases)
- Architecture patterns for THIS feature
- Implementation approach and rationale
- Data models and API contracts
- Performance targets for THIS feature
- Technology-specific best practices

**If violations found:**
```
+---------------------------------------------------------------+
|  PHASE SEPARATION VIOLATION DETECTED                          |
+---------------------------------------------------------------+
|  Plan contains governance content:                            |
|  - [list each violation]                                      |
|                                                               |
|  Governance principles belong in /iikit-00-constitution.      |
|  Plan defines HOW to implement THIS feature, not project laws.|
+---------------------------------------------------------------+
|  ACTION: Moving governance content to constitution reference..|
+---------------------------------------------------------------+
```

**Auto-fix:** Replace governance statements with constitution references:
- "Always use TDD" -> "Per constitution: [reference TDD principle]"
- "Code must have 100% coverage" -> "Coverage target per constitution"
- "All PRs require review" -> (remove - this is workflow, not implementation)

Re-validate after fixes until no violations remain.

## Output Validation (REQUIRED)

Before writing ANY artifact:

1. Review output against EACH constitutional principle
2. If ANY violation detected:
   - STOP immediately
   - State: "CONSTITUTION VIOLATION: [Principle Name]"
   - Explain: What specifically violates the principle
   - Suggest: Compliant alternative approach
3. If compliant, proceed and note: "Validated against constitution v[VERSION]"

## Key Rules

- Use absolute paths
- ERROR on gate failures or unresolved clarifications
- Command ends after Phase 1 design is complete

## Report

Output:
- Branch name
- IMPL_PLAN path
- Generated artifacts list:
  - research.md (includes Tessl Tiles section if Tessl available)
  - data-model.md
  - contracts/*
  - quickstart.md
- Agent file update status
- Tessl integration status:
  - Tiles installed (with versions)
  - Skills available for implementation phase
  - Technologies without tiles

## Semantic Diff on Re-run

**If plan.md already exists with content**, perform semantic diff before overwriting:

### 1. Detect and Parse Existing Plan

If plan.md exists and has Technical Context filled in:

1. **Extract semantic elements**:
   - Language/Version
   - Primary Dependencies
   - Storage choice
   - Project structure decisions

2. **Compare with new content**:
   ```
   +-----------------------------------------------------+
   |  SEMANTIC DIFF: plan.md                             |
   +-----------------------------------------------------+
   |  Tech Stack:                                        |
   |    ~ Language: Python 3.11 -> Python 3.12           |
   |    + Added: Redis for caching                       |
   |    - Removed: None                                  |
   |                                                     |
   |  Architecture:                                      |
   |    ~ Changed: Switched from REST to GraphQL         |
   |    + Added: Event sourcing pattern                  |
   +-----------------------------------------------------+
   |  DOWNSTREAM IMPACT:                                 |
   |  ! tasks.md MUST be regenerated (arch change)       |
   |  ! contracts/ need updates (API change)             |
   |  ! data-model.md may need updates                   |
   +-----------------------------------------------------+
   ```

3. **Flag breaking changes**:
   - Language change -> ALL tasks affected
   - Framework change -> Most tasks affected
   - Storage change -> Data layer tasks affected

### 2. Automatic Downstream Invalidation

If significant changes detected:
```
WARNING: Plan changes detected that invalidate downstream artifacts.
Recommend re-running:
- /iikit-06-tasks (REQUIRED - architecture changed)
- /iikit-07-analyze (RECOMMENDED - verify consistency)
```

## Next Steps

After completing the plan:

1. **Recommended**: Run `/iikit-04-checklist` to create domain-specific quality checklists
   - Generates "unit tests for English" to validate requirements quality
   - Helps catch requirement gaps before implementation
   - Required to reach 100% before `/iikit-08-implement`

2. If constitution requires TDD: **(REQUIRED by constitution) Generate test specifications** with `/iikit-05-testify`
   - If no TDD requirement: **(Optional) Generate test specifications for TDD** with `/iikit-05-testify`

3. **Required**: Run `/iikit-06-tasks` to generate the task breakdown

Suggest to user:
```
Plan complete! Next steps:
- /iikit-04-checklist - (Recommended) Generate quality checklists for requirements validation
- /iikit-05-testify - Generate test specifications (REQUIRED if TDD mandated, otherwise Optional)
- /iikit-06-tasks - Generate task breakdown from plan
```

Related Skills

project-planner

16
from diegosouzapw/awesome-omni-skill

Transforms project ideas into structured documentation (overview + specifications). Use when starting new projects or when brief needs project-level planning with vision, features, and technical requirements.

planning

16
from diegosouzapw/awesome-omni-skill

Universal planning for technical and non-technical projects. Domains: software implementation, business, personal, creative, academic, events. Capabilities: feature planning, system architecture, goal setting, milestone planning, requirement breakdown, trade-off analysis, resource allocation, risk assessment. Actions: plan, architect, design, evaluate, breakdown, structure projects. Keywords: implementation plan, technical design, architecture, roadmap, project plan, strategy, goal setting, milestones, timeline, action plan, SMART goals, sprint planning, task breakdown, OKRs. Use when: planning features, designing architecture, creating roadmaps, setting goals, organizing projects, breaking down requirements.

plan-feature

16
from diegosouzapw/awesome-omni-skill

Plan a new feature from concept to approved implementation plan. Activates Product Council for strategic evaluation, then Feature Council for technical planning. Produces a documented decision and scoped task breakdown. Use when starting any new feature work.

breakdown-plan

16
from diegosouzapw/awesome-omni-skill

Issue Planning and Automation prompt that generates comprehensive project plans with Epic > Feature > Story/Enabler > Test hierarchy, dependencies, priorities, and automated tracking.

agile-planning

16
from diegosouzapw/awesome-omni-skill

Generate agile release plans with sprints and roadmaps using unique sprint codes. Use when creating sprint schedules, product roadmaps, release planning, or when user mentions agile planning, sprints, roadmap, or release plans.

account-plan

16
from diegosouzapw/awesome-omni-skill

Create or update strategic account plan

40-plan-action-150

16
from diegosouzapw/awesome-omni-skill

[40] PLAN. Create clear action plans with steps, success criteria, and risk awareness. Use before implementing features, making changes, starting projects, or anytime you need a roadmap to success. Triggers on "plan this", "how should we approach", "what's the strategy", "steps to complete", or when facing complex multi-step work.

overseer-plan

16
from diegosouzapw/awesome-omni-skill

Convert markdown planning documents to Overseer tasks via MCP codemode. Use when converting plans, specs, or design docs to trackable task hierarchies.

implementation-planning

16
from diegosouzapw/awesome-omni-skill

Use when you have specifications or requirements for multi-step implementation tasks requiring comprehensive documentation for handoff

explanation-docs

16
from diegosouzapw/awesome-omni-skill

Explanation documentation patterns for understanding-oriented content - conceptual guides that explain why things work the way they do

executing-plans

16
from diegosouzapw/awesome-omni-skill

Execute implementation plans with batch processing and review checkpoints. Use when given a plan document.

AILANG Sprint Planner

16
from diegosouzapw/awesome-omni-skill

Analyze design docs, calculate velocity from recent work, and create realistic sprint plans with day-by-day breakdowns. Use when user asks to "plan sprint", "create sprint plan", or wants to estimate development timeline.