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/ces-ltd/lumi/flow-developnpx skills add CES-Ltd/Lumi --skill flow-developgit clone --depth 1 https://github.com/CES-Ltd/LumiWhat 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.00057 | $0.07294 |
| Opus 5 | $0.00028 | $0.03647 |
| Sonnet 5 | $0.00011 | $0.01459 |
| Haiku 4.5 | $0.00006 | $0.00729 |
Grade A, and why
flow-develop 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 2d 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 — 843 lines — stays where its author put it; the contents beside it link to each section on GitHub.
This file is generated from a template. Edit the
.tmplfile, not this file directly. Runscripts/gen-skill-docs.shto regenerate after changes.
Pre-Development: State Check
Before starting development:
- Read
.octo/STATE.mdto verify Define phase complete - Update STATE.md:
- current_phase: 3
- phase_position: "Development"
- status: "in_progress"
# Verify Define phase is complete
if [[ -f ".octo/STATE.md" ]]; then
define_status=$("${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" get_phase_status 2)
if [[ "$define_status" != "complete" ]]; then
echo "⚠️ Warning: Define phase not marked complete. Consider running definition first."
fi
fi
# Update state for Development phase
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_state \
--phase 3 \
--position "Development" \
--status "in_progress"
⚠️ EXECUTION CONTRACT (MANDATORY - CANNOT SKIP)
This skill uses ENFORCED execution mode. You MUST follow this exact sequence.
STEP 1: Detect Work Context (MANDATORY)
Analyze the user's prompt and project to determine context:
Knowledge Context Indicators:
- Deliverable terms: "PRD", "proposal", "presentation", "report", "strategy document", "business case"
- Business terms: "market entry", "competitive analysis", "stakeholder", "executive summary"
Dev Context Indicators:
- Technical terms: "API", "endpoint", "function", "module", "service", "component"
- Action terms: "implement", "code", "build", "create", "develop" + technical noun
Also check: Does project have package.json, Cargo.toml, etc.? (suggests Dev Context)
Capture context_type = "Dev" or "Knowledge"
Step 1b: Detect Dev Subtype (if Dev context)
When context_type is Dev, determine the subtype to inject domain-appropriate quality guidance into the prompt sent to providers. Append the matching supplement text after the user's prompt.
| Subtype | Trigger keywords | Quality supplement |
|---|---|---|
frontend-ui |
"page", "widget", "component", "UI", "HTML", "CSS", "form", "dashboard", "layout" | See frontend-ui enrichment below. |
cli-tool |
"CLI", "command-line", "terminal", "script", "flag", "argument" | Help text via --help flag. Meaningful exit codes (0 success, 1 user error, 2 system error). Stdin/stdout/stderr used correctly. Argument validation with clear error messages. |
api-service |
"API", "endpoint", "REST", "GraphQL", "gRPC", "server", "route" | Input validation at boundaries. Consistent error response format. Auth/authz on every endpoint. Rate limiting consideration. OpenAPI/schema documentation. |
infra |
"deploy", "terraform", "docker", "CI", "pipeline", "Kubernetes", "helm" | Idempotent operations. Secrets never hardcoded. Rollback path documented. Health checks included. |
data |
"ETL", "pipeline", "migration", "schema", "database", "SQL" | Idempotent migrations. Backup/rollback strategy. Data validation at ingestion. |
general |
Default if no subtype matches | No supplement — use base implementer persona only. |
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.
- 2d ago First seen · 843 lines · 57 tokens per session scan A 65046542408e
flow-develop is a skill published in the GitHub repository CES-Ltd/Lumi (30 stars, last pushed 3mo ago), licensed MIT. It adds 57 tokens to every session and 7,294 once invoked, about $0.0003 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-30.
Other skills, from other repositories
agent-framework-py-release
Use when cutting a Python release for the microsoft/agent-framework monorepo. Triggers on "bump py versions", "cut a python release", "prepare release PR for python", "release py packages", "bump python to X.Y.Z", or similar requests to bump Python package versions and prepare a release PR. Handles all four lifecycle…
python-package-management
Guide for managing packages in the Agent Framework Python monorepo, including creating new connector packages, versioning, and the lazy-loading pattern. Use this when adding, modifying, or releasing packages.
foundry-hosted-agent-validation
Step-by-step process for validating a Python Foundry hosted agent sample (under python/samples/04-hosting/foundry-hosted-agents/) end to end — running it locally (native runtime and azd ai agent run) and after deploying it to an Azure AI Foundry project with azd. Use this when asked to validate a hosted agent sample.
verify-samples-tool
How to use the verify-samples tool to run, verify, and manage sample definitions in the Agent Framework repository. Use this when adding, updating, or running sample verification.
build-and-test
How to build and test .NET projects in the Agent Framework repository. Use this when verifying or testing changes.
python-feature-lifecycle
Guidance for package and feature lifecycle in the Agent Framework Python codebase, including stage meanings, feature-stage decorators, feature enums, and how to move APIs from one stage to the next.