AgentSkillsCN

workflows-code--full-stack

无栈依赖的开发编排器,通过标记文件与内置的栈相关知识,自动识别栈环境,引导开发者顺利度过实现、调试与验证三大阶段。

SKILL.md
--- frontmatter
name: workflows-code--full-stack
description: "Stack-agnostic development orchestrator guiding developers through implementation, debugging, and verification phases with automatic stack detection via marker files and bundled stack-specific knowledge."
allowed-tools: [Read, Grep, Glob, Bash]
version: 1.0.0
<!-- Keywords: workflows-code, development-orchestrator, multi-stack, stack-detection, debugging-workflow, implementation-patterns, react, nextjs, react-native, swift, go, nodejs -->

Code Workflows - Stack-Agnostic Development Orchestrator

Unified workflow guidance for any technology stack: Go, React, React Native, Swift, Node.js, and more.

Core Principle: Implementation → Debugging (if needed) → Verification (MANDATORY) = reliable, production-ready code.


1. 🎯 WHEN TO USE

Activation Triggers

Use this skill when:

  • Starting development work (any stack)
  • Implementing features, APIs, components, services
  • Encountering errors or unexpected behavior
  • Before ANY completion claim ("works", "fixed", "done", "complete")

Keyword triggers:

  • Implementation: "implement", "build", "create", "add feature", "service", "component"
  • Debugging: "debug", "fix", "error", "not working", "broken", "issue", "bug"
  • Verification: "done", "complete", "works", "fixed", "finished", "verify", "test"

When NOT to Use

  • Documentation-only changes → use workflows-documentation
  • Git/version control → use workflows-git
  • Infrastructure/DevOps → use specialized DevOps skills

Phase Overview

PhasePurposeTrigger
Phase 1: ImplementationWriting code following stack-specific patternsStarting new code, modifying existing
Phase 2: DebuggingFixing issues systematically, root cause analysisTest failures, errors
Phase 3: VerificationFinal validation before completion claimsBefore ANY "done" claim

The Iron Law: NO COMPLETION CLAIMS WITHOUT RUNNING VERIFICATION FOR YOUR STACK


2. 🧭 SMART ROUTING

Stack Detection (Marker File Based)

bash
# Detection order (first match wins)
[ -f "go.mod" ] && STACK="GO"
[ -f "Package.swift" ] && STACK="SWIFT"
[ -f "app.json" ] && grep -q "expo" app.json && STACK="REACT_NATIVE"
[ -f "package.json" ] && grep -q "react-native" package.json && STACK="REACT_NATIVE"
[ -f "next.config.js" ] || [ -f "next.config.mjs" ] && STACK="REACT"
[ -f "package.json" ] && grep -q '"react"' package.json && STACK="REACT"
[ -f "package.json" ] && grep -q '"express"\|"fastify"' package.json && STACK="NODEJS"

Stack-to-Folder Mapping

StackCategoryReferencesAssets
GObackendreferences/backend/go/assets/backend/go/
NODEJSbackendreferences/backend/nodejs/assets/backend/nodejs/
REACTfrontendreferences/frontend/react/assets/frontend/react/
REACT_NATIVEmobilereferences/mobile/react-native/assets/mobile/react-native/
SWIFTmobilereferences/mobile/swift/assets/mobile/swift/

Task Classification & Load Levels

python
# Task keywords for intelligent routing
TASK_KEYWORDS = {
    "VERIFICATION": ["done", "complete", "works", "verify", "finished", "check"],
    "DEBUGGING": ["bug", "fix", "error", "broken", "issue", "failing", "crash"],
    "TESTING": ["test", "mock", "coverage", "spec", "unit", "integration"],
    "DATABASE": ["database", "query", "GORM", "SQL", "migration", "model", "schema"],
    "API": ["API", "endpoint", "handler", "HTTP", "route", "REST", "request"],
    "DEPLOYMENT": ["deploy", "release", "production", "kubernetes", "docker"],
    "IMPLEMENTATION": ["implement", "create", "add", "build", "feature", "new"]
}

# Load level determines how many resources to load
LOAD_LEVELS = {
    "VERIFICATION": "MINIMAL",      # Just verification checklist
    "DEBUGGING": "DEBUGGING",       # Stack refs + debugging checklist
    "TESTING": "FOCUSED",           # Stack refs filtered by "test" keywords
    "DATABASE": "FOCUSED",          # Stack refs filtered by "database" keywords
    "API": "FOCUSED",               # Stack refs filtered by "api" keywords
    "DEPLOYMENT": "FOCUSED",        # Stack refs filtered by deployment keywords
    "IMPLEMENTATION": "STANDARD"    # All stack refs + patterns
}

STACK_FOLDERS = {
    "GO": ("backend", "go"),
    "NODEJS": ("backend", "nodejs"),
    "REACT": ("frontend", "react"),
    "REACT_NATIVE": ("mobile", "react-native"),
    "SWIFT": ("mobile", "swift")
}

def classify_task(user_request):
    """Classify task type based on keywords in request."""
    request_lower = user_request.lower()
    for task_type, keywords in TASK_KEYWORDS.items():
        if any(kw.lower() in request_lower for kw in keywords):
            return task_type
    return "IMPLEMENTATION"

def route_resources(user_request, stack):
    """Route to appropriate resources based on task type and stack."""
    category, folder = STACK_FOLDERS[stack]
    task_type = classify_task(user_request)
    load_level = LOAD_LEVELS[task_type]

    # MINIMAL: Verification only
    if load_level == "MINIMAL":
        return [f"assets/{category}/{folder}/checklists/verification_checklist.md"]

    # DEBUGGING: Stack refs + debugging checklist
    if load_level == "DEBUGGING":
        return [
            f"assets/{category}/{folder}/checklists/debugging_checklist.md",
            f"references/{category}/{folder}/*testing*.md"
        ]

    # FOCUSED: Filter refs by task keywords (database, api, test, deploy)
    if load_level == "FOCUSED":
        keywords = TASK_KEYWORDS.get(task_type, [])
        return [
            f"references/{category}/{folder}/*_standards.md",  # Always load standards
            f"references/{category}/{folder}/*{keywords[0].lower()}*.md"  # Filter by domain
        ]

    # STANDARD: All stack refs + patterns (default for IMPLEMENTATION)
    return [
        f"references/{category}/{folder}/*.md",
        f"assets/{category}/{folder}/checklists/code_quality_checklist.md",
        f"assets/{category}/{folder}/patterns/*.*"
    ]

Phase Detection Flow

code
TASK CONTEXT
    │
    ├─► STEP 0: Detect Stack (from marker files)
    │   └─► Load: references/{category}/{stack}/*.md
    │
    ├─► PHASE 1: Implementation
    │   └─► Load: *standards*.md, patterns/*.*
    │
    ├─► PHASE 2: Debugging
    │   └─► Load: debugging_checklist.md, *testing*.md
    │
    └─► PHASE 3: Verification (MANDATORY)
        └─► Load: verification_checklist.md
        └─► Run: stack-specific test commands

Stack Resources Pattern

All stacks follow the same structure:

Resource TypePath PatternLoad Level
Standardsreferences/{category}/{stack}/*_standards.mdALWAYS
Domain/Architecturereferences/{category}/{stack}/*.mdCONDITIONAL
Code Quality Checkassets/{category}/{stack}/checklists/code_quality_checklist.mdALWAYS
Debugging Checkassets/{category}/{stack}/checklists/debugging_checklist.mdDEBUGGING
Verification Checkassets/{category}/{stack}/checklists/verification_checklist.mdVERIFICATION
Code Patternsassets/{category}/{stack}/patterns/*.*CONDITIONAL

3. 🛠️ HOW IT WORKS

Development Lifecycle

code
Implementation → Debugging (if issues) → Verification (MANDATORY)

Phase 1: Implementation (Stack-Specific)

Common Stack Patterns:

StackKey PatternsNaming
GoDomain layers, DI, generics, table-driven testssnake_case files, PascalCase exports
Node.jsExpress middleware, async/await, service patternscamelCase everywhere
ReactHooks, component composition, data fetchingkebab-case files, PascalCase classes
React NativeHooks extraction, responsive scaling, navigationkebab-case files, PascalCase classes
SwiftMVVM, SwiftUI views, async/await, CombinePascalCase types, camelCase members

Code Quality Gate (Before claiming implementation complete):

  1. Detect stack via marker files
  2. Load assets/{category}/{stack}/checklists/code_quality_checklist.md
  3. Validate P0 items (MUST fix), P1 items (fix or document deferral)
  4. Gate Rule: If ANY P0 item fails, completion is BLOCKED

Phase 2: Debugging

Systematic Debugging (Universal):

  1. Root Cause Investigation - Read errors, reproduce, check git diff, trace data flow
  2. Pattern Analysis - Find working examples, compare against stack patterns
  3. Hypothesis Testing - Single hypothesis, one change at a time, if 3+ fixes failed → question approach
  4. Implementation - Document fix, implement, run verification

Stack-Specific Testing:

StackTest CommandCoverageLint
Gogo test ./...go test -covergolangci-lint run
Node.jsnpm testJest coverageESLint
Reactnpm testJest coverageESLint
React Nativenpm testJest coverageESLint
Swiftswift testXcode coverageSwiftLint

Phase 3: Verification (MANDATORY)

The Gate Function - BEFORE claiming any status:

  1. IDENTIFY: What command proves this claim?
  2. RUN: Execute verification command
  3. VERIFY: All tests pass? Linting clean?
  4. RECORD: Note what you verified
  5. ONLY THEN: Make the claim

Stack-Specific Verification:

StackTest CommandLint CommandBuild Command
GOgo test ./...golangci-lint rungo build ./...
NODEJSnpm testnpx eslint .npm run build
REACTnpm testnpx eslint .npm run build
REACT_NATIVEnpm testnpx eslint .npx expo export
SWIFTswift testswiftlintswift build

4. 📋 RULES

Universal Rules (All Stacks)

✅ ALWAYS

  • Validate all inputs at function boundaries
  • Handle errors with meaningful messages
  • Add tests for new functionality
  • Run verification before claiming complete

❌ NEVER

  • Skip input validation
  • Catch and swallow errors silently
  • Change multiple things simultaneously when debugging
  • Claim "works" without running tests

⚠️ ESCALATE IF

  • Bug only occurs in production
  • Root cause in third-party dependency
  • Cannot reproduce consistently

Go-Specific

✅ ALWAYS❌ NEVER
Use context.Context as first paramIgnore errors (use _ only when intentional)
Return errors as last return valueUse panic for normal error handling
Use defer for cleanupShare memory without synchronization
Use table-driven testsUse global mutable state

Swift-Specific

✅ ALWAYS❌ NEVER
Use guard let or if let for optionalsForce unwrap (!) without proven safety
Use weak self in closuresBlock main thread with sync operations
Use @MainActor for UI updatesUse try! without handling errors

React / Next.js Specific

✅ ALWAYS❌ NEVER
Use hooks at top level of componentsMutate state directly
Include all deps in useEffect arraysUse any type without justification
Handle loading and error statesSkip key prop in lists

React Native / Expo Specific

✅ ALWAYS❌ NEVER
Use FlatList for long listsUse inline styles for repeated components
Handle platform-specific with Platform.selectSkip testing on physical devices
Test on both iOS and AndroidUse synchronous storage for large data

Node.js Specific

✅ ALWAYS❌ NEVER
Use async/await over callbacksBlock event loop with sync operations
Validate all API inputsStore secrets in code
Use environment variables for configTrust client data without validation

Debugging Rules

✅ ALWAYS❌ NEVER
Read complete error messagesSkip error messages
Test one change at a timeChange multiple things simultaneously
Trace backward to root causeFix symptoms without understanding cause
Document root causeProceed with 4th fix without questioning approach

Verification Rules

✅ ALWAYS❌ NEVER
Run tests before claiming completeClaim "works" without running tests
Note what you verifiedSay "should work" - prove it
Check for errors in outputSkip verification for "small changes"

5. 🏆 SUCCESS CRITERIA

Phase Completion Checklists

PhaseChecklist PathKey Criteria
Implementationassets/{cat}/{stack}/checklists/code_quality_checklist.mdStack conventions, P0 items pass
Debuggingassets/{cat}/{stack}/checklists/debugging_checklist.mdRoot cause documented, fix at source
Verificationassets/{cat}/{stack}/checklists/verification_checklist.mdTests pass, verified in environment

Stack-Specific Success Criteria

StackTest CoverageLint CleanBuild SuccessEnvironment Verified
GO80%+RequiredRequiredgo test -race
NODEJS80%+RequiredRequiredAPI Tests
REACT70%+RequiredRequiredBrowser (multi-VP)
REACT_NATIVE70%+RequiredRequiredDevice/Simulator
SWIFT70%+RequiredRequiredDevice/Simulator

Performance Targets

Web: FCP < 1.8s, LCP < 2.5s, TTI < 3.8s, CLS < 0.1, FPS 60fps, Errors 0 Mobile: App Launch < 2s, Memory (no leaks), FPS 60fps


6. 🔌 INTEGRATION POINTS

Framework Integration

  • Gate 2: Skill routing via skill_advisor.py
  • Memory: Context preserved via Spec Kit Memory MCP

Knowledge Base Structure

code
workflows-code--full-stack/
├── references/{category}/{stack}/*.md    # Reference docs per stack
├── assets/{category}/{stack}/checklists/ # Code quality, debugging, verification
├── assets/{category}/{stack}/patterns/   # Code templates
└── SKILL.md

External Tools

ToolPurpose
workflows-chrome-devtoolsBrowser debugging (CLI-first via bdg)
mcp-narsilSecurity scanning (OWASP, CWE)

7. 📚 EXTERNAL RESOURCES

StackDocumentation
Gogo.dev/doc
Node.jsnodejs.org/docs
Reactreact.dev
Next.jsnextjs.org/docs
React Nativereactnative.dev
Expodocs.expo.dev
Swiftswift.org/documentation

8. 🔗 RELATED SKILLS

SkillUse For
workflows-documentationDocumentation, skill creation
workflows-gitGit workflows, commit hygiene
system-spec-kitSpec folder management, memory
mcp-narsilCode intelligence, security scanning
workflows-chrome-devtoolsBrowser debugging, screenshots

Navigation Guide

Implementation: Detect stack → Load *_standards.md → Load code_quality_checklist.md Debugging: Load debugging_checklist.md → Load *testing*.md → Follow 4-step debug Verification: Load verification_checklist.md → Run test/lint/build → Claim done


9. 📍 WHERE AM I?

PhaseYou're here if...Exit criteria
1: ImplementationWriting/modifying codeCode builds, P0 items pass
2: DebuggingCode has bugs/failing testsAll tests passing
3: VerificationTests pass, final validationVerified, ready to ship

Transitions: 1→2 (bugs found) | 2→1 (missing code) | 2→3 (fixed) | 3→1/2 (issues found) Key principle: Always end with Phase 3 before claiming completion.


10. 🏎️ QUICK REFERENCE

Universal Workflow

  1. Detect Stack → Check marker files (go.mod, Package.swift, app.json, package.json)
  2. Load Resourcesreferences/{category}/{stack}/ + assets/{category}/{stack}/
  3. Execute → Follow phase-specific patterns
  4. Verify → Use verification checklist before claiming completion

Stack Commands Quick Reference

StackTestLintBuild
GOgo test ./...golangci-lint rungo build ./...
NODEJSnpm testnpx eslint .npm run build
REACTnpm testnpx eslint .npm run build
REACT_NATIVEnpm testnpx eslint .npx expo export
SWIFTswift testswiftlintswift build

Resource Paths

StackStandardsChecklists
GOreferences/backend/go/go_standards.mdassets/backend/go/checklists/
NODEJSreferences/backend/nodejs/nodejs_standards.mdassets/backend/nodejs/checklists/
REACTreferences/frontend/react/react_nextjs_standards.mdassets/frontend/react/checklists/
REACT_NATIVEreferences/mobile/react-native/react-native-standards.mdassets/mobile/react-native/checklists/
SWIFTreferences/mobile/swift/swift_standards.mdassets/mobile/swift/checklists/

Success Checklist (Quick)

code
[ ] Stack detected via marker file
[ ] Standards loaded for stack
[ ] Code quality P0 items passing
[ ] Stack test command run and passing
[ ] Lint command passing
[ ] Build succeeds
[ ] Documented what was verified

11. 📁 DIRECTORY STRUCTURE

code
workflows-code--full-stack/
├── SKILL.md
├── references/
│   ├── backend/go/           # go_standards.md, api_design.md, database_patterns.md, ...
│   ├── backend/nodejs/       # nodejs_standards.md, express_patterns.md, ...
│   ├── frontend/react/       # react_nextjs_standards.md, state_management.md, ...
│   └── mobile/
│       ├── react-native/     # react-native-standards.md, navigation-patterns.md, ...
│       └── swift/            # swift_standards.md, swiftui_patterns.md, ...
└── assets/
    ├── backend/go/           # checklists/ + patterns/
    ├── backend/nodejs/       # checklists/ + patterns/
    ├── frontend/react/       # checklists/ + patterns/
    └── mobile/
        ├── react-native/     # checklists/ + patterns/
        └── swift/            # checklists/ + patterns/

Adding New Stack

  1. Create references/{category}/{stack}/ with {stack}_standards.md
  2. Create assets/{category}/{stack}/checklists/ (code_quality, debugging, verification)
  3. Create assets/{category}/{stack}/patterns/
  4. Add detection logic to Section 2
  5. Add to STACK_FOLDERS mapping
  6. Add rules to Section 4