{"id":48446178,"url":"https://github.com/doodledood/manifest-dev","last_synced_at":"2026-04-06T18:01:38.952Z","repository":{"id":334979477,"uuid":"1143517499","full_name":"doodledood/manifest-dev","owner":"doodledood","description":"Stop iterating with the model after implementation. Define what you'd accept, run two commands, ship it.","archived":false,"fork":false,"pushed_at":"2026-04-03T13:03:31.000Z","size":2268,"stargazers_count":62,"open_issues_count":1,"forks_count":8,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-04-03T16:29:51.931Z","etag":null,"topics":["dev-workflow","development"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/doodledood.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-01-27T17:17:19.000Z","updated_at":"2026-04-03T13:03:38.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/doodledood/manifest-dev","commit_stats":null,"previous_names":["doodledood/manifest-dev"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/doodledood/manifest-dev","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/doodledood%2Fmanifest-dev","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/doodledood%2Fmanifest-dev/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/doodledood%2Fmanifest-dev/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/doodledood%2Fmanifest-dev/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/doodledood","download_url":"https://codeload.github.com/doodledood/manifest-dev/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/doodledood%2Fmanifest-dev/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31483380,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-06T17:22:55.647Z","status":"ssl_error","status_checked_at":"2026-04-06T17:22:54.741Z","response_time":112,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["dev-workflow","development"],"created_at":"2026-04-06T18:01:38.228Z","updated_at":"2026-04-06T18:01:38.946Z","avatar_url":"https://github.com/doodledood.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003cp align=\"center\"\u003e\n  \u003cpicture\u003e\n    \u003cimg src=\"assets/logo.png\" alt=\"Manifest Dev Logo\" width=\"120\" style=\"background: transparent;\"\u003e\n  \u003c/picture\u003e\n\u003c/p\u003e\n\n# Manifest-Driven Development\n\nStop iterating with the model after implementation. Define what you'd accept, run two commands, ship it.\n\n## Quick Start\n\n```bash\n# Claude Code (primary)\n/plugin marketplace add doodledood/manifest-dev\n/plugin install manifest-dev@manifest-dev-marketplace\n\n# Gemini CLI — everything (skills, agents, hooks)\ncurl -fsSL https://raw.githubusercontent.com/doodledood/manifest-dev/main/dist/gemini/install.sh | bash\n\n# OpenCode — everything (skills, agents, commands, plugin)\ncurl -fsSL https://raw.githubusercontent.com/doodledood/manifest-dev/main/dist/opencode/install.sh | bash\n\n# Codex CLI — everything (skills, TOML stubs, rules, config)\ncurl -fsSL https://raw.githubusercontent.com/doodledood/manifest-dev/main/dist/codex/install.sh | bash\n```\n\nThen use it:\n```bash\n# Define what to build, then execute\n/define \u003cwhat you want to build\u003e\n/do \u003cmanifest-path\u003e\n\n# Or go end-to-end autonomously:\n/auto \u003cwhat you want to build\u003e\n\n# Tend a PR through review:\n/tend-pr \u003cmanifest-path-or-pr-url\u003e\n\n# Optional: figure something out before acting\n/figure-out \u003ctopic or problem\u003e\n```\n\n`/define` interviews you and builds a manifest. `/do` executes it. `/auto` chains both — define autonomously, auto-approve, execute — in a single command. `/figure-out` is optional — a truth-convergent thinking partner for when figuring it out IS the goal, or before `/define` when the problem space is foggy.\n\nControl interview depth with `--interview minimal|autonomous|thorough` (default: thorough). Thorough asks everything. Minimal asks scope and high-impact items. Autonomous builds the manifest without asking, presents it for approval.\n\nIf you use zsh and want easy upgrade commands for the non-Claude distributions, add this to `~/.zshrc`:\n\n```zsh\nalias upgrade-manifest-dev-codex='curl -fsSL https://raw.githubusercontent.com/doodledood/manifest-dev/main/dist/codex/install.sh | bash'\nalias upgrade-manifest-dev-gemini='curl -fsSL https://raw.githubusercontent.com/doodledood/manifest-dev/main/dist/gemini/install.sh | bash'\nalias upgrade-manifest-dev-opencode='curl -fsSL https://raw.githubusercontent.com/doodledood/manifest-dev/main/dist/opencode/install.sh | bash'\nalias upgrade-manifest-dev-all='upgrade-manifest-dev-codex \u0026\u0026 upgrade-manifest-dev-gemini \u0026\u0026 upgrade-manifest-dev-opencode'\n```\n\nThen run `source ~/.zshrc` once. Future updates are just `upgrade-manifest-dev-codex`, `upgrade-manifest-dev-gemini`, `upgrade-manifest-dev-opencode`, or `upgrade-manifest-dev-all` for all three.\n\nUninstall uses the same entrypoints:\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/doodledood/manifest-dev/main/dist/gemini/install.sh | bash -s -- uninstall\ncurl -fsSL https://raw.githubusercontent.com/doodledood/manifest-dev/main/dist/opencode/install.sh | bash -s -- uninstall\ncurl -fsSL https://raw.githubusercontent.com/doodledood/manifest-dev/main/dist/codex/install.sh | bash -s -- uninstall\n```\n\n## The Mindset Shift\n\nInstead of telling the AI *how* to build something, you tell it what you'd accept.\n\nSay you need a login page. The old way: \"use React Hook Form, validate with Zod, show inline errors, disable the button while submitting.\" You've made every design decision upfront. The manifest way: \"invalid credentials show an error without clearing the password field\" and \"the form can't be submitted twice.\" You define the bar. The AI picks how to clear it. Automated verification confirms it did.\n\n## How It Works\n\n```mermaid\nflowchart TD\n    A[\"/define 'task'\"] --\u003e B[\"Interview\"]\n    B --\u003e C[\"Manifest file\"]\n    C --\u003e D[\"/do manifest.md\"]\n    D --\u003e E{\"For each Deliverable\"}\n    E --\u003e F[\"Satisfy ACs\"]\n    F --\u003e G[\"/verify\"]\n    G --\u003e|failures| H[\"Fix specific criterion\"]\n    H --\u003e G\n    G --\u003e|all pass| I[\"/done\"]\n    E --\u003e|risk detected| J[\"Consult trade-offs, adjust approach\"]\n    J --\u003e|ACs achievable| E\n    J --\u003e|stuck| K[\"/escalate\"]\n```\n\n`/define` interviews you to surface what you actually want. The stuff you'd reject in a PR but wouldn't think to specify upfront. Then `/do` implements toward those acceptance criteria, flexible on *how* but not on *what*.\n\nAfter each deliverable, `/verify` runs automated checks against every criterion. Failing checks say exactly what's wrong. The AI fixes what failed, only what failed, and the loop continues until everything passes or a blocker needs your attention.\n\n## What Changes\n\nYour first pass lands closer to done. Issues get caught by verification before you see them, and the fix loop handles cleanup without your involvement. Every acceptance criterion has been verified, and you know what was checked.\n\nWhile one manifest executes, you can define the next. The define phase is where your judgment matters; the do-verify-fix phase runs on its own. Writing acceptance criteria also forces you to stay engaged with your own code, which matters when heavy AI usage starts making your codebase feel foreign.\n\nResist the urge to intervene during `/do`. It won't nail everything on the first pass. That's expected. You invested in define; let the loop run.\n\n## Who This Is For\n\nIf you've burned out on the weekly \"game-changing AI coding tool\" cycle and just want something that works, this is for you. Experienced developers who care more about output quality than execution speed. People who've learned the hard way that AI-generated code needs guardrails more than cheerleading.\n\nWe build around how LLMs actually work, not how we wish they worked. That means investing upfront for better results, not optimizing for token cost or raw speed. If you're counting every cent per token or want the fastest possible output regardless of quality, this probably isn't your thing.\n\n---\n\nEverything below is reference. You don't need any of it to get started.\n\n---\n\n## Going Deeper\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003cstrong\u003eThe problem this solves\u003c/strong\u003e\u003c/summary\u003e\n\nYou plan a feature with the agent. It implements. The code looks reasonable. Then you review it and half the things aren't how you'd want them: wrong error handling patterns, conventions ignored, edge cases skipped. You send it back. It fixes some things, breaks others. Two or three rounds later you're satisfied, but you've spent more time reviewing and iterating than you saved.\n\nThe models can code. But we're throwing them into deep water without defining what \"done\" actually means. So the review-iterate loop eats the productivity gains.\n\nManifest-dev front-loads that review energy into `/define`. You spell out acceptance criteria and invariants before implementation starts. The do phase becomes mechanical, and the output lands closer to what you'd accept as a reviewer.\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003cstrong\u003eWhy this works (LLM first principles)\u003c/strong\u003e\u003c/summary\u003e\n\nLLMs are goal-oriented pattern matchers trained through reinforcement learning, not general reasoners. Clear acceptance criteria play to that strength. Rigid step-by-step plans fall apart because neither you nor the model can predict every detail upfront. Acceptance criteria focus on outcomes and leave implementation open.\n\nThere's also the drift problem. Long sessions cause the model to lose track of earlier instructions. The manifest compensates with external state and verification that catches drift before it ships. And since LLMs can't express genuine uncertainty (they'll confidently produce broken code), the verify-fix loop doesn't rely on the AI knowing it failed. It relies on automated checks catching failures.\n\nThese are design constraints, and the workflow treats them that way.\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003cstrong\u003eProcess Guidance and Approach\u003c/strong\u003e\u003c/summary\u003e\n\nThe manifest also supports Process Guidance and an initial Approach (architecture, execution order). These are exactly what they sound like: recommendations, not requirements. Hints to help the model make better decisions while it's still not AGI. The acceptance criteria are the contract; the guidance is optimization on top.\n\nThis is spec-driven development adapted for LLM execution. The manifest is a spec, but ephemeral: it drives one task, then the code is the source of truth. No spec maintenance. No drift.\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003cstrong\u003eExecution Modes\u003c/strong\u003e\u003c/summary\u003e\n\n`/do` supports `--mode efficient|balanced|thorough` to control verification intensity. Default is `thorough` (current behavior). Only pass `--mode` when you explicitly want to trade verification depth for quota savings.\n\n| Mode | What changes | When to use |\n|------|-------------|-------------|\n| **thorough** (default) | Full verification: all quality gates, all models inherit from session, unlimited parallelism and fix loops | Most tasks. Don't change unless you have a reason. |\n| **balanced** | Same models, but limits parallelism (max 4 concurrent verifiers) and fix loops (max 2) | Long-running tasks where you want to limit concurrent quota burn |\n| **efficient** | Uses haiku for criteria-checker, skips quality gate reviewers, sequential verification, max 1 fix loop | Quick iterations where speed matters more than verification depth |\n\nSet per-execution: `/do manifest.md --mode balanced`\nSet in manifest: add `mode: balanced` to the Intent \u0026 Context section.\n\n\u003c/details\u003e\n\n### Best Practice: Two Sessions, One Source of Truth\n\nRun `/define` and `/do` in separate sessions. The define session holds your intent; the do session holds implementation state. Keep both open.\n\nWhen `/do` finishes and something's off: a missed edge case, a reviewer comment, a bug you didn't anticipate. Don't patch it ad hoc. Go back to the define session. Encode the issue as an acceptance criterion in the manifest. Then re-run `/do` against the updated manifest in the do session.\n\nThis closes the loop properly. The fix gets the same verification treatment as everything else. The manifest stays the single source of truth for what \"done\" means. And if something regresses on a later pass, the criterion catches it.\n\n**Example**: You ship a login feature. A reviewer flags that error messages leak whether an email exists in the system.\n\n1. **Define session**: add `[AC-2.4] Authentication errors return a generic message regardless of whether the account exists` with a verification method\n2. **Do session**: run `/do` against the updated manifest\n3. `/verify` confirms the fix. It will also catch it if it regresses in a future change.\n\nEvery round trip through the manifest grows your verification surface. Bug fixes and late requirements become checked criteria. The manifest accumulates what \"done\" means for this task, and nothing falls through because you fixed it outside the loop.\n\nThe do session doesn't need to remember the define conversation. The manifest is external state. Run `/do` in a fresh session after `/define`, or at minimum `/compact` before starting.\n\n## What /define Produces\n\nThe interview classifies your task (Feature, Bug, Refactor, Prompting, Writing, Document, Blog, Research) and loads task-specific guidance. It probes for your latent criteria, the standards you hold but wouldn't think to spell out. A `manifest-verifier` agent validates the manifest for gaps before output.\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003cstrong\u003eExample manifest\u003c/strong\u003e\u003c/summary\u003e\n\n````markdown\n# Definition: User Authentication\n\n## 1. Intent \u0026 Context\n- **Goal:** Add password-based authentication to existing Express app\n  with JWT sessions. Users can register, log in, and log out.\n- **Mental Model:** Auth is a cross-cutting concern. Security invariants\n  apply globally; endpoint behavior is per-deliverable.\n\n## 2. Approach\n- **Architecture:** Middleware-based auth with JWT stored in httpOnly cookies\n- **Execution Order:** D1 (Model) → D2 (Endpoints) → D3 (Protected Routes)\n- **Risk Areas:**\n  - [R-1] Session fixation if tokens not rotated | Detect: security review\n  - [R-2] Timing attacks on password comparison | Detect: constant-time check\n- **Trade-offs:**\n  - [T-1] Simplicity vs Security → Prefer security (use bcrypt, not md5)\n\n## 3. Global Invariants (The Constitution)\n- [INV-G1] Passwords never stored in plaintext\n  ```yaml\n  verify:\n    method: bash\n    command: \"! grep -r 'password.*=' src/ | grep -v hash | grep -v test\"\n  ```\n- [INV-G2] All auth endpoints rate-limited (max 5 attempts/minute)\n  ```yaml\n  verify:\n    method: subagent\n    agent: general-purpose\n    model: inherit\n    prompt: \"Verify rate limiting exists on /login and /register endpoints\"\n  ```\n- [INV-G3] JWT secrets from environment, never hardcoded\n  ```yaml\n  verify:\n    method: bash\n    command: \"grep -r 'process.env.JWT' src/auth/\"\n  ```\n\n## 4. Process Guidance (Non-Verifiable)\n- [PG-1] Follow existing error handling patterns in the codebase\n- [PG-2] Use established logging conventions\n\n## 5. Known Assumptions\n- [ASM-1] Express.js already configured | Default: true | Impact if wrong: Add setup step\n- [ASM-2] PostgreSQL available | Default: true | Impact if wrong: Adjust migration\n\n## 6. Deliverables (The Work)\n\n### Deliverable 1: User Model \u0026 Migration\n**Acceptance Criteria:**\n- [AC-1.1] User model has id, email, hashedPassword, createdAt\n  ```yaml\n  verify:\n    method: codebase\n    pattern: \"User.*id.*email.*hashedPassword.*createdAt\"\n  ```\n- [AC-1.2] Email has unique constraint\n- [AC-1.3] Migration creates users table with indexes\n\n### Deliverable 2: Auth Endpoints\n**Acceptance Criteria:**\n- [AC-2.1] POST /register creates user, returns 201\n- [AC-2.2] POST /login validates credentials, returns JWT\n- [AC-2.3] Invalid credentials return 401, not 500\n  ```yaml\n  verify:\n    method: subagent\n    agent: code-bugs-reviewer\n    model: inherit\n    prompt: \"Check auth routes return 401 for auth failures, not 500\"\n  ```\n````\n\n\u003c/details\u003e\n\n## The Manifest Schema\n\n| Section | Purpose | ID Scheme |\n|---------|---------|-----------|\n| **Intent \u0026 Context** | Goal and mental model | -- |\n| **Approach** | Architecture, execution order, risks, trade-offs | `R-{N}`, `T-{N}` |\n| **Global Invariants** | Task-level rules (task fails if violated) | `INV-G{N}` |\n| **Process Guidance** | Non-verifiable recommendations for how to work | `PG-{N}` |\n| **Known Assumptions** | Low-impact items with defaults | `ASM-{N}` |\n| **Deliverables** | Ordered work items with acceptance criteria | `AC-{D}.{N}` |\n\nApproach section is added for complex tasks with dependencies, risks, or architectural decisions.\n\n## Verification Methods\n\nEvery criterion can have an automated verification method:\n\n| Method | When to Use | Example |\n|--------|-------------|---------|\n| `bash` | Commands with deterministic output | `npm run typecheck \u0026\u0026 npm run lint` |\n| `codebase` | Code pattern checks | Check file exists, pattern matches |\n| `subagent` | LLM-as-judge for subjective criteria | Code quality, security review |\n| `research` | External information lookup | API compatibility, version checks |\n| `manual` | Human verification required | UI review, deployment checks |\n\n```yaml\n# Bash verification\nverify:\n  method: bash\n  command: \"npm run test -- --coverage\"\n\n# Subagent verification with specialized reviewer\nverify:\n  method: subagent\n  agent: code-maintainability-reviewer\n  model: inherit\n  prompt: \"Review for DRY violations and coupling issues\"\n\n# Slow/expensive verification runs in a later phase\nverify:\n  method: bash\n  phase: 2\n  command: \"curl -s https://staging.example.com/health\"\n\n# Manual verification\nverify:\n  method: manual\n  instructions: \"Verify the login flow works in staging\"\n```\n\nCriteria support a `phase:` field (numeric, default 1). `/verify` runs phases in ascending order — faster checks first, slower/expensive ones only after earlier phases pass. This avoids wasting e2e deploy cycles when cheaper checks are still failing.\n\n## Multi-CLI Support\n\nThe Claude Code plugin is the source of truth. Per-CLI distributions under `dist/` provide native packages for other AI coding CLIs. Each has a one-command remote installer — run again to update, or pass `uninstall` to remove only manifest-dev-managed files.\n\n| CLI | Install | Skills | Agents | Hooks | Details |\n|-----|---------|--------|--------|-------|---------|\n| Claude Code | `/plugin install` | Full | Full | Full | Primary target |\n| Gemini CLI | `curl .../gemini/install.sh \\| bash` | Full | Full (converted) | Full (adapted) | [README](dist/gemini/README.md) |\n| OpenCode | `curl .../opencode/install.sh \\| bash` | Full | Full (converted) | Partial (adapted plugin) | [README](dist/opencode/README.md) |\n| Codex CLI | `curl .../codex/install.sh \\| bash` | Full | TOML stubs | Not available | [README](dist/codex/README.md) |\n\n**Keeping distributions in sync**: After changing plugin components, run `/sync-tools` in Claude Code to regenerate `dist/`. The sync skill reads reference files with per-CLI conversion rules and produces the full distribution for each target.\n\n## Available Plugins\n\n| Plugin | Description |\n|--------|-------------|\n| `manifest-dev` | Core manifest workflows: `/define`, `/do`, `/verify`, `/tend-pr`, review agents, workflow hooks. Mid-execution manifest amendments via `--amend` flag and UserPromptSubmit hook. |\n| `manifest-dev-tools` | Post-processing utilities for manifest workflows. `/adr` synthesizes Architecture Decision Records from session transcripts via multi-agent extraction pipeline. |\n\n## Plugin Architecture\n\n### Core Skills\n\n| Skill | Type | Description |\n|-------|------|-------------|\n| `/define` | User-invoked | Interviews you, classifies task type, probes for latent criteria, outputs manifest with verification methods |\n| `/do` | User-invoked | Executes against manifest. Follows execution order, watches for risks, logs progress for disaster recovery |\n| `/auto` | User-invoked | End-to-end autonomous: `/define --interview autonomous` → auto-approve → `/do`. Supports `--mode` and `--tend-pr` pass-through |\n| `/tend-pr` | User-invoked | Sets up PR for review and starts polling loop. Manifest-aware or babysit mode |\n| `/tend-pr-tick` | Internal | Single iteration of PR tending (classify, route, fix). Called by `/loop` via `/tend-pr` |\n| `/verify` | Internal | Spawns verifiers for all criteria, phased by iteration speed (fast checks first, e2e/deploy-dependent later). Routes to `criteria-checker` agents based on verification method |\n| `/done` | Internal | Prints hierarchical completion summary mirroring manifest structure |\n| `/escalate` | Internal | Structured escalation when blockers need human intervention. Requires evidence: 3+ attempts, failure reasons, hypothesis, resolution options |\n| `/figure-out` | User-invoked | Collaborative thinking partner for any topic. Investigates before claiming, surfaces gaps, resists premature synthesis |\n| `/learn-define-patterns` | User-invoked | Analyzes recent /define sessions, extracts user preference patterns, writes them to CLAUDE.md for future /define sessions |\n| `thinking-disciplines` | Internal | Core thinking disciplines for rigorous collaborative reasoning. Invoked by `/figure-out` and `/define` |\n| `/stop-thinking-disciplines` | User-invoked | Deactivates thinking disciplines mode |\n\n### Review Agents\n\nBuilt-in agents for quality verification via `subagent` method:\n\n| Agent | Focus |\n|-------|-------|\n| `criteria-checker` | Core verifier: validates single criterion using bash/codebase/subagent/research methods |\n| `manifest-verifier` | Validates manifest completeness during `/define` |\n| `change-intent-reviewer` | Adversarial intent analysis: reconstructs change intent, finds behavioral divergences across code, prompts, and config |\n| `contracts-reviewer` | Bidirectional API/interface contract verification with evidence from docs and codebase |\n| `code-bugs-reviewer` | Mechanical code defects: race conditions, data loss, edge cases, resource leaks, dangerous defaults |\n| `code-maintainability-reviewer` | DRY violations, coupling, cohesion, dead code, consistency |\n| `code-design-reviewer` | Design fitness: reinvented wheels, code vs configuration boundary, under-engineering, interface foresight, PR coherence |\n| `code-simplicity-reviewer` | Over-engineering, premature optimization, cognitive complexity |\n| `code-testability-reviewer` | Excessive mocking requirements, logic buried in IO, hidden dependencies |\n| `code-coverage-reviewer` | Test coverage with proactive edge case enumeration — derives specific test scenarios from code logic |\n| `type-safety-reviewer` | TypeScript type safety: `any` abuse, invalid states representable, narrowing issues |\n| `docs-reviewer` | Documentation accuracy against code changes |\n| `context-file-adherence-reviewer` | Compliance with context file (CLAUDE.md/AGENTS.md/GEMINI.md) project rules |\n| `define-session-analyzer` | Analyzes a single /define session transcript for user preference patterns. Spawned by `/learn-define-patterns` |\n\nEach reviewer returns structured output with severity levels (Critical, High, Medium, Low) and specific fix guidance.\n\n### Workflow Enforcement Hooks\n\nHooks enforce workflow integrity. The AI can't skip steps:\n\n| Hook | Event | Purpose |\n|------|-------|---------|\n| `stop_do_hook` | Stop command | Blocks premature stopping. Can't stop without verification passing or proper escalation. |\n| `post_compact_hook` | Session compaction | Restores /do workflow context after compaction. Reminds to re-read manifest and log. |\n| `pretool_verify_hook` | `/verify` invocation | Ensures manifest and log are in context before spawning verifiers. |\n| `posttool_log_hook` | Task progress | Reminds to update execution log after task updates, task creation, or workflow skill calls during `/do`. |\n| `prompt_submit_hook` | User input during `/do` | Detects manifest amendments when user provides input during `/do` — enables the autonomous Self-Amendment flow. |\n| `thinking_disciplines_prompt_hook` | User input | Reinforces thinking disciplines on each user message when active (during `/figure-out` or `/define`). |\n| `thinking_disciplines_pretool_hook` | AskUserQuestion | Reinforces thinking disciplines before asking user questions — the moment where sycophantic drift is most likely. |\n\n### Task-Specific Guidance\n\n`/define` loads guidance based on task classification:\n\n| Task Type | Guidance | Quality Gates |\n|-----------|----------|---------------|\n| **Feature** | `tasks/FEATURE.md` + `CODING.md` | Bug detection, type safety, maintainability, simplicity, test coverage, testability, CLAUDE.md adherence |\n| **Bug** | `tasks/BUG.md` + `CODING.md` | Bug fix verification, regression prevention, root cause analysis |\n| **Refactor** | `tasks/REFACTOR.md` + `CODING.md` | Behavior preservation, maintainability, simplicity |\n| **Prompting** | `tasks/PROMPTING.md` | Prompt quality criteria |\n| **Writing** | `tasks/WRITING.md` | Prose quality, AI tells, vocabulary, anti-patterns, craft fundamentals (base for Blog, Document) |\n| **Document** | `tasks/DOCUMENT.md` + `WRITING.md` | Structure completeness, consistency |\n| **Blog** | `tasks/BLOG.md` + `WRITING.md` | Engagement, SEO |\n| **Research** | `tasks/research/RESEARCH.md` + source files | Source-agnostic research methodology. Source-specific guidance in `tasks/research/sources/` |\n\n## Development\n\n```bash\n# Setup (first time)\n./scripts/setup.sh\nsource .venv/bin/activate\n\n# Lint, format, typecheck\nruff check --fix claude-plugins/ \u0026\u0026 black claude-plugins/ \u0026\u0026 mypy\n\n# Test hooks (run after ANY hook changes)\npytest tests/hooks/ -v\n\n# Test plugin locally\n/plugin marketplace add /path/to/manifest-dev\n/plugin install manifest-dev@manifest-dev-marketplace\n```\n\n## Contributing\n\nSee [CONTRIBUTING.md](./CONTRIBUTING.md) for plugin development guidelines.\n\n## License\n\nMIT\n\n---\n\n*Built by developers who understand LLM limitations, and design around them.*\n\nFollow along: [@aviramkofman](https://x.com/aviramkofman)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdoodledood%2Fmanifest-dev","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdoodledood%2Fmanifest-dev","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdoodledood%2Fmanifest-dev/lists"}