s1-context-bridge

name

s1-context-bridge

description

Create concise, copy-paste-ready bridge prompts between a repo-aware coding agent and an external strategic reasoning agent such as S1 ArchDevAgent. Use when the user wants to offload architecture, research, large refactor planning, migration design, plan critique, implementation-spec drafting, test-strategy design, whole-repo analysis, or diff review to an external agent while keeping repo inspection and implementation in the coding agent. Also use when the user says "use S1", "ask S1", "make a prompt for S1", "bridge this to my external agent", "prepare a context packet", or "validate this S1 response".

S1 Context Bridge

Use this skill to coordinate a manual relay:

coding agent → user → S1/external reasoning agent → user → coding agent

The coding agent owns repo inspection, context compression, implementation, and validation. S1 owns high-token reasoning, research, critique, and artifact generation.

Core workflow

1. Inspect the repository before asking S1.
2. Extract only the context needed to answer the user's goal.
3. Produce a copy-paste-ready prompt for S1.
4. Stop after the prompt and ask the user to paste S1's response back.
5. When S1 responds, validate its assumptions against the repo before implementing.
6. Implement only accepted recommendations.
7. Run relevant tests or checks.
8. Report accepted, modified, and rejected S1 guidance.

Choose the bridge mode

Use one mode:

• DISCOVERY_PACKET: summarize a subsystem or problem area for S1 analysis.
• PLAN_REVIEW_PACKET: ask S1 to critique the coding agent's proposed plan.
• ARTIFACT_REQUEST_PACKET: ask S1 to produce an ADR, PRD, SDS, implementation spec, migration plan, test strategy, or coding-agent prompt.
• DIFF_REVIEW_PACKET: ask S1 to review an existing diff.
• S1_RESPONSE_INTAKE: process S1's response and convert it into repo-validated action.

For packet formats, read references/packet-templates.md.

For response intake and validation rules, read references/intake-rules.md.

Context gathering rules

Before creating an S1 packet:

• Identify relevant files, packages, tests, configs, entrypoints, and dependency edges.
• Prefer summaries, interfaces, type signatures, failing test output, command output, and short snippets.
• Include file paths and why each file matters.
• Include the coding agent's current assessment when useful.
• Include specific questions and a required output format.
• Do not dump the whole repo.
• Do not ask S1 vague questions.

Security rules

Never include:

• API keys, tokens, passwords, private certs, SSH keys, or .env contents.
• Customer data, personal data, production data, or private logs with identifiers.
• Full proprietary files unless the user explicitly approves.
• License-restricted source code.
• Browser history or unrelated local context.

Redact sensitive values from logs and configs. If sensitive context is required, ask the user before creating the packet.

Anti-loop rule

Use at most:

1. one initial S1 packet;
2. one follow-up packet if S1 identifies a real blocker;
3. one diff-review packet after implementation.

Default to shipping a small verified change rather than continuing analysis.

Required handoff sentence

After producing an S1 packet, end with:

"Paste this into S1, then paste S1's response back here. I will validate it against the repo before implementing."