myspec
v2.0.1Specification-Driven Development framework for Codex. Provides skills for feature workflows, memory system, ideas pipeline, and project scaffolding.
By Jan Salwowski2 GitHub starsUpdated 2 weeks ago
Directory evidence
- Runtimes
- Codex and Claude Code
- Parsed components
- 46 skill or MCP entries
- Source updated
- Sep 4, 2026
- Manifest status
- Canonical path parsed
The directory validates manifest shape and source location. It does not execute the plugin or provide a security endorsement. Review the indexing methodology →
Install myspec for Codex and Claude Code
codex plugin marketplace add IchenDEV/agent-plugin-mkt
codex plugin marketplace upgrade agent-plugin-marketplace
codex plugin add myspec@agent-plugin-marketplacePaste and run these commands in a terminal with Codex. They add and refresh the PluginsMP catalog, then install this plugin.
The installer fetches third-party code from the source repository shown on this page. This directory validates manifest structure and source location, but does not perform a security audit; review the manifest, components, and source before installing.
Get the source manually
git clone https://github.com/jansalwowski/myspecClone the source repository, then follow its setup instructions to add the plugin to a compatible client. The repository root is the plugin root.
Plugin files
├── .codex-plugin/plugin.json├── .claude-plugin/plugin.json├── skills/bootstrap/SKILL.md├── skills/brainstorm/SKILL.md├── skills/code-review/SKILL.md├── skills/cross-spec-validation/SKILL.md├── skills/docs-sanitize/SKILL.md├── skills/doctor/SKILL.md├── skills/feature-complete/SKILL.md├── skills/feature-decompose/SKILL.md├── skills/feature-discover/SKILL.md├── skills/feature-implement/SKILL.md├── skills/feature-implement-review/SKILL.md├── skills/feature-mockup/SKILL.md├── skills/feature-mockup-review/SKILL.md├── skills/feature-plan/SKILL.md├── skills/feature-scenario/SKILL.md├── skills/feature-seed-data/SKILL.md├── skills/feature-spec/SKILL.md├── skills/feature-spec-cleanup/SKILL.md├── skills/feature-spec-review/SKILL.md├── skills/feature-spec-sync/SKILL.md├── skills/feature-status-audit/SKILL.md├── skills/feature-tech-spec/SKILL.md├── skills/feature-tech-spec-review/SKILL.md├── skills/feature-update/SKILL.md├── skills/feature-verify/SKILL.md├── skills/features-status-audit/SKILL.md├── skills/idea-intake/SKILL.md├── skills/idea-process/SKILL.md├── skills/init/SKILL.md├── skills/memorify/SKILL.md├── skills/memorize/SKILL.md├── skills/memory-create/SKILL.md├── skills/memory-lookup/SKILL.md├── skills/memory-optimize/SKILL.md├── skills/memory-preflight/SKILL.md├── skills/memory-sanitize/SKILL.md├── skills/root-cause-debugging/SKILL.md├── skills/session-clean/SKILL.md├── skills/session-complete/SKILL.md├── skills/session-start/SKILL.md├── skills/setup/SKILL.md├── skills/skill-verify/SKILL.md├── skills/update/SKILL.md├── skills/upstream-sync/SKILL.md├── skills/worktree-clean/SKILL.md└── skills/worktree-cleanup/SKILL.md
Included Skills46
Use when a session starts and the agent needs project orientation before answering or changing anything. Keywords: orient, where am I, what is this project, what's the state. Do NOT use mid-task or twice in one session.
Use when the user wants to explore ideas, generate options, name something, frame a fuzzy problem, or pressure-test a direction with devil's-advocate thinking. Infers its mode rather than interviewing. Do NOT use to plan an approved spec (feature-plan).
Use when implemented code needs review for bugs, quality, and standards conformance — after a feature is built, before a PR. Keywords: review changes, review diff, pre-merge review, find bugs. Do NOT use for spec.md (feature-spec-review), tech-spec.md (feature-tech-spec-review), or SKILL.md (skill-verify).
Use when a new or changed spec may contradict or supersede an existing one. Keywords: contradiction, spec conflict, supersede, breaking change, API contract, schema conflict. Do NOT use for single-spec review (feature-spec-review).
Retired in myspec 2.0, not replaced.
Use when the project's myspec setup needs a health check — CLAUDE.md, rules, skills, agents, hooks, ${aiDir} docs, memory tree, feature manifest. An optional surface (A-F) checks one. Keywords: healthcheck, setup broken, context bloat, rules drift. Do NOT use for project code (code-review), one skill (skill-verify), or one feature (feature-verify).
Use when implementation is done and every plan task is checked off or explicitly deferred. Keywords: feature done, finish feature, archive plan, merge branch, finish PR. Do NOT use mid-implementation.
Use when one feature has grown to cover several distinct capabilities and should be split into sub-features. Keywords: decompose, split feature, break down, modularize. Do NOT use for new or single-capability features.
Use when code exists but no spec does — undocumented features, reverse engineering. Produces discovery.md and optionally spec.md plus tech-spec.md from code exploration. Do NOT use where a spec already exists.
Use when an approved implementation-plan.md is ready to execute — dispatches one implementer subagent per task, parallelizing where the plan allows. Keywords: execute plan, run plan, start implementation. Do NOT use to create plans (feature-plan), or for a plan with no Execution Order table.
Use when an implementation is done or paused and needs an independent check that the code fulfills the spec and plan. Keywords: conformance check, traceability, scope drift, acceptance verification. Produces conformance-report.md; never edits code.
Use when a feature needs spec-validation UI mockups under ${aiDir}/features/{feature}/mockups/ before tech design. Keywords: mockup, prototype screen, wireframe, visualize spec. Do NOT use for production UI or aesthetic landing pages (frontend-design), or to critique mockups (feature-mockup-review).
Use when mockups in ${aiDir}/features/{feature}/mockups/ need critique — UX issues, scope creep, dead buttons, missing states, accessibility, hard-guard violations. Keywords: review mockup, mockup audit, loose ends. Do NOT use to build mockups (feature-mockup).
Use when a feature has an approved spec.md and tech-spec.md and needs an execution-ready plan with parallel task groups and milestone checkpoints. Do NOT use without an approved tech-spec, or for a plan already in progress.
Use when a feature needs Gherkin test scenarios. Generates scenarios.md with happy paths, edge cases and error states. Requires spec.md. Do NOT use for unit tests.
Use when a feature needs test seed data. Generates seed.json matching the data models and scenarios. Requires scenarios.md. Do NOT use for production data.
Use when starting a new feature. Creates spec.md and dependencies.md in ${aiDir}/features/. Keywords: new feature, requirements, user stories, acceptance criteria. Do NOT use for tech design (feature-tech-spec).
Use when a spec.md has leaked implementation detail — SQL, code blocks, ORM patterns, indexes, file paths — that belongs in tech-spec.md. Keywords: spec cleanup, move code out of spec, spec hygiene. Do NOT use to create specs.
Use when a spec.md needs review before tech design — completeness, consistency, testability, scope, dependency hygiene. Keywords: review spec, critique requirements, validate spec. Do NOT use for tech-spec.md (feature-tech-spec-review).
Use when docs have drifted from code — after refactoring, or before completing a feature. Handles spec.md and tech-spec.md drift, stale paths, version mismatches.
Use when the whole feature manifest needs auditing against on-disk docs. Keywords: manifest drift, index.yaml audit, orphan features, docs ahead of status, feature inventory. Do NOT use for one feature's deep audit (feature-verify).
Use when an approved feature needs its implementation designed. Creates tech-spec.md with architecture and implementation steps. Requires an approved spec.md.
Use when a tech-spec.md needs review for implementability, spec alignment, and pattern conformance before planning. Keywords: validate technical design, critique tech-spec. Do NOT use for spec.md (feature-spec-review) or code (code-review).
Use when an already-implemented feature needs changed requirements — edits spec.md and tech-spec.md in place instead of recreating them. Keywords: modify feature, change feature, extend feature, spec_version bump. Do NOT use for new features (feature-spec).
Use when one feature's health needs auditing — spec, tech-spec, plan, implementation, sub-features, memories, manifest sync. Keywords: feature health, verify feature, feature drift. Do NOT use to audit every feature (feature-status-audit).
Retired in myspec 2.0 — renamed to feature-status-audit.
Use when a new idea file lands in ${aiDir}/ideas/ and needs triaging into the priority queue — analysis, priority, dependencies, PRIORITY-LISTING.md. Keywords: new idea, idea queue, idea triage, queue idea. Do NOT use to convert an idea to a spec (idea-process).
Use when an approved idea should graduate into feature documentation in ${aiDir}/features/. Requires the idea listed in PRIORITY-LISTING.md with dependencies satisfied. Keywords: promote idea, graduate idea, convert idea. Do NOT use for triage (idea-intake).
Use when setting up myspec in a project for the first time. Keywords: initialize, install myspec, new project setup, scaffold AI documentation. Do NOT use on an existing setup (update).
Use when the user asks to scan the conversation for what is worth keeping — 'memorify this', 'anything to remember?', 'save what we learned'. Yields zero, one, or many memories. Do NOT use when the content is already named (memorize) or when wrapping a session (session-complete).
Use when the user names the exact thing to remember inline, e.g. '/memorize the prod DB is in us-east-1'. Captures one memory per call. Do NOT use to sweep the conversation for candidates (memorify) or to edit an existing memory.
Use when an approved insight needs writing to memory — the shared path called by session-complete, memorize and memorify. Handles procedural, semantic and episodic types with a consolidation check. Do NOT use for user-facing capture (memorize, memorify) or without approval.
Use when debugging, hitting an error, or researching a past decision. Searches procedural, semantic and episodic memories in ${aiDir}/memory/. Do NOT use for first-time implementation with no prior context.
Use when the project memory tree at ${aiDir}/memory/ needs grooming — dead anchors, memories that never fire, colliding triggers, expired episodes, index drift. Keywords: groom memories, memory audit, stale anchor, re-anchor. Do NOT use for the user-level store (memory-sanitize).
Use when code work is about to start and relevant past memories should surface first. Keywords: preflight, memory check, pre-work scan, load memory. Do NOT use for research-only tasks, doc updates, or answering questions.
Use when the user-level auto-memory store at ~/.claude-personal/projects/ needs grooming — stale entries, bloated bodies, duplicates, contradictions. Keywords: prune memories, compress memory, memory triage. Do NOT use for the project store (memory-optimize).
Use when a bug, test failure, build error, or unexpected behavior needs its root cause found before any fix. Keywords: why is this failing, diagnose, hypothesis test. Do NOT use for feature planning, code review (code-review), or performance tuning.
Use when dangling session files need sweeping — live logs in .claude/state/sessions/ belonging to nobody still working, plus orphaned untracked files in ${aiDir}/memory/sessions/archive/. Keywords: session cleanup, session sweep, orphaned archives. Do NOT use on your own session (session-complete).
Use when a tracked session is finished and ready to archive. Keywords: end session, wrap up, close session, archive session, extract memories. Archives your own session only. Do NOT use mid-implementation or on another agent's file (session-clean).
Use when starting a NON-CODE session (debugging without edits, discovery, doc-only work) — code sessions get their log from the mark-code-changed.sh hook on first edit. Keywords: begin session, start tracking. Do NOT use for code-editing work.
Use when a project-specific file should be generated from a guided wizard. Blueprints: backbone, claude-md, conventions, code-review, mockup, index-md, workflow, pre-flight, anti-patterns. Do NOT use for first-time init (init).
Use when an existing SKILL.md needs auditing for quality, compliance, and token efficiency — frontmatter validation, anti-pattern detection. Keywords: verify skill, check skill, skill lint. Do NOT use to create skills.
Use when an existing project's myspec framework files need refreshing after the plugin updated. Keywords: upgrade framework, sync framework files. Do NOT use for first-time setup (init).
Use when tracked upstream repos should be checked for changes worth porting into local skills. Surfaces a per-mapping diff and commit history for the pairs in upstream-sources.yml. Do NOT use for dependency bumps.
Use when stale git worktrees and the branches behind them need cleaning up. Keywords: prune worktrees, stale branches, git cleanup, squash-merged branch won't delete. Do NOT use to create branches or worktrees.
Retired in myspec 2.0 — renamed to worktree-clean.
Plugin manifests2
{
"name": "myspec",
"version": "2.0.1",
"description": "Specification-Driven Development framework for Codex. Provides skills for feature workflows, memory system, ideas pipeline, and project scaffolding.",
"author": {
"name": "Jan Salwowski",
"url": "https://github.com/jansalwowski"
},
"homepage": "https://github.com/jansalwowski/myspec",
"repository": "https://github.com/jansalwowski/myspec",
"keywords": [
"myspec",
"specification-driven-development",
"codex",
"skills",
"project-scaffolding"
],
"skills": "./skills/",
"hooks": "./hooks.json",
"interface": {
"displayName": "myspec",
"shortDescription": "Specification-driven development workflow for Codex",
"longDescription": "Use myspec in Codex to scaffold AI documentation, create feature specs and technical plans, maintain project memory, and run a structured spec-to-implementation workflow.",
"developerName": "Jan Salwowski",
"category": "Coding",
"capabilities": [
"Interactive",
"Read",
"Write"
],
"websiteURL": "https://github.com/jansalwowski/myspec",
"defaultPrompt": [
"Use myspec to initialize this repository for specification-driven development.",
"Use myspec to create a feature spec and technical plan for this change.",
"Use myspec to bootstrap project context before implementation."
],
"screenshots": [],
"brandColor": "#0F766E"
}
}{
"name": "myspec",
"description": "Specification-Driven Development framework. Provides skills for feature workflows (spec, tech-spec, review, decompose), memory system (preflight, create, lookup, sessions), ideas pipeline, and project scaffolding.",
"version": "2.0.1",
"author": {
"name": "Jan Salwowski"
},
"homepage": "https://github.com/jansalwowski/myspec",
"repository": "https://github.com/jansalwowski/myspec"
}For maintainers
If you maintain this plugin, link to this source-backed listing from your README so users can review its manifest and indexed components.
[myspec on Agent Plugins Marketplace](https://pluginsmp.com/plugins/myspec)