alinaqi/claude-bootstrap/base-2

Trust tier 3
  • community
Source check pending

Checking that the SKILL.md file is still in the repository.

Universal coding patterns, constraints, TDD workflow, atomic todos

Install

npx vskill@latest install alinaqi/claude-bootstrap/base-2

Semi-extensibleMentions customization, but needs skill-specific knowledge. Read the extensible skills standard

SKILL.md

Base Skill - Universal Patterns

Core Principle

Complexity is the enemy. Every line of code is a liability. The goal is software simple enough that any engineer (or AI) can understand the entire system in one session.

Simplicity Rules

These limits apply to every file created or modified.

Function Level
  • Maximum 20 lines per function - if longer, decompose IMMEDIATELY
  • Maximum 3 parameters per function - if more, use an options object or decompose
  • Maximum 2 levels of nesting - flatten with early returns or extract functions
  • Single responsibility - each function does exactly one thing
  • Descriptive names over comments - if you need a comment to explain what, rename it
File Level
  • Maximum 200 lines per file - if longer, split by responsibility BEFORE continuing
  • Maximum 10 functions per file - keeps cognitive load manageable
  • One export focus per file - a file should have one primary purpose
Module Level
  • Maximum 3 levels of directory nesting - flat is better than nested
  • Clear boundaries - each module has a single public interface
  • No circular dependencies - ever
Enforcement Protocol

Before completing ANY file:

  1. Count total lines - if > 200, STOP and split
  2. Count functions - if > 10, STOP and split
  3. Check each function length - if any > 20 lines, STOP and decompose
  4. Check parameter counts - if any > 3, STOP and refactor

If limits are exceeded during development:

⚠️ FILE SIZE VIOLATION DETECTED
 
[filename] has [X] lines (limit: 200)
 
Splitting into:
- [filename-a].ts - [responsibility A]
- [filename-b].ts - [responsibility B]

Never defer refactoring. Fix violations immediately, not "later".

Architectural Patterns

Functional Core, Imperative Shell
  • Pure functions for business logic - no side effects, deterministic
  • Side effects only at boundaries - API calls, database, file system at edges
  • Data in, data out - functions transform data, they don't mutate state
Composition Over Inheritance
  • No inheritance deeper than 1 level - prefer interfaces/composition
  • Small, composable utilities - build complex from simple
  • Dependency injection - pass dependencies, don't import them directly
Error Handling
  • Fail fast, fail loud - errors surface immediately
  • No silent failures - every error is logged or thrown
  • Design APIs where misuse is impossible

Testing Philosophy

  • 100% coverage on business logic - the functional core
  • Integration tests for boundaries - API endpoints, database operations
  • No untested code merges - CI blocks without passing tests
  • Test behavior, not implementation - tests survive refactoring
  • Each test runs in isolation - no interdependence

Anti-Patterns (Never Do This)

  • ❌ Global state
  • ❌ Magic numbers/strings - use named constants
  • ❌ Deep nesting - flatten or extract
  • ❌ Long parameter lists - use objects
  • ❌ Comments explaining "what" - code should be self-documenting
  • ❌ Dead code - delete it, git remembers
  • ❌ Copy-paste duplication - extract to shared function
  • ❌ God objects/files - split by responsibility
  • ❌ Circular dependencies
  • ❌ Premature optimization
  • ❌ Large PRs - small, focused changes only
  • ❌ Mixing refactoring with features - separate commits

Documentation Structure

Every project must have clear separation between code docs and project specs:

project/
├── docs/                      # Code documentation
│   ├── architecture.md        # System design decisions
│   ├── api.md                 # API reference (if applicable)
│   └── setup.md               # Development setup guide
├── _project_specs/            # Project specifications
│   ├── overview.md            # Project vision and goals
│   ├── features/              # Feature specifications
│   │   ├── feature-a.md
│   │   └── feature-b.md
│   ├── todos/                 # Atomic todos tracking
│   │   ├── active.md          # Current sprint/focus
│   │   ├── backlog.md         # Future work
│   │   └── completed.md       # Done items (for reference)
│   ├── session/               # Session state (see session-management.md)
│   │   ├── current-state.md   # Live session state
│   │   ├── decisions.md       # Key decisions log
│   │   ├── code-landmarks.md  # Important code locations
│   │   └── archive/           # Past session summaries
│   └── prompts/               # LLM prompt specifications (if AI-first)
└── CLAUDE.md                  # Claude instructions (references skills)
What Goes Where
LocationContent
docs/Technical documentation, API refs, setup guides
_project_specs/Business logic, features, requirements, todos
_project_specs/session/Session state, decisions, context for resumability
CLAUDE.mdClaude-specific instructions and skill references

Atomic Todos

All work is tracked as atomic todos with validation and test criteria.

Todo Format (Required)
markdown
## [TODO-001] Short descriptive title
 
**Status:** pending | in-progress | blocked | done
**Priority:** high | medium | low
**Estimate:** XS | S | M | L | XL
 
### Description
One paragraph describing what needs to be done.
 
### Acceptance Criteria
-[ ] Criterion 1 - specific, measurable
-[ ] Criterion 2 - specific, measurable
 
### Validation
How to verify this is complete:
-Manual: [steps to manually test]
-Automated: [test file/command that validates this]
 
### Test Cases
| Input | Expected Output | Notes |
|-------|-----------------|-------|
| ... | ... | ... |
 
### Dependencies
-Depends on: [TODO-xxx] (if any)
-Blocks: [TODO-yyy] (if any)
 
### TDD Execution Log
| Phase | Command | Result | Timestamp |
|-------|---------|--------|-----------|
| RED | `[test command]` | - | - |
| GREEN | `[test command]` | - | - |
| VALIDATE | `[lint && typecheck && test --coverage]` | - | - |
| COMPLETE | Moved to completed.md | - | - |
Todo Rules
  1. Atomic - Each todo is a single, completable unit of work
  2. Testable - Every todo has validation criteria and test cases
  3. Sized - If larger than "M", break it down further
  4. Independent - Minimize dependencies between todos
  5. Tracked - Move between active.md → completed.md when done
Todo Execution Workflow (TDD - Mandatory)

Every todo MUST follow this exact workflow. No exceptions.

┌─────────────────────────────────────────────────────────────┐
│  1. RED: Write Tests First                                  │
│     └─ Create test file(s) based on Test Cases table        │
│     └─ Tests should cover all acceptance criteria           │
│     └─ Run tests → ALL MUST FAIL (proves tests are valid)   │
├─────────────────────────────────────────────────────────────┤
│  2. GREEN: Implement the Feature                            │
│     └─ Write minimum code to make tests pass                │
│     └─ Follow simplicity rules (20 lines/function, etc.)    │
│     └─ Run tests → ALL MUST PASS                            │
├─────────────────────────────────────────────────────────────┤
│  3. VALIDATE: Quality Gates                                 │
│     └─ Run linter (auto-fix if possible)                    │
│     └─ Run type checker (tsc/mypy/pyright)                  │
│     └─ Run full test suite with coverage                    │
│     └─ Verify coverage threshold (≥80%)                     │
├─────────────────────────────────────────────────────────────┤
│  4. PROVE + COMPLETE: Show evidence, then mark done         │
│     └─ Only after ALL validations pass                      │
│     └─ SHOW PROOF — paste the real test/lint/type output    │
│        (pass/fail counts), never just "tests pass"          │
│     └─ UI change? attach a screenshot / visual-diff         │
│     └─ Web user-facing flow? record a demo-video walkthrough │
│     └─ Security-critical change? run a security-audit pass   │
│     └─ Generated content? show the actual artifact          │
│     └─ Move todo to completed.md + checkpoint session state │
└─────────────────────────────────────────────────────────────┘
Done = proven, not claimed. A todo is only complete when the evidence is in
your response: real command output, a screenshot for any UI change, a
demo-video walkthrough for any user-facing web flow, the actual artifact for
any generated content. No proof → not done. (See the "Definition of Done —
NON-NEGOTIABLE" section in CLAUDE.md.)
Execution Commands by Stack

Node.js/TypeScript:

bash
# 1. RED - Run tests (expect failures)
npm test -- --grep "todo-description"
 
# 2. GREEN - Run tests (expect pass)
npm test -- --grep "todo-description"
 
# 3. VALIDATE - Full quality check
npm run lint && npm run typecheck && npm test -- --coverage

Python:

bash
# 1. RED - Run tests (expect failures)
pytest -k "todo_description" -v
 
# 2. GREEN - Run tests (expect pass)
pytest -k "todo_description" -v
 
# 3. VALIDATE - Full quality check
ruff check . && mypy . && pytest --cov --cov-fail-under=80

React/Next.js:

bash
# 1. RED - Run tests (expect failures)
npm test -- --testPathPattern="ComponentName"
 
# 2. GREEN - Run tests (expect pass)
npm test -- --testPathPattern="ComponentName"
 
# 3. VALIDATE - Full quality check
npm run lint && npm run typecheck && npm test -- --coverage --watchAll=false
Blocking Conditions

NEVER mark a todo as complete if:

  • ❌ Tests were not written first (skipped RED phase)
  • ❌ Tests did not fail initially (invalid tests)
  • ❌ Any test is failing
  • ❌ Linter has errors (warnings may be acceptable)
  • ❌ Type checker has errors
  • ❌ Coverage dropped below threshold

If blocked by failures:

markdown
## [TODO-042] - BLOCKED
 
**Blocking Reason:** [Lint error in X / Test failure in Y / Coverage at 75%]
**Action Required:** [Specific fix needed]
Bug Fix Workflow (TDD - Mandatory)

When a user reports a bug, NEVER jump to fixing it directly.

┌─────────────────────────────────────────────────────────────┐
│  1. DIAGNOSE: Identify the Test Gap                         │
│     └─ Run existing tests - do any fail?                    │
│     └─ If tests pass but bug exists → tests are incomplete  │
│     └─ Document: "Test gap: [what was missed]"              │
├─────────────────────────────────────────────────────────────┤
│  2. RED: Write a Failing Test for the Bug                   │
│     └─ Create test that reproduces the exact bug            │
│     └─ Test should FAIL with current code                   │
│     └─ This proves the test catches the bug                 │
├─────────────────────────────────────────────────────────────┤
│  3. GREEN: Fix the Bug                                      │
│     └─ Write minimum code to make the test pass             │
│     └─ Run test → must PASS now                             │
├─────────────────────────────────────────────────────────────┤
│  4. VALIDATE: Full Quality Check                            │
│     └─ Run ALL tests (not just the new one)                 │
│     └─ Run linter and type checker                          │
│     └─ Verify no regression in coverage                     │
└─────────────────────────────────────────────────────────────┘
Bug Report Todo Format
markdown
## [BUG-001] Short description of the bug
 
**Status:** pending
**Priority:** high
**Reported:** [how user reported it / reproduction steps]
 
### Bug Description
What is happening vs. what should happen.
 
### Reproduction Steps
1.Step one
2.Step two
3.Observe: [incorrect behavior]
4.Expected: [correct behavior]
 
### Test Gap Analysis
-Existing test coverage: [list relevant test files]
-Gap identified: [what the tests missed]
-New test needed: [describe the test to add]
 
### Test Cases for Bug
| Input | Current (Bug) | Expected (Fixed) |
|-------|---------------|------------------|
| ... | ... | ... |

This is the start of the file. Read the full SKILL.md on GitHub.

Security

  • Security scanPassed, 95 of 100Pattern checks on the skill's files.
  • Model reviewPassed

See the full security report

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

See evaluation results

Source

Popularity

Repository stars
530
Repository forks
41
Repository npm downloads, 7 days
11,772
7-day trend score
53

Stars and forks are for the whole GitHub repository, not this skill alone. Downloads are for the repository's npm package. Refreshed 19 Mar 2026, 7 months ago.

Extension points

  • hookPre/post lifecycle hooks

Learn the extensible skills standard

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/alinaqi/claude-bootstrap/base-2/badge)](https://verified-skill.com/skills/alinaqi/claude-bootstrap/base-2)

Something wrong with this skill or its page? Tell us.