poseidon-plan

poseidon-plan

Local, in-session port of the Poseidon issue-plan agent. It does not ship a copy of the Poseidon instructions — it fetches them live from a8cteam51/poseidon-actions@trunk every run, so you always match the deployed version. It then follows those instructions with a thin set of local overrides, running on the model you've selected with no turn cap.

Inputs

$ARGUMENTS, one of:

• 45 — issue #45 in the current directory's repo.
• a8cteam51/some-repo 45 — explicit repo + issue.
• Optionally append site:<blog-id> to pass the production WordPress Blog ID for MCP site lookups (e.g. site:212289766).

Requires gh authenticated with access to a8cteam51/poseidon-actions (to fetch the instructions) and to the target repo (to read the issue and post the plan). For site-specific tickets, the team51 MCP server.

How it runs

1. Resolve OWNER/REPO, issue number N, and optional Blog ID from $ARGUMENTS (bare N → gh repo view --json nameWithOwner -q .nameWithOwner).

2. Fetch the live upstream instructions:

   mkdir -p /tmp/poseidon
   gh api repos/a8cteam51/poseidon-actions/contents/issue-plan/action.yml \
     -H "Accept: application/vnd.github.raw" > /tmp/poseidon/issue-plan.action.yml
   

   If this fails (e.g. 404 / no access to the private repo), STOP and tell the user — do not fall back to remembered or guessed instructions.

3. Read /tmp/poseidon/issue-plan.action.yml. The Run Claude Code step carries TWO instruction blocks — extract and follow BOTH:

   • the prompt: input — the task itself (issue framing, comments pointer, Blog ID guidance);
   • the --append-system-prompt "<PROMPT>" value inside claude_args — your authoritative operating contract. Read both in full and follow them exactly, with the local overrides below. You are NOT executing the YAML's steps; you only extract and follow those two embedded prompts. If the fetched file no longer matches this layout, find the embedded prompts wherever they now live, follow them, and tell the user the upstream layout changed.