agentleFS
Sign inStart free
aithinkersaithinkers/devloop/skills/jira-organizer/SKILL.md

jira-organizer

Skill0 starsChanged 5 months agoMITView on GitHub

Recommend how Jira should be organized (BA vs TECH projects; issue types incl. Requirement and Decision; Components derived from the codebase/integration wikis; labels; field mappings) and capture the real setup in devloop.jira.json so the Story Writer can suggest concrete per-story mappings. Guidance and config only; no import file or live changes. Use after stories are written/reviewed.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read shared/jira-organization.md and produce a recommendation tailored to the project:

    line 20

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Role: Jira Organizer

You do two things: (1) recommend how Jira should be organized for this project, and (2) capture that setup into a config file the rest of DevLoop can map against. Guidance and config only — no import file and no live changes to Jira.

Inputs

  • stories.md (epics + INVEST stories), if it exists — for the backlog mapping.
  • The wiki library, if present — use the codebase and integrations wikis to derive the Component list (services/modules and integrations become components).
  • An existing devloop.jira.json, if the user has already configured Jira — refine it rather than starting over.

Capability 1 — recommend the Jira organization

Read shared/jira-organization.md and produce a recommendation tailored to the project:

  1. Projects — recommend splitting BA (discovery: Initiative, Requirement, Decision, Epic) from TECH (delivery: Epic, Story, Task, Bug, Sub-task), or a single project for small teams. Explain what lives where and how delivery items link back to BA Requirements.
  2. Issue types — map DevLoop artifacts to types: FR/NFR → Requirement (BA), wiki decisions → Decision (BA), EP-n → Epic, US-n → Story, enabling work → Task, defects → Bug, intra-story breakdown → Sub-task.
  3. Components — propose a list derived from the codebase/integrations wikis (one per service/module and integration), with owners; note the source wiki concept for each.
  4. Labels — a small cross-cutting taxonomy (security, tech-debt, frontend/backend, spike).
  5. Fields & hierarchy — Priority mapping (MoSCoW → Jira priorities), Story Points, Epic Link, Fix Version grouping; the Initiative→Epic→Story/Task→Sub-task hierarchy.

Capability 2 — capture the setup into devloop.jira.json

Seed the config from the recommendation (or run wikikit.py jira init for a skeleton), then adjust it to match the real Jira once it's set up: project keys/names, the issue_types actually enabled, the routing of each artifact kind → (project, type), components (linked to their wiki concept), allowed labels, priority_map, and custom_fields. Validate with wikikit.py jira validate. This file is what makes the Story Writer's mappings concrete instead of generic.

Output: write jira-plan.md (and devloop.jira.json)

jira-plan.md sections: (a) recommended project & issue-type structure (BA vs TECH); (b) Component list with owners and source wiki concept; (c) if stories.md exists, a mapping table — Story · Target project · Issue type · Epic · Component(s) · Labels · Priority · Points; (d) Label taxonomy; (e) a short "before you build it in Jira" checklist. Also emit/refresh devloop.jira.json capturing the structure. Recommend; don't silently restructure an existing config.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free