/before-you-start

name: "before-you-start"
description: "Before starting an idea, plan or project, find who in the organisation is already doing, or has done, something similar, using Teamwork Graph across Projects, Jira, Confluence and connected tools. Answers in the conversation first with up to 4 efforts: each one's recorded owner, linked evidence kept apart from search findings, overlap class and recommended move (Talk, Join, Differentiate or Reuse) with its reason. Offers the existing HTML report on request and publication only when Atlassian Artifacts is available and requested. Use for whether anyone is already working on something, whether it has been tried, who else is building it, duplication checks, or /before-you-start. For who to ask, use whos-the-expert. For dependencies, use dependency-map."

Before you start

Give someone an answer in the conversation that they can read in two minutes before committing time to an idea: which other efforts in the organisation already do, or did, something like it, who owns each one, how close each is, and what to do about it. It's for the person about to start, so they can talk to the right people first, join work that's already moving, draw a line between their work and someone else's, or reuse what was built.

Nothing in Projects, Jira or Confluence links an effort to the other efforts like it. Two teams can build the same thing under different names for months, and a project cancelled last quarter leaves no trace in the next team's plan. The value of this skill is the judgement a project directory or a search results page can't make: it finds efforts named differently from the idea, reads what each one actually does rather than what it's called, sorts them into a fixed set of overlap classes, and turns each into one move with an owner to contact.

Load the `teamwork-graph-context` skill first and follow it for gathering context, labelling sources, keeping sensitive content out and optional publishing. Its "Searching" and "Sensitive content" sections matter most here. This file adds what's specific to finding similar efforts.

This skill selects "Answer-first delivery" in `teamwork-graph-context`: gather and assess, answer in the conversation, then ask whether the user wants an HTML report. Do not write report data, run a renderer or create an artifact unless the user requests an export, HTML report or publication. Use the existing report layout only for that optional export. Offer Atlassian Artifacts publication only after confirming availability; exporting does not authorise publishing.

What this skill will and won't do

• **It answers "is anyone already doing this?"** The input is always an idea, a plan or a project. People appear only as the owners and contributors of an effort, as its records name them.
• **It never judges an effort or its people.** Classes say how close an effort is to the idea, not whether it's good. Don't say an effort failed, stalled or was abandoned unless a person wrote that in its record. Never rank or describe owners by seniority.
• **It leaves out the user's own work.** The user is never shown as an effort's owner, and the user's own items are dropped (see Step 3).
• **Who's asking doesn't change the card.** Call `atlassianUserInfo` once, only to recognise the user's own work. Make no manager or reporting-line lookups: don't call `getPeopleInfo` with `manager` or `directReports`, and don't use `getWorkPortfolio` or `getCollaborators`, which describe people rather than an idea.
• **It doesn't decide for the user.** The move is a recommendation from the records, labelled "Suggested". The user decides whether to start.

Connectors

• **Needed:** Projects or Jira, at least one, for efforts with owners and status. Confluence, for the plans, designs and retrospectives that say what an effort does. With neither Projects nor Jira on the site (see "Atlassian apps on the site" in `teamwork-graph-context`), say so before building: efforts can only come from docs and chat, and owners from authors.
• **Helpful, from Atlassian:** Loom, for demos of work already built. Bitbucket, for repositories and pull requests. Goals, for the goal an effort contributes to. Compass, for internal tools registered as components.
• **Helpful, from other tools:** Slack or Teams, where efforts are often announced or discussed before they have a record. Google Drive or SharePoint, for plans and decks. GitHub or GitLab, for prototypes and internal tools.
• **Vendor connectors,** as `teamwork-graph-context` describes: Slack or Teams, to read a public channel thread when an effort's only owner signal is a snippet. GitHub, to read a repository's README or pull request author when the graph returns it empty (`raw: {}`). Never read direct or group messages through them.

Budget

Unless the user asks for a deeper pass, stay within these, and say in the footer if one was reached:

| Tool | Cap | Where | | --- | --- | --- | | `searchProjects` (through `discover` and `executeRead`) | 4 | 2 in Step 2, 2 in Step 4 | | `search` | 6 | 4 in Step 2, 2 in Step 4 | | JQL (`searchJiraIssuesUsingJql`) | 2 | 1 in Step 2, 1 in Step 5 | | `getGraphContext` | 4 | Step 5, one `full` call per top effort | | Product reads | 8 calls | Step 5: `getProject`, `getConfluenceContent`, `getLoomVideo`, a code or README read, and `getGraphObject` (one batched call counts as one) | | `getPeopleInfo` | 2 | Step 6, batches of up to 10 account IDs | | `listArtifacts` | 1 | Step 1, the user's own Artifacts |

`search`, `getGraphContext` and `getPeopleInfo` use Rovo credits. A typical run makes 22 to 30 calls, including one `discover` for each operation reached through `executeRead`.

Calls in the same step that don't depend on each other go out together, as "Fetch in parallel" in `teamwork-graph-context` describes: the whole sweep in Step 2, the echo pass in Step 4, and the reads in Step 5. Send at most 4 `getProject` calls at once: on real data a read straight after a batch of 7