Project Intent

Project Intent

Use this skill before project-docs, create-planner-project, or issue-authoring when the project direction is still fuzzy. It turns scattered ideas into a concise intent packet that future agents can ingest.

Core posture

• Interview first. Do not jump to implementation, Linear project creation, or issue creation while purpose, audience, scope, and current lane are unclear.
• Keep Linear and GitHub as execution sources of truth. This skill owns intent shaping and LLM alignment, not backlog management.
• Prefer one short round at a time. When the user is lost, offer A/B/C options with trade-offs instead of asking broad open-ended questions.
• Keep decisions, assumptions, open questions, and evidence separate.
• Treat build, pause, merge into another project, and kill as equally valid outcomes.

Workflow

1. Scope the session: one new idea, one existing project, or a portfolio triage across many projects.
2. For an existing project, inspect available repo, Linear, GitHub, and prior-context evidence before interviewing. Do not rely only on the user's memory if live state is cheap to check.
3. Read references/interview-playbook.md for the matching interview mode.
4. Run one interview round at a time. Ask at most three questions, or present one A/B/C choice set.
5. After each answer, reflect the working interpretation in two to five bullets and name the uncertainty that remains.
6. Use A/B/C option narrowing whenever the user hesitates, gives multiple directions, or asks what you would do.
7. Stop interviewing when the packet can state: why this should exist, who it serves, current lane, next proof, non-goals, and agent behavior rules.
8. Draft the project intent packet using references/project-intent-packet-template.md.
9. Ask the user to approve, correct, or choose between remaining options before creating durable Linear docs, Linear issues, repo files, or implementation tasks.

A/B/C option rules

• Default to exactly three options: a focused/small path, a balanced/practical path, and an ambitious/high-variance path.
• Give every option a concrete consequence, not just a label.
• Mark one option as recommended only when evidence supports it. Otherwise say what evidence would decide.
• Let the user pick, mix, reject all three, or answer freeform. Do not trap them in the options.
• When the user rejects the options, extract the hidden criterion and make a better option set.

Output contract

The final packet should include:

• One-line intent
• Project type and current status
• Audience or user
• Problem, job, or desire
• Chosen strategy and rejected alternatives
• Scope, non-goals, and taste/principles
• Linear/GitHub/repo source-of-truth links when known
• Next proof or decision gate
• Agent alignment packet: what future LLM sessions should do, avoid, verify, and ask before changing direction
• Open questions and follow-up handoffs

Handoffs

• Use project-docs to turn an approved intent packet into a project brief, customer profile, research brief, decision record, or testing strategy.
• Use create-planner-project only after the intent is committed enough to justify a real Linear planning project.
• Use issue-authoring only after the work can be phrased as executable issues.
• Use repository docs skills when a repo exists and the intent packet needs to become public README flow or private repo hub documentation.