execute-phase
Skill104 starsChanged 8 months agoMITView on GitHub
Execute implementation plans from .artifacts/plan/. Focus on EXECUTING ONLY - no planning, no fixes outside plan scope. Uses gated checks, atomic commits, and maintains a single execution log in .artifacts/execute/. Use when the user says "execute this plan" or provides a plan path.
4 other projects use a version of this.
Adopted by
Most recently taken up by
- takleb3rry/claude-global-appbuilding-skillstheir own version, first seen Nov 8, 2026
- buildomator/buildomatortheir own version, first seen Nov 4, 2026
- Pitcocy/skillstheir own version, first seen Nov 1, 2026
- gtrabanco/agentic-workflowtheir own version, first seen Sep 22, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- buildomator/buildomator★ 102same name
- gtrabanco/agentic-workflow★ 23same name
- takleb3rry/claude-global-appbuilding-skills★ 6same name
- Pitcocy/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository7 other files it gives its agents.
- agents-md-mapperSkill
- ast-grep-setupSkill
- differential-session-runnerSkill
- harness-mapSkill
- plan-phaseSkill
- qa-from-executeSkill
- research-phaseSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. 0 are common, 14 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
14
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 64
Read the FULL plan. Extract:
- Distinctive: line 73
Before any code changes:
- Distinctive: line 141
Run gates in order. Document ALL results.
- Distinctive: line 159
Document in the execution log:
- Distinctive: line 170
STOP and ask user for next steps
- Distinctive: line 171
Do NOT roll back without user confirmation
- Distinctive: line 267
After the Execute phase, summarize:
- Distinctive: line 304
ONE execution log: - Create once, update as you work.
- Distinctive: line 306
Rollback first: - Create rollback commit before any code changes.
- Distinctive: line 307
Gates are mandatory: - Run all gates. Document failures.
- Distinctive: line 308
Plan is source of truth: - Do not add, remove, or change tasks.
- Distinctive: line 309
Ask when blocked: - If gates fail or plan is ambiguous, stop and ask.
- Distinctive: line 313
Before proceeding with each task:
- Distinctive: line 315
Clarity: Do I understand exactly what this task requires?
- Very specific: line 343
After writing the execution log to .artifacts/execute/, proceed to qa-from-execute if the next step is the QA phase.
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Execute Phase
Overview
Execute implementation plans from .artifacts/plan/ with strict discipline: gated checks, atomic commits, and a single living execution log.
North Star Rule
Follow the plan exactly. Do not improvise. Do not fix what isn't in the plan.
If something is ambiguous or missing, stop and ask the user.
When to Use
- User provides a plan path in
.artifacts/plan/ - User says "execute this plan" or "run the plan"
- User references a plan document for implementation
What This Skill Does NOT Do
| ❌ DON'T | ✅ DO INSTEAD |
| Re-plan the work | Execute tasks as written |
| Fix unrelated issues | Follow plan scope only |
| Skip quality gates | Run all gates, document failures |
| Ignore the plan | Plan is the source of truth |
Execute Phase Workflow
0. Input
User provides: $ARGUMENTS = path to plan in .artifacts/plan/
1. Read Plan & Lock Context
Read the FULL plan. Extract:
- Milestones
- Task IDs and order
- Acceptance tests
- Quality gates
- Success criteria
2. Pre-Flight Snapshot
Before any code changes:
# Capture git state
BRANCH=$(git branch --show-current)
SHA=$(git rev-parse --short HEAD)
STATUS=$(git status --short)Create rollback point:
git add -A
git commit -m "rollback: before executing plan <topic>"Create .artifacts/execute/YYYY-MM-DD_HH-MM-SS_<topic>.md:
---
title: "<topic> execution log"
link: "<topic>-execute"
type: debug_history
ontological_relations:
- relates_to: [[<plan-link>]]
tags: [execute, <topic>]
uuid: "<uuid>"
created_at: "<ISO-8601 timestamp>"
owner: "{{user}}"
plan_path: ".artifacts/plan/<file>.md"
start_commit: "<short_sha>"
env: {target: "local|staging|prod", notes: ""}
---
## Pre-Flight Checks
- Branch: <branch>
- Rollback commit: <sha>
- DoR satisfied: yes/no
- Access/secrets: present/missing
- Fixtures/data: ready/not ready
[If any NO → abort and add Blockers section]3. Task-by-Task Execution
For EACH task in plan order:
1. Read task requirements
2. Implement minimal slice aligned with acceptance test
3. Run local validation
4. Commit atomic change with Task ID in message
5. Update execution logCommit message format:
T<NNN>: <task summary>
<brief description of change>
Refs: plan/<file>.md4. Quality Gates
Run gates in order. Document ALL results.
Gate C - Code Quality
# Run tests
pytest
# Type check
mypy src/
# Lint
black --check src/
# Coverage
coverage reportDocument in the execution log:
### Gate Results
- Tests: pass/fail + evidence
- Coverage: X% (target Y%)
- Type checks: pass/fail
- Linters: pass/failIf gate FAILS:
- Record failure + remediation attempted
- STOP and ask user for next steps
- Do NOT roll back without user confirmation
5. Permalinks & Artifacts
If commits pushed:
# Get repo info for permalinks
gh repo view --json owner,nameAttach permalinks to:
- PRs/commits
- Build logs
- Coverage reports
- Security scans
Persist artifact pointers in the execution log.
6. Post-Deploy Verification (if applicable)
### Post-Deploy Verification
- Error rates: <metrics>
- Latencies: <metrics>
- Dashboard links: <URLs>
- Smoke/E2E results: <pass/fail>Execution Log Template
Keep ONE document. Update as you work.
---
title: "<topic> execution log"
link: "<topic>-execute"
type: debug_history
ontological_relations:
- relates_to: [[<plan-link>]]
tags: [execute, <topic>]
uuid: "<uuid>"
created_at: "<ISO-8601 timestamp>"
plan_path: ".artifacts/plan/<file>.md"
start_commit: "<sha>"
end_commit: "<sha>"
env: {target: "...", notes: "..."}
---
## Pre-Flight Checks
- Branch: <branch>
- Rollback: <commit_sha>
- DoR: satisfied/not
- Ready: yes/no
## Task Execution
### T001 – <Summary>
- Status: completed/skipped/failed
- Commit: <sha>
- Files: <list>
- Commands: <cmd> → <output>
- Tests: pass/fail
- Coverage delta: +X%
- Notes: <decisions made>
### T002 – <Summary>
[... repeat for each task ...]
## Gate Results
- Tests: X/Y passed
- Coverage: X% (target Y%)
- Type checks: pass/fail
- Security: # issues
- Linters: pass/fail
## Deployment (if applicable)
- Staging: success/fail
- Prod: success/fail
- Timestamps: <start> → <end>
## Issues & Resolutions
- T<NNN> – <issue> → <resolution|rollback|asked user>
## Success Criteria
- [ ] All planned gates passed
- [ ] Rollout completed or rolled back
- [ ] KPIs/SLOs within thresholds
- [ ] Execution log saved
## Next Steps
- Follow-ups, tech debt, docsFinal Report
After the Execute phase, summarize:
# Execution Report – <topic>
**Date:** {{date}}
**Plan:** <plan_file>
**Log:** <log_file>
## Overview
- Environment: <env>
- Start: <sha>
- End: <sha>
- Duration: Xh Ym
- Branch: <branch>
## Outcomes
- Tasks attempted: N
- Tasks completed: N
- Final status: Success | Failure | Blocked
## Gate Results
- Tests: pass/fail
- Coverage: X% (target Y%)
- Type checks: pass/fail
- Security: # issues
## What Was Touched
[List all files modified]
## Next Steps
- [ ] Item 1
- [ ] Item 2Strict Rules
- ONE execution log - Create once, update as you work. Do not create multiple docs.
- Atomic commits - One commit per task. Task ID in commit message.
- Rollback first - Create rollback commit before any code changes.
- Gates are mandatory - Run all gates. Document failures. Stop on failure.
- Plan is source of truth - Do not add, remove, or change tasks.
- Ask when blocked - If gates fail or plan is ambiguous, stop and ask.
Validation Questions
Before proceeding with each task:
- Clarity: Do I understand exactly what this task requires?
- Scope: Is this within the plan's scope?
- Dependencies: Are prerequisite tasks completed?
- Rollback: Can I revert to the safe state?
Output Format
Start:
Executing plan: .artifacts/plan/<file>.md
Branch: <branch>
Rollback point: <commit_sha>
Tasks: N
Milestones: MEnd:
Execution complete: Success | Failure | Blocked
Tasks completed: N/N
Log: .artifacts/execute/<file>.md
Next step: QA from execute using the generated execution log pathHandoff
After writing the execution log to .artifacts/execute/, proceed to qa-from-execute if the next step is the QA phase.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

