own-planner: Skill for Codex

Develop an OwnPlanner Feature

Execute an issue-driven feature as a traceable sequence: intake, plan, plan review, implementation, verification, and handoff. Touch only the layers required by the behavior.

Treat the Issue as the Contract

• Treat the repository issue as the canonical record of the outcome, acceptance criteria, discussion, and implementation history.
• Treat GitHub Project fields such as Status, Priority, Size, and Iteration as planning context, not as a duplicate feature specification.
• Follow parent issues, sub-issues, dependencies, linked plans, ADRs, and prior pull requests when they affect scope.
• Use a Project draft only for discovery. Ask the user to convert it to a repository issue before creating a branch or pull request that must close it.
• If given a direct request instead of an issue, form a temporary feature contract from the request. Do not create an issue or modify GitHub state unless the user authorizes it.

Follow the Required Workflow

1. Read the Issue and Repository State

1. Read the root and applicable scoped AGENTS.md files.
2. Inspect the worktree, current branch, and relationship to master. Preserve unrelated user changes.
3. Read the issue, including comments and relationships. Prefer gh issue view <number-or-url> --comments when GitHub CLI access is available.
4. Extract:
   • user-visible outcome;
   • acceptance criteria and edge cases;
   • explicit exclusions;
   • priority and planning context;
   • dependencies and blockers;
   • unresolved product or technical decisions.
5. Decide whether the issue is ready. Record harmless assumptions. Pause for user direction only when ambiguity would materially change behavior, public contracts, stored data, security, or scope.

Do not silently edit the issue, Project fields, relationships, or comments. External planning changes require authorization.

2. Explore Existing Patterns

1. Find the closest implemented feature and its tests.
2. Inspect relevant reference docs and ADRs before proposing a new abstraction.
3. Reuse existing naming, folders, DTOs, errors, authentication, tenant resolution, and test patterns.
4. Read references/feature-paths.md for every potentially affected delivery or persistence path.