Xpersona
Claim this agent
agentCLAWHUBUnverified

ia-planning

Software implementation planning with optional file-based persistence. Use when asked to plan, when unresolved architecture or scope decisions need a durable record, or when multi-phase implementation needs recovery state. For the full research-and-issue workflow, use the ia-plan command (/ia-plan in Claude Code). Skill: ia-planning Owner: iliaal Summary: Software implementation planning with optional file-based persistence. Use when asked to plan, when unresolved architecture or scope decisions need a durable record, or when multi-phase implementation needs recovery state. For the full research-and-issue workflow, use the ia-plan command (/ia-plan in Claude Code). Tags: latest:5.0.1 Version history: v5.0.1 | 2026-10-03T17:08:

OpenClaw
View on ClawHubHomepage

Rank

62

Safety

84

Downloads

2.6k

Updated

Oct 9, 2026

Version

5.0.1

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 2.6K downloads reported by the source. Last updated 10/9/2026.

Avoid when

  • Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor
Clawhubvendor · observed Oct 9, 2026
Protocol compatibility
OpenClawcompatibility · observed Oct 9, 2026
Adoption signal
2.6K downloadsadoption · observed Oct 9, 2026
Latest release
5.0.1release · observed Oct 3, 2026
Handshake status
UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17bcar8wq0xhegs0ny6f57ypd8484bw:compound-eng-planning
  1. Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
  2. Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-planning/snapshot"

Documentation

CLAWHUB

146,792 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: ia-planning
class: workflow
description: >-
  Software implementation planning with optional file-based persistence. Use
  when asked to plan, when unresolved architecture or scope decisions need a
  durable record, or when multi-phase implementation needs recovery state.
  For the full research-and-issue workflow, use the ia-plan command (/ia-plan
  in Claude Code).
---

# Planning

Produce the smallest plan that reduces implementation risk and preserves state costly to reconstruct. User requirements and verified facts govern the plan; a reference implementation supplies evidence about behavior, not independent authority to change scope.

## Procedure

1. Define the concrete outcome, evidence, binary or quantitative success threshold, scope boundaries, and stop conditions. If the request already names an artifact and success signal, use them. Otherwise repair activity-only goals before planning.
2. Separate the objective from the proposed mechanism: would the goal remain valid if the implementation changed? Ensure a colleague can understand the objective alone and verify it without knowing component internals.
3. Choose a full durable plan for interdependent phases, recovery needs, or work crossing context limits; an inline list for clear work fitting one session; direct implementation for clear scope and acceptance criteria. File and tool-call counts are signals, not triggers. Inspect hidden decisions such as cache TTL, invalidation, and key shape before treating work as simple.
4. Inspect existing tests, canonical commands, related code, and any existing brainstorm specification. Extend repository patterns. Record significant architectural tradeoffs in its ADR convention when needed.
5. Define files, ownership, interface contracts, dependencies, concrete tasks, verification, and exit conditions. Organize phases around runnable capabilities with implementation and tests together. Put high-variance decisions before mechanical work; keep execution dependencies in phase order.
6. Verify the plan against the user's requirements. Keep phase status and next step consistent. Never weaken acceptance criteria to match incomplete code or add speculative checks and machinery.
7. Deliver the plan when planning alone was requested. Continue implementation when already authorized. Ask about execution mode only if it materially changes cost, risk, isolation, or review quality.

## Durable state

For a full working plan, read [plan-format.md](./references/plan-format.md) and scaffold with [init-plan.sh](./scripts/init-plan.sh), anchored to the installed skill directory rather than the caller's working directory. When the project already uses a spec or plan system, keep that system's artifact format; the skill owns the clarification, content, and approval gates, not the representation. Otherwise, use `.plan/task_plan.md` for uncommitted session state and `docs/plans/` for a formal committed plan.

Inspect an existing plan before overwriting it. Contin

_meta.json

{
  "ownerId": "kn715jrbbh71q9zncr0bqdkr8n848q1a",
  "slug": "compound-eng-planning",
  "version": "5.0.1",
  "publishedAt": 1791047331512
}

references/execution-and-methodology.md

# Execution & Decomposition Patterns

Load when decomposing a plan into slices, annotating phases with execution postures, handing an approved plan off to implementation, or specifying behavior against an existing reference implementation.

## Reference Implementations

When an authorized reference implementation embodies target behavior, cite its source to preserve exact semantics and edge cases that a summary may omit. Treat it as evidence subordinate to governing requirements, not a replacement specification; existing bugs do not become requirements merely because the source contains them. Name the file or module and the behavior to match, resolve conflicts against user requirements, and plan to reimplement the *semantics* rather than copy code verbatim, including across languages. Record the pointer so the implementer reads the source: `ref: legacy/pricing.py -> reimplement the specified pricing semantics in src/pricing.ts`.

## Task Decomposition

### Vertical slicing

Decompose by user-visible capability, not by technical layer. "User can log in" is a vertical slice: it touches UI, API, and DB, and delivers a working feature when done. "Build the auth database schema" is a horizontal slice that delivers zero value until other slices complete.

Vertical slices are independently demonstrable and testable. Each slice should produce something a stakeholder can see, try, or verify. When a phase in a plan delivers only one layer (all models, all controllers, all views), restructure it into slices that cut through all layers for one capability at a time.

### Checkpoint system

Pause and verify when completed pieces first cross an integration boundary, before an irreversible transition, and before phase closure. Run the narrowest test or user path that proves the pieces work together. This catches drift without turning task count into a ceremony trigger.

Checkpoints are lightweight: run the test suite, hit the endpoint, render the component. Not a formal review. The goal is a fast feedback signal: "everything built so far integrates correctly." Record a result in `task_plan.md` only when it changes phase state or matters for recovery.

## Execution Posture Signals

Plans can carry lightweight metadata per phase that shapes how `/ia-work` sequences implementation. These are optional annotations, not requirements.

**Default**: tests-after. `/ia-work` writes tests alongside implementation for new features. No posture signal needed in this case.

Opt-in postures for phases that need different sequencing:

- **test-first**: Write failing tests before implementation. Use when behavior is well-defined and testable upfront (bug fixes always qualify; new features qualify when the contract is clear before coding).
- **characterization-first**: Capture existing behavior with tests before changing it. Use when modifying code without existing test coverage.
- **external-delegate**: Mark self-contained units suitable for parallel execution (separate worktree,

references/execution-handoff.md

# execution handoff

## Operational Patterns

Context management rules, error protocol (3-attempt escalation), iterative plan refinement, the 5-question context check, and session-continuity/traceability conventions (numbered outputs, resume protocol, SHA and deviation notes) are in [operational-patterns.md](./operational-patterns.md). Read when starting a multi-phase plan or resuming after a gap.

## Execution Posture Signals

Phases can carry optional metadata that shapes how `/ia-work` sequences implementation. Default is tests-after; opt in per phase via the header (`## Phase 2: Auth middleware [test-first]`): `test-first` (write failing test before implementation), `characterization-first` (capture existing behavior before changing it), `external-delegate` (mark units suitable for parallel/external execution). When to use each is in [execution-and-methodology.md](./execution-and-methodology.md).

## Plan Deepening

When asked to "deepen" or "strengthen" an existing plan, load [plan-deepening.md](./plan-deepening.md): targeted research workflow (additive, not restructuring), per-section enhancement format, and Enhancement Summary block at the plan head. Orchestrated by the `/ia-deepen-plan` command.

## Execution Handoff

When the user requested a plan only, stop after delivering the plan. When the request already authorizes implementation, continue with the simplest execution mode that fits the work. Do not infer execution approval from a prior conversation; approval carries across a session restart only when the durable plan artifact records it. Ask the user to choose between inline and delegated execution only when the choice materially changes cost, risk, isolation, or review quality. Dispatch discipline and portable task-prompt anchoring are in [execution-and-methodology.md](./execution-and-methodology.md).

## Verify

- Plan file exists at `.plan/task_plan.md` (or `docs/plans/` for formal plans)
- All tasks are verb-first and independently verifiable
- File structure and ownership are explicit where they affect integration
- Phase boundaries follow runnable capability and context safety rather than file or task counts
- No placeholder tasks ("implement feature", "add tests"); every task names specific files and patterns
- Each phase delivers end-to-end functionality (not a single horizontal layer)
- Every process item names the capability or observed defect class it gates
- Open questions contain only genuinely blocking unknowns

## Integration

- **Predecessor:** `ia-brainstorming` when requirements are ambiguous; use an existing brainstorm spec (`docs/brainstorms/`) as input and skip idea refinement.
- **Architecture decisions:** record significant trade-offs (chosen approach, what was given up) as an ADR (`/ia-adr` in Claude Code); ADRs outlive the plan.
- **Threat modeling:** obtain a read-only threat-model review before implementation when the plan adds auth flows, payment handling, external API surfaces, or new trust boundaries. U

references/goal-definition.md

# goal definition

## Core Principle

```
Context window = RAM (volatile, limited)
Filesystem     = Disk (persistent, unlimited)
→ Persist only state that would be costly to reconstruct.
```

Planning exists to reduce implementation risk and preserve necessary state. Scale it to unresolved decisions, dependency depth, and continuity needs rather than file count or tool activity alone.

## Procedure

1. Run the *Goal Quality Gate* on the stated goal.
2. Pick the path per *When to Plan*: full plan, flat list, or skip.
3. For a full plan, scaffold `.plan/` via [init-plan.sh](../scripts/init-plan.sh).
4. Write the plan per the [plan template](./plan-format.md#plan-template), applying the quality, sizing, and task rules.
5. Run the [Verify checklist](../SKILL.md#authority-and-verification) against the finished plan.
6. Continue authorized implementation unless [Execution handoff](./execution-handoff.md#execution-handoff) identifies a material choice.

## Goal Quality Gate

Run this gate before *When to Plan* below; a weak goal wastes tokens on any path and produces an unverifiable result. Answer these five questions first:

1. **What concrete thing will be true when this is done?** (named artifact, system state verifiable without knowing the changed component's internals, or user-visible behavior; not "improve X" or "investigate Y")
2. **What evidence will prove it?** (specific test, command, screenshot, metric; not "looks right")
3. **What quantitative or binary threshold defines success?** (p95 < 250ms; `npm run test:checkout` passes; `gh pr view 123` shows no unresolved threads)
4. **What scope boundaries matter?** (which files/modules/environments are in scope; which are explicitly not)
5. **What should cause the agent to stop and ask?** (which decisions belong to the user, not Claude)

Then apply the Means test to the answer to question 1: **if the implementation changed, would this still be the goal?** If not, what was named is a Means, not the Objective. A request that supplies only an approach ("move the retry logic out of the controller into a job") passes all five questions while anchoring the plan to a mechanism, and when the mechanism turns out wrong there is nothing left to re-derive the plan from. Recover the Objective from why the approach was proposed, keep the approach as the current best route, and record it as a decision rather than as the goal. An outcome-shaped Objective can still be a disguised mechanism, so apply the altitude test: could a reader who does not know the changed component's internals tell whether it was met? "X no longer holds the request open while it waits" fails that test; the real Objective is whatever depended on it ("checkout p95 under 300ms").

Apply a standalone-readability test as well: could a colleague who was not in this conversation state the goal from the Objective alone, without reading Scope, Key Decisions, or any later section? If the Objective only makes sense alongside later context, fold that co

Related agents

Same protocol, similar job.

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW
Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.

MCPOPENCLAW
Github ReposUpdated 6mo agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW
Github ReposUpdated 7mo agoRank 70

CopilotKit

The Frontend for Agents & Generative UI. React + Angular

OPENCLAW

Machine-readable data

The same record, as JSON, for agents and crawlers.

{
  "facts": [
    {
      "factKey": "vendor",
      "category": "vendor",
      "label": "Vendor",
      "value": "Clawhub",
      "href": "https://clawhub.ai/iliaal/skills/compound-eng-planning",
      "sourceUrl": "https://clawhub.ai/iliaal/skills/compound-eng-planning",
      "sourceType": "profile",
      "confidence": "medium",
      "observedAt": "2026-10-09T13:32:29.712Z",
      "isPublic": true
    },
    {
      "factKey": "protocols",
      "category": "compatibility",
      "label": "Protocol compatibility",
      "value": "OpenClaw",
      "href": "https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-planning/contract",
      "sourceUrl": "https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-planning/contract",
      "sourceType": "contract",
      "confidence": "medium",
      "observedAt": "2026-10-09T13:32:29.712Z",
      "isPublic": true
    },
    {
      "factKey": "traction",
      "category": "adoption",
      "label": "Adoption signal",
      "value": "2.6K downloads",
      "href": "https://clawhub.ai/iliaal/compound-eng-planning",
      "sourceUrl": "https://clawhub.ai/iliaal/compound-eng-planning",
      "sourceType": "profile",
      "confidence": "medium",
      "observedAt": "2026-10-09T13:32:29.712Z",
      "isPublic": true
    },
    {
      "factKey": "latest_release",
      "category": "release",
      "label": "Latest release",
      "value": "5.0.1",
      "href": "https://clawhub.ai/iliaal/compound-eng-planning",
      "sourceUrl": "https://clawhub.ai/iliaal/compound-eng-planning",
      "sourceType": "release",
      "confidence": "medium",
      "observedAt": "2026-10-03T17:08:51.512Z",
      "isPublic": true
    },
    {
      "factKey": "handshake_status",
      "category": "security",
      "label": "Handshake status",
      "value": "UNKNOWN",
      "href": "https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-planning/trust",
      "sourceUrl": "https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-planning/trust",
      "sourceType": "trust",
      "confidence": "medium",
      "observedAt": null,
      "isPublic": true
    }
  ],
  "events": [
    {
      "eventType": "release",
      "title": "Release 5.0.1",
      "description": "v5.0.1",
      "href": "https://clawhub.ai/iliaal/compound-eng-planning",
      "sourceUrl": "https://clawhub.ai/iliaal/compound-eng-planning",
      "sourceType": "release",
      "confidence": "medium",
      "observedAt": "2026-10-03T17:08:51.512Z",
      "isPublic": true
    }
  ]
}

Record generated Oct 9, 2026.

Sponsored

Ads related to ia-planning and adjacent AI workflows.