Code Implementation from Business Specifications

Implement code based on user-described business requirements with a strict workflow: confirm requirements first, implement, self-test, and fix until it runs.

Core Workflow

Every implementation task follows these phases in order. Never skip a phase.

Phase 1: Requirement Clarification

Goal: Ensure complete alignment with the user before writing any code.

Process:

1. Read the user's requirement description carefully.
2. Identify any ambiguities, missing details, or conflicting requirements.
3. Present the user with a structured summary of your understanding, including:

• What will be built (feature list, functionality scope)
• Tech stack choices (language, framework, libraries) — if not specified, state your recommendation and ask
• Expected inputs and outputs
• Edge cases and error handling expectations
• Any assumptions you are making

1. Format your confirmation as a clear checklist or structured summary. Example:

Here's my understanding before I start:

• Language: Python 3.11
• Framework: FastAPI
• Features: user registration, login, JWT auth
• Database: SQLite (local dev)
• Edge cases: duplicate email handling, weak password rejection
• Testing: you'll run python main.py to verify

Does this match what you want? Any changes?

1. Wait for explicit user confirmation before proceeding to Phase 2. Do not write code until the user confirms.
2. If the user provides corrections, re-summarize and confirm again.

Key rule: Never assume. If a requirement is unclear, ask. If a choice could reasonably go multiple ways, present options and let the user decide.

Phase 2: Implementation

Goal: Write complete, working code that satisfies the confirmed requirements.

Process:

1. Based on confirmed requirements, plan the file structure before writing.
2. Write the code, following these principles:

• Write complete files — no stubs, no // TODO, no half-finished logic
• Follow language/framework conventions
• Handle the edge cases identified in Phase 1
• Write clean, readable code with appropriate naming
• No unnecessary comments — code should be self-documenting

1. If the project spans multiple files, implement them in dependency order.
2. Keep the implementation focused on what was confirmed in Phase 1 — no scope creep.

Phase 3: Self-Test & Verification

Goal: Verify the code actually runs correctly before reporting completion.

Process:

1. Run the project using the method the user will use (e.g., python main.py, npm start, go run .).
2. If the project has tests, run them: the test suite must pass.
3. If there are no tests, manually exercise the key paths:

• Start the application
• Hit the main endpoint(s) or run the main flow
• Test edge cases identified in Phase 1
• Verify expected outputs

1. If everything works: proceed to report completion.
2. If anything fails or behaves unexpectedly: go to Phase 4.

Phase 4: Debug & Fix

Goal: Iterate until the project runs correctly.

Process:

1. Read the error output carefully. Understand the root cause.
2. Fix the code — prefer targeted fixes over rewrites.
3. Run the verification again (back to Phase 3).
4. Loop through Phase 3 → Phase 4 until:

• All errors are resolved
• The application runs without crashes
• Output matches expected behavior

1. If you are stuck after 3 iterations, present the error and your analysis to the user for guidance — do not loop endlessly.

Phase 5: Completion Report

Goal: Clearly summarize what was done and how to use it.

Process:

1. Report a brief summary:

• What was built
• Files created/modified
• How to run the project
• Any known limitations (only if real)

1. Be concise — no filler, no self-praise.

Key Principles

• No code before confirmation: Phase 1 is mandatory. Never start implementing until the user confirms the requirements.
• Always self-test: Never report a task as done without running the code yourself first.
• Fix, don't abandon: If the code has issues, fix them. Only ask the user for help after 3 failed debugging attempts.
• Stay in scope: Build exactly what was confirmed. Don't add "bonus" features.
• Be transparent: If you hit a limitation or can't fully test something (e.g., needs an external API key), say so explicitly in the completion report.

When to Use This Skill

This skill activates when the user:

• Describes a feature or project they want built in natural language
• Asks to "implement", "build", "create", "develop" something based on requirements
• Provides specifications or acceptance criteria for a coding task
• Says things like "I need an app that...", "Build me a script that...", "Create a service for..."

When NOT to Use

Skip this skill for:

• Bug fixes on existing code (no new feature being built)
• Code reviews or analysis tasks
• One-line changes or trivial edits
• Questions about how something works
• Tasks where the user has already provided a detailed, unambiguous implementation plan