itx-plan-create
Skill67 starsChanged 2 months agoApache-2.0View on GitHub
Create high-level implementation plan with product output and technical details
In this repository26 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- clawctl-lmworkSkill
- clawctlSkill
- clawctl-uatSkill
- create-playwrightSkill
- create-vhsSkill
- itx-bug-newSkill
- itx-bug-updateSkill
- itx-executeSkill
- itx-issue-newSkill
- itx-issue-updateSkill
- itx-noteSkill
- itx-plan-scaffoldSkill
- itx-pr-statusSkill
- itx-releaseSkill
- itx-review-prSkill
- itx-triageSkill
- itx-verifySkill
- sync-upstreamSkill
- tddSkill
- blog-authorSkill
- daily-digestSkill
- docs-syncSkill
- issue-triageSkill
- release-watcherSkill
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
- Distinctive: line 9
Create a high-level implementation plan for a GitHub issue with product output and technical details.
- Distinctive: line 21
Check for existing tests
- Distinctive: line 67
Post Plan: Add plan as comment on parent issue
- Distinctive: line 122
Use expensive models (Opus/Sonnet) for planning - this is where thinking matters
≈ “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.
Files
Implementation Planning (Create Phase)
Create a high-level implementation plan for a GitHub issue with product output and technical details.
Instructions
- Fetch Issue: Get full issue details
gh issue view <number> --json number,title,body,labels,comments - Explore Codebase: Understand the scope
- Identify affected files and modules
- Review related code patterns
- Check for existing tests
- Note any dependencies
- Create Plan: Structure the implementation approach
- Break down into logical steps
- Identify files to modify/create
- Define test strategy
- Note potential risks
- Save Plan to File:
mkdir -p .itx/<number> # Write plan to .itx/<number>/00_PLAN.md - Decide on Subtasks:
- Simple issue (< 3 files, single concern): No subtasks needed
- Complex issue (multiple files, multiple concerns): Create subtasks
- 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') 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> ```- Update Labels:
gh issue edit <number> --remove-label "planning" --add-label "planned" - 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.mdfor reference
Prompt Logging
REQUIRED: Append prompt log to .itx/<N>/00_PLAN.md.
See AGENTS.md for format specification.
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
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.

