Execute
Structured non-code project and knowledge management for Claude Code. (Before Karpathy made this fashionable...)
npx -y skills add OdinMB/ops-workflow --skill executeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Execute an approved ops plan — research, write, review, update state, archive. Use after /plan approval. Not for code.
SKILL.md
3.9 KB, as published. Nobody here has run it
Execute the plan at: $ARGUMENTS
Scope: This skill produces research, content, strategy, and specs — not code. If the plan involves code changes, use /implement instead.
Instructions
1. Read the plan
Read the plan file. Understand the objective, steps, and success criteria.
2. Execute
Carry out the plan:
- Do the research, analysis, or writing described in the plan.
- When researching, always cite sources — include URLs, document names, or specific references.
- Store outputs in the appropriate location:
- Research findings →
references/<topic>/ - Work products and deliverables →
artifacts/(or as specified in the plan)
- Research findings →
- If the plan needs to change mid-execution (new information, blocked path), update the plan file and confirm the revised approach with the user before continuing.
Opportunity lifecycle: When researching and qualifying opportunities (grants, partnerships, platforms, etc.):
- Raw idea → backlog item. The item is the task: "research and qualify this."
- After research → reference file gets the findings. Then either:
- Pursue → backlog action item linking to the reference
- Pass → reference entry updated with pass rationale + date, backlog entry removed
3. Review
Before updating state, review the deliverables. In autonomous execution this is the only verification gate — nothing you produce is seen by a human before it lands in the repo's state and knowledge base — so approach it as a skeptic reading someone else's work, not as a rubber-stamp of what you just wrote. A clean pass is fine, but only after you've genuinely tried to find the weak claim, the unsupported assertion, and the inconsistency:
- Fact-check — verify claims against cited sources. Flag unsupported assertions.
- Consistency — check that new artifacts don't contradict existing state files or prior completed plans.
- Completeness — confirm the output covers everything the plan promised. Fill gaps or note them as out-of-scope with justification.
- Quality — check formatting consistency, broken links, and missing references.
4. State updates
- Complete the plan file — fill in Outcome, Key Decisions, Artifacts, and Session Log sections.
- Update
backlog/— delete the completed item from the relevant file (don't mark it "done"). If only part was completed, rewrite the entry to cover remaining work. If new tasks emerged, add them in priority order (highest first) — not at the end. - Update
state/files — if the task changed anything documented instate/, update those files. Create a new state file if a significant new aspect emerged. - Harvest insights — review what you learned and persist it:
- MEMORY.md Key Learnings — add or update if you learned something that changes the project's understanding of its landscape, constraints, opportunities, or strategic position. Never put WAITING markers, task status, or blocked items in MEMORY.md.
- New backlog items — add actionable opportunities or follow-up tasks to the appropriate backlog file in priority order.
- Patterns, anti-patterns, and conventions — if the work revealed patterns worth documenting for future agents (e.g., effective research approaches, naming conventions for artifacts, common pitfalls in a domain), add them to
CLAUDE.mdonly if most sessions need them, otherwise to the relevant reference file. - INDEX.md cascade — list every file created, moved, renamed, or significantly changed. For each, confirm its folder's
INDEX.mdis up to date. Cascade to parent INDEX.md if needed.
5. Archive the plan
Move the plan to plans/completed/ with a date prefix: YYYY-MM-DD_original-filename.md.