[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6M9KAH2WRF51QSA5V7FVZ20":3,"skill-same:01M6M9KAH2WRF51QSA5V7FVZ20":76},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6M9KAH2WRF51QSA5V7FVZ20","prompt-pipeline",null,"How to design the numbered prompt pipeline that drives Hunt phases in Cavekit. Covers greenfield 3-prompt patterns, rewrite 6-9 prompt patterns, shared principles, prompt engineering best practices, task templates, and time guards. Trigger phrases: \"prompt pipeline\", \"design prompts for SDD\", \"create Hunt prompts\", \"pipeline prompts\", \"how many prompts do I need\"","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1575,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FJuliusBrussee\u002Fblueprint\u002Fskills\u002Fprompt-pipeline\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"prompt pipeline","pipeline","prompt","patterns","for","principles","how to","rewrite","trigger","sdd","shared","time","design","task","do","hunt","how","best practices","create","prompt engineering","2026-11-10 10:12:30",false,"---\nname: prompt-pipeline\ndescription: >\n  How to design the numbered prompt pipeline that drives Hunt phases in Cavekit.\n  Covers greenfield 3-prompt patterns, rewrite 6-9 prompt patterns, shared principles,\n  prompt engineering best practices, task templates, and time guards.\n  Trigger phrases: \"prompt pipeline\", \"design prompts for SDD\", \"create Hunt prompts\",\n  \"pipeline prompts\", \"how many prompts do I need\"\n---\n\n# Prompt Pipeline Design\n\nThe prompt pipeline is the engine of SDD. Each numbered prompt drives one phase of the Hunt lifecycle (Spec, Plan, Implement, Iterate, Monitor). Prompts are structured markdown files that instruct an AI agent to perform a specific phase, with detailed information delegated to specs, plans, and reference materials.\n\n**Core principle:** Prompts should be as lightweight and systemic as possible. They define the *process*, not the *content* -- specs and plans hold the content.\n\n---\n\n## 1. Greenfield Pattern (3-Prompt Pipeline)\n\nFor new projects starting from reference materials (PRDs, language specs, design docs, research).\n\n```\nPipeline Flow:\n  refs\u002F ──> [001] ──> specs\u002F ──> [002] ──> plans\u002F ──> [003] ──> src\u002F + tests\u002F\n                                   ^                     |\n                                   |                     |\n                                   +── impl\u002F \u003C───────────+\n                                   (bidirectional flow)\n```\n\n| Prompt File | Lifecycle Stage | Reads From | Writes To | Description |\n|-------------|----------------|------------|-----------|-------------|\n| `001-generate-specs-from-refs.md` | **Spec** | `context\u002Frefs\u002F` | `context\u002Fkits\u002F` | Reads reference materials, decomposes into domain-specific specs with cross-references and testable acceptance criteria |\n| `002-generate-plans-from-specs.md` | **Plan** | `context\u002Fkits\u002F` + `context\u002Fimpl\u002F` | `context\u002Fplans\u002F` | Reads specs plus implementation progress, creates framework-specific plans with feature dependencies, test strategies, and acceptance criteria |\n| `003-generate-impl-from-plans.md` | **Implement** | `context\u002Fplans\u002F` + `context\u002Fkits\u002F` | `src\u002F`, `tests\u002F`, `context\u002Fimpl\u002F` | Implements the highest-priority unblocked work from plans, runs tests, updates implementation tracking |\n\n### Key behaviors\n\n- **Prompt 001** runs once or a few times to stabilize specs. It reads `context\u002Frefs\u002F` and produces `context\u002Fkits\u002F`.\n- **Prompt 002** reads specs and any existing implementation tracking (`context\u002Fimpl\u002F`). It produces plans that sequence the work.\n- **Prompt 003** reads plans and specs, implements code, runs validation gates, and updates `context\u002Fimpl\u002F` with progress.\n- **Prompts 002 and 003 modify each other's files.** This bidirectional flow is expected and healthy -- it is how the system self-corrects.\n\n### Example prompt 001 structure\n\n```markdown\n# 001: Generate Specs from Reference Materials\n\n## Runtime Inputs\n- Framework: {FRAMEWORK}\n- Build command: {BUILD_COMMAND}\n- Test command: {TEST_COMMAND}\n\n## Context\nRead all files in `context\u002Frefs\u002F`. These are the source of truth.\n\n## Task\nDecompose the reference materials into domain-specific specifications:\n1. Create `context\u002Fkits\u002Fcavekit-overview.md` as the index file\n2. Create one `context\u002Fkits\u002Fspec-{domain}.md` per domain\n3. Each spec must include: Scope, Requirements with Acceptance Criteria, Dependencies, Out of Scope, Cross-References\n\n## Exit Criteria\n- [ ] All domains from reference materials have corresponding spec files\n- [ ] Every requirement has at least one testable acceptance criterion\n- [ ] cavekit-overview.md indexes all spec files with one-line summaries\n- [ ] Cross-references link related specs\n\n## Completion Signal\n\u003Call-tasks-complete>\n```\n\n---\n\n## 2. Rewrite Pattern (6-9 Prompt Pipeline)\n\nFor projects that start from existing code that must be reverse-engineered into specs before building a new implementation.\n\n```\nPipeline Flow:\n  old-code ──> [001] ──> reference\u002F ──> [002] ──> specs\u002F ──> [003] ──> validated specs\n                                                                            |\n       +────────────────────────────────────────────────────────────────────+\n       |\n       v\n  specs\u002F ──> [004] ──> plans\u002F ──> [005] ──> src\u002F + tests\u002F ──> [006] ──> updated specs\n                                                                            |\n       +────────────────────────────────────────────────────────────────────+\n       |\n       v\n  (loop back to 002 for refinement)\n```\n\n| Prompt File | Lifecycle Stage | Reads From | Writes To |\n|-------------|----------------|------------|-----------|\n| `001-generate-refs-from-code.md` | Pre-Spec | Old application source | `shared-context\u002Freference\u002F` (API docs, data models, UI components) |\n| `002-generate-specs.md` | Spec | Feature scope + reference materials | `shared-context\u002Fkits\u002F` (implementation-agnostic specs) |\n| `003-validate-specs.md` | Spec QA | Reference + specs | Validation report (specs match old behavior) |\n| `004-create-plans.md` | Plan | Specs + framework research | `context\u002Fplans\u002F` (framework-specific plans) |\n| `005-implement.md` | Implement | Plans + specs | `src\u002F` + `tests\u002F` + `context\u002Fimpl\u002F` |\n| `006-backpropagate.md` | Iterate | Working prototype | Updated specs (back-propagates to 002) |\n\n### Rewrite-specific considerations\n\n- **Prompt 001** only runs once -- it extracts reference documentation from the old codebase.\n- **Prompt 003** is a validation pass -- it does not produce code, only a report on spec accuracy.\n- **Prompt 006** creates a feedback loop: prototype learnings flow back into specs, which then flow forward through 004 and 005 again.\n- The rewrite pipeline supports **multi-repo strategies**: shared specs can drive implementations in multiple frameworks simultaneously (e.g., evaluating framework A vs framework B using the same specs).\n\n---\n\n## 3. Shared Principles Across All Pipelines\n\nThese principles apply regardless of whether the pipeline is greenfield, rewrite, or hybrid.\n\n| Principle | Detail |\n|-----------|--------|\n| **One prompt per Hunt phase** | Each prompt maps to exactly one phase. Do not combine phases. |\n| **Explicit input\u002Foutput directories** | Every prompt declares what it reads and what it writes. No implicit side effects. |\n| **Git-based continuity** | Agents read git history (`git log`, `git diff`, `git status`) between iterations to understand what was done before. |\n| **Explicit done-conditions with termination markers** | Every prompt concludes with a verifiable checklist of conditions and a distinct output token that the iteration loop uses to detect completion. |\n| **Bidirectional spec\u002Fplan updates** | Plan prompts read impl tracking; implement prompts update plans. This cross-pollination is healthy. |\n| **Test generation on changed files** | After modifying source files, run test generation to maintain coverage. |\n| **Phase gates between prompts** | Before moving to the next prompt, verify: build passes, tests pass, acceptance criteria met. |\n\n### The bidirectional flow in detail\n\n```\nPrompt 002 (Plans):\n  READS:  context\u002Fkits\u002F     (what to build)\n  READS:  context\u002Fimpl\u002F      (what has been built, what failed)\n  WRITES: context\u002Fplans\u002F     (how to build it)\n\nPrompt 003 (Implement):\n  READS:  context\u002Fplans\u002F     (how to build it)\n  READS:  context\u002Fkits\u002F     (acceptance criteria)\n  WRITES: src\u002F, tests\u002F       (the code)\n  WRITES: context\u002Fimpl\u002F      (progress tracking)\n  WRITES: context\u002Fplans\u002F     (updates to plans based on implementation reality)\n```\n\nThis means running prompt 002 again after prompt 003 will incorporate implementation learnings into plans. Running prompt 003 again after prompt 002 will implement updated plans. This is exactly the convergence loop at work.\n\n---\n\n## 4. Prompt Engineering Best Practices\n\n### 4.1 Runtime Inputs\n\nUse runtime variables so prompts work across any project without modification:\n\n```markdown\n## Runtime Inputs\n- Framework: {FRAMEWORK}           # e.g., \"React + Vite\", \"Tauri + Svelte\"\n- Build command: {BUILD_COMMAND}   # e.g., \"npm run build\", \"cargo build\"\n- Test command: {TEST_COMMAND}     # e.g., \"npm test\", \"pytest\"\n- Lint command: {LINT_COMMAND}     # e.g., \"npm run lint\", \"cargo clippy\"\n- Source dir: {SRC_DIR}            # e.g., \"src\u002F\", \"lib\u002F\"\n- Test dir: {TEST_DIR}            # e.g., \"tests\u002F\", \"__tests__\u002F\"\n```\n\n### 4.2 Agent Team Structure (ASCII Trees)\n\nWhen prompts use agent teams, define the hierarchy explicitly as an ASCII tree:\n\n```\nAgent Team Structure:\n  Lead (delegate mode -- never writes code directly)\n  +-- Teammate A: domain-auth\n  |   Owns: src\u002Fauth\u002F*, context\u002Fimpl\u002Fimpl-auth.md\n  |   Dispatch: Agent tool\n  +-- Teammate B: domain-data\n  |   Owns: src\u002Fdata\u002F*, context\u002Fimpl\u002Fimpl-data.md\n  |   Dispatch: Agent tool\n  +-- Teammate C: domain-ui\n      Owns: src\u002Fui\u002F*, context\u002Fimpl\u002Fimpl-ui.md\n      Dispatch: Agent tool\n```\n\n**Why:** Agents need to understand their role and what they own. Dispatch subagents via the Agent tool. After merging a subagent's branch, the caller must clean up: `git branch -D \u003Cbranch>`.\n\n### 4.3 Batching Rules\n\n- **Max 3 concurrent teammates** per batch. Prevents resource exhaustion and race conditions.\n- **Batch phases:** Spawn batch 1 (3 teammates) -> wait for completion -> shutdown -> spawn batch 2.\n- **Max 3 sub-agents per teammate.** Sub-agents handle discrete subtasks (reading docs, running tests) to preserve the teammate's context window.\n\n```\nExecution Timeline:\n  Batch 1: [Teammate A] [Teammate B] [Teammate C]\n           ─────────────────────────────────────────> complete, shutdown\n  Batch 2: [Teammate D] [Teammate E] [Teammate F]\n           ─────────────────────────────────────────> complete, shutdown\n```\n\n### 4.4 File Ownership Tables\n\nAssign each shared file to exactly one teammate to eliminate merge conflicts:\n\n```markdown\n## File Ownership\n| File\u002FPattern | Owner |\n|-------------|-------|\n| `src\u002Fauth\u002F**` | domain-auth |\n| `src\u002Fdata\u002F**` | domain-data |\n| `src\u002Fui\u002F**` | domain-ui |\n| `src\u002Fshared\u002Ftypes.ts` | domain-data |\n| `context\u002Fimpl\u002Fimpl-auth.md` | domain-auth |\n```\n\n**Rule:** If two teammates need to modify the same file, assign ownership to one and have the other request changes through the lead.\n\n### 4.5 Exit Criteria and Completion Signals\n\nEvery prompt must end with explicit exit criteria and a completion signal:\n\n```markdown\n## Exit Criteria\n- [ ] All T- tasks are DONE or documented as BLOCKED\n- [ ] {BUILD_COMMAND} passes with zero errors\n- [ ] {TEST_COMMAND} passes with zero failures\n- [ ] All modified source files have corresponding test coverage\n- [ ] context\u002Fimpl\u002F updated with current status\n\n## Completion Signal\nWhen ALL exit criteria are met, output exactly:\n\u003Call-tasks-complete>\n\nThis signal is used by the iteration loop to detect when to stop.\n```\n\n### 4.6 Spawn Templates\n\nTeammates are fresh processes with **no inherited history**. Every spawn must include full context:\n\n```markdown\n## Spawn Template for Teammate\n\nYou are implementing {DOMAIN} for the {PROJECT_NAME} project.\n\n### Your Role\n- You own: {FILE_PATTERNS}\n- Dispatched via the Agent tool\n- Your impl tracking: context\u002Fimpl\u002Fimpl-{DOMAIN}.md\n\n### Context to Read First\n1. context\u002Fkits\u002Fspec-{DOMAIN}.md (WHAT to build)\n2. context\u002Fplans\u002Fplan-{DOMAIN}.md (HOW to build it)\n3. context\u002Fimpl\u002Fimpl-{DOMAIN}.md (what has been done)\n4. git log --oneline -20 (recent history)\n\n### Task\n{TASK_DESCRIPTION}\n\n### Exit Criteria\n- [ ] {CRITERIA}\n\n### Halting Conditions\n- Do NOT push to remote unless explicitly asked\n- Do NOT modify files outside your ownership\n- If blocked for more than 20 minutes, document the blocker and stop\n```\n\n### 4.7 Halting Conditions\n\nExplicit halting conditions prevent irreversible or wasteful actions:\n\n```markdown\n## Halting Conditions\n- Do NOT push to remote unless explicitly asked\n- Do NOT modify files outside your file ownership table\n- Do NOT delete test files or skip failing tests\n- If a task takes more than 20 minutes, document findings and move on\n- If you encounter a circular dependency, document it and stop\n- Commit frequently to preserve progress\n```\n\n### 4.8 Sub-Agent Delegation\n\nTeammates should delegate discrete subtasks to sub-agents to preserve their own context window:\n\n```markdown\n## When to Use Sub-Agents\n- Reading large documentation files\n- Running and parsing test output\n- Generating boilerplate code\n- Researching framework APIs\n- Performing file-by-file migrations\n\n## Sub-Agent Rules\n- Max 3 concurrent sub-agents per teammate\n- Each sub-agent gets a focused, self-contained task\n- Sub-agent results are summarized back to the teammate\n- Sub-agents do NOT inherit the teammate's conversation history\n```\n\n---\n\n## 5. Task Template Standardization\n\nUse standardized task templates for consistent tracking across prompts:\n\n### Task ID format\n\n```markdown\n### T-{DOMAIN}-{NUMBER}: {Task Title}\n- **Status:** TODO | IN_PROGRESS | DONE | BLOCKED\n- **blockedBy:** T-{OTHER_DOMAIN}-{NUMBER} (if applicable)\n- **Files:** {list of files to create or modify}\n- **Acceptance criteria:**\n  - [ ] {criterion 1}\n  - [ ] {criterion 2}\n```\n\n### Dependency tracking with blockedBy\n\n```markdown\n### T-AUTH-001: Implement login flow\n- **Status:** TODO\n- **blockedBy:** T-DATA-001 (needs user model)\n\n### T-DATA-001: Create user data model\n- **Status:** IN_PROGRESS\n- **blockedBy:** none\n```\n\n### Conditional and dynamic tasks\n\n```markdown\n### T-UI-005: Implement dark mode [CONDITIONAL]\n- **Skip if:** {FRAMEWORK} does not support CSS variables\n- **Status:** TODO\n\n### T-PERF-001: Optimize hot paths [DYNAMIC]\n- **Created when:** Performance gate identifies bottlenecks\n- **Status:** not yet created\n```\n\n**`[CONDITIONAL]`** tasks include a skip condition -- if the condition is met, the task is skipped without failure.\n\n**`[DYNAMIC]`** tasks are placeholders created at runtime when a specific trigger occurs. They do not exist in the initial plan.\n\n---\n\n## 6. Time Guards\n\nPer-task time budgets prevent agents from spending too long on any single task:\n\n| Category | Budget | Examples |\n|----------|--------|----------|\n| **Mechanical** | 10 minutes | File creation, boilerplate, simple refactors |\n| **Investigation** | 20 minutes | Debugging, researching APIs, understanding existing code |\n| **Category budget** | 20 minutes | Total time for all tasks in one category before escalating |\n\n### Time guard rules\n\n1. **Set expectations in the prompt:**\n   ```markdown\n   ## Time Guards\n   - Mechanical tasks (file creation, boilerplate): 10 min max\n   - Investigation tasks (debugging, research): 20 min max\n   - If you hit a time guard, document your findings and move to the next task\n   - Do NOT silently retry -- document the blocker\n   ```\n\n2. **Hard stops:** When a time guard is hit, the agent must:\n   - Document what was attempted\n   - Document what was learned\n   - Document the blocker or open question\n   - Move to the next unblocked task\n\n3. **Escalation:** If an agent hits time guards on multiple related tasks, this signals a systemic issue (fuzzy spec, missing dependency, architectural problem). Document it as a pattern, not individual failures.\n\n---\n\n## 7. Prompt File Naming Convention\n\n```\ncontext\u002Fprompts\u002F\n+-- 000-generate-specs-from-code.md    # Brownfield only (bootstrap, runs once)\n+-- 001-generate-specs-from-refs.md    # Greenfield spec generation\n+-- 002-generate-plans-from-specs.md   # Plan generation\n+-- 003-generate-impl-from-plans.md    # Implementation\n+-- 004-validate-specs.md              # Spec validation (rewrite pipelines)\n+-- 005-backpropagate.md               # Back-propagation (rewrite pipelines)\n```\n\n### Naming rules\n\n- **Three-digit prefix** for ordering (000, 001, 002...)\n- **Verb-noun format** describing the transformation (generate-specs-from-refs)\n- **Lower prompt numbers** are upstream (closer to specs)\n- **Higher prompt numbers** are downstream (closer to code)\n- **000** is reserved for brownfield bootstrap (runs once, not in the main loop)\n\n---\n\n## 8. Designing Your Pipeline\n\n### Step-by-step process\n\n1. **Identify your project type:** Greenfield (start from refs) or Rewrite (start from old code)?\n2. **Start with the minimum pipeline:** Greenfield = 3 prompts. Rewrite = 6 prompts.\n3. **Write prompt 001 first:** This is always the spec generation step.\n4. **Define your runtime variables:** What framework, build command, test command?\n5. **Set exit criteria for each prompt:** What must be true before moving to the next phase?\n6. **Add agent teams if needed:** For large projects, add team structure and file ownership.\n7. **Run the pipeline with the iteration loop:** Start with a small number of iterations (3-5) and increase as needed.\n8. **Watch for convergence:** Exponentially decreasing changes = convergence. Flat or oscillating changes = fix your specs.\n\n### When to add more prompts\n\n- If a single prompt is trying to do too much (reading AND writing specs, for example), split it.\n- If you see a phase producing inconsistent results, add a validation prompt between phases.\n- If back-propagation is frequent, add an explicit back-propagation prompt (006 in the rewrite pattern).\n\n---\n\n## 9. Iteration Loop Integration\n\nPrompts are designed to run inside an iteration loop that repeats them until convergence:\n\n```bash\n# Greenfield: Run implementation prompt with iteration loop\n# -n 10: max 10 iterations\n# -t 1h: 1 hour timeout per iteration\niteration-loop context\u002Fprompts\u002F003-generate-impl-from-plans.md -n 10 -t 1h\n\n# Leader-follower pattern: staggered pipeline\n# Terminal 1: Specs (leader)\niteration-loop context\u002Fprompts\u002F001-generate-specs-from-refs.md -n 5 -t 2h\n\n# Terminal 2: Plans (follower, 1h delay)\niteration-loop context\u002Fprompts\u002F002-generate-plans-from-specs.md -n 5 -t 2h -d 1h\n\n# Terminal 3: Implementation (follower, 2h delay)\niteration-loop context\u002Fprompts\u002F003-generate-impl-from-plans.md -n 10 -t 1h -d 2h\n```\n\nThe iteration loop handles: iteration counting, timeouts, nudging idle agents, detecting completion signals, and graceful stop on convergence.\n\n---\n\n## Cross-References\n\n- **Prompt engineering details:** See `references\u002Fprompt-engineering.md` for the complete reference on runtime inputs, spawn templates, task templates, time guards, and file ownership.\n- **Agent team patterns:** See `references\u002Fagent-team-patterns.md` for coordination patterns, batching, agent isolation, and merge protocol.\n- **Convergence monitoring:** See `ck:convergence-monitoring` skill for detecting when the iteration loop should stop.\n- **Revision:** See `ck:revision` skill for how prompt 006 traces bugs back to specs.\n- **Context architecture:** See `ck:context-architecture` skill for the directory structure that prompts read from and write to.\n","# Prompt Pipeline Design\n\nThe prompt pipeline is the engine of SDD. Each numbered prompt drives one phase of the Hunt lifecycle (Spec, Plan, Implement, Iterate, Monitor). Prompts are structured markdown files that instruct an AI agent to perform a specific phase, with detailed information delegated to specs, plans, and reference materials.\n\n**Core principle:** Prompts should be as lightweight and systemic as possible. They define the *process*, not the *content* -- specs and plans hold the content.\n\n---\n\n## 1. Greenfield Pattern (3-Prompt Pipeline)\n\nFor new projects starting from reference materials (PRDs, language specs, design docs, research).\n\n```\nPipeline Flow:\n  refs\u002F ──> [001] ──> specs\u002F ──> [002] ──> plans\u002F ──> [003] ──> src\u002F + tests\u002F\n                                   ^                     |\n                                   |                     |\n                                   +── impl\u002F \u003C───────────+\n                                   (bidirectional flow)\n```\n\n| Prompt File | Lifecycle Stage | Reads From | Writes To | Description |\n|-------------|----------------|------------|-----------|-------------|\n| `001-generate-specs-from-refs.md` | **Spec** | `context\u002Frefs\u002F` | `context\u002Fkits\u002F` | Reads reference materials, decomposes into domain-specific specs with cross-references and testable acceptance criteria |\n| `002-generate-plans-from-specs.md` | **Plan** | `context\u002Fkits\u002F` + `context\u002Fimpl\u002F` | `context\u002Fplans\u002F` | Reads specs plus implementation progress, creates framework-specific plans with feature dependencies, test strategies, and acceptance criteria |\n| `003-generate-impl-from-plans.md` | **Implement** | `context\u002Fplans\u002F` + `context\u002Fkits\u002F` | `src\u002F`, `tests\u002F`, `context\u002Fimpl\u002F` | Implements the highest-priority unblocked work from plans, runs tests, updates implementation tracking |\n\n### Key behaviors\n\n- **Prompt 001** runs once or a few times to stabilize specs. It reads `context\u002Frefs\u002F` and produces `context\u002Fkits\u002F`.\n- **Prompt 002** reads specs and any existing implementation tracking (`context\u002Fimpl\u002F`). It produces plans that sequence the work.\n- **Prompt 003** reads plans and specs, implements code, runs validation gates, and updates `context\u002Fimpl\u002F` with progress.\n- **Prompts 002 and 003 modify each other's files.** This bidirectional flow is expected and healthy -- it is how the system self-corrects.\n\n### Example prompt 001 structure\n\n```markdown\n# 001: Generate Specs from Reference Materials\n\n## Runtime Inputs\n- Framework: {FRAMEWORK}\n- Build command: {BUILD_COMMAND}\n- Test command: {TEST_COMMAND}\n\n## Context\nRead all files in `context\u002Frefs\u002F`. These are the source of truth.\n\n## Task\nDecompose the reference materials into domain-specific specifications:\n1. Create `context\u002Fkits\u002Fcavekit-overview.md` as the index file\n2. Create one `context\u002Fkits\u002Fspec-{domain}.md` per domain\n3. Each spec must include: Scope, Requirements with Acceptance Criteria, Dependencies, Out of Scope, Cross-References\n\n## Exit Criteria\n- [ ] All domains from reference materials have corresponding spec files\n- [ ] Every requirement has at least one testable acceptance criterion\n- [ ] cavekit-overview.md indexes all spec files with one-line summaries\n- [ ] Cross-references link related specs\n\n## Completion Signal\n\u003Call-tasks-complete>\n```\n\n---\n\n## 2. Rewrite Pattern (6-9 Prompt Pipeline)\n\nFor projects that start from existing code that must be reverse-engineered into specs before building a new implementation.\n\n```\nPipeline Flow:\n  old-code ──> [001] ──> reference\u002F ──> [002] ──> specs\u002F ──> [003] ──> validated specs\n                                                                            |\n       +────────────────────────────────────────────────────────────────────+\n       |\n       v\n  specs\u002F ──> [004] ──> plans\u002F ──> [005] ──> src\u002F + tests\u002F ──> [006] ──> updated specs\n                                                                            |\n       +────────────────────────────────────────────────────────────────────+\n       |\n       v\n  (loop back to 002 for refinement)\n```\n\n| Prompt File | Lifecycle Stage | Reads From | Writes To |\n|-------------|----------------|------------|-----------|\n| `001-generate-refs-from-code.md` | Pre-Spec | Old application source | `shared-context\u002Freference\u002F` (API docs, data models, UI components) |\n| `002-generate-specs.md` | Spec | Feature scope + reference materials | `shared-context\u002Fkits\u002F` (implementation-agnostic specs) |\n| `003-validate-specs.md` | Spec QA | Reference + specs | Validation report (specs match old behavior) |\n| `004-create-plans.md` | Plan | Specs + framework research | `context\u002Fplans\u002F` (framework-specific plans) |\n| `005-implement.md` | Implement | Plans + specs | `src\u002F` + `tests\u002F` + `context\u002Fimpl\u002F` |\n| `006-backpropagate.md` | Iterate | Working prototype | Updated specs (back-propagates to 002) |\n\n### Rewrite-specific considerations\n\n- **Prompt 001** only runs once -- it extracts reference documentation from the old codebase.\n- **Prompt 003** is a validation pass -- it does not produce code, only a report on spec accuracy.\n- **Prompt 006** creates a feedback loop: prototype learnings flow back into specs, which then flow forward through 004 and 005 again.\n- The rewrite pipeline supports **multi-repo strategies**: shared specs can drive implementations in multiple frameworks simultaneously (e.g., evaluating framework A vs framework B using the same specs).\n\n---\n\n## 3. Shared Principles Across All Pipelines\n\nThese principles apply regardless of whether the pipeline is greenfield, rewrite, or hybrid.\n\n| Principle | Detail |\n|-----------|--------|\n| **One prompt per Hunt phase** | Each prompt maps to exactly one phase. Do not combine phases. |\n| **Explicit input\u002Foutput directories** | Every prompt declares what it reads and what it writes. No implicit side effects. |\n| **Git-based continuity** | Agents read git history (`git log`, `git diff`, `git status`) between iterations to understand what was done before. |\n| **Explicit done-conditions with termination markers** | Every prompt concludes with a verifiable checklist of conditions and a distinct output token that the iteration loop uses to detect completion. |\n| **Bidirectional spec\u002Fplan updates** | Plan prompts read impl tracking; implement prompts update plans. This cross-pollination is healthy. |\n| **Test generation on changed files** | After modifying source files, run test generation to maintain coverage. |\n| **Phase gates between prompts** | Before moving to the next prompt, verify: build passes, tests pass, acceptance criteria met. |\n\n### The bidirectional flow in detail\n\n```\nPrompt 002 (Plans):\n  READS:  context\u002Fkits\u002F     (what to build)\n  READS:  context\u002Fimpl\u002F      (what has been built, what failed)\n  WRITES: context\u002Fplans\u002F     (how to build it)\n\nPrompt 003 (Implement):\n  READS:  context\u002Fplans\u002F     (how to build it)\n  READS:  context\u002Fkits\u002F     (acceptance criteria)\n  WRITES: src\u002F, tests\u002F       (the code)\n  WRITES: context\u002Fimpl\u002F      (progress tracking)\n  WRITES: context\u002Fplans\u002F     (updates to plans based on implementation reality)\n```\n\nThis means running prompt 002 again after prompt 003 will incorporate implementation learnings into plans. Running prompt 003 again after prompt 002 will implement updated plans. This is exactly the convergence loop at work.\n\n---\n\n## 4. Prompt Engineering Best Practices\n\n### 4.1 Runtime Inputs\n\nUse runtime variables so prompts work across any project without modification:\n\n```markdown\n## Runtime Inputs\n- Framework: {FRAMEWORK}           # e.g., \"React + Vite\", \"Tauri + Svelte\"\n- Build command: {BUILD_COMMAND}   # e.g., \"npm run build\", \"cargo build\"\n- Test command: {TEST_COMMAND}     # e.g., \"npm test\", \"pytest\"\n- Lint command: {LINT_COMMAND}     # e.g., \"npm run lint\", \"cargo clippy\"\n- Source dir: {SRC_DIR}            # e.g., \"src\u002F\", \"lib\u002F\"\n- Test dir: {TEST_DIR}            # e.g., \"tests\u002F\", \"__tests__\u002F\"\n```\n\n### 4.2 Agent Team Structure (ASCII Trees)\n\nWhen prompts use agent teams, define the hierarchy explicitly as an ASCII tree:\n\n```\nAgent Team Structure:\n  Lead (delegate mode -- never writes code directly)\n  +-- Teammate A: domain-auth\n  |   Owns: src\u002Fauth\u002F*, context\u002Fimpl\u002Fimpl-auth.md\n  |   Dispatch: Agent tool\n  +-- Teammate B: domain-data\n  |   Owns: src\u002Fdata\u002F*, context\u002Fimpl\u002Fimpl-data.md\n  |   Dispatch: Agent tool\n  +-- Teammate C: domain-ui\n      Owns: src\u002Fui\u002F*, context\u002Fimpl\u002Fimpl-ui.md\n      Dispatch: Agent tool\n```\n\n**Why:** Agents need to understand their role and what they own. Dispatch subagents via the Agent tool. After merging a subagent's branch, the caller must clean up: `git branch -D \u003Cbranch>`.\n\n### 4.3 Batching Rules\n\n- **Max 3 concurrent teammates** per batch. Prevents resource exhaustion and race conditions.\n- **Batch phases:** Spawn batch 1 (3 teammates) -> wait for completion -> shutdown -> spawn batch 2.\n- **Max 3 sub-agents per teammate.** Sub-agents handle discrete subtasks (reading docs, running tests) to preserve the teammate's context window.\n\n```\nExecution Timeline:\n  Batch 1: [Teammate A] [Teammate B] [Teammate C]\n           ─────────────────────────────────────────> complete, shutdown\n  Batch 2: [Teammate D] [Teammate E] [Teammate F]\n           ─────────────────────────────────────────> complete, shutdown\n```\n\n### 4.4 File Ownership Tables\n\nAssign each shared file to exactly one teammate to eliminate merge conflicts:\n\n```markdown\n## File Ownership\n| File\u002FPattern | Owner |\n|-------------|-------|\n| `src\u002Fauth\u002F**` | domain-auth |\n| `src\u002Fdata\u002F**` | domain-data |\n| `src\u002Fui\u002F**` | domain-ui |\n| `src\u002Fshared\u002Ftypes.ts` | domain-data |\n| `context\u002Fimpl\u002Fimpl-auth.md` | domain-auth |\n```\n\n**Rule:** If two teammates need to modify the same file, assign ownership to one and have the other request changes through the lead.\n\n### 4.5 Exit Criteria and Completion Signals\n\nEvery prompt must end with explicit exit criteria and a completion signal:\n\n```markdown\n## Exit Criteria\n- [ ] All T- tasks are DONE or documented as BLOCKED\n- [ ] {BUILD_COMMAND} passes with zero errors\n- [ ] {TEST_COMMAND} passes with zero failures\n- [ ] All modified source files have corresponding test coverage\n- [ ] context\u002Fimpl\u002F updated with current status\n\n## Completion Signal\nWhen ALL exit criteria are met, output exactly:\n\u003Call-tasks-complete>\n\nThis signal is used by the iteration loop to detect when to stop.\n```\n\n### 4.6 Spawn Templates\n\nTeammates are fresh processes with **no inherited history**. Every spawn must include full context:\n\n```markdown\n## Spawn Template for Teammate\n\nYou are implementing {DOMAIN} for the {PROJECT_NAME} project.\n\n### Your Role\n- You own: {FILE_PATTERNS}\n- Dispatched via the Agent tool\n- Your impl tracking: context\u002Fimpl\u002Fimpl-{DOMAIN}.md\n\n### Context to Read First\n1. context\u002Fkits\u002Fspec-{DOMAIN}.md (WHAT to build)\n2. context\u002Fplans\u002Fplan-{DOMAIN}.md (HOW to build it)\n3. context\u002Fimpl\u002Fimpl-{DOMAIN}.md (what has been done)\n4. git log --oneline -20 (recent history)\n\n### Task\n{TASK_DESCRIPTION}\n\n### Exit Criteria\n- [ ] {CRITERIA}\n\n### Halting Conditions\n- Do NOT push to remote unless explicitly asked\n- Do NOT modify files outside your ownership\n- If blocked for more than 20 minutes, document the blocker and stop\n```\n\n### 4.7 Halting Conditions\n\nExplicit halting conditions prevent irreversible or wasteful actions:\n\n```markdown\n## Halting Conditions\n- Do NOT push to remote unless explicitly asked\n- Do NOT modify files outside your file ownership table\n- Do NOT delete test files or skip failing tests\n- If a task takes more than 20 minutes, document findings and move on\n- If you encounter a circular dependency, document it and stop\n- Commit frequently to preserve progress\n```\n\n### 4.8 Sub-Agent Delegation\n\nTeammates should delegate discrete subtasks to sub-agents to preserve their own context window:\n\n```markdown\n## When to Use Sub-Agents\n- Reading large documentation files\n- Running and parsing test output\n- Generating boilerplate code\n- Researching framework APIs\n- Performing file-by-file migrations\n\n## Sub-Agent Rules\n- Max 3 concurrent sub-agents per teammate\n- Each sub-agent gets a focused, self-contained task\n- Sub-agent results are summarized back to the teammate\n- Sub-agents do NOT inherit the teammate's conversation history\n```\n\n---\n\n## 5. Task Template Standardization\n\nUse standardized task templates for consistent tracking across prompts:\n\n### Task ID format\n\n```markdown\n### T-{DOMAIN}-{NUMBER}: {Task Title}\n- **Status:** TODO | IN_PROGRESS | DONE | BLOCKED\n- **blockedBy:** T-{OTHER_DOMAIN}-{NUMBER} (if applicable)\n- **Files:** {list of files to create or modify}\n- **Acceptance criteria:**\n  - [ ] {criterion 1}\n  - [ ] {criterion 2}\n```\n\n### Dependency tracking with blockedBy\n\n```markdown\n### T-AUTH-001: Implement login flow\n- **Status:** TODO\n- **blockedBy:** T-DATA-001 (needs user model)\n\n### T-DATA-001: Create user data model\n- **Status:** IN_PROGRESS\n- **blockedBy:** none\n```\n\n### Conditional and dynamic tasks\n\n```markdown\n### T-UI-005: Implement dark mode [CONDITIONAL]\n- **Skip if:** {FRAMEWORK} does not support CSS variables\n- **Status:** TODO\n\n### T-PERF-001: Optimize hot paths [DYNAMIC]\n- **Created when:** Performance gate identifies bottlenecks\n- **Status:** not yet created\n```\n\n**`[CONDITIONAL]`** tasks include a skip condition -- if the condition is met, the task is skipped without failure.\n\n**`[DYNAMIC]`** tasks are placeholders created at runtime when a specific trigger occurs. They do not exist in the initial plan.\n\n---\n\n## 6. Time Guards\n\nPer-task time budgets prevent agents from spending too long on any single task:\n\n| Category | Budget | Examples |\n|----------|--------|----------|\n| **Mechanical** | 10 minutes | File creation, boilerplate, simple refactors |\n| **Investigation** | 20 minutes | Debugging, researching APIs, understanding existing code |\n| **Category budget** | 20 minutes | Total time for all tasks in one category before escalating |\n\n### Time guard rules\n\n1. **Set expectations in the prompt:**\n   ```markdown\n   ## Time Guards\n   - Mechanical tasks (file creation, boilerplate): 10 min max\n   - Investigation tasks (debugging, research): 20 min max\n   - If you hit a time guard, document your findings and move to the next task\n   - Do NOT silently retry -- document the blocker\n   ```\n\n2. **Hard stops:** When a time guard is hit, the agent must:\n   - Document what was attempted\n   - Document what was learned\n   - Document the blocker or open question\n   - Move to the next unblocked task\n\n3. **Escalation:** If an agent hits time guards on multiple related tasks, this signals a systemic issue (fuzzy spec, missing dependency, architectural problem). Document it as a pattern, not individual failures.\n\n---\n\n## 7. Prompt File Naming Convention\n\n```\ncontext\u002Fprompts\u002F\n+-- 000-generate-specs-from-code.md    # Brownfield only (bootstrap, runs once)\n+-- 001-generate-specs-from-refs.md    # Greenfield spec generation\n+-- 002-generate-plans-from-specs.md   # Plan generation\n+-- 003-generate-impl-from-plans.md    # Implementation\n+-- 004-validate-specs.md              # Spec validation (rewrite pipelines)\n+-- 005-backpropagate.md               # Back-propagation (rewrite pipelines)\n```\n\n### Naming rules\n\n- **Three-digit prefix** for ordering (000, 001, 002...)\n- **Verb-noun format** describing the transformation (generate-specs-from-refs)\n- **Lower prompt numbers** are upstream (closer to specs)\n- **Higher prompt numbers** are downstream (closer to code)\n- **000** is reserved for brownfield bootstrap (runs once, not in the main loop)\n\n---\n\n## 8. Designing Your Pipeline\n\n### Step-by-step process\n\n1. **Identify your project type:** Greenfield (start from refs) or Rewrite (start from old code)?\n2. **Start with the minimum pipeline:** Greenfield = 3 prompts. Rewrite = 6 prompts.\n3. **Write prompt 001 first:** This is always the spec generation step.\n4. **Define your runtime variables:** What framework, build command, test command?\n5. **Set exit criteria for each prompt:** What must be true before moving to the next phase?\n6. **Add agent teams if needed:** For large projects, add team structure and file ownership.\n7. **Run the pipeline with the iteration loop:** Start with a small number of iterations (3-5) and increase as needed.\n8. **Watch for convergence:** Exponentially decreasing changes = convergence. Flat or oscillating changes = fix your specs.\n\n### When to add more prompts\n\n- If a single prompt is trying to do too much (reading AND writing specs, for example), split it.\n- If you see a phase producing inconsistent results, add a validation prompt between phases.\n- If back-propagation is frequent, add an explicit back-propagation prompt (006 in the rewrite pattern).\n\n---\n\n## 9. Iteration Loop Integration\n\nPrompts are designed to run inside an iteration loop that repeats them until convergence:\n\n```bash\n# Greenfield: Run implementation prompt with iteration loop\n# -n 10: max 10 iterations\n# -t 1h: 1 hour timeout per iteration\niteration-loop context\u002Fprompts\u002F003-generate-impl-from-plans.md -n 10 -t 1h\n\n# Leader-follower pattern: staggered pipeline\n# Terminal 1: Specs (leader)\niteration-loop context\u002Fprompts\u002F001-generate-specs-from-refs.md -n 5 -t 2h\n\n# Terminal 2: Plans (follower, 1h delay)\niteration-loop context\u002Fprompts\u002F002-generate-plans-from-specs.md -n 5 -t 2h -d 1h\n\n# Terminal 3: Implementation (follower, 2h delay)\niteration-loop context\u002Fprompts\u002F003-generate-impl-from-plans.md -n 10 -t 1h -d 2h\n```\n\nThe iteration loop handles: iteration counting, timeouts, nudging idle agents, detecting completion signals, and graceful stop on convergence.\n\n---\n\n## Cross-References\n\n- **Prompt engineering details:** See `references\u002Fprompt-engineering.md` for the complete reference on runtime inputs, spawn templates, task templates, time guards, and file ownership.\n- **Agent team patterns:** See `references\u002Fagent-team-patterns.md` for coordination patterns, batching, agent isolation, and merge protocol.\n- **Convergence monitoring:** See `ck:convergence-monitoring` skill for detecting when the iteration loop should stop.\n- **Revision:** See `ck:revision` skill for how prompt 006 traces bugs back to specs.\n- **Context architecture:** See `ck:context-architecture` skill for the directory structure that prompts read from and write to.\n",{"name":5,"description":7},"main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002FJuliusBrussee\u002Fblueprint\u002Fskills\u002Fprompt-pipeline",491,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 14:06:13",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill prompt-pipeline",{"tool":68,"command":69},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill prompt-pipeline",{"tool":71,"command":72},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill prompt-pipeline","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FJuliusBrussee\u002Fblueprint\u002Fskills\u002Fprompt-pipeline\u002FSKILL.md",true,[],[77,85,92,99,125,150],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":84},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":84},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":84},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":47},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[106,107,108,109,110,111,112,113,114,39,115,116,117,118,119,120,121,122,123,124],"search","deja search","never","error","ready","memory","re","decide","fix","debugging","when","you","done","reviewer","io","change","cli","merge","past",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":47},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[132,133,134,120,135,136,137,138,139,140,141,142,143,144,111,145,146,147,148,149],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":163,"publishedAt":47},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[156,159,160],{"categoryNo":157,"categoryName":158,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":161,"categoryName":162,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[152,164,165,166,167,168,169,146,170,112,171,172,173,174,116,175,176,177,178,179],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]