alexei-led/spec-core
dist/claude/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:44 AM151.0s1 file scanned
SKILL.md
- context:
- fork
- description:
- Spec-driven development orientation and quick reference. Use when starting
- model:
- sonnet
- name:
- spec-core
- user-invocable:
- true
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/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, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, TypeScript, Go, web code, or infrastructure operations.
33SKILL.mdUpdated Jun 5, 2026
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.
33SKILL.mdUpdated Jun 5, 2026
alexei-led/operating-infra
testing
VerifiedTrustedCommunity
Author, inspect, troubleshoot, and review infrastructure across IaC, Kubernetes, cloud resources, containers, CI/CD, and Linux hosts. Use when changing Terraform/OpenTofu, Kubernetes, Helm, Kustomize, Dockerfiles, GitHub Actions, AWS, GCP, Cloud Run, BigQuery, IAM, logs, instances, or service health. NOT for deploy/apply/rollback workflows (see deploying-infra). NOT for shell scripts or generic command pipelines (see writing-shell).
33SKILL.mdUpdated Jun 5, 2026
alexei-led/configuring-git-hygiene
development
VerifiedTrustedCommunity
Configure safe git workflow hygiene: pre-commit/pre-push hooks, Gitleaks secret scanning, .gitignore rules, local git config, and guardrails. Use when setting up git hooks, gitleaks/git leaks, staged pre-commit checks, pre-push validation, core.hooksPath, .gitignore, or git config best practices. NOT for creating commits (use committing-code), cleaning branches/worktrees (use cleanup-git), or creating worktrees (use using-git-worktrees).
33SKILL.mdUpdated Jun 5, 2026