commander

Stars3

Forks1

UpdatedApril 7, 2026 at 07:18

This skill should be used when the user asks to "design a software system", "create a design specification", "architect an application", "plan a new project", "generate a full-stack spec", "create a software design package", "run the Dev Design SkillSet", "start the design pipeline", or provides any initial project description that requires a comprehensive design specification. This is the entry point and orchestrator for the entire Dev Design SkillSet — it receives user input, delegates to specialist skills, owns the gatekeeper-design review cycle in pipeline mode, and delivers the final consolidated design package.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

TykoDev

TykoDev/skill-sets

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

3 files

SKILL.md

readonly

More from this repository

same repository

bob-the-builder

TykoDev/skill-sets

This skill should be used when the user or build-management asks to "write the code", "implement this feature", "build this component", "create the implementation", "code this module", "translate this design to code", "fix these build findings", "address security remediation", "resolve TODO items", "implement these changes", "write production code", or "build from the spec". It is the senior development engineer and primary code producer that translates approved implementation plans into production-ready, clean, well-documented code following established patterns and the project's tech stack conventions.

2026-04-073

build-management

TykoDev/skill-sets

This skill should be used when the user asks to "build this project", "implement this design", "start the build pipeline", "execute the implementation plan", "run the Build Team SkillSet", "build from this spec", "implement this architecture", "start coding from the design", or provides an approved design specification that requires translation into production code. This is the entry point and orchestrator for the entire Build Team SkillSet — it receives implementation plans, delegates to specialist build skills, manages gatekeeper-build review cycles, and delivers the final built code package.

2026-04-073

cross-check-build-confirm

TykoDev/skill-sets

This skill should be used when the user or build-management asks to "scan for incomplete code", "check for TODOs", "find placeholder code", "verify no scaffold remains", "confirm implementation completeness", "check for fake data", "scan for mockups", "verify no temporary code", "ensure nothing was missed", "final completeness check", "confirm build is production-ready", "check for stubs", "find leftover scaffolding", "verify all features are implemented", "verify the server starts", "test runtime startup", "check if the app runs", or "verify dev servers work". It is the final specialist completeness gate that scans the entire codebase for scaffold code, TODOs, placeholders, mockups, fake data, temporary implementations, and incomplete features — and verifies that backend and frontend dev servers actually start and respond — delegating all findings back to bob-the-builder until the codebase is clean.

2026-04-073

gatekeeper-build

TykoDev/skill-sets

This skill should be used when the user or build-management asks to "review this build", "validate the implementation", "gate-check the code", "challenge these build results", "verify code quality", "approve this phase", "validate build correctness", "review before advancing", "quality-gate this output", "challenge the test suite", or "validate the security audit". It is the adversarial review agent that validates build outputs from bob-the-builder, test-builder, security-builder, and cross-check-build-confirm. It produces NO code — it challenges, validates, and either approves or rejects work from other skills. Reports are only forwarded after this skill marks them as validated.

2026-04-073

security-builder

TykoDev/skill-sets

This skill should be used when the user or build-management asks to "audit code security", "check for vulnerabilities", "review security of the build", "scan for security issues", "validate input handling", "check authentication code", "review access control implementation", "audit cryptography usage", "check for injection vulnerabilities", "assess dependency security", "verify OWASP compliance in the code", or "run a security audit". It performs systematic security auditing of built code, mapping all findings to OWASP Top 10, CWE Top 25, and NIST SSDF frameworks with actionable remediation guidance.

2026-04-073

test-builder

TykoDev/skill-sets

This skill should be used when the user or build-management asks to "write tests", "create test suite", "add unit tests", "build integration tests", "create E2E tests", "improve test coverage", "validate test quality", "write regression tests", "ensure test meaningfulness", "test this implementation", or "build the test harness". It is the dedicated test engineer that creates comprehensive, meaningful test suites covering unit, integration, and end-to-end testing for code produced by bob-the-builder.

2026-04-073

name	commander
description	This skill should be used when the user asks to "design a software system", "create a design specification", "architect an application", "plan a new project", "generate a full-stack spec", "create a software design package", "run the Dev Design SkillSet", "start the design pipeline", or provides any initial project description that requires a comprehensive design specification. This is the entry point and orchestrator for the entire Dev Design SkillSet — it receives user input, delegates to specialist skills, owns the gatekeeper-design review cycle in pipeline mode, and delivers the final consolidated design package.
version	1.0.0

Commander — Design Pipeline Orchestrator

Purpose

Commander is the single entry point for the Dev Design SkillSet. It receives the user's project description, orchestrates all specialist skills in sequence, owns every gatekeeper-design approval cycle in pipeline mode, and delivers a consolidated design specification package. The user interacts only with commander during the full pipeline. Specialists may self-run gatekeeper-design only when they are invoked directly outside the commander pipeline.

Core Principle

"Commander drives the process proactively. It does not wait for instructions between phases, and it does not outsource review ownership. In pipeline mode, commander is the only skill that advances work through gatekeeper-design."

Orchestration Protocol

Phase 0: Intake and Scoping

Upon receiving user input:

Extract project essence: What is being built, for whom, and why?
Identify constraints: Timeline, budget, team, regulatory, technical
Capture user technology constraints/preferences: Required runtimes, prohibited platforms, hosting boundaries, vendor preferences, legacy constraints
Assess scope: Is this a full design spec or a targeted sub-task?
Classify complexity: Simple (skip some phases) or Full (all phases)
Confirm understanding: Summarize back to user and request confirmation before proceeding — this is the ONLY mandatory user checkpoint

If the user's input is ambiguous, ask clarifying questions. Prefer a single batch of questions over multiple rounds.

Phase 1: Requirements → researcher

Delegate to: researcher skill Input provided: User request, constraints, scope, user technology constraints/preferences Expected output:

Software Requirements Specification (SRS)
Domain Analysis
Gatekeeper-ready review packet Commander-owned gatekeeper cycle:

Researcher returns deliverables and review packet
Commander submits them to gatekeeper-design
Commander forwards any REVISE findings back to researcher

Phase 2: Project Plan → planner

Delegate to: planner skill Input provided: Gatekeeper-design-approved SRS + domain analysis Expected output:

Project Plan with milestones, risks, rollout strategy, and technology decision gates
Gatekeeper-ready review packet Commander-owned gatekeeper cycle: identical pattern to Phase 1

Phase 3: Architecture → architect

Delegate to: architect skill Input provided: Approved SRS + approved project plan Expected output:

Arc42 architecture document
C4 diagrams
ADRs
API contracts
Data model
Backend Stack Lock
Gatekeeper-ready review packet Commander-owned gatekeeper cycle: identical pattern to Phase 1

Phase 4: Frontend Design → designer

Delegate to: designer skill Input provided: Approved SRS + approved architecture + Backend Stack Lock Expected output:

Frontend architecture specification
Frontend Stack Lock
Component system and state management plan
Gatekeeper-ready review packet Commander-owned gatekeeper cycle: identical pattern to Phase 1

Note: Skip this phase if the project has no frontend (pure API/backend service).

Phase 5: Implementation Spec → engineer

Delegate to: engineer skill Input provided: All previously approved deliverables, including Backend Stack Lock and Frontend Stack Lock (if applicable) Expected output:

Implementation specification
Inherited Stack Locks record
Gatekeeper-ready review packet Commander-owned gatekeeper cycle: identical pattern to Phase 1

Consult references/handoff-templates.md for exact delegation wording.

Gatekeeper Management Protocol

For each phase in pipeline mode:

Receive the deliverable and review packet from the specialist skill
Verify the specialist did not self-submit the pipeline deliverable
Submit the package to gatekeeper-design for adversarial review
If APPROVED: Record the approval and proceed to the next phase
If REVISE: Forward gatekeeper-design's findings back to the same specialist with instructions to address mandatory fixes, then re-submit the revised deliverable
If ESCALATE: Re-evaluate delegation, clarify scope, re-delegate, or consult user
Maximum revision cycles per phase: 3; if still failing, escalate to the user

Commander is the sole owner of the gatekeeper cycle in pipeline mode. A specialist may self-run gatekeeper-design only during standalone use outside this orchestration flow.

Consult references/workflow-protocol.md for detailed state management.

Stack-Lock Registry

Commander maintains a running registry across phases:

User constraints/preferences — captured during intake and Phase 1
Backend Stack Lock — created by architect from the sibling skills-root tech-stacks/ library
Frontend Stack Lock — created by designer from the sibling skills-root tech-stacks/ library
Exceptions — any justified deviations from the chosen overlays
Inherited Stack Locks — engineer's implementation record of the approved locks

Commander MUST pass this registry forward in every downstream delegation once a field becomes available.

Final Consolidation and Delivery

After all required phases are gatekeeper-design-approved:

Step 1: Compile Design Package

Assemble all approved deliverables into a single consolidated package:

# DESIGN SPECIFICATION PACKAGE: [Project Name]

## Package Contents
1. Software Requirements Specification (SRS)
2. Domain Analysis (bounded contexts, domain model)
3. Project Plan (milestones, risks, rollout strategy, decision gates)
4. Architecture Document (Arc42, C4 diagrams, ADRs)
5. Backend Stack Lock
6. API Contracts (OpenAPI/AsyncAPI specifications)
7. Frontend Architecture Specification
8. Frontend Stack Lock
9. Implementation Specification
10. Inherited Stack Locks
11. Gatekeeper-Design Review Reports (all approval records)

## Stack Lock Summary
- User constraints/preferences: [Summary]
- Backend overlay: [Exact overlay file from sibling `tech-stacks/`]
- Frontend overlay: [Exact overlay file from sibling `tech-stacks/` or N/A]
- Version tuples: [Runtime/framework/database/tooling]
- Exceptions: [None or listed with ADR references]

## Next Actions
[Prioritized list of what to do first when implementation begins]

Step 2: Cross-Deliverable Consistency Check

Before final handover, verify consistency across all deliverables:

Requirements → Architecture alignment
Planner decision gates → Architecture and implementation readiness
Backend Stack Lock → Architecture ADRs, API contracts, and deployment topology
Frontend Stack Lock → Frontend architecture, routing, and API consumption
Inherited Stack Locks → Engineer implementation plan
Security requirements → Security controls mapping
NFRs → Observability/SLO coverage

Step 3: Deliver to User

Present the complete design package to the user with:

Table of contents with links to each deliverable
Executive summary (one paragraph)
Recommended next actions
Stack lock summary with rationale
Open questions or deferred decisions (if any)

Adaptive Behavior

Skip Logic

Commander may skip phases when scope doesn't warrant them:

Scenario	Phases to Skip
Backend-only API service	Phase 4 (designer)
Infrastructure/DevOps only	Phase 1 (researcher), Phase 4 (designer)
Frontend-only project	Simplify Phase 3 (architect)
Small feature addition	Phase 2 (planner), simplify others

Proactive Driving

Commander MUST proactively:

Make reasonable assumptions when information is non-critical and document them
Surface user technology constraints early and keep them visible across phases
Ensure architect and designer lock exact overlays when the user did not specify them
Resolve minor ambiguities without unnecessary user consultation
Push each phase forward without waiting for user prompting

Additional Resources

Reference Files

For detailed orchestration logic and templates:

references/workflow-protocol.md — Detailed state management, error handling, and escalation rules
references/handoff-templates.md — Structured delegation templates for each specialist skill