Source profileQuality 90/100

boshu2/agentops/skills/plan/SKILL.md

plan

Shape or refine the existing bead or caller intent without a second planning artifact. Triggers: "plan", "discover and plan", "shape this goal", "plan manifest".

Source repository stars
416
Declared platforms
0
Static risk flags
0
Last source update
2026-08-05
Source checked
2026-08-05

Decision brief

What it does—and where it fits

Turn the caller's intent into one bounded, testable behavior in the place that already owns the work. Prefer the caller's tracker, if any. When no tracker is available, use the caller's conversation or supplied issue text; the runtime snapshots the resolved intent bytes automati…

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/boshu2/agentops --skill "skills/plan"
    Safe inspection promptEditorial

    Inspect the Agent Skill "plan" from https://github.com/boshu2/agentops/blob/c0f78fddd95ab30f8adadc5e513e27064980a529/skills/plan/SKILL.md at commit c0f78fddd95ab30f8adadc5e513e27064980a529. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      Workflow

      1. Resolve the intent source and choose one active behavior. When that source is not already durable, have the runtime pass its exact bytes to the validate skill's scripts/validate.py snapshot-intent --source -, resolved relative to wherever that skill package is installed (a re…

      Resolve the intent source and choose one active behavior. When that sourceRoute the work by type (see Ground-truth routing) and name its groundEnsure the source contains acceptance examples, important non-goals, and the
    2. 02

      Manifest mode (many behaviors, zero beads)

      When the caller's goal genuinely decomposes into several bounded behaviors — an audit remediation, an epic, a contraction — shape one caller-owned specification manifest instead of one behavior:

      One document in the caller's location (commonly docs/plans/-.md)Tracker IDs stay TBD: manifest mode authors zero beads. The executingReference example:
    3. 03

      Scope admission

      In a repository with generated projections, write scope names generator-owned outputs as a class — the hand-edited sources plus all outputs of the owning regen commands — never as a hand-enumerated path list. Hand enumeration is falsified the first time a regen command rewrites…

      In a repository with generated projections, write scope names generator-owned outputs as a class — the hand-edited sources plus all outputs of the owning regen commands — never as a hand-enumerated path list. Hand enume…Before freezing acceptance, run a complexity admission: enumerate the generated companions, parity twins (for example a skills-codex/ mirror), and test files that assert on the paths being changed. Anything this pass fi…
    4. 04

      Ground-truth routing

      Every plan needs a ground truth outside the planner's own reasoning. Before freezing acceptance, classify the work and name its ground truth, its control experiment, and its deviation ledger from the row below.

      Every plan needs a ground truth outside the planner's own reasoning. Before freezing acceptance, classify the work and name its ground truth, its control experiment, and its deviation ledger from the row below.The Extend row is already the repo's default discipline: behavior-first acceptance, RED - GREEN, the smallest real change. The Integrate row is the one that is cheap to skip and expensive to have skipped — run the stock…Trigger: the Integrate-row mechanics — the stock-quickstart control run and the deviation ledger from the documented flow — apply only to integration-class work (adopting or wiring in an external substrate, runtime, tra…

    Permission review

    Static risk signals and limitations

    No configured static risk pattern was detected

    This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score90/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars416SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    boshu2/agentops
    Skill path
    skills/plan/SKILL.md
    Commit
    c0f78fddd95ab30f8adadc5e513e27064980a529
    License
    Apache-2.0
    Collected
    2026-08-05
    Default branch
    main
    View the original SKILL.md

    Plan

    Turn the caller's intent into one bounded, testable behavior in the place that already owns the work. Prefer the caller's tracker, if any. When no tracker is available, use the caller's conversation or supplied issue text; the runtime snapshots the resolved intent bytes automatically so later contexts can read and hash the same source. Do not make the model restate those facts in a packet.

    Workflow

    1. Resolve the intent source and choose one active behavior. When that source is not already durable, have the runtime pass its exact bytes to the validate skill's scripts/validate.py snapshot-intent --source -, resolved relative to wherever that skill package is installed (a repo checkout: skills/validate/scripts/validate.py; an installed skill package: .agents/skills/validate/scripts/validate.py), and use the returned intent_ref for later phases.
    2. Route the work by type (see Ground-truth routing) and name its ground truth first. Then inspect only enough real context to make paths, interfaces, and evidence concrete. Existing research and specialist skills are advisory inputs.
    3. Ensure the source contains acceptance examples, important non-goals, and the allowed write scope. Use lightweight prose or Given/When/Then only where it removes ambiguity; do not require both normal and edge ceremony for every change.
    4. Name the first useful acceptance check.
    5. If authorized and the source is writable, update that bead or issue in place. Otherwise return a concise proposed amendment to the caller.

    Planning produces no AgentOps packet. The runtime stores and hashes the resolved source bytes to detect later acceptance drift. That content-addressed snapshot is derived automatically and is not another model-authored planning artifact.

    Bound the work around the caller-visible outcome, not individual files, gates, or reviewer comments. Decomposition is useful only when it reduces reasoning cost; it must not multiply invocations or proof artifacts.

    Manifest mode (many behaviors, zero beads)

    When the caller's goal genuinely decomposes into several bounded behaviors — an audit remediation, an epic, a contraction — shape one caller-owned specification manifest instead of one behavior:

    • One document in the caller's location (commonly docs/plans/<date>-<slug>.md) holding a manifest table (stable slug, type, priority, parent, dependency edges) plus one section per child with acceptance, non-goals, write scope, and evidence commands. Each child must satisfy the same bar as a single-behavior plan.
    • Tracker IDs stay TBD: manifest mode authors zero beads. The executing substrate materializes tracker state — the caller's session in the default loop, or the selected factory's coordinator (for Gas City the Mayor, per using-gc; for the Flywheel, its native workflow per using-flywheel).
    • Reference example: 2026-07-30-ponytail-whole-repo-contraction.md.

    Scope admission

    In a repository with generated projections, write scope names generator-owned outputs as a class — the hand-edited sources plus all outputs of the owning regen commands — never as a hand-enumerated path list. Hand enumeration is falsified the first time a regen command rewrites a companion the author did not list: the 2026-07-15 heal-skill fold burned two implement lanes and three intent revisions (.agents/ao/intents/sha256/d1db59d4...2b81 superseded by f5fd7c3c...af75 superseded by 26a4f2be...eb48) before scope was restated as a class.

    Before freezing acceptance, run a complexity admission: enumerate the generated companions, parity twins (for example a skills-codex/ mirror), and test files that assert on the paths being changed. Anything this pass finds that the scope does not admit will surface later as an out-of-scope diff or a broken gate.

    Ground-truth routing

    Every plan needs a ground truth outside the planner's own reasoning. Before freezing acceptance, classify the work and name its ground truth, its control experiment, and its deviation ledger from the row below.

    Work typeGround truthControl experimentDeviation ledger
    Integrate an external substrate, runtime, tracker, or servicethe vendor's own docs plus stock behaviorrun their vanilla quickstart on pinned versions with zero local code, before designingeach deviation from the documented flow, each justified; and every component you write that has a native counterpart in the substrate
    Extend this projectthe repo's existing patterns and behavior specthe simplest version that satisfies acceptance, and why it is insufficienteach novelty introduced — new abstraction, dependency, or pattern
    Greenfieldreference experience and domain prior arta walking skeletoneach deviation from the boring default, ~one novelty per change

    The Extend row is already the repo's default discipline: behavior-first acceptance, RED -> GREEN, the smallest real change. The Integrate row is the one that is cheap to skip and expensive to have skipped — run the stock control experiment before you design, or you will re-plumb what the substrate already documents and inherit bugs you built yourself.

    Trigger: the Integrate-row mechanics — the stock-quickstart control run and the deviation ledger from the documented flow — apply only to integration-class work (adopting or wiring in an external substrate, runtime, tracker, or service). Routine feature work on this project uses the Extend row and does not incur them.

    A plan is done only when it passes the fresh-context test: a cold context, given the intent source alone, could execute it without the author's conversation. If execution needs facts that live only in the planning conversation, move them into the source before freezing.

    Alternatives

    Compare before choosing

    Computed 9225

    xoai/sage

    plan

    Creates implementation plans from specifications by breaking work into small tasks (2-5 min each) with exact file paths, tests, and dependency ordering. Use after a spec is approved and before implementation begins, or when the user says "create a plan", "break this down", "how should we build this", or "task breakdown".

    Computed 8714

    eltmon/overdeck

    plan

    Opus-driven planning for issues before Sonnet implementation. Creates workspace, .pan/continue.json, .pan/spec.vbrief.json with xBRIEF tasks, and updates issue tracker. Ensures strategic decisions are made by Opus, not cheaper models.

    Computed 10023,835

    alirezarezvani/claude-skills

    app-store-optimization

    App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist

    Computed 10014,533

    prowler-cloud/prowler

    postgresql-indexing

    PostgreSQL indexing best practices for Prowler: index design, partial indexes, partitioned table indexing, EXPLAIN ANALYZE validation, concurrent operations, monitoring, and maintenance. Trigger: When creating or modifying PostgreSQL indexes, analyzing query performance with EXPLAIN, debugging slow queries, reviewing index usage statistics, reindexing, dropping indexes, or working with partitioned table indexes. Also trigger when discussing index strategies, partial indexes, or index maintenance