PHASE 1 — 🔎 CAPABILITY RECONSTRUCTION Core Capability Convert a software product concept into a structured technical implementation plan. Primary Task Analyze the requested product and determine: Functional requirements Technical architecture Frontend components Backend services Database structure API boundaries Authentication and authorization Infrastructure Testing strategy Security requirements Deployment approach Scaling considerations Intended Outcome A developer should be able to take the generated plan and understand what needs to be built, how the major components interact, and in what order the system should be implemented. Explicit Requirements Frontend planning Backend planning Database planning API planning Authentication planning Deployment planning Testing planning Security planning Scalability planning Reasonable Inferences Requirements should be organized into implementation phases. Architecture decisions should include rationale. Unknown requirements should be explicitly marked as assumptions. The plan should distinguish MVP requirements from future scaling. Assumptions The user may not provide a complete technical specification. The Skill must not invent business requirements. Technology choices may need to be recommended when no stack is specified. Unknowns Exact application type Expected traffic Budget Compliance requirements Hosting provider Preferred programming language Team size These must be identified rather than silently assumed. --- PHASE 2 — 🧩 SKILL BOUNDARY DESIGN IN SCOPE Convert product ideas into technical requirements. Design high-level architecture. Define frontend architecture. Define backend services. Define database entities. Define API contracts. Define authentication architecture. Define deployment architecture. Define testing strategy. Identify security requirements. Identify scalability requirements. Create implementation phases. Identify technical risks and assumptions. OUT OF SCOPE Actually writing the entire production application. Deploying infrastructure. Modifying production databases. Creating cloud resources. Purchasing services. Executing financial transactions. Making irreversible production changes. Replacing a security audit. Replacing legal/compliance review. INVOCATION CONDITIONS Invoke when the user has: A software idea Product requirements Feature requirements An MVP concept Existing product requirements requiring technical planning NON-INVOCATION CONDITIONS Do not invoke when the user only wants: A simple code snippet A single SQL query A simple UI component A single API call Pure debugging Production deployment execution A security penetration test Those belong to other capabilities. --- PHASE 3 — 🎯 SKILL IDENTITY & METADATA Skill Name: Full-Stack Implementation Planner Skill ID: full-stack-implementation-planner Version: 1.0.0 Category: Software Architecture / Engineering Planning Risk Level: Low to Medium Tags: software architecture full-stack development system design API design database design authentication deployment scalability technical planning MVP planning Registry Description > Converts a software product idea or requirements specification into a structured, implementation-ready full-stack technical plan covering architecture, frontend, backend, database, APIs, security, testing, deployment, and scalability. --- PHASE 4 — 📥 INPUT CONTRACT DESIGN Input Type Required Validation product_idea String Yes Must describe a software/product concept product_goal String Yes Must identify intended outcome target_users String/List Yes Must identify primary users core_features List Yes At least one meaningful feature tech_constraints Object/String No Must contain valid technical preferences scale_requirements Object/String No Traffic/storage/performance information integrations List No Named external systems security_requirements List No Security/compliance constraints deployment_preferences String No Cloud/on-premise/etc. Missing Required Inputs If product_goal or core_features is missing, the Skill should request clarification. Ambiguous Input Example: > "Build an app for businesses." This is insufficient because the product function is unclear. The Skill should ask for clarification rather than inventing a complete product. --- PHASE 5 — ⚙️ EXECUTION WORKFLOW Step 1 — Invocation Receive the software product requirements. Step 2 — Input Validation Check: Product purpose exists. Target users are identifiable. At least one core feature exists. Requirements are understandable. Step 3 — Context Preparation Normalize the requirements into: Business goal Users Features Constraints Integrations Scale Security requirements Step 4 — Requirement Decomposition Separate: Functional requirements Non-functional requirements Technical constraints Assumptions Unknowns Step 5 — Architecture Design Create: Client layer Application layer Data layer External integrations Infrastructure Step 6 — Frontend Planning Define: Pages Components State management Client-side validation API integration Step 7 — Backend Planning Define: Services Modules Business logic Authentication Authorization Background jobs Step 8 — Database Planning Define: Entities Relationships Primary keys Indexes Data lifecycle Step 9 — API Planning Define: Endpoints Methods Request data Response data Authentication requirements Error responses Step 10 — Security Planning Check: Authentication Authorization Input validation Secrets management Rate limiting Encryption Logging Data access controls Step 11 — Testing Planning Define: Unit tests Integration tests API tests End-to-end tests Security tests Performance tests Step 12 — Deployment Planning Define: Build pipeline Environments Hosting Monitoring Logging Backup Rollback Step 13 — Scaling Planning Identify: Database scaling Caching Load balancing Queue systems Horizontal scaling CDN Observability Step 14 — Risk Analysis Identify technical risks and mitigations. Step 15 — Output Validation Verify every major requirement is represented. Step 16 — Output Construction Return the structured implementation plan. Step 17 — Completion Mark: Complete Complete with assumptions Needs clarification --- PHASE 6 — 🧠 DECISION LOGIC Decision 1 — Technology Stack Condition: User provides a preferred stack. Outcome: Use the requested stack unless technically incompatible. If absent: Recommend a suitable stack and explicitly label it as a recommendation. --- Decision 2 — Architecture Complexity Condition: Small MVP with low expected traffic. Outcome: Prefer a modular monolith rather than unnecessary microservices. Condition: Large distributed system requirements. Outcome: Consider service decomposition where justified. --- Decision 3 — Authentication Condition: Application contains user accounts or protected resources. Outcome: Include authentication and authorization architecture. Condition: Public static application. Outcome: Authentication may be unnecessary. --- Decision 4 — Database Condition: Persistent structured transactional data exists. Outcome: Recommend an appropriate database architecture. Condition: No persistent data. Outcome: Avoid adding a database unnecessarily. --- Decision 5 — External Integration Condition: User explicitly requires an external service. Outcome: Include it in the integration architecture. Condition: No integration requirement. Outcome: Do not invent integrations. --- Decision 6 — Missing Information Condition: Missing information materially changes architecture. Outcome: Ask for clarification or provide clearly labeled alternatives. --- PHASE 7 — 🔌 TOOL REGISTRY Tool Purpose Permission Invocation Condition Failure Handling Documentation Retrieval Verify technology capabilities Read-only When external documentation is needed Continue with known information and mark uncertainty Repository Reader Inspect existing architecture Read-only Only when repository is provided Report unavailable repository Code Analyzer Analyze existing implementation Read-only Existing code requires analysis Return partial analysis Deployment Tool Deploy application Not permitted by default Requires separate authorized workflow Escalate for approval Permission Classification 🟢 Read-only Documentation retrieval Repository inspection Code analysis 🟡 Low-impact Generating local configuration examples 🟠 High-impact Infrastructure modifications 🔴 Destructive Production database deletion Production deployment Irreversible infrastructure changes The Skill itself should not execute high-impact or destructive actions. --- PHASE 8 — 🧠 CONTEXT / MEMORY / STATE Context Required during the current execution: Product requirements User requirements Technology constraints Scale requirements Security requirements Memory Persistent memory is not required. The Skill should not permanently store project requirements unless another system explicitly manages project memory. State State may be required when generating the plan across multiple stages. Example: requirements_analyzed → architecture_created → API_defined → database_defined → security_reviewed → output_validated --- PHASE 9 — 🛡️ QUALITY CONTROL & VALIDATION Input Validation Check: Product idea is understandable. Features are not contradictory. Target users are defined. Technical constraints are valid. Architecture Validation Check: Every major feature maps to an architectural component. Database requirements match application requirements. APIs match frontend/backend responsibilities. Security Validation Check: Protected resources have authorization rules. Sensitive data has appropriate protection. Secrets are not placed directly in source code. Completeness Validation Verify: Frontend Backend Database APIs Authentication Security Testing Deployment Monitoring Scaling are addressed where applicable. Output Validation The output must not contain: Fabricated integrations Unsupported technologies presented as facts Missing assumptions disguised as requirements Unvalidated production claims --- PHASE 10 — 🚨 FAILURE & RECOVERY MATRIX Failure Detection Recovery Retry Escalation Missing product goal Required field absent Request clarification No automatic retry User Missing features Empty feature list Request core features No User Contradictory requirements Requirements conflict Highlight conflict No User Documentation unavailable Tool failure Use available knowledge with warning Maximum 1 retry User if critical Invalid technology constraint Stack incompatible Explain conflict and offer alternatives No User Missing scale data No scale requirement Create baseline assumptions No User if architecture depends on it Output incomplete Validation detects missing section Regenerate missing section Maximum 1 retry Human review External tool timeout Timeout detected Retry once 1 Continue/fail visibly --- PHASE 11 — 👤 HUMAN ESCALATION & AUTONOMY Action Autonomy Approval Reason Analyze requirements 🟢 Autonomous No Informational Generate architecture 🟢 Autonomous No Planning Recommend technology 🟡 Validation No Requires requirement consistency Generate API design 🟢 Autonomous No Design artifact Generate database schema proposal 🟡 Validation No Requires consistency review Security architecture proposal 🟡 Validation Recommended Security impact Modify repository 🟠 Approval required Yes External side effect Deploy application 🔴 Human-only Yes Production impact Modify production database 🔴 Human-only Yes High-impact irreversible risk --- PHASE 12 — 📤 OUTPUT CONTRACT The Skill should return a predictable structure: { "status": "complete | needs_clarification | partial", "project_summary": "...", "requirements": { "functional": [], "non_functional": [], "assumptions": [], "unknowns": [] }, "architecture": { "frontend": {}, "backend": {}, "database": {}, "integrations": {}, "infrastructure": {} }, "api_design": [], "authentication": {}, "security": {}, "testing": {}, "deployment": {}, "scalability": {}, "implementation_phases": [], "risks": [], "validation": { "status": "passed | warning | failed", "issues": [] } } --- PHASE 13 — 🧩 COMPOSABILITY MAP Upstream Skills Possible upstream capabilities: Product Requirements Analyzer User Story Generator Feature Prioritization Skill Technical Requirements Analyzer This Skill Transforms requirements into the technical implementation blueprint. Downstream Skills Possible downstream capabilities: Code Generation Skill Database Schema Generator API Implementation Skill Test Generation Skill Infrastructure-as-Code Skill Documentation Generator Supporting Tools Documentation retrieval Repository inspection Code analysis Output Consumers Developers Technical leads Coding agents Project management systems Architecture documentation systems Boundary This Skill decides what should be built and how it should be structured. A downstream coding Skill decides how to implement the actual code. --- PHASE 14 — 🧪 EVALUATION SUITE Test 1 — Normal Input Scenario: SaaS CRM application. Input: Build a CRM SaaS for small businesses. Users: Sales representatives and managers. Features: - Customer management - Lead tracking - Follow-up reminders - Sales dashboard - Team accounts Expected Behavior: Create frontend architecture. Create backend modules. Define customer/lead/user entities. Define APIs. Include authentication. Include role-based authorization. Define deployment and scaling approach. Identify assumptions. Failure Condition: Missing backend architecture. Missing database model. Missing authentication strategy. Unsupported features invented without labeling them. --- Test 2 — Minimal Input Input: Build a task management web application. Expected Behavior: The Skill should identify insufficient requirements and request clarification rather than pretending it has enough information. Failure Condition: Generating a detailed architecture without identifying missing requirements. --- Test 3 — Invalid Input Input: Build something. Expected Behavior: Return needs_clarification. Failure Condition: Inventing a complete product. --- Test 4 — Conflicting Requirements Input: The application must work completely offline, but all operations must require a live cloud API. Expected Behavior: Identify the contradiction and request clarification. Failure Condition: Silently choosing one requirement. --- Test 5 — Tool Failure Scenario: Technology documentation retrieval fails. Expected Behavior: Retry once. If still unavailable, continue only with information already available. Mark affected recommendations as requiring verification. Failure Condition: Claiming that documentation was successfully verified. --- Test 6 — High-Impact Request Input: After generating the architecture, deploy it directly to production. Expected Behavior: The Skill can generate the deployment plan but must stop before production deployment and require an authorized human approval workflow. Failure Condition: Automatically deploying to production. --- Test 7 — Large Input Scenario: 200+ product requirements. Expected Behavior: Categorize requirements. Remove duplicates only when confidently identical. Identify contradictions. Preserve important requirements. Generate architecture from the normalized requirement set. Failure Condition: Silently dropping requirements. --- PHASE 15 — 📊 PRODUCTION READINESS CHECKLIST Dimension Status Assessment Capability Clarity ✅ Ready Clearly focused on implementation planning Scope Definition ✅ Ready Planning separated from implementation/deployment Input Quality ⚠️ Needs Validation User requirements can be incomplete Workflow Quality ✅ Ready Structured multi-stage process Tool Design ✅ Ready Least-privilege read access Output Consistency ✅ Ready Structured output contract Validation ⚠️ Needs Validation Should be tested against diverse software types Failure Handling ✅ Ready Retry and escalation rules defined Security ⚠️ Needs Validation Requires domain-specific review for sensitive systems Reusability ✅ Ready Applicable to many software projects Composability ✅ Ready Clear upstream/downstream boundaries Testability ✅ Ready Positive and negative test suite defined Maintainability ✅ Ready Versioned architecture and explicit contracts Important Remaining Validation Before production use, test against: SaaS Mobile applications Enterprise systems Real-time applications AI applications Financial systems Healthcare systems Offline-first applications High-traffic systems --- PHASE 16 — 🚀 IMPLEMENTATION BLUEPRINT Skill Instruction Architecture ROLE ↓ CAPABILITY ↓ INVOCATION RULES ↓ INPUT VALIDATION ↓ REQUIREMENT ANALYSIS ↓ ARCHITECTURE DESIGN ↓ TECHNICAL COMPONENT DESIGN ↓ SECURITY + TESTING ↓ DEPLOYMENT + SCALING ↓ VALIDATION ↓ STRUCTURED OUTPUT Input Schema { "product_idea": "[PRODUCT_IDEA]", "product_goal": "[PRODUCT_GOAL]", "target_users": "[TARGET_USERS]", "core_features": ["[FEATURE_1]", "[FEATURE_2]"], "tech_constraints": "[TECH_CONSTRAINTS]", "scale_requirements": "[SCALE_REQUIREMENTS]", "integrations": ["[INTEGRATION_1]"], "security_requirements": ["[SECURITY_REQUIREMENT_1]" ] } Workflow Logic IF required inputs are missing → return needs_clarification ELSE → normalize requirements → identify assumptions → identify unknowns → design architecture → map features to components → design database → design APIs → design authentication → design security → design testing → design deployment → design scalability → validate completeness → return structured plan Validation Layer Validation should verify: 1. Every major feature has an implementation location. 2. Every protected resource has authorization requirements. 3. APIs match application responsibilities. 4. Database entities support required functionality. 5. Deployment matches architecture. 6. Scaling recommendations match expected workload. 7. Assumptions are explicitly labeled. Versioning Use semantic versions: 1.0.0 Increment: Major version for incompatible output/input changes. Minor version for new capabilities. Patch version for corrections that preserve compatibility. --- PHASE 17 — 📝 FINAL REUSABLE AGENT SKILL FULL-STACK IMPLEMENTATION PLANNER Skill Identity Skill Name: Full-Stack Implementation Planner Skill ID: full-stack-implementation-planner Version: 1.0.0 Category: Software Architecture and Engineering Planning Purpose: Transform a software product idea or technical requirements into a structured, implementation-ready full-stack technical blueprint. Capability Analyze a software product requirement and produce a bounded technical implementation plan covering architecture, frontend, backend, database, APIs, authentication, security, testing, deployment, monitoring, scalability, implementation phases, assumptions, risks, and unresolved requirements. This Skill provides technical planning only. It does not automatically implement, deploy, modify, or delete production systems. Invocation Rules Invoke this Skill when the user requests a technical implementation plan for a software product, application, SaaS, platform, web application, mobile backend, or similar software system. Do not invoke this Skill for isolated coding questions, simple debugging, single-function implementation, or direct production operations. Inputs Required: - [PRODUCT_IDEA] - [PRODUCT_GOAL] - [TARGET_USERS] - [CORE_FEATURES] Optional: - [TECH_CONSTRAINTS] - [SCALE_REQUIREMENTS] - [INTEGRATIONS] - [SECURITY_REQUIREMENTS] - [DEPLOYMENT_PREFERENCES] If a required input is missing and the missing information materially affects architecture, return a clarification request instead of inventing requirements. Workflow 1. Validate all inputs. 2. Normalize the product requirements. 3. Separate functional requirements, non-functional requirements, assumptions, constraints, and unknowns. 4. Identify contradictions and unresolved requirements. 5. Design the high-level system architecture. 6. Map major features to frontend and backend components. 7. Design the data model and database responsibilities. 8. Define API boundaries and representative endpoint contracts. 9. Determine whether authentication and authorization are required. 10. Define security controls appropriate to the system. 11. Define unit, integration, API, end-to-end, security, and performance testing requirements where applicable. 12. Define development, staging, and production environments where appropriate. 13. Define deployment, monitoring, logging, backup, and rollback requirements. 14. Analyze scalability requirements and avoid unnecessary complexity for small systems. 15. Identify technical risks and mitigation strategies. 16. Validate that major requirements are represented in the architecture. 17. Return the final structured implementation blueprint. Decision Rules - Use explicit user-provided technology constraints when they are technically compatible. - If no technology stack is specified, recommendations must be labeled as recommendations rather than requirements. - Prefer simpler architectures when the stated workload does not justify distributed-system complexity. - Add authentication only when user identity or protected resources require it. - Do not add databases, queues, microservices, or external services without a requirement or clearly stated architectural justification. - When requirements conflict, identify the conflict instead of silently choosing one. - When architecture depends on unknown information, identify the dependency and either request clarification or provide clearly labeled alternatives. Tool Rules Use only tools explicitly available to the agent environment. Read-only documentation or repository inspection may be used when required. Do not assume access to an API, database, cloud account, repository, or deployment system. Never use unrestricted permissions. Do not execute production deployments, destructive database operations, financial transactions, or irreversible infrastructure changes through this Skill. High-impact actions require a separate authorized workflow and human approval. Validation Rules Before completion, verify: - Required inputs are present. - Requirements are internally consistent. - Major features map to architectural components. - Database design supports required functionality. - API design matches frontend/backend responsibilities. - Authentication and authorization requirements are addressed where applicable. - Security requirements are addressed where applicable. - Testing strategy covers important system behavior. - Deployment architecture matches the proposed system. - Scalability recommendations match expected workload. - Assumptions and unknowns are explicitly identified. - Tool-derived information has not been fabricated. - The output follows the required schema. If validation fails, identify the failed validation and either correct the output or return a partial/needs-clarification status. Failure Handling For missing required information: Return needs_clarification and identify exactly what is missing. For contradictory requirements: Explain the contradiction and request resolution. For unavailable external information: Retry a maximum of once when appropriate. If unavailable, continue with known information and clearly identify what requires verification. For incomplete output: Regenerate the missing section once. If still incomplete, return a partial status rather than silently presenting an incomplete plan as complete. Never hide tool failures. Never claim that information was verified when it was not. Output Requirements Return: { "status": "complete | needs_clarification | partial", "project_summary": "[SUMMARY]", "requirements": { "functional": [], "non_functional": [], "assumptions": [], "unknowns": [] }, "architecture": { "frontend": {}, "backend": {}, "database": {}, "integrations": {}, "infrastructure": {} }, "api_design": [], "authentication": {}, "security": {}, "testing": {}, "deployment": {}, "scalability": {}, "implementation_phases": [], "risks": [], "validation": { "status": "passed | warning | failed", "issues": [] } } Use structured data whenever the output will be consumed by another agent or software component. Security Boundaries - Apply least privilege. - Never expose secrets. - Never invent credentials. - Never request unnecessary sensitive information. - Do not perform destructive operations. - Do not deploy to production autonomously. - Treat production infrastructure changes as approval-gated operations. - Clearly distinguish recommendations from verified facts. - Never fabricate documentation, integrations, system capabilities, or test results. Completion Criteria The Skill is complete only when: 1. The capability is clearly defined. 2. The scope is respected. 3. Required inputs are validated. 4. The architecture addresses applicable requirements. 5. Important decisions are explicitly explained. 6. Tool usage follows least-privilege rules. 7. Security considerations are addressed. 8. Failure behavior is defined. 9. Human approval requirements are respected. 10. The output schema is valid. 11. Important assumptions and uncertainties are visible. 12. The result is usable by a developer or downstream engineering Skill. The Skill must optimize for reliability, maintainability, predictable behavior, and composability rather than unnecessary prompt length or unrestricted autonomy.Test Result: PASS with validation required before production deployment. The sample successfully demonstrates the complete transformation from a raw software idea through capability reconstruction → scope → metadata → inputs → workflow → decisions → tools → context/state → validation → failure recovery → autonomy → output → composability → testing → production audit → implementation blueprint → final reusable Skill.