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 agentmods add skills/ayberkyasa/tripod/tasksnpx skills add ayberkyasa/tripod --skill tasksgit clone --depth 1 https://github.com/ayberkyasa/tripodWrote 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/ayberkyasa/tripod/tasks)<a href="https://agentmods.dev/skills/ayberkyasa/tripod/tasks"><img src="https://agentmods.dev/badge/skills/ayberkyasa/tripod/tasks.svg" alt="Measured on agentmods" height="20"></a>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 | $0.00077 | $0.00833 |
| Opus 5 | $0.00039 | $0.00417 |
| Sonnet 5 | $0.00015 | $0.00167 |
| Haiku 4.5 | $0.00008 | $0.00083 |
Grade A, and why
tasks 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 5d 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 — 52 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Tripod: Tasks
You are running phase 2 of the Tripod workflow. The outcome is exactly one file at the repository root: TASKS.md. It is the third and final source of truth, and it is the project's execution plan and progress tracker in one.
Preconditions
Read SPEC.md and CLAUDE.md in full before writing anything. If either is missing, stop and tell the user to run /tripod:spec first. If TASKS.md already exists, ask whether to regenerate (losing checked-off progress) or amend.
Also record the current baseline: inspect the repository state (fresh template? existing code? which files?) and describe it in one or two lines at the top of TASKS.md. Tasks are written relative to this baseline.
Task shape — the non-negotiables
Follow templates/TASKS.template.md from this plugin (read it before writing). Every single task must have:
- A checkbox title:
### [ ] N.M Short imperative title - Scope: what it creates or changes, with concrete file paths that follow the folder structure in CLAUDE.md.
- A "Done when" line: an objectively verifiable condition — a command that passes, a behavior observable in a preview or simulator, a test that goes green. Never "code is written." If you cannot state a verifiable done-condition, the task is not well-defined; redesign it.
Sizing rules:
- One task ≈ one focused session ending in a green build (and green tests where applicable).
- If a task would produce more than ~300 lines of new code, split it.
- Mark a task [P] only if it can be done in parallel with the task directly above it. Everything else is strictly sequential — the order in the file is the order of execution.
Ordering strategy
Structure tasks into phases, ordered to maximize early verifiability and de-risk the hard parts:
- Phase 0 — Foundation: project settings, folder skeleton, test target, lint, design tokens, configuration. Everything CLAUDE.md mandates becomes enforceable before feature code exists.
- Pure domain logic next: algorithms and business rules as dependency-free, unit-tested code. The technical crux identified in SPEC.md gets tackled here, early, where it is cheapest to be wrong.
- Persistence and services: protocol-fronted, mockable, tested against fixtures — no live network in tests.
- UI/features: built on top of already-verified logic, wired through the architecture CLAUDE.md prescribes.
- Hardening: end-to-end verification, performance, real-data QA, release readiness.
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.
- 5d ago First seen · 52 lines · 77 tokens per session scan A 1e2e9af66201
tasks is a skill published in the GitHub repository ayberkyasa/tripod (2 stars, last pushed 19d ago), licensed MIT. It adds 77 tokens to every session and 833 once invoked, about $0.0004 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-08-31.
Other skills, from other repositories
artifact-conventions
Defines preservation, format, and section rules for SDD specification artifacts (spec.md, plan.md, tasks.md, checklists). Use when editing feature-artifact files under specs/ / to prevent accidental corruption of cross-referenced IDs, priorities, and gating state.
plan-authoring
Reference material for writing implementation plans (technical context, architecture decisions, data models, API contracts, project-instructions alignment). Loaded on demand by plan-feature; not directly invokable.
task-generation
Reference material with the canonical task-format grammar and decomposition rules for plan-to-tasks expansion. Loaded on demand by generate-tasks; not directly invokable.
adr-authoring
Defines the canonical MADR format, lifecycle rules, numbering policy, and SAD catalog contract for standalone ADRs under specs/adrs/.
implementation-standards
Reference material with coding standards (defensive coding, error handling, testing patterns). Loaded on demand by the Developer sub-agent (.github/agents/developer.md); not directly invokable.
spec-authoring
Reference material for writing product, technical, and operational specifications (work-item priorities, requirement families, success criteria). Loaded on demand by specify-feature; not directly invokable.