alexei-led/spec-core
dist/codex/plugins/spec/skills/spec-core/SKILL.md
Spec-driven development orientation and quick reference. Use when starting spec-driven development, unsure which sub-skill to use, or wanting a pipeline overview and current project state. NOT for executing tasks (spec-work) or marking them done (spec-done).
$ install --global
skillsauthnpx skillsauth add alexei-led/claude-code-config spec-coreInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 14, 2026, 3:50 AM139.1s1 file scanned
SKILL.md
- description:
- Spec-driven development orientation and quick reference. Use when starting
- name:
- spec-core
Spec-driven development
Show the user this quick reference, check .spec/ state, and direct them to the right sub-skill.
Pipeline
spec-init → spec-interview → spec-plan → spec-work → spec-done (loop until epic complete)
spec-status reads state at any point.
Sub-skills
spec-init— initialize.spec/, or add requirements from an existing docspec-interview— deep PRD-quality requirement capture via Q&Aspec-plan— create an EPIC + vertical-slice TASKs from a requirement or ideaspec-new— one-off task or requirement from a templatespec-work— implement the next ready task (one per session, user approval at every step)spec-done— mark a task complete with evidence; optionally discover or verify firstspec-status— overview, single-task detail, filtered list, or quality audit
specctl commands (bundled CLI)
CLI at scripts/specctl.
scripts/specctl init— create the.spec/structurescripts/specctl ready [--epic EPIC-x]— list unblocked tasks, priority orderscripts/specctl show <REQ-x | EPIC-x | TASK-x>— render an artifactscripts/specctl start TASK-x— mark in-progress, record base commitscripts/specctl done TASK-x --summary ... --files ... --commits ... --tests ...— close with evidencescripts/specctl validate— check for orphans, cycles, missing fieldsscripts/specctl status— global counts and progressscripts/specctl dep add A B [--type X]— add dependency with cycle checkscripts/specctl dep rm A B— remove dependencyscripts/specctl epic close X— mark an epic donescripts/specctl session show | resume | step <name>— session state and recoveryscripts/specctl hook install— install git pre-commit validation
File structure
.spec/reqs/REQ-*.md— requirements (WHAT / WHY).spec/epics/EPIC-*.md— epics grouping related tasks.spec/tasks/TASK-*.md— vertical-slice tasks with dependencies.spec/memory/— pitfalls, conventions, decisions discovered during work.spec/SESSION.yaml— current session (task, step, base commit).spec/PROGRESS.md— activity log
Principles
- REQ = WHAT / WHY (business requirements, success criteria)
- TASK = vertical slice with acceptance criteria
- Blockers and open questions stay in artifact frontmatter or body
- One task per session — complete before starting the next
- Quality gates: build, test, lint — every time
- User approves every edit — no hidden automation
Where to start
scripts/specctl status 2>/dev/null || echo "NO_SPEC"
- No
.spec/yet → use thespec-initskill to initialize the project - Have an idea → use the
spec-interviewskill to capture requirements - Have REQ files → use the
spec-planskill to create tasks - Have TASK files → use the
spec-workskill to implement the next task
Related Skills
alexei-led/spec-flow
tools
VerifiedTrustedCommunity
Use when planning, executing, checkpointing, finishing, or inspecting lightweight spec-driven work. Runs one task at a time using `.spec/` markdown files and the bundled `specctl` helper. NOT for broad product discovery beyond a short requirement interview. NOT for generic implementation planning that does not read or write `.spec/` files.
35SKILL.mdUpdated Jul 18, 2026
alexei-led/writing-web
development
VerifiedTrustedCommunity
Simple web development with HTML, CSS, JS, and HTMX. Use when working with .html, .css, or .htmx files, web templates, stylesheets, or vanilla JS scripts. NOT for React/Vue/Angular (use writing-typescript) or Node.js backends.
35SKILL.mdUpdated Jul 18, 2026
alexei-led/writing-typescript
tools
VerifiedTrustedCommunity
Idiomatic TypeScript development. Use when writing TypeScript code, Node.js services, React apps, or TypeScript design advice. Emphasizes strict typing, boundary validation, composition, fast feedback, behavior tests, and project-configured tooling. NOT for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates (use writing-web).
35SKILL.mdUpdated Jul 18, 2026
alexei-led/writing-shell
tools
VerifiedTrustedCommunity
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, CI `run:` shell bodies, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, Rust, TypeScript, Go, web code, or GitHub Actions workflow/job/permissions semantics; use operating-infra.
35SKILL.mdUpdated Jul 18, 2026