Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add athola/claude-night-market --skill project-executiongit clone --depth 1 https://github.com/athola/claude-night-marketWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/athola/claude-night-market/project-execution)<a href="https://agentmods.dev/skills/athola/claude-night-market/project-execution"><img src="https://agentmods.dev/badge/skills/athola/claude-night-market/project-execution/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/athola/claude-night-market/project-execution"><img src="https://agentmods.dev/badge/skills/athola/claude-night-market/project-execution.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 3 findings, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Anti-Refusal · line 216 Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.Fix: Remove instructions that suppress warnings, disclaimers, or ethical commentary. Let the agent surface safety-relevant caveats to the user.
- high Anti-Refusal · line 378 Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.Fix: Remove instructions that suppress warnings, disclaimers, or ethical commentary. Let the agent surface safety-relevant caveats to the user.
- medium Excessive Agency · line 6 Skill selects an external model or provider that may use a different account or billing plan than the operator expects. Undisclosed model switches can cause unexpected cost or quota consumption.Fix: Remove the model/provider override or disclose it prominently and require explicit operator approval before invoking an external coding CLI or billed model.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00031 | $0.03409 |
| Opus 5 | $0.00015 | $0.01705 |
| Sonnet 5 | $0.00006 | $0.00682 |
| Haiku 4.5 | $0.00003 | $0.00341 |
Grade A, and why
project-execution scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 486 lines — stays where its author put it; the contents beside it link to each section on GitHub.
When To Use
- After planning phase completes
- Ready to implement tasks
- Need systematic execution with tracking
- Want checkpoint-based validation
- Executing task lists with dependencies
- Monitoring progress and velocity
When NOT To Use
- No implementation plan exists (use
Skill(attune:project-planning)first) - Still planning or designing (complete planning phase before execution)
- Single isolated task (execute directly without framework overhead)
- Exploratory coding or prototyping (use focused development instead)
Integration
With superpowers:
- Uses
Skill(superpowers:executing-plans)for systematic execution - Uses
Skill(superpowers:systematic-debugging)for issue resolution - Uses
Skill(superpowers:verification-before-completion)for validation - Uses
Skill(superpowers:test-driven-development)for TDD workflow
With imbue:
- Uses
Skill(imbue:graduated-implementation)at the ramp gate so each increment's ambition is earned by demonstrated understanding of the prior one, not ramped on completion alone
Without superpowers:
- Standalone execution framework
- Built-in checkpoint validation
- Progress tracking patterns
Execution Framework
Pre-Execution Phase
Actions:
- Load implementation plan
- Validate project initialized
- Check dependencies installed
- Review task dependency graph
- Identify starting tasks (no dependencies)
Validation:
- ✅ Plan file exists and is valid
- ✅ Project structure initialized
- ✅ Git repository configured
- ✅ Development environment ready
Task Execution Loop
For each task in dependency order:
1. PRE-TASK
- Verify dependencies complete
- Review acceptance criteria
- Create feature branch (optional)
- Set up task context
2. IMPLEMENT (TDD Cycle)
- Write failing test (RED)
- Implement minimal code (GREEN)
- Refactor for quality (REFACTOR)
- Repeat until all criteria met
3. VALIDATE
- All tests passing?
- All acceptance criteria met?
- Code quality checks pass?
- Documentation updated?
4. RAMP GATE (before the next, more ambitious task)
- Invoke Skill(imbue:graduated-implementation)
- Demonstrate understanding of THIS increment, sized to stakes:
low-stakes on the evidence gate (green tests plus a recorded
tradeoff), high-stakes on the human explaining the diff unaided
- On a clean demonstration, record it in the ramp ledger and
mark the rung widened; below the band, hold and split the next
task smaller instead of ramping
5. CHECKPOINT
- Mark task complete IMMEDIATELY (do NOT batch)
- Update execution state
- Report progress
- Identify blockers
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 486 lines · 31 tokens per session scan A ee2e752241ee
project-execution is a skill published in the GitHub repository athola/claude-night-market (337 stars, last pushed 2d ago), licensed MIT. It adds 31 tokens to every session and 3,409 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
flow-next-plan
Plan a feature into a flow-next spec with tasks in .flow/. Use when asked to plan, spec out, or break down work (fn-N ids).
flow-next-tracker-sync
Project a flow-next spec to a tracker issue (Linear, GitHub, GitLab, Jira) and reconcile two-way. Use when asked to sync to a tracker. NOT plan-sync.
flow-next
Manage .flow/ tasks and specs. Use for show or list tasks, task status, what is ready, show fn-N. NOT for planning or executing (use the plan and work skills).
flow-next-flow
Attended conductor for an idea, change request, spec or task id, tracker issue, branch or path, bug report, how or why question, slowness, cleanup, or design fork. Use when no skill is named.
subtask-update
Update subtask with fixes or new steps. Two trigger modes: (A) Auto-called by autoworker:gate-check on FAIL — reads FAIL info, adds supplementary steps. (B) User calls with a finding/bug during testing — diagnoses, fixes, updates subtask. Both modes end by invoking autoworker:dispatch to re-enter the loop.
checkpoint
Record progress to subtask: Phase completion (from autoworker:code) or test results (from autoworker:test). Auto-detects upstream type from conversation context. Ends by calling autoworker:dispatch.