agentleFS
ric03uecric03uec/clawrium/.claude/skills/itx-plan-create/SKILL.md

itx-plan-create

Skill67 starsChanged 2 months agoApache-2.0View on GitHub

Create high-level implementation plan with product output and technical details

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Create a high-level implementation plan for a GitHub issue with product output and technical details.

    line 9
  2. Distinctive:

    Check for existing tests

    line 21
  3. Distinctive:

    Post Plan: Add plan as comment on parent issue

    line 67
  4. Distinctive:

    Use expensive models (Opus/Sonnet) for planning - this is where thinking matters

    line 122

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Implementation Planning (Create Phase)

Create a high-level implementation plan for a GitHub issue with product output and technical details.

Instructions

  1. Fetch Issue: Get full issue details
    gh issue view <number> --json number,title,body,labels,comments
  2. Explore Codebase: Understand the scope
    • Identify affected files and modules
    • Review related code patterns
    • Check for existing tests
    • Note any dependencies
  3. Create Plan: Structure the implementation approach
    • Break down into logical steps
    • Identify files to modify/create
    • Define test strategy
    • Note potential risks
  4. Save Plan to File:
    mkdir -p .itx/<number>
    # Write plan to .itx/<number>/00_PLAN.md
  5. Decide on Subtasks:
    • Simple issue (< 3 files, single concern): No subtasks needed
    • Complex issue (multiple files, multiple concerns): Create subtasks
  6. If Subtasks Needed: Detect repository info and create subtask issues with sub-issue links
    # Extract repository info
    REMOTE_URL=$(git config --get remote.origin.url)
    OWNER_REPO=$(echo "$REMOTE_URL" | sed -E 's/.*[:/]([^/]+\/[^/]+)(\.git)?$/\1/')
    OWNER=$(echo "$OWNER_REPO" | cut -d'/' -f1)
    REPO=$(echo "$OWNER_REPO" | cut -d'/' -f2)
    
    # Create subtask
    CHILD_URL=$(gh issue create \
      --title "[Parent #<parent>] <subtask description>" \
      --label "ready" \
      --body "<subtask details>")
    CHILD_NUM=$(basename $CHILD_URL)
    
    # Link as sub-issue using GraphQL with dynamic repo
    gh api graphql -f query='
      mutation($parentId: ID!, $childId: ID!) {
        addSubIssue(input: {issueId: $parentId, subIssueId: $childId}) {
          issue { number }
          subIssue { number }
        }
      }' \
      -f parentId=$(gh api graphql -f query='query($owner: String!, $repo: String!, $issue: Int!) { repository(owner: $owner, name: $repo) { issue(number: $issue) { id } } }' -f owner="$OWNER" -f repo="$REPO" -F issue=$PARENT_NUM | jq -r '.data.repository.issue.id') \
      -f childId=$(gh api graphql -f query='query($owner: String!, $repo: String!, $issue: Int!) { repository(owner: $owner, name: $repo) { issue(number: $issue) { id } } }' -f owner="$OWNER" -f repo="$REPO" -F issue=$CHILD_NUM | jq -r '.data.repository.issue.id')
  7. Post Plan: Add plan as comment on parent issue

    ## Implementation Plan
    
    ### Overview
    <brief description of approach>
    
    ### Files to Modify
    - `path/to/file.py` - <what changes>
    
    ### Steps
    1. <step>
    2. <step>
    
    ### Test Strategy
    - <how to verify>
    
    ### Subtasks
    - #<subtask1> - <description>
    - #<subtask2> - <description>
    (or "None - single task execution")
    
    ---
    
    <details>
    <summary>Prompt Log</summary>
    
    **Stage**: planning
    **Skill**: /itx-plan-create
    **Timestamp**: <ISO timestamp>
    **Model**: <model>
    
    ```prompt
    <original user prompt that triggered planning>
    </details> ```
  8. Update Labels:
    gh issue edit <number> --remove-label "planning" --add-label "planned"
  9. Return: Plan summary and any subtask issue numbers

Subtask Guidelines

  • Each subtask should be independently executable
  • Subtasks should have clear boundaries
  • Order subtasks by dependency (execute first -> last)
  • Subtask title format: [Parent #N] <action verb> <target>

Notes

  • Use expensive models (Opus/Sonnet) for planning - this is where thinking matters
  • Execution can use cheaper models (Haiku)
  • Plans should be detailed enough that any developer can execute
  • Plan file saved to .itx/<N>/00_PLAN.md for reference

Prompt Logging

REQUIRED: Append prompt log to .itx/<N>/00_PLAN.md.

See AGENTS.md for format specification.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.